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
<mailto:smyslov.i...@gmail.com> > wrote:
Hi,
this version addresses comments made during WGLC.
Regards,
Valery.
> -----Original Message-----
> From: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
> <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> >
> Sent: Monday, December 16, 2024 4:01 PM
> To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>
> Cc: ipsec@ietf.org <mailto: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 <mailto:ipsec@ietf.org>
> To unsubscribe send an email to ipsec-le...@ietf.org
> <mailto:ipsec-le...@ietf.org>
_______________________________________________
IPsec mailing list -- ipsec@ietf.org <mailto:ipsec@ietf.org>
To unsubscribe send an email to ipsec-le...@ietf.org
<mailto:ipsec-le...@ietf.org>
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
