Valery Smyslov writes: > Traditionally, IPsec specifications contain very few quantitatives > concerning various timings. This is due to the belief that concrete > timeouts don't affect interoperability. Instead, some very generic > recommendations are usually given. See for example Section 2.4 of > RFC 7296: > > The number of retries and length of timeouts are not covered in this > specification because they do not affect interoperability. It is > suggested that messages be retransmitted at least a dozen times over > a period of at least several minutes before giving up on an SA, but > different environments may require different rules.
The reason why we do not give quantitative timings is that they differ so much depending on the environment. In the site to site VPN the initial retransmission timer of 500 ms and then doubling from there up to 4 seconds and then timing out after 30 seconds is fine. On road warrior VPN users in the hotel network where first packet exchange might actually trigger login to hotel network or similar requiring password needs much longer timers. Then when using EAP where users might actually need to type in password, pin codes or similar requires even longer timers (usually 10 times longer timers than for site to site VPN cases). Also when using mobike the timers needed are also much longer, as it usually takes some time to detect that packets do not go through using old interface, and then in some cases switching to another interface (i.e. 4g or similar), might require bringing that interface up and only after that it can even try to connect through that new interface. In implemenations using mobike, the timers are also about 10 times longer than when using site to site vpn (i.e., the exchange will expire only after 5 minutes or so). > What WG members think about these values? I would still leave out the values, and just use vague recommendations. That causes the implementor to actually think himself in which kind of environment the implementation is aimed for and adjust timers accordingly (and usually also make those timers to be configurable, i.e., implementor usually just set defaults). > > ** 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: > > Yes. Actually the RFC8019 puzzles requires that IKEv2 Cookies are used, as the puzzle solution is PRF calculations over the IKEv2 cookie. > > > ** 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)? > > I don't think this is needed. The new recommendations are only > applicable in the context of TCP encapsulation, so all old > implementations remain compliant with RFC 7296. I do not think we had this discussion in the working group, but I agree with Valery, that I do not think this document updates RFC 7296 in any way that would affect any implementations not using TCP encapsulation, thus if someone implements RFC 7296 and does not implement TCP they do not need to read this document, as this does not offer anything useful for them. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
