Hi Antony, > > Some candidates: > > > > Sequence Number Properties (SNP)
Got it, thanks. > 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'? Yes (to be pedantic: 'Transform Type 5 - Sequence Number Properties Transforms IDs'). > 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. Yes, I was thinking about this too. For the full 64-bit either the value 1 can be re-used, or a new value allocated. This also depends on whether EESP will have its own Security Protocol ID (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-18) With ESP and AH the value 1 means that the upper 32 bits are not transmitted. If new Protocol ID is allocated for EESP, then value 1 in the context of EESP will mean that full 64 bits are transmitted. Alternatively, a new value can be allocated for EESP, (e.g. "Explicit 64-bit Sequential Numbers" or something like that) that will be prohibited to be used in AH and ESP proposals. I slightly prefer this way to keep the current semantics of value 1 intact, we can even change its name to "Implicit 64-bit Sequential Numbers" or "Partially Transmitted 64-bit Sequential Numbers" to make this clear. As for the case when no SN is not present, I believe a new value like "No SN" or "Absent" or similar will have to be allocated anyway. The question is whether the properties of SN include the case when SN is absent :-) I think that a broad definition of "properties" should include this case, but if someone disagrees, then we have to invent a better name for this transform type. > > Sequence Number Interpretation (SNI) (can be mixed up with SNI in TLS) > > Sequence Number Features (SNF) > > SNF would be my next choice. Noted, thanks. Regards, Valery. > thanks for your explinations. > -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
