Hi!
I performed a AD review of draft-ietf-ipsecme-rfc8229bis-05. Thanks for
revising RFC8229 with this new guidance. Comments are below:
** The abstract notes that many of the document updates came from deployment
experience. I'm hoping to incorporate that feedback on a particular issue.
There are a number places in this document where qualitative recommendations
are made about various network stack timers. Can quantitative recommendations
be made in any of the following:
-- Section 7.1 "If the TCP connection is no more associated with any active
IKE SA, the TCP Responder MAY close the connection to clean up resources if TCP
Originator didn't close it within some reasonable period of time."
-- Section 7.4. "In particular, it is advised that the Initiator should not act
immediately after receiving error notification and should instead wait some
time for valid response, ..."
-- Section 8.1. "If no response is received within a certain period of time
after several retransmissions ..."
-- Section 8.4. "For the client, the cluster failover event may remain
undetected for long time if it has no IKE or ESP traffic to send. "
-- Section 8.4. "if support for High Availability in IKEv2 is negotiated and
TCP transport is used, a client that is a TCP Originator SHOULD periodically
send IKEv2 messages (e.g. by initiating liveness check exchange) whenever there
is no IKEv2 or ESP traffic."
The only place I found quantitative guidance was in Section 7.3.1.
** Section 6.1. Editorial. s/with new Initiators's SPI/with the Initiator's
new SPI/
** Section 7.1 Editorial.
OLD
If the TCP connection is no more
associated
NEW
If the TCP connection is no longer associated
** Section 7.3 Should something be said about the utility of mixing both SYN
Cookies and IKEv2 Cookies?
** Section 7.3
* the exchange Responder SHOULD NOT request a Cookie, with the
exception of Puzzles or in rare cases like preventing TCP Sequence
Number attacks.
I'm having trouble following this guidance. Is this saying "you SHOULD NOT
send IKEv2 Cookies without Puzzles?". If so, is this the intent:
The exchange Responder SHOULD NOT request a IKEv2 Cookie without a Puzzle,
unless mitigation against only TCP Sequence Number attacks is desired?
** Section 7.3. Typo. s/change change/change/
** Section 7.6
... TCP keep-alives [RFC1122] and TLS keep-alives [RFC6520]
may be used
Should this be "... MAY be used"?
** Section 7.7. Editorial. s/Besides, TCP encapsulation/TCP encapsulation/
** Section 8.3. Typo. s/incative/inactive/
** Section 8.4.
This document makes the following recommendation: if support for High
Availability in IKEv2 is negotiated and TCP transport is used, a
client that is a TCP Originator SHOULD periodically send IKEv2
messages (e.g. by initiating liveness check exchange) whenever there
is no IKEv2 or ESP traffic. This differs from the recommendations
given in Section 2.4 of [RFC7296] in the following: the liveness
check should be periodically performed even if the client has nothing
to send over ESP. The frequency of sending such messages should be
high enough to allow quick detection and restoring of broken TCP
connection.
-- Due to the change in behavior being suggested to RFC7296, did the WG discuss
this document formally updating it (RFC7296)?
-- Consider using a more precise term that "TCP Originator"
** Appendix A. Would there be a reason not to reference a recommended
conformance to RFC7525 or draft-ietf-uta-rfc7525bis for TLS connections?
Regards,
Roman
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
