Subject: [IPsec] ESN question regarding wording in 4304

From: Paul Wouters <[email-masked]>
Date: Wed, 20 Jan 2016 19:27:40 -0500 (EST)

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Jan 2016 06:47:36 +0200

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 <[email-masked]> wrote:
> 
> 
> 
> RFC-4304 states:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec