Hi Valery, On Mon, Dec 02, 2024 at 06:18:35PM +0300, Valery Smyslov wrote: > Hi Antony, > > > > > 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. > > No, I disagree. The name "Anti-Replay Protection (ARP)" is wrong (despite I > myself proposed it in G-IKEv2). > > The correct name for this transform is a bit difficult to express in concise > form (at least for me). > In a long form: what is being negotiated via this transform is a way the > sender of AH or ESP packets > is preparing these packets with regard to the Sequence Number field in the > AH or ESP header. > And, flipping the table, this transform defines what properties the receiver > of the AH/ESP packets is expecting > to get from this field and how it should be handled. > > The anti-replay protection is not negotiated, this is a local decision of > receivers > and we do not want to change this fact, otherwise we should revise RFC > 4301-4303. > But to be able to enable anti-replay protection, receivers need to know > how the Sequence Number field is to be interpreted - that is what this > transform for. > > Currently this transform only defines only two possible values - either you > use 32-bit sequence numbers > or you use 64-bit "implicit" sequence numbers, when the upper 32 bits are > not transmitted. > Both these options assume that senders always increment the Sequence Number > field on sending. > And the name of the transform doesn't imply that any other options are > plausible. > > So, the goal of the document in question, as I see it, is to give this > transform a proper name, > that will reflect its real semantics (that I tried to explain above). > Once this done, new values can be added that are not fitted into any of the > existing values. > > I want to emphasize that this document must not change the current semantics > (otherwise it would break existing implementations) it should only give this > transform (and two existing values for it) a proper name that would reflect > its current semantics. > > Some candidates: > > Sequence Number Properties (SNP)
SNP sounds good to me as well. However, I have a question about the IKEv2 IANA document. Would the registry end up being titled simply 'Sequence Number Properties Transforms ID'? Number Name Reference 0 32-bit Sequential Numbers (SN) [RFC7296] 1 64-bit Sequential Numbers (ESN) [RFC7296] 2 32-bit Arbitrary Numbers (AN) [this ID] 3-65535 Reserved [RFC7296] I’m envisioning a future where EESP could either carry a full 64-bit sequence number or no sequence number at all in the packet. 64 bits could correspond to the value 1. If the transform is absent the Child SA proposal, no sequence number would be included in the packet. > Sequence Number Interpretation (SNI) (can be mixed up with SNI in TLS) > Sequence Number Features (SNF) SNF would be my next choice. thanks for your explinations. -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
