Thanks for the quick response. The clarifications/changes you have made are fine. I'll push this draft to IETF Last Call on 2 Jan.
Deb On Sat, Dec 28, 2024 at 4:51 AM Valery Smyslov <s...@elvis.ru> wrote: > Hi Deb, > > > > please see inline. > > > > Many thanks for this work! > > > > As part of my AD review of this draft, I have a few easy comments. I > recognize that I'm sending this during the holiday season, so please don't > interrupt whatever holiday plans you have to respond. The earliest I can > put this draft into IETF Last Call is on 2 Jan 2025. > > > > Deb > > ------------------------------------- > > General: There is no BCP 14 language? Are there really no 'requirements' > on how future transforms are specified? Or because this is all in IANA, it > isn't required? I'm happy to be corrected on this. > > > > As far as I understand, BCP14 language is not required (and > perhaps even is not applicable) for IANA considerations. And the document > actually does not > > define any formal “requirements” for future IANA codepoints, only > clarifies the meaning of one transform and renames it. Thus I’m not sure > where to include > > BCP 14 language J > > > Section 1, para 1, sentence 2: 'which is called there anti-replay'/'which > is called anti-replay'. > > > > Perhaps “which is referred to as "anti-replay" in these > documents”? My idea was to link the terms “anti-replay”, “anti-replay > protection” etc. > > that are used in RFC4301-4303 with the term “replay protection”, > that is used in this document. > > > Section 1, para 1, sentence 3: I can't tell what the word 'individually' > applies to in the phrase, 'each receiver of AH and ESP packets individually > selects whether to enable it'. A singe receiver gets both AH and ESP > packets which they can choose to enable anti-replay on either ESP, AH, or > both? If it means that for each connection (where a 'connection' is AH or > ESP), the receiver has to enable anti-replay, then maybe: 'each receiver of > AH and/or ESP packets can choose whether to enable it on a per connection > basis'. Or something else? > > > > Your understanding is correct. I just think that we can use “SA” > instead of “connection” (since “connection” is too broad). How about > > “each receiver of AH and/or ESP packets can choose whether to > enable it on a per Security Association (SA) basis”? > > > Section 1, para 2, last sentence: deduced/calculated? (deduced means > drawing a logical conclusion, which means they might draw the wrong > conclusion?) > > > > I tried to avoid “calculated”, since in my understanding this is > mostly deterministic procedure. > > With ESN the receiver has to track and “guess” the upper 32 bits > and then verify its guess. > > In some cases there have to be two or more iterations of this > process. > > > > Perhaps s/deduced/determined ? > > > > “Determine” is used in RFC 4301-03, thus it looks as an > appropriate term here. > > > Section 1, para 4, sentence 3: 'performed via so called > transforms'/'performed via transforms'. > > > > OK. > > > End of Section 1, or Section 2: I'd like the phrase 'updates RFC 7296' > slid in somewhere here. I think the last paragraph of Section 2 might be > the best place. But I'm happy to see it done anywhere in these two > sections. [Note: the 'Introduction' is more of a preface, setting the > stage, vice an overview.] > > > > I’ve added the following text at the end of Section 1. > > > > This document updates IKEv2 specification [RFC7296] by renaming > > transform type 5 and two associated transform IDs. > > > Section 2, last para, first sentence: 'Transform type 5 looks like an > appropriate candidate'/'Transform type 5 is an appropriate candidate', or > even better 'Transform type 5 is the best candidate'. (is there another > option?) > > > > OK, good point, I used “the best candidate”. > > > Section 3, idnits line numbers 192-194: I'm having trouble parsing > this. How about 'When a new transform ID is defined, there will be a > description of the sequence number properties that includes a discussion on > which protocols can be used if this transform ID is selected.' If this is > what is intended, is it actually possible to do the last part? One would > have to consider all protocols that utilize IPsec, and say whether a new > transform can be utilized? > > > > The intention was to draw attention to some IPsec extensions, > that rely on the current SN properties > > (I found two such – Implicit IV and Aggregation and > Fragmentation). Since such protocols exist, > > the document advises to add a discussion for the > yet-to-be-defined transform IDs about whether > > these transform IDs can be used in these protocols. It’s true, > that more such protocols can be defined > > in future and we don’t know what requirements they would have, > but since they > > will be defined after this document is published (hopefully), the > definition of these protocols > > will (hopefully) include some discussion on the requirements to > SN properties, > > because at that time it will be already known, that the semantics > of this transform is extended > > to cover cases when SN are not really sequential and unique. > > > > Perhaps the following text is a bit more clear? > > > > Some existing protocols (like Implicit IV in ESP [RFC8750] or > > Aggregation and Fragmentation for ESP [RFC9347]) rely on properties > > that are guaranteed for the currently defined transform IDs, but this > > might not be true for future transform IDs. When a new transform ID > > is defined, its description should include a discussion about the > > possibility of using this transform ID in protocols, that rely on > > some particular sequence number properties. > > > > Regards, > > Valery. > > > > On Mon, Dec 16, 2024 at 8:04 AM Valery Smyslov <smyslov.i...@gmail.com> > wrote: > > Hi, > > this version addresses comments made during WGLC. > > Regards, > Valery. > > > -----Original Message----- > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > Sent: Monday, December 16, 2024 4:01 PM > > To: i-d-annou...@ietf.org > > Cc: ipsec@ietf.org > > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-rename-esn-01.txt > > > > Internet-Draft draft-ietf-ipsecme-ikev2-rename-esn-01.txt is now > available. It is a > > work item of the IP Security Maintenance and Extensions (IPSECME) WG of > the > > IETF. > > > > Title: Renaming Extended Sequence Number (ESN) Transform Type in the > > Internet Key Exchange Protocol Version 2 (IKEv2) > > Author: Valery Smyslov > > Name: draft-ietf-ipsecme-ikev2-rename-esn-01.txt > > Pages: 9 > > Dates: 2024-12-16 > > > > Abstract: > > > > This documents clarifies and extends the meaning of transform type 5 > > in IKEv2. It updates RFC 7296 by renaming the transform type 5 from > > "Extended Sequence Numbers (ESN)" to "Sequence Numbers Properties > > (SNP)". It also renames two currently defined values for this > > transform type: value 0 from "No Extended Sequence Numbers" to > > "32-bit Sequential Numbers" and value 1 from "Extended Sequence > > Numbers" to "Partially Transmitted 64-bit Sequential Numbers". > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-rename-esn/ > > > > There is also an HTMLized version available at: > > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-rename-esn-01 > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-rename-esn-01 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > IPsec mailing list -- ipsec@ietf.org > > To unsubscribe send an email to ipsec-le...@ietf.org > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org > >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
