Hi Paul, > > "Anti-Replay Protection (ARP)" transform type was originally named > > "Extended Sequence Numbers (ESN)" and was referenced by that name > > in a number of RFCs published prior to [RFCXXXX], which gave it > > the current title. > > > > Do you think this is not enough? > > It would be better in a separate RFC.
The text above would appear in the IANA registry page for IKEv2 (regardless of whether this document or a separate document updates it). > But also I do not like the term “ARP”, since in > networking this acronym is well known for something completely different. > Maybe > SNRP for “Serial Number Replay Protection”? Good point. To be pedantic, this transform determines the sender's actions with SN field (or, flipping the table, what receiver is expected to get in SN field and how it is supposed to process it). The ultimate decision of whether to do an anti-replay protection (when it is possible) is still a local matter of the receiver (as per RFCs 4302, 4303) and the draft doesn't change this. Thus, perhaps the adequate name would be: "Sequence Number Behavior (SNB)" or "Sequence Number Generation (SNG)" or "Sequence Number Processing (SNP)" or something like that. And the registry would look like: 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] Opinions? > >> 3. The proposed IANA changes are not clear to me > >> > >> I think the extended table > >> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xh > >> tml#ikev2- > >> parameters-9 > >> will become > >> > >> Transform Type 5 - Anti-Replay Protection Transform IDs > >> > >> Number Name Reference > >> 0 No Extended Sequence Numbers [RFC7296] > >> 1 Extended Sequence Numbers [RFC7296] > >> 2 Note Used [this ID] > >> 3-65535 Reserved [RFC7296] > > > > Correct. > > > >> It is hard to distinguish option 0 and 2, especially thinking of ESP. > >> Does "Not Used" mean it is not part ESP Integrity check? > > > > No, it doesn't change ESP processing, except that it informs receivers > > that SN is not guaranteed to be unique in the received packets for a given > > SA. > > Thus, anti-replay protection service in ESP cannot be achieved. > > > > Perhaps, it would be more clear if we also rename the two existing entries. > > For > example: > > > > Transform Type 5 - Anti-Replay Protection Transform IDs > > > > Number Name Reference > > 0 Used with 32-bit SN [RFC7296] > > 1 Used with 64-bit ESN [RFC7296] > > 2 Note Used [this ID] > > 3-65535 Reserved [RFC7296] > > I am fine with this (but Note -> Not) > But perhaps not used is not there best description because people might > interpret it > as not present in the packet. Maybe it should be like “No Replay protection > using > non-unique 33-bit SN” See the proposed registry above. > >> Just as a thought, would it be better addressed in a separate document? > > > > I suspect that this would make things worse. The renaming itself is a > > tiny portion of the draft needed to be able to add one more value into the > registry. > > If we put it into the separate document the readers of this draft would be > confused, IMHO. > > I don’t follow this. The draft could still explain this in the section 1 > terminology > subsection. My concern is that a separate document, on which this draft should depend, will delay its publication for few more years (given the IETF performance). Not a big deal for 14+ years document, I see. But still not good news. On the other hand, the whole renaming of this registry is done for a sole purpose of making it more generic (with no changes in the semantics of the currently defined values and bits on the wire!) to be able to add one more value into it, that is currently not used anywhere but in this draft. So, it seems to me that this is relatively small action to deserve its own RFC. > >> Additionally, would it make sense to allow the transmission of the > >> full 64-bit ESN number, or even consider omitting the sequence number > >> entirely in ESP when ARP is disabled! > > > > I think, once the transform type is renamed and generalized, we can > > add a new values in the future, e.g. as you proposed. > > True. But splitting this in a separate draft should be easy and people > looking at > things updating 7296 don’t have to read this giant doc only for the registry > name > changes. The changes are explained in the abstract, no need to go further. In addition, a notes would be added to the IANA registry page with all information about the changes. Actually, as I wrote in my response to Russ SECDIR review (not yet finished), there is absolutely nothing that would change for implementers of IKEv2 with this renaming - all their past and future implementations remain interoperable and compliant with RFC 7296 even if implementers are unaware of this renaming, since the semantic of existing values is preserved (as well as bits on the wire). We only would give them a proper names. Regards, Valery. > Paul= _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
