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

[Megan Ferguson <[e-mail]>]

Authors,

We just wanted to check back on whether you would like to continue to wait publication of this document or go forward with a pointer to the draft version of draft-ietf-uta-rfc7525bis-11?  It is currently in RFC-EDITOR state (not yet released to authors for review).  We cannot estimate the length of AUTH48.  

Please let us know how you would like to proceed.

>> 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.


Thank you.

RFC Editor/mf


> On Oct 25, 2022, at 2:49 PM, Roman Danyliw <[e-mail]> wrote:
> 
> Hi!
> 
> Approved.  This latest diff to Appendix B is fine.
> 
> Roman 
> 
>> -----Original Message-----
>> From: Megan Ferguson <[e-mail]>
>> Sent: Wednesday, October 12, 2022 9:59 AM
>> To: Valery Smyslov <[e-mail]>; Tommy Pauly <[e-mail]>;
>> [e-mail]
>> Cc: RFC Errata System <[e-mail]>; [e-mail];
>> Tero Kivinen <[e-mail]>; [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.
>> 
>> 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:rfc-editor@rfc-
>> editor.org]
>>>>>>>>>>>>>> Sent: Saturday, October 01, 2022 12:18 AM
>>>>>>>>>>>>>> To: [e-mail]; [e-mail]
>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]; ipsecme-
>> [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
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>