On Nov 28, 2024, at 07:16, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > > "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. 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”? > >> 3. The proposed IANA changes are not clear to me >> >> I think the extended table >> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#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” > >> 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. >> 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. Paul _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
