Hi, Paul At some point there was talk of allowing people to omit the ESN attribute from the SA payload, and that would mean “ESN yes only”. That was not in the final 4306, but apparently a trace of this remains in 4304.
As for what my implementation does, we send only “ESN no” and accept only “ESN no”. Yoav > On 21 Jan 2016, at 2:27 AM, Paul Wouters <p...@nohats.ca> wrote: > > > > RFC-4304 states: > > 2.2.1. Extended (64-bit) Sequence Number > > To support high-speed IPsec implementations, Extended Sequence > Numbers (ESNs) SHOULD be implemented, as an extension to the current, > 32-bit sequence number field. Use of an ESN MUST be negotiated by an > SA management protocol. Note that in IKEv2, this negotiation is > implicit; the default is ESN unless 32-bit sequence numbers are > explicitly negotiated. (The ESN feature is applicable to multicast > as well as unicast SAs.) > > RFC-7296 states: > > Note that an initiator who supports ESNs will usually include two ESN > transforms, with values "0" and "1", in its proposals. A proposal > containing a single ESN transform with value "1" means that using > normal (non-extended) sequence numbers is not acceptable. > > > I'm a little confused about the word "default" in 4304. All proposals > must have an ESN transform type, which can contain 0, 1 or 2 payloads, > referring to "NO ESN" (0), "YES ESN" (1) or both. > > I could read this to mean, the default should be "YES ESN" only? But I > could also read this as "you should allow YES and NO but as responder, > when given the choice, choose YES". > > I'm wondering what other implementations do (and prefer) > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
