Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9329 <draft-ietf-ipsecme-rfc8229bis-09> for your review

[Valery Smyslov <[e-mail]>]

Hi Megan,

> -----Original Message-----
> From: Megan Ferguson [mailto:[e-mail]]
> Sent: Wednesday, October 12, 2022 4:59 PM
> To: Valery Smyslov; Tommy Pauly; [e-mail]
> Cc: RFC Errata System; [e-mail]; Tero Kivinen; [e-mail]
> Subject: [AD] Re: AUTH48: RFC-to-be 9329 <draft-ietf-ipsecme-rfc8229bis-09> for your review
> 
> Valery and *AD,
> 
> [*AD - please review and approve the text addition to Appendix B (see diffs below).]
> 
> Thank you for pointing this out!  We have updated the spacing as requested; please review and confirm.

Thank you for doing this. I confirm that it's OK now.

Regards,
Valery.

> Note that we have moved this document back to AUTH48 (from AUTH48-DONE) until we receive AD
> approval.
> 
> The files have been posted here:
>   https://www.rfc-editor.org/authors/rfc9329.txt
>   https://www.rfc-editor.org/authors/rfc9329.pdf
>   https://www.rfc-editor.org/authors/rfc9329.html
>   https://www.rfc-editor.org/authors/rfc9329.xml
> 
> The relevant diff files have been posted here:
>   https://www.rfc-editor.org/authors/rfc9329-diff.html (comprehensive diff)
>   https://www.rfc-editor.org/authors/rfc9329-rfcdiff.html (comprehensive rfcdiff)
>   https://www.rfc-editor.org/authors/rfc9329-auth48diff.html (all AUTH48 changes)
>   https://www.rfc-editor.org/authors/rfc9329-lastdiff.html (last version to this)
>   https://www.rfc-editor.org/authors/rfc9329-lastrfcdiff.html (last version to this rfcdiff)
> 
> Thank you.
> 
> RFC Editor/mf
> 
> 
> > On Oct 12, 2022, at 2:35 AM, Valery Smyslov <[e-mail]> wrote:
> >
> > Hi Megan,
> >
> >> Valery,
> >>
> >> We’ve mocked up how these changes could work.  Some notes:
> >
> > Thank you.
> >
> >> Adding the text to the previously empty Appendix B seems to have remedied the pagination problem
> >> there without further negative impacts to the other versions (text or html).  *Note that we will need
> AD
> >> approval of added text.
> >
> > OK.
> >
> >> However, note that while breaking the figure in Appendix B.4 looks better in the pdf version, please
> >> review how that break appears in the html and let us know if breaking is still desirable (text version
> only
> >> adds an extra line of whitespace, so not distracting IMHO).
> >
> > While an extra line break in txt and a gap before "6)" in html are noticeable,
> > I think this is acceptable. I don't think we can get better results (at least relatively easily).
> >
> >> Please let us know how you would like to proceed.
> >
> > One minor nit (sorry for being nerd :-)):
> >
> > In the latest version in the part of the figure from B.4
> >
> >     6)  ------------ Retransmit Message from step 2 -------------
> >         Length + Non-ESP Marker  ------->
> >         INFORMATIONAL
> >         HDR, SK { N(UPDATE_SA_ADDRESSES),
> >         N(NAT_DETECTION_SOURCE_IP),
> >         N(NAT_DETECTION_DESTINATION_IP) }
> >                                  <------- Length + Non-ESP Marker
> >                                                     INFORMATIONAL
> >                             HDR, SK { N(NAT_DETECTION_SOURCE_IP),
> >                             N(NAT_DETECTION_DESTINATION_IP) }
> >
> > the last line has been changed so that it is now shifted left a bit (and aligned with the previous line).
> > This line was right-justified before (as all other lines that belong to "Server" actions).
> > Can we restore the original position of this line, just for aesthetical reasons?
> >
> > Originally it was:
> >
> >     6)  ------------ Retransmit Message from step 2 -------------
> >         Length + Non-ESP Marker  ------->
> >         INFORMATIONAL
> >         HDR, SK { N(UPDATE_SA_ADDRESSES),
> >         N(NAT_DETECTION_SOURCE_IP),
> >         N(NAT_DETECTION_DESTINATION_IP) }
> >                                  <------- Length + Non-ESP Marker
> >                                                     INFORMATIONAL
> >                             HDR, SK { N(NAT_DETECTION_SOURCE_IP),
> >                                 N(NAT_DETECTION_DESTINATION_IP) }
> >
> > (to see the difference you should use fixed size font).
> >
> > Regards,
> > Valery.
> >
> >> The files have been posted here:
> >>   https://www.rfc-editor.org/authors/rfc9329.txt
> >>   https://www.rfc-editor.org/authors/rfc9329.pdf
> >>   https://www.rfc-editor.org/authors/rfc9329.html
> >>   https://www.rfc-editor.org/authors/rfc9329.xml
> >>
> >> The relevant diff files have been posted here:
> >>   https://www.rfc-editor.org/authors/rfc9329-diff.html (comprehensive diff)
> >>   https://www.rfc-editor.org/authors/rfc9329-rfcdiff.html (comprehensive rfcdiff)
> >>   https://www.rfc-editor.org/authors/rfc9329-auth48diff.html (all AUTH48 changes)
> >>   https://www.rfc-editor.org/authors/rfc9329-lastdiff.html (last version to this)
> >>   https://www.rfc-editor.org/authors/rfc9329-lastrfcdiff.html (last version to this rfcdiff)
> >>
> >> Thank you.
> >>
> >> RFC Editor/mf
> >>
> >>
> >>> On Oct 11, 2022, at 3:38 AM, Valery Smyslov <[e-mail]> wrote:
> >>>
> >>> Hi Megan,
> >>>
> >>>> Hi Valery,
> >>>>
> >>>> Looking at this more carefully:
> >>>>
> >>>> -The figure in Appendix B.1 fits entirely on the page; would that actually be preferable to the
> reader?
> >> If
> >>>> so, another possible workaround might be to add some “filler” text to Appendix B talking about
> what
> >> the
> >>>> Appendix covers and “see below” so the reader knows the RFC isn’t missing text and they keep on
> >>>> scrolling…
> >>>
> >>> This is a good idea. I think the possible text could be as follows (sorry for possible grammar/style
> >> issues):
> >>>
> >>> PROPOSED TEXT:
> >>> 	This Appendix contains examples of data flows in case TCP encapsulation of IKE and IPsec packets
> >>> 	is used with TLS 1.3. The examples below are provided for illustrative purpose only,
> >>> 	readers should refer to the main body of the document for details.
> >>>
> >>> (Tommy, please review the text).
> >>>
> >>>> -The figure in B.4 does not entirely fit anyway, so breaking that one differently seems like it would
> >>>> actually be helpful for the reader.
> >>>
> >>> Agree. I suggest to break it at the " 7) -- New Exchange with recalculated NAT_DETECTION_*_IP ---
> line
> >>> or at " 6) ------------ Retransmit Message from step 2 -------------" lone in case the subtitle still doesn't
> fit.
> >>> Anyway - my point is that the breaking should be at one of the numbered lines.
> >>>
> >>>> If you let us know how you’d like to break things / proceed, we’d be happy to mock up some
> >> examples.
> >>>
> >>> Thank you for the help.
> >>>
> >>> Regards,
> >>> Valery.
> >>>
> >>>> Thank you.
> >>>>
> >>>> RFC Editor/mf
> >>>>
> >>>>> On Oct 7, 2022, at 2:33 AM, Valery Smyslov <[e-mail]> wrote:
> >>>>>
> >>>>> Hi Megan,
> >>>>>
> >>>>> I approve the publication (with a hope that the pdf issue can be resolved somehow).
> >>>>>
> >>>>>> Hi Valery and Tommy,
> >>>>>>
> >>>>>> Thanks for your replies.  We have updated the sentence as requested (please refresh links
> below).
> >>>>>>
> >>>>>> We have noted the requested hold at the AUTH48 status page (https://www.rfc-
> >>>>>> editor.org/auth48/rfc9329).
> >>>>>>
> >>>>>> With regard to the pdf, I believe you’re correct that this is due to trying to keep the figure (or as
> >> much
> >>>> of
> >>>>>> the figure as possible) on the same page.  I can look into this, but this is likely the nature of the
> >> beast.
> >>>> I
> >>>>>> will let you know if any resolution is possible.
> >>>>>
> >>>>> I don't know whether there are options that could tell pdf renderer not to do it
> >>>>> (if there are no such options, then I think it's a good reason to file a ticket :-))
> >>>>> Anyway, one possible solution would be to manually split those large figures in xml into two
> >>>>> (adjusting the size of the first so that visually most of the page is occupied).
> >>>>> Visually this should not be noticeable in txt and html (I hope).
> >>>>> Of course this is some kind of hack...
> >>>>>
> >>>>> Regards,
> >>>>> Valery.
> >>>>>
> >>>>>> The files have been posted here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9329.txt
> >>>>>> https://www.rfc-editor.org/authors/rfc9329.pdf
> >>>>>> https://www.rfc-editor.org/authors/rfc9329.html
> >>>>>> https://www.rfc-editor.org/authors/rfc9329.xml
> >>>>>>
> >>>>>> The relevant diff files have been posted here:
> >>>>>> https://www.rfc-editor.org/authors/rfc9329-diff.html (comprehensive diff)
> >>>>>> https://www.rfc-editor.org/authors/rfc9329-rfcdiff.html (comprehensive rfcdiff)
> >>>>>> https://www.rfc-editor.org/authors/rfc9329-auth48diff.html (AUTH48 changes only)
> >>>>>> https://www.rfc-editor.org/authors/rfc9329-lastdiff.html (last version to this)
> >>>>>> https://www.rfc-editor.org/authors/rfc9329-lastrfcdiff.html (last to this rfcdiff)
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>> RFC Editor/mf
> >>>>>>
> >>>>>>
> >>>>>>> On Oct 6, 2022, at 9:43 AM, Tommy Pauly <[e-mail]> wrote:
> >>>>>>>
> >>>>>>> Hi Megan,
> >>>>>>>
> >>>>>>> I agree with Valery’s points. I also think it’s fine to wait for the UTA draft. Once the typo and
> PDF
> >>>> issues
> >>>>>> are resolved, I approve this document!
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tommy
> >>>>>>>
> >>>>>>>> On Oct 6, 2022, at 12:53 AM, Valery Smyslov <[e-mail]> wrote:
> >>>>>>>>
> >>>>>>>> Hi Megan,
> >>>>>>>>
> >>>>>>>> thank you for the update. Please see inline.
> >>>>>>>>
> >>>>>>>>> Hi Valery and Tommy,
> >>>>>>>>>
> >>>>>>>>> Thank you for your replies and guidance.  We have updated the document as requested.
> >>>>>>>>> Please review our updates carefully (as we do not make changes once the document is
> >>>>>>>>> published) and let us know if any further changes are necessary or if you approve the
> >>>>>>>>> document in its current form.
> >>>>>>>>>
> >>>>>>>>> A few notes below in response to your questions/comments:
> >>>>>>>>>
> >>>>>>>>> 1) Note that IPsec is not expanded in the title as it is marked as “well-known” at
> >>>>>>>>> https://www.rfc-editor.org/materials/abbrev.expansion.txt, which states:
> >>>>>>>>>
> >>>>>>>>> Some abbreviations are so well known that expansion is probably
> >>>>>>>>> unnecessary.  The RFC Editor exercises editorial judgment about whether
> >>>>>>>>> a particular use of one of the "well-known" abbreviations requires
> >>>>>>>>> expansion.
> >>>>>>>>
> >>>>>>>> Got it.
> >>>>>>>>
> >>>>>>>>> 2) FYI - We have updated our database to use the keywords from RFC 8229.
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>>> 3) Please review our updates to use both RFCs 6528 and 9239 in the text and let us know
> >>>>>>>>> any objections.
> >>>>>>>>
> >>>>>>>> Looks good.
> >>>>>>>>
> >>>>>>>>> 4) FYI - We removed the figure numbering from those figures that you did not want titled.
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>>> 5) Regarding draft-ietf-uta-rfc7525bis-11: it is currently in RFC-ED state (i.e., has not yet
> >>>>>>>>> reached AUTH48 state).  We are unable to estimate the length of AUTH48 state as it would
> >>>> depend
> >>>>>>>>> on author response times.  We would recommend either moving forward with the reference
> >>>>>> pointing
> >>>>>>>>> to the draft version (as it currently stands) or letting us know the max wait time you are
> willing
> >>>>>>>>> to allow for it to get through AUTH48 state.
> >>>>>>>>
> >>>>>>>> I think that it's OK to wait few weeks (say, to the end of October). I don't expect
> >>>>>>>> long delays in publication of 7525bis, at least caused by its authors
> >>>>>>>> (as UTA WG co-chair I know them). So I suggest to wait few week and
> >>>>>>>> if the 7525bis is not published by then, we can reconsider.
> >>>>>>>>
> >>>>>>>> And I noticed a typo in the latest changes (in the text I proposed):
> >>>>>>>>
> >>>>>>>> CURRENT TEXT:
> >>>>>>>> As with TCP Originators, a TCP Responder SHOULD send packets for an
> >>>>>>>> IKE SA and its Child SAs over only one TCP connection at any given
> >>>>>>>> time.  It SHOULD choose the TCP connection on which it last received
> >>>>>>>> a valid and decryptable IKE or ESP message.  In order to be
> >>>>>>>> considered valid for choosing a TCP connection, an IKE message must
> >>>>>>>> be successfully decrypted and authenticated, not be a retransmission
> >>>>>>>> of a previously received message, and be within the expected window
> >>>>>>>> for IKE message IDs.  Similarly, an ESP message must successfully
> >>>>>>>> decrypted and authenticated, and must not be a replay of a previous
> >>>>>>>> message.
> >>>>>>>>
> >>>>>>>> CORRECT TEXT:
> >>>>>>>> As with TCP Originators, a TCP Responder SHOULD send packets for an
> >>>>>>>> IKE SA and its Child SAs over only one TCP connection at any given
> >>>>>>>> time.  It SHOULD choose the TCP connection on which it last received
> >>>>>>>> a valid and decryptable IKE or ESP message.  In order to be
> >>>>>>>> considered valid for choosing a TCP connection, an IKE message must
> >>>>>>>> be successfully decrypted and authenticated, not be a retransmission
> >>>>>>>> of a previously received message, and be within the expected window
> >>>>>>>> for IKE message IDs.  Similarly, an ESP message must be successfully
> >>>>>>>> decrypted and authenticated, and must not be a replay of a previous
> >>>>>>>> message.
> >>>>>>>>
> >>>>>>>> (note that "be" is missing before "successfully" in the last sentence).
> >>>>>>>> It was my fault caused by careless copy-paste, sorry.
> >>>>>>>>
> >>>>>>>> And one minor issue, that I noticed in the pdf version:
> >>>>>>>> there are 2 pages that contain nothing except subtitle (pages 25 & 29).
> >>>>>>>> I guess the reason is that the pdf formatter tries to fit the following
> >>>>>>>> figures into one page, but IMHO the result is worse - the second figure
> >>>>>>>> still doesn't fit and we have empty pages in the document.
> >>>>>>>> Can this be fixed or is it an issue with the pdf formatter?
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Valery.
> >>>>>>>>
> >>>>>>>>> The files have been posted here (please refresh):
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.txt
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.pdf
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.html
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.xml
> >>>>>>>>>
> >>>>>>>>> The relevant diff files have been posted here:
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-diff.html (comprehensive diff)
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-rfcdiff.html (comprehensive rfcdiff)
> >>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-auth48diff.html (AUTH48 changes only)
> >>>>>>>>>
> >>>>>>>>> The AUTH48 status page for this document is posted here:
> >>>>>>>>> http://www.rfc-editor.org/auth48/rfc9329
> >>>>>>>>>
> >>>>>>>>> Thank you.
> >>>>>>>>>
> >>>>>>>>> RFC Editor/mf
> >>>>>>>>>
> >>>>>>>>>>> On Oct 3, 2022, at 11:23 PM, Tommy Pauly <tpauly=[e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Oct 3, 2022, at 9:30 AM, Valery Smyslov <[e-mail]> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: [e-mail] [mailto:[e-mail]]
> >>>>>>>>>>>> Sent: Saturday, October 01, 2022 12:18 AM
> >>>>>>>>>>>> To: [e-mail]; [e-mail]
> >>>>>>>>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
> >> [e-mail];
> >>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9329 <draft-ietf-ipsecme-rfc8229bis-09> for your review
> >>>>>>>>>>>>
> >>>>>>>>>>>> Authors,
> >>>>>>>>>>>>
> >>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the
> following
> >>>>>>>>> questions,
> >>>>>>>>>>>> which are also in the XML file.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1) <!--[rfced] While we understand the original document (RFC 8229) was published with
> >> some
> >>>> of
> >>>>>>>>> the
> >>>>>>>>>>>> text we are questioning below, the questions
> >>>>>>>>>>>> are aimed at making the text as clear/correct as possible.  Please let us
> >>>>>>>>>>>> know if any updates we have made are incorrect or undesirable in this -bis.
> >>>>>>>>>>>
> >>>>>>>>>>> OK.
> >>>>>>>>>>>
> >>>>>>>>>>>> -->
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2) <!-- [rfced] Because this document obsoletes RFC 8229, please review the
> >>>>>>>>>>>> erratum reported for RFC 8229 (https://www.rfc-editor.org/errata/eid5320) and ensure
> that
> >>>>>> any
> >>>>>>>>>>>> necessary updates have been addressed.  -->
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, this erratum has been addressed (as noted in the resolution text for the erratum,
> >>>>>>>>>>> although referencing the wrong Section in the draft, it is actually 6.2, not 7.2).
> >>>>>>>>>>>
> >>>>>>>>>>>> 3) <!-- [rfced] Please note that the title of the document has been updated as follows:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
> >>>>>>>>>>>> Style Guide"). Please review.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> TCP Encapsulation of IKE and IPsec Packets
> >>>>>>>>>>>>
> >>>>>>>>>>>> Current:
> >>>>>>>>>>>> TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec
> >>>>>>>>>>>> Packets
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> I don't mind this change (although I'm curious why IKE is expanded and IPsec not),
> >>>>>>>>>>> but I like the original title a bit more. Well, I rely on my co-author in this case.
> >>>>>>>>>>
> >>>>>>>>>> I am fine with the new title if it fits the style guide. It is a bit long, but that’s OK.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in
> >>>>>>>>>>>> the title) for use on https://www.rfc-editor.org/search. -->
> >>>>>>>>>>>
> >>>>>>>>>>> I believe we can re-use keywords from RFC 8229. Is it possible?
> >>>>>>>>>>
> >>>>>>>>>> Agreed, this should match.
> >>>>>>>>>>>
> >>>>>>>>>>>> 5) <!--[rfced] Please note that we have changed the following text in the
> >>>>>>>>>>>> Abstract and Acknowledgments sections, respectively, in order to
> >>>>>>>>>>>> avoid any confusion caused by the use of the word "update" (as
> >>>>>>>>>>>> this document obsoletes RFC 8229.)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>>
> >>>>>>>>>>>> TCP encapsulation for IKE and IPsec was defined in RFC 8229.  This
> >>>>>>>>>>>> document updates the specification for TCP encapsulation by including
> >>>>>>>>>>>> additional clarifications obtained during implementation and
> >>>>>>>>>>>> deployment of this method.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> and
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since this document updates and obsoletes RFC 8229, most of
> >>>>>>>>>>>> its text was borrowed from the original document.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Current:
> >>>>>>>>>>>>
> >>>>>>>>>>>> TCP encapsulation for IKE and IPsec was defined in RFC 8229.  This
> >>>>>>>>>>>> document clarifies the specification for TCP encapsulation by including
> >>>>>>>>>>>> additional clarifications obtained during implementation and
> >>>>>>>>>>>> deployment of this method.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Since this document clarifies and obsoletes RFC 8229, most of
> >>>>>>>>>>>> its text was borrowed from the original document.
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> Fine, thank you.
> >>>>>>>>>>>
> >>>>>>>>>>>> 6) <!--[rfced] Section 1: we had a few questions regarding the first
> >>>>>>>>>>>> list.
> >>>>>>>>>>>>
> >>>>>>>>>>>> a) Might we update the list that appears in the Introduction to be a
> >>>>>>>>>>>> definitions list instead of a numbered list?
> >>>>>>>>>>>>
> >>>>>>>>>>>> b) We see a reference pointing the reader to further information on
> >>>>>>>>>>>> UDP Encapsulation: might the same be helpful for TCP Encapsulation?
> >>>>>>>>>>>> If yes, please let us know what to add.
> >>>>>>>>>>>>
> >>>>>>>>>>>> c) Is "currently" in #1 still desirable?  Or should this be made
> >>>>>>>>>>>> something like "At the time RFC 8229 was written.." or the like?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Current:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Using TCP as a transport for IPsec packets adds a third option to the
> >>>>>>>>>>>> list of traditional IPsec transports:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1.  Direct.  Currently, IKE negotiations begin over UDP port 500.  If
> >>>>>>>>>>>>  no Network Address Translation (NAT) device is detected between
> >>>>>>>>>>>>  the Initiator and the Responder, then subsequent IKE packets are
> >>>>>>>>>>>>  sent over UDP port 500 and IPsec data packets are sent using ESP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2.  UDP Encapsulation [RFC3948].  If a NAT is detected between the
> >>>>>>>>>>>>  Initiator and the Responder, then subsequent IKE packets are sent
> >>>>>>>>>>>>  over UDP port 4500 with four bytes of zero at the start of the
> >>>>>>>>>>>>  UDP payload, and ESP packets are sent out over UDP port 4500.
> >>>>>>>>>>>>  Some implementations default to using UDP encapsulation even when
> >>>>>>>>>>>>  no NAT is detected on the path, as some middleboxes do not
> >>>>>>>>>>>>  support IP protocols other than TCP and UDP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 3.  TCP Encapsulation.  If the other two methods are not available or
> >>>>>>>>>>>>  appropriate, IKE negotiation packets as well as ESP packets can
> >>>>>>>>>>>>  be sent over a single TCP connection to the peer.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps:
> >>>>>>>>>>>> Using TCP as a transport for IPsec packets adds a third option to the
> >>>>>>>>>>>> list of traditional IPsec transports:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Direct:  Currently, IKE negotiations begin over UDP port 500.  If no
> >>>>>>>>>>>> Network Address Translation (NAT) device is detected between the
> >>>>>>>>>>>> Initiator and the Responder, then subsequent IKE packets are sent
> >>>>>>>>>>>> over UDP port 500 and IPsec data packets are sent using ESP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> UDP Encapsulation:  Described in [RFC3948].  If a NAT is detected
> >>>>>>>>>>>> between the Initiator and the Responder, then subsequent IKE
> >>>>>>>>>>>> packets are sent over UDP port 4500 with 4 bytes of zero at the
> >>>>>>>>>>>> start of the UDP payload, and ESP packets are sent out over UDP
> >>>>>>>>>>>> port 4500.  Some implementations default to using UDP
> >>>>>>>>>>>> encapsulation even when no NAT is detected on the path, as some
> >>>>>>>>>>>> middleboxes do not support IP protocols other than TCP and UDP.
> >>>>>>>>>>>>
> >>>>>>>>>>>> TCP Encapsulation: Described in [?].  If the other two methods are
> >>>>>>>>>>>> not available or appropriate, IKE negotiation packets as well as
> >>>>>>>>>>>> ESP packets can be sent over a single TCP connection to the peer.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> a) This list enumerates possible options for IPsec transport. While they are not definitions
> per
> >>>> se,
> >>>>>>>>>>> visually this change is OK.
> >>>>>>>>>>
> >>>>>>>>>> I think it’s OK, but it sounds a bit odd that we say “we add the third option” and then don’t
> >>>> actually
> >>>>>>>>> number it as the third. I’d lean away from this change, personally.
> >>>>>>>>>>>
> >>>>>>>>>>> b) The TCP encapsulation is described in this very document,
> >>>>>>>>>>> so no other reference can be added (we may add clarification if you think it is needed):
> >>>>>>>>>>>
> >>>>>>>>>>> OLD:
> >>>>>>>>>>> 3.  TCP Encapsulation.
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> TCP Encapsulation: (described in this document).
> >>>>>>>>>>
> >>>>>>>>>> Right, this is the document itself. I think this was clearer as a numbered list.
> >>>>>>>>>>>
> >>>>>>>>>>> c) No, "currently" here means "as defined in IKEv2 specification".
> >>>>>>>>>>> I agree that using "currently" in this case may be confusing. What about
> >>>>>>>>>>> using "usually" instead? Tommy, your opinion?:
> >>>>>>>>>>>
> >>>>>>>>>>> PERHAPS:
> >>>>>>>>>>> Direct:  Usually IKE negotiations begin over UDP port 500.
> >>>>>>>>>>
> >>>>>>>>>> Yes, “Usually” works fine.
> >>>>>>>>>>>
> >>>>>>>>>>>> 7) <!--[rfced] Would you like to add a title for figures that do not have
> >>>>>>>>>>>> them?-->
> >>>>>>>>>>>
> >>>>>>>>>>> I would rather leave unnumbered figures unnumbered, but
> >>>>>>>>>>> I'm not sure if it is possible (I remember there was xml2rfc v3
> >>>>>>>>>>> limitation that unnumbered items - I don't remember figures or tables -
> >>>>>>>>>>> were not allowed). If this is the case and all figures must have numbers,
> >>>>>>>>>>> then we will definitely want to add titles to them. Let us know
> >>>>>>>>>>> if all pictures must be numbered - then we'll think of titles.
> >>>>>>>>>>>
> >>>>>>>>>>>> 8) <!--[rfced] How may we update this sentence for subject/verb
> >>>>>>>>>>>> agreement?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> In brief, the exchange Initiator is responsible for retransmissions
> >>>>>>>>>>>> and must retransmit requests message until response message is
> >>>>>>>>>>>> received.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps A:
> >>>>>>>>>>>> In brief, the exchange Initiator is responsible for retransmissions
> >>>>>>>>>>>> and must retransmit request messages until a response message is
> >>>>>>>>>>>> received.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps B:
> >>>>>>>>>>>> In brief, the exchange Initiator is responsible for retransmissions
> >>>>>>>>>>>> and must retransmit a request message until a response message is
> >>>>>>>>>>>> received.-->
> >>>>>>>>>>>
> >>>>>>>>>>> Option B looks better. However, I think that "a request message"
> >>>>>>>>>>> means "any request message", while in fact there is only one request
> >>>>>>>>>>> message for any particular exchange. So I believe it should be:
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> In brief, the exchange Initiator is responsible for retransmissions
> >>>>>>>>>>> and must retransmit the request message until a response message is
> >>>>>>>>>>> received.
> >>>>>>>>>>>
> >>>>>>>>>>> Tommy, your opinion (I'm not strong in using articles)?
> >>>>>>>>>>
> >>>>>>>>>> I actually prefer Option A, because it lets you know that this applies to all such request and
> >>>>>> response
> >>>>>>>>> messages (not a particular one).
> >>>>>>>>>>>
> >>>>>>>>>>>> 9) <!--[rfced] In the text version, the bulleted list in Sections 6.2 and
> >>>>>>>>>>>> 6.3 will use asterisks to mark each bullet.  Will this cause the
> >>>>>>>>>>>> notes that are marked with (*) in those lists to be either lost
> >>>>>>>>>>>> or misread by the reader?  Perhaps these notes could be marked
> >>>>>>>>>>>> differently?  Please review and let us know if/how you would like
> >>>>>>>>>>>> updates to appear.-->
> >>>>>>>>>>>
> >>>>>>>>>>> Good point, thanks. Actually it doesn't seem to get lost (at least for me),
> >>>>>>>>>>> but for completeness - can you give advice how the appearance
> >>>>>>>>>>> may be improved here?
> >>>>>>>>>>
> >>>>>>>>>> I think this is fine without a change, IMO. In the HTML, this should look better anyhow.
> >>>>>>>>>>>
> >>>>>>>>>>>> 10) <!--[rfced] Is this text contradictory?  First it says no amount of
> >>>>>>>>>>>> time is specified and then specifies an amount of time.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> This document doesn't specify the duration of time because it doesn't
> >>>>>>>>>>>> affect interoperability, but it is believed that 5-10 seconds is a
> >>>>>>>>>>>> good compromise.
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> It was meant that no value is mandated by this documents,
> >>>>>>>>>>> provided values are only advice. We can change the text as follows:
> >>>>>>>>>>>
> >>>>>>>>>>> OLD:
> >>>>>>>>>>> This document doesn't specify the duration of time because it doesn't
> >>>>>>>>>>> affect interoperability, but it is believed that 5-10 seconds is a
> >>>>>>>>>>> good compromise.
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> This document doesn't mandate the duration of time because it doesn't
> >>>>>>>>>>> affect interoperability, it is believed that 5-10 seconds is a
> >>>>>>>>>>> good compromise.
> >>>>>>>>>>
> >>>>>>>>>> Agreed with this proposed text. “Mandate” is better here.
> >>>>>>>>>>>
> >>>>>>>>>>>> 11) <!--[rfced] These sentences are a bit redundant with their
> >>>>>>>>>>>> introductory phrases.  Might we combine them?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> In case of TCP encapsulation this check has little value, since TCP
> >>>>>>>>>>>> handshake proves routability of the TCP Originator's address.  So, in
> >>>>>>>>>>>> case of TCP encapsulation the Return Routability Check SHOULD NOT be
> >>>>>>>>>>>> performed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps:
> >>>>>>>>>>>> In the case of TCP encapsulation, this check has little value since a
> >>>>>>>>>>>> TCP handshake proves the routability of the TCP Originator's address;
> >>>>>>>>>>>> thus, the Return Routability Check SHOULD NOT be performed.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> I don't mind, thanks.
> >>>>>>>>>>
> >>>>>>>>>> Looks good.
> >>>>>>>>>>>
> >>>>>>>>>>>> 12) <!--[rfced] We suggest rewording this sentence for the ease of the
> >>>>>>>>>>>> reader. Please confirm that the proposed text does not change the
> >>>>>>>>>>>> intended meaning.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> In other words, the client MUST again try first UDP and then fall
> >>>>>>>>>>>> back to TCP while establishing a new IKE SA, regardless of the transport of
> >>>>>>>>>>>> the SA the redirect notification was received over (unless the client's
> >>>>>>>>>>>> configuration instructs it to instantly use TCP for the gateway it is
> >>>>>>>>>>>> redirected to).
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps:
> >>>>>>>>>>>> In other words, the client MUST first try UDP again, and then fall
> >>>>>>>>>>>> back to TCP while establishing a new IKE SA, regardless of the transport of
> >>>>>>>>>>>> the SA the redirect notification was received over (unless the client's
> >>>>>>>>>>>> configuration instructs it to instantly use TCP for the gateway it is
> >>>>>>>>>>>> redirected to).
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> I suggest another text change for more clarity:
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> In other words, with the next security gateway the client MUST first try UDP, and then fall
> >>>>>>>>>>> back to TCP while establishing a new IKE SA, regardless of the transport of
> >>>>>>>>>>> the SA the redirect notification was received over (unless the client's
> >>>>>>>>>>> configuration instructs it to instantly use TCP for the gateway it is
> >>>>>>>>>>> redirected to).
> >>>>>>>>>>>
> >>>>>>>>>>>> 13) <!--[rfced] The term "simply" can have more than one meaning that
> >>>>>>>>>>>> might apply here.  Might a different word choice in this text be
> >>>>>>>>>>>> more clear for readers?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> Since there is not a one-to-one relationship between outer IP packets
> >>>>>>>>>>>> and inner ESP/IP messages when using TCP encapsulation, the markings
> >>>>>>>>>>>> for Explicit Congestion Notification (ECN) [RFC3168] cannot be simply
> >>>>>>>>>>>> mapped.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps A:
> >>>>>>>>>>>> Since there is not a one-to-one relationship between outer IP packets
> >>>>>>>>>>>> and inner ESP/IP messages when using TCP encapsulation, the markings
> >>>>>>>>>>>> for Explicit Congestion Notification (ECN) [RFC3168] cannot easily be
> >>>>>>>>>>>> mapped.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps B:
> >>>>>>>>>>>> Since there is not a one-to-one relationship between outer IP packets
> >>>>>>>>>>>> and inner ESP/IP messages when using TCP encapsulation, the markings
> >>>>>>>>>>>> for Explicit Congestion Notification (ECN) [RFC3168] cannot only be
> >>>>>>>>>>>> mapped.
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> Option A is the correct meaning.
> >>>>>>>>>>
> >>>>>>>>>> Correct.
> >>>>>>>>>>>
> >>>>>>>>>>>> 14) <!--[rfced] This text is a bit difficult to parse: how does the last
> >>>>>>>>>>>> clause relate?  Will it be clear which packets are dropped (i.e.,
> >>>>>>>>>>>> those going to the ESP, coming from it, or both)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> *  if an attacker alters the non-ESP marker then IKE packets will be
> >>>>>>>>>>>> dispatched to ESP and sometimes visa versa, those packets will be
> >>>>>>>>>>>> dropped
> >>>>>>>>>>>>
> >>>>>>>>>>>> Perhaps:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  If an attacker alters the non-ESP marker, then IKE packets will be
> >>>>>>>>>>>> dispatched to the ESP (and sometimes visa versa) and those packets
> >>>>>>>>>>>> will be dropped.
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> It was meant that both kind of packets are dropped (because both would go to
> >>>>>>>>>>> wrong parser).
> >>>>>>>>>>>
> >>>>>>>>>>> I'm fine with the suggested change.
> >>>>>>>>>>>
> >>>>>>>>>>>> 15) <!--[rfced] Please confirm the use of "...of IKE SPIs of IKE SA" is
> >>>>>>>>>>>> intended.  If this is intentional, it seems the equivalent of
> >>>>>>>>>>>> "Indexes of Association": perhaps "an IKE SA" or "IKE SAs"?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Original:
> >>>>>>>>>>>> They can also search for 4 bytes of zero (non-ESP marker) followed by
> >>>>>>>>>>>> 128 bits of IKE SPIs of IKE SA associated with this TCP connection and
> >>>>>>>>>>>> then validate ICV of this IKE message candidate by taking the 16 bits
> >>>>>>>>>>>> preceding the non-ESP marker as the Length field.
> >>>>>>>>>>>>
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> I think the better change would be:
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> They can also search for 4 bytes of zero (non-ESP marker) followed by
> >>>>>>>>>>> 128 bits of IKE SPIs of the IKE SA(s) associated with this TCP connection and
> >>>>>>>>>>> then validate ICV of this IKE message candidate by taking the 16 bits
> >>>>>>>>>>> preceding the non-ESP marker as the Length field.
> >>>>>>>>>>>
> >>>>>>>>>>> So, they will search for the concrete IKE SPIs that belongs to the IKE SA
> >>>>>>>>>>> associated with this TCP connection. When this SA is being rekeyed, for some short
> >>>>>>>>>>> period of time there will be two concrete IKE SAs associated with this TCP connection.
> >>>>>>>>>>>
> >>>>>>>>>>>> 16) <!--[rfced] Please note that we have updated the IANA Considerations
> >>>>>>>>>>>> section to more closely mirror what appears at
> >>>>>>>>>>>> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-
> >>>>>>>>>>>> numbers.xhtml?search=ipsec-nat-t.
> >>>>>>>>>>>> Please let us know any objections.-->
> >>>>>>>>>>>
> >>>>>>>>>>> No objections, thank you.
> >>>>>>>>>>>
> >>>>>>>>>>>> 17) <!-- [rfced] RFC 6528 has been obsoleted by RFC 9293; thus, We have
> >>>>>>>>>>>> replaced pointers to RFC 6528 with those to RFC 9293. Please let
> >>>>>>>>>>>> us know of any objections.
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> While formally this replacement is correct, RFC 9293 incorporates
> >>>>>>>>>>> a lot of TCP extensions and it's not easy to find the needed information.
> >>>>>>>>>>> And despite the fact RFC 9293  obsoletes RFC 6528, it still reference it (Section 5):
> >>>>>>>>>>>
> >>>>>>>>>>> See RFC 6528 for discussion of the attacks
> >>>>>>>>>>> that this mitigates, as well as advice on selecting PRF algorithms
> >>>>>>>>>>> and managing secret key data.
> >>>>>>>>>>>
> >>>>>>>>>>> So I suggest to keep reference to 6528 or reference both documents.
> >>>>>>>>>>>
> >>>>>>>>>>> PERHAPS:
> >>>>>>>>>>> (see [RFC9293], more details in [RFC6528])
> >>>>>>>>>>>
> >>>>>>>>>>>> 18) <!--[rfced] Throughout the text, we see the following similar terms
> >>>>>>>>>>>> capped somewhat differently.  Please review and let us know
> >>>>>>>>>>>> if/how these may be made uniform.
> >>>>>>>>>>>>
> >>>>>>>>>>>> TCP Sequence Number attack vs. TCP sequence numbers vs. Sequence Number
> >>>>>>>>>>>> keepalive vs. keep-alive
> >>>>>>>>>>>>
> >>>>>>>>>>>> -->
> >>>>>>>>>>>
> >>>>>>>>>>> I believe "TCP sequence number" is correct for the first two cases you mentioned.
> >>>>>>>>>>> Note, that "Sequence Number" is also used in Section 10, which is not TCP sequence
> number,
> >>>>>>>>>>> but instead ESP Sequence Number, which is always used capitalized in RFC 4301.
> >>>>>>>>>>>
> >>>>>>>>>>> RFC 1122 uses "TCP keep-alive" as well as RFC 6520 uses "keep-alive",
> >>>>>>>>>>> so we reflect these terms in the document. On the other hand,
> >>>>>>>>>>> RFC 3948 uses "keepalive", so we use this form when talking about NAT-keepalive packets.
> >>>>>>>>>>>
> >>>>>>>>>>>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the
> >>>>>>>>>>>> online Style Guide
> >>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >>>>>>>>>>>> and let us know if any changes are needed. -->
> >>>>>>>>>>>
> >>>>>>>>>>> I believe no changes are needed.
> >>>>>>>>>>>
> >>>>>>>>>>> I also have a couple of comments (I continue the numeration).
> >>>>>>>>>>>
> >>>>>>>>>>> 20. Section 6.1 contains the following change:
> >>>>>>>>>>>
> >>>>>>>>>>> ORIGINAL:
> >>>>>>>>>>> If a TCP connection is being used to continue an existing IKE/ESP
> >>>>>>>>>>> session, the TCP Responder can recognize the session using either the
> >>>>>>>>>>> IKE SPI from an encapsulated IKE message or the ESP SPI from an
> >>>>>>>>>>> encapsulated ESP packet.  If the session had been fully established
> >>>>>>>>>>> previously, it is suggested that the TCP Originator send an
> >>>>>>>>>>> UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an empty
> >>>>>>>>>>> informational message otherwise.
> >>>>>>>>>>>
> >>>>>>>>>>> CHANGED:
> >>>>>>>>>>> If a TCP connection is being used to continue an existing IKE/ESP
> >>>>>>>>>>> session, the TCP Responder can recognize the session using either the
> >>>>>>>>>>> IKE SPI from an encapsulated IKE message or the ESP SPI from an
> >>>>>>>>>>> encapsulated ESP packet.  If the session had been fully established
> >>>>>>>>>>> previously, it is suggested that the TCP Originator send an
> >>>>>>>>>>> UPDATE_SA_ADDRESSES message if MOBIKE is supported; otherwise, an
> >>>>>>>>>>> empty informational message should be sent.
> >>>>>>>>>>>
> >>>>>>>>>>> The last sentence contains two "if", so "otherwise" can be mistakenly
> >>>>>>>>>>> applied to the first one (while in fact it relates to the second). I believe
> >>>>>>>>>>> the original text didn't have this possible confusion. May I suggest
> >>>>>>>>>>> the following text:
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> If a TCP connection is being used to continue an existing IKE/ESP
> >>>>>>>>>>> session, the TCP Responder can recognize the session using either the
> >>>>>>>>>>> IKE SPI from an encapsulated IKE message or the ESP SPI from an
> >>>>>>>>>>> encapsulated ESP packet.  If the session had been fully established
> >>>>>>>>>>> previously, it is suggested that the TCP Originator send an
> >>>>>>>>>>> UPDATE_SA_ADDRESSES message if MOBIKE is supported and an
> >>>>>>>>>>> empty informational message if it is not.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 21. Section 6.1:
> >>>>>>>>>>>
> >>>>>>>>>>> ORIGINAL:
> >>>>>>>>>>> Similarly, a TCP Responder SHOULD at any given time send packets for
> >>>>>>>>>>> an IKE SA and its Child SAs over only one TCP connection.  It SHOULD
> >>>>>>>>>>> choose the TCP connection on which it last received a valid and
> >>>>>>>>>>> decryptable IKE or ESP message.  In order to be considered valid for
> >>>>>>>>>>> choosing a TCP connection, an IKE message must be successfully
> >>>>>>>>>>> decrypted and authenticated, not be a retransmission of a previously
> >>>>>>>>>>> received message, and be within the expected window for IKE message
> >>>>>>>>>>> IDs.  Similarly, an ESP message must pass authentication checks and
> >>>>>>>>>>> be decrypted, and must not be a replay of a previous message.
> >>>>>>>>>>>
> >>>>>>>>>>> CHANGED:
> >>>>>>>>>>> At any given time, a TCP Responder SHOULD send packets for an IKE SA
> >>>>>>>>>>> and its Child SAs over only one TCP connection.  It SHOULD choose the
> >>>>>>>>>>> TCP connection on which it last received a valid and decryptable IKE
> >>>>>>>>>>> or ESP message.  In order to be considered valid for choosing a TCP
> >>>>>>>>>>> connection, an IKE message must be successfully decrypted and
> >>>>>>>>>>> authenticated, not be a retransmission of a previously received
> >>>>>>>>>>> message, and be within the expected window for IKE message IDs.
> >>>>>>>>>>> Similarly, an ESP message must pass authentication checks, must be
> >>>>>>>>>>> decrypted, and must not be a replay of a previous message.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm a bit upset that "similarly" get lost. Can we add some introduction
> >>>>>>>>>>> word to indicate, that the responder's behavior is similar to the initiator's one?
> >>>>>>>>>>>
> >>>>>>>>>>> Another thing that scratches my eye is that ESP message now
> >>>>>>>>>>> "must be decrypted". In fact, this is not a requirement, I'd  rather
> >>>>>>>>>>> to use the text we use for IKE message:
> >>>>>>>>>>>
> >>>>>>>>>>> PROPOSED:
> >>>>>>>>>>> As with TCP Originator, a TCP Responder SHOULD send packets for an IKE SA
> >>>>>>>>>>> and its Child SAs over only one TCP connection at any given time.  It SHOULD choose the
> >>>>>>>>>>> TCP connection on which it last received a valid and decryptable IKE
> >>>>>>>>>>> or ESP message.  In order to be considered valid for choosing a TCP
> >>>>>>>>>>> connection, an IKE message must be successfully decrypted and
> >>>>>>>>>>> authenticated, not be a retransmission of a previously received
> >>>>>>>>>>> message, and be within the expected window for IKE message IDs.
> >>>>>>>>>>> Similarly, an ESP message must successfully decrypted and
> >>>>>>>>>>> authenticated, and must not be a replay of a previous message.
> >>>>>>>>>>>
> >>>>>>>>>>> 22. Section 6.6.
> >>>>>>>>>>> In the text:
> >>>>>>>>>>>
> >>>>>>>>>>> NAT-keepalive packets over a TCP-
> >>>>>>>>>>> encapsulated IPsec connection will be sent as a 1-octet-long payload
> >>>>>>>>>>> with the value 0xFF, preceded by the 2-byte Length specifying a
> >>>>>>>>>>> length of 3 (since it includes the length of the Length field).
> >>>>>>>>>>>
> >>>>>>>>>>> there is mix of "byte" and "octet" in the same sentence. I admit,
> >>>>>>>>>>> that we use both i\throughout the document (that is that),
> >>>>>>>>>>> but I suggest to use one form (any) in a single sentence.
> >>>>>>>>>>>
> >>>>>>>>>>> 23. Section 10:
> >>>>>>>>>>> ORIGINAL:
> >>>>>>>>>>> Implementations SHOULD limit the
> >>>>>>>>>>> attempts to resync, since if the injection attack is ongoing then
> >>>>>>>>>>> there is a high probability that the resync process will not succeed,
> >>>>>>>>>>> or quickly come under attack again.
> >>>>>>>>>>>
> >>>>>>>>>>> CHANGED:
> >>>>>>>>>>> Implementations SHOULD limit the attempts to resync.  If the
> >>>>>>>>>>> injection attack is ongoing, then there is a high probability that
> >>>>>>>>>>> the resync process will not succeed or will quickly come under attack
> >>>>>>>>>>> again.
> >>>>>>>>>>>
> >>>>>>>>>>> The last sentence in the para provides explanation why the attempts
> >>>>>>>>>>> to resync should be limited. I think it should be somehow
> >>>>>>>>>>> emphasized that this is the reason for SHOULD.
> >>>>>>>>>>>
> >>>>>>>>>>> PERHAPS:
> >>>>>>>>>>> Implementations SHOULD limit the attempts to resync, because if the
> >>>>>>>>>>> injection attack is ongoing, then there is a high probability that
> >>>>>>>>>>> the resync process will not succeed or will quickly come under attack
> >>>>>>>>>>> again.
> >>>>>>>>>>>
> >>>>>>>>>>> 24. Just a suggestion: draft-ietf-uta-rfc7525bis-11 is in the RFC Editor queue
> >>>>>>>>>>> and hopefully will be published soon. Our document has an informative
> >>>>>>>>>>> reference to it. Probably we can wait a bit and reference an RFC instead of a draft?
> >>>>>>>>>>> Tommy, your opinion?
> >>>>>>>>>>
> >>>>>>>>>> I think it’s fine if they can align easily, but it is fine to reference a draft if for some reason
> that
> >>>>>>>>> document will be more delayed.
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>> Tommy
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Valery.
> >>>>>>>>>>>
> >>>>>>>>>>>> Thank you.
> >>>>>>>>>>>>
> >>>>>>>>>>>> RFC Editor/mc/mf
> >>>>>>>>>>>>
> >>>>>>>>>>>> *****IMPORTANT*****
> >>>>>>>>>>>>
> >>>>>>>>>>>> Updated 2022/09/30
> >>>>>>>>>>>>
> >>>>>>>>>>>> RFC Author(s):
> >>>>>>>>>>>> --------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> Instructions for Completing AUTH48
> >>>>>>>>>>>>
> >>>>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed and
> >>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.
> >>>>>>>>>>>> If an author is no longer available, there are several remedies
> >>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> >>>>>>>>>>>>
> >>>>>>>>>>>> You and you coauthors are responsible for engaging other parties
> >>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
> >>>>>>>>>>>> your approval.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Planning your review
> >>>>>>>>>>>> ---------------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review the following aspects of your document:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  RFC Editor questions
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor
> >>>>>>>>>>>> that have been included in the XML file as comments marked as
> >>>>>>>>>>>> follows:
> >>>>>>>>>>>>
> >>>>>>>>>>>> <!-- [rfced] ... -->
> >>>>>>>>>>>>
> >>>>>>>>>>>> These questions will also be sent in a subsequent email.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Changes submitted by coauthors
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please ensure that you review any changes submitted by your
> >>>>>>>>>>>> coauthors.  We assume that if you do not speak up that you
> >>>>>>>>>>>> agree to changes submitted by your coauthors.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Content
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review the full content of the document, as this cannot
> >>>>>>>>>>>> change once the RFC is published.  Please pay particular attention to:
> >>>>>>>>>>>> - IANA considerations updates (if applicable)
> >>>>>>>>>>>> - contact information
> >>>>>>>>>>>> - references
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Copyright notices and legends
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review the copyright notice and legends as defined in
> >>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
> >>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/).
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Semantic markup
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of
> >>>>>>>>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
> >>>>>>>>>>>> and <artwork> are set correctly.  See details at
> >>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Formatted output
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
> >>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is
> >>>>>>>>>>>> reasonable.  Please note that the TXT will have formatting
> >>>>>>>>>>>> limitations compared to the PDF and HTML.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Submitting changes
> >>>>>>>>>>>> ------------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> >>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties
> >>>>>>>>>>>> include:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  your coauthors
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  [e-mail] (the RPC team)
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  other document participants, depending on the stream (e.g.,
> >>>>>>>>>>>> IETF Stream participants are your working group chairs, the
> >>>>>>>>>>>> responsible ADs, and the document shepherd).
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  [e-mail], which is a new archival mailing list
> >>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion
> >>>>>>>>>>>> list:
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  More info:
> >>>>>>>>>>>>   https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  The archive itself:
> >>>>>>>>>>>>   https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>>>>>>>>>>
> >>>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
> >>>>>>>>>>>>   of the archiving of messages (e.g., to discuss a sensitive matter).
> >>>>>>>>>>>>   If needed, please add a note at the top of the message that you
> >>>>>>>>>>>>   have dropped the address. When the discussion is concluded,
> >>>>>>>>>>>>   [e-mail] will be re-added to the CC list and
> >>>>>>>>>>>>   its addition will be noted at the top of the message.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You may submit your changes in one of two ways:
> >>>>>>>>>>>>
> >>>>>>>>>>>> An update to the provided XML file
> >>>>>>>>>>>> — OR —
> >>>>>>>>>>>> An explicit list of changes in this format
> >>>>>>>>>>>>
> >>>>>>>>>>>> Section # (or indicate Global)
> >>>>>>>>>>>>
> >>>>>>>>>>>> OLD:
> >>>>>>>>>>>> old text
> >>>>>>>>>>>>
> >>>>>>>>>>>> NEW:
> >>>>>>>>>>>> new text
> >>>>>>>>>>>>
> >>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit
> >>>>>>>>>>>> list of changes, as either form is sufficient.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem
> >>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text,
> >>>>>>>>>>>> and technical changes.  Information about stream managers can be found in
> >>>>>>>>>>>> the FAQ.  Editorial changes do not require approval from a stream manager.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Approving for publication
> >>>>>>>>>>>> --------------------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating
> >>>>>>>>>>>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> >>>>>>>>>>>> as all the parties CCed on this message need to see your approval.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Files
> >>>>>>>>>>>> -----
> >>>>>>>>>>>>
> >>>>>>>>>>>> The files are available here:
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.xml
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.html
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.pdf
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.txt
> >>>>>>>>>>>>
> >>>>>>>>>>>> Diff file of the text:
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-diff.html
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-rfcdiff.html (side by side)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Diff of the XML:
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329-xmldiff1.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> The following files are provided to facilitate creation of your own
> >>>>>>>>>>>> diff files of the XML.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.original.v2v3.xml
> >>>>>>>>>>>>
> >>>>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates
> >>>>>>>>>>>> only:
> >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9329.form.xml
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Tracking progress
> >>>>>>>>>>>> -----------------
> >>>>>>>>>>>>
> >>>>>>>>>>>> The details of the AUTH48 status of your document are here:
> >>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9329
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please let us know if you have any questions.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thank you for your cooperation,
> >>>>>>>>>>>>
> >>>>>>>>>>>> RFC Editor
> >>>>>>>>>>>>
> >>>>>>>>>>>> --------------------------------------
> >>>>>>>>>>>> RFC9329 (draft-ietf-ipsecme-rfc8229bis-09)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Title            : TCP Encapsulation of IKE and IPsec Packets
> >>>>>>>>>>>> Author(s)        : T. Pauly, V. Smyslov
> >>>>>>>>>>>> WG Chair(s)      : Yoav Nir, Tero Kivinen
> >>>>>>>>>>>>
> >>>>>>>>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >