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) Sequence Number Interpretation (SNI) (can be mixed up with SNI in TLS) Sequence Number Features (SNF) Thoughts? Other proposals? > 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. No, we can't negotiate the anti-replay service - it is a local decision for receiver. But we can negotiate some features of SN that can influence this decision. For example, if we add a value with an SN property "non-uniqueness" (so that it can repeat), the anti-replay service is obviously impossible and since this value is negotiated, in some sense the anti-replay service is negotiated too (in this case both peers must agree not to use it). Another value that can be added once the proper name is given to the transform - "SN not present". This value will not be valid for AH and ESP, but it can be used for EESP. Obviously, this also assumes that anti-replay protection is not available, but this is only a consequence - what is being negotiated is a way the SN is generated and interpreted. > 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 don't think this should ever be mentioned in the document. As I said, the document must not change the current semantics for the transform type and for the two existing values. Thus, all the restrictions for the use of this transform in the existing documents will persist. And the document will add a note in the IANA page notifying about the previous name of this transform, so that we avoid updating all existing documents that reference it. Regards, Valery. > > 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
