On Mon, Dec 02, 2024 at 05:31:00AM +0200, Tero Kivinen wrote: > Valery Smyslov writes: > > Hi Antony, > > Combining with the proposal above: > > > > Number Name Reference > > 0 32-bit Sequential Numbers (SN) [RFC7296] [this ID] > > 1 64-bit Sequential Numbers (ESN) [RFC7296] [this ID] > > 2 32-bit Unspecified [this ID] > > 3-65535 Reserved [RFC7296] > > > > And the name of transform can be: > > > > "Sequence Number Generation (SNG)" or something like that.
For the transform name, I prefer Anti-Replay Protection (ARP), as Anti-Replay Service is already a term used in the IPsec architecture document RFC 4301. I believe keeping this name for the transform aligns well with the terminology. Please read 4301 before suggesting other names. A funny story. Years ago, when I first read RFC 4301, which mentions the Anti-Replay Service, I used to wonder how this mapped to IKEv2 negotiation. Over time, I associated the Anti-Replay Service with the ESP Sequence Number and ESN. Now we can actually negotation Anti-Replay service as envisioned over 25 years ago in RFC2401. Alo upcoming EESP which propose not to carry SN when ARP is not negotiated, when it is carry the full 64 bits in the packet. I also noticed another point buried deep in the document: ARP value 2 MUST NOT be used with IIV (RFC 8750) for ESP, also on on simple ESP SA with G-IKEv2. When you create new document. Make it explicit. > > I like that. > > As a WG chair, I agree with concers people have with this document > Updating the RFC7296 and doing this kind of change in the large > document which would not be updating IKEv2 otherwise. > > So I would think it would be best if you could cut & paste the this > change from the g-ikev2 document to separate document, and post it as > internet-draft (as a working group draft, as g-ikev2 where this is > taken frm is already wg draft), and I can start working group last > call of that immediately. Then we can ask for publication of that new > draft after WGLC is done. As the g-ikev2 draft is quite big anyways > and we do have longer IETF last call for it anyways, I do not think > this would cause any real delays for the publication of the g-ikev2, > but would make several people happy... :-) > > Valery, can you get this document done? > > Does anybody have any objections of doing this? No. Thanks Tero. -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
