TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets
draft-ietf-ipsecme-rfc8229bis-09

[Ballot comment]
I reviewed the diff to RFC 8229 and didn't notice anything of concern to the ART area.

I concur with Eric about the shepherd writeup, and in particular the unanswered part of the first question.

[Ballot discuss]
Do not panic!

This should be trivial to address, probably by pointing me at something that I missed (very likely), or by dropping in a sentence to two into the document.

The document starts off with: "This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP."

As far as I can tell (and again, it is likely that I missed something!) it doesn't really discuss the fact that the operator may be intentionally blocking IKE.
For example, many enterprises really don't want their users to be building IPSec tunnels into/out of their network because they want to do DLP, firewalling, and so they block IKE to block IPSec. This may be a flawed concept, and you and I may think that it's a losing battle, but I really think that the document needs to at least discuss that this potentially bypasses intentional security controls.

See: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

[Ballot comment]
# SEC AD comments for draft-ietf-ipsecme-rfc8229bis-07
CC @paulwouters


## Comments

I have a number of comments and some small fixes. While the appendix fixes technically
might be a DISCUSS, I have faith the authors will pick it up from the comment section too :)



###

The Length field plus non-ESP marker plus IKE packet is called "message"
at the start in Section 3, but in Section 3.1 it is called an "IKE Header Format"
and "IKE message" is used to denote the non-ESP marker plus IKE Header _without_
the Length field. And then it uses "IKE Packet" in the Length field description to
mean the thing without the Length and non-esp marker. And then the figure uses
"IKE header" were it should probably say "IKE packet".

These names should be made more consistent :)

###

Section 3.1 and Section 3.2 state:

        The value in the Length field MUST NOT be 0 or 1.

In fact, a lot more values are clearly wrong, like anything
under 4 which cannot contain the non-esp marker. Then there
is the size of the minimum UDP IKE or ESP packet as well.
Why are these two values singled out?

###

Section 3.1 states:

        The IKE header is preceded by a 16-bit Length field in network byte
        order that specifies the length of the IKE message

Section 3.2 states:

        The ESP header is preceded by a 16-bit Length field in network byte
        order that specifies the length of the ESP packet

Why don't both say either "message" or "packet"? I would say "packet" for both.

###

Section 4:

        at the beginning of any stream of IKE and ESP messages.

I would s/any/the TCP/ to avoid people thinking of the inner streams and thinking
they need to repeat the IKETCP prefix for each burst of traffic - this mistake was
made once in the first version of the Linux kernel code.

###

Section 5:

        when it has been configured to be used with specific IKE peers.

I would say "when it has been configured to be optionally used with specific IKE peers.
Otherwise, implementers might think it needs to be an on/off setting instead of a
"may be used when udp is blocked" setting.

Similarly:

        If a Responder is configured to use TCP encapsulation,

I would say "is configured to accept TCP encapsulation"

(nit: "it is recommended that Initiators should only use TCP encapsulation" can be
written more clearly by omitting the "should")

###

        If TCP encapsulation is being used for a specific IKE SA, all
        messages for that IKE SA and its Child SAs MUST be sent over a TCP
        connection

I think "messages" here is unclear. It might be confused for control messages
(IKE) only and not mean data (ESP) packets. I would use:

        If TCP encapsulation is being used for a specific IKE SA, all
        IKE and ESP packets for that IKE SA and its Child SAs MUST be
        encapsulated and sent over this TCP connection


Note that technically, this is not true because if you want to see if
UDP becomes available again, you have to send an IKE packet over UDP,
but it is probaly clearer not to mention that here.
###

Section 6.1

        using the configured TCP port.

I would say "using the preconfigured Responder's TCP port"

###

        The first bytes sent on the stream MUST be the stream prefix value

Maybe again say "TCP stream" ?

This also made me realize that Section 4. could use a diagram to ensure people do it
right, eg:

        Initiator                      Responder

        Prefix|Length|non-ESP marker|IKE packet ->
                                <- Length|non-ESP marker|IKE packet
        Length|non-ESP marker|IKE packet ->
                                <- Length|non-ESP marker|IKE packet
                                [...]
        Length|ESP packet ->
                          <- Length|ESP packet

###

        If a TCP connection is being used to resume a previous IKE session,

I would use "continue" instead of "resume" to avoid confusion with Session Resumption.
Also instead of "previous IKE session" maybe say "previous encapsulation session"?

Note: at this point it has also not been made clear in the draft whether multiple
IKE SAs can use the same encapsulation session. That information should probably
have been conveyed earlier in the document. This is only stated at the end of Section 6.1

###

        Implementations
        SHOULD NOT tear down a connection if only a single ESP message has an
        unknown SPI, since the SPI databases may be momentarily out of sync.

This advise might be difficult to follow. If this out of sync really happens,
it would be likely that a number of ESP packets would be seen before the IKE
packet comes in that syncs up the SPI. (assuming this out of sync issue happens
when the TCP responder is also the IKE responder to a rekey and once it rekeyed
and installed a new IPsec SA it starts sending ESP packets before it sends its
IKE rekey reply, or a number of smaller ESP packets arrive sooner somehow?)

###

nit:

        if the Responder chooses to send Cookie request

add " a ", eg "a Cookie request".

###

Section 6.3 talks a lot about how COOKIE stuff is both useless for TCP
and can fail in mysterious new ways. Why not simplify things and say
"cookies must (should?)  not be verified and fully ignored when over TCP,
and only puzzles should be verified"

###

Section 6.3.1 assumes the responder knows the rough CPU power of its
clients and that these are all in the same ballpark. Is this really
the case?

###

section 6.4

nit: in case it receives error notification -> in case it receives an error notification

###

section 6.5:

        When negotiating over UDP port 500, IKE_SA_INIT packets include
        NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads

An IKE peer is allowed to skip port 500 and use 4500 directly. It would
still send the NAT payloads. I would write "When negotiating over UDP,
IKE_SA_INIT packets include".

###

How about sharing an alternative to the transport mode checksum fixups:

        Implementations MAY use the information that a NAT is present to omit
        sending USE_TRANSPORT over TCP, and thus enforce tunnel mode IPsec SA's
        to avoid the need for checksum fixups for encapsulated packets inside TCP.

###

I would personally split out NAT-T and keepalive into its own seperate sections.
People already confuse them too often and it is really two completely different
things.

###

Section 6.6

        NAT keep-alive packets over a TCP-
        encapsulated IPsec connection will be sent as an ESP message with a
        one-octet-long payload with the value 0xFF.

I don't think you can call it an ESP message? I understand you say this so
implementers will know there is no non-ESP marker, but its really not an ESP message.

Maybe something like:

        NAT keep-alive packets over a TCP-
        encapsulated IPsec connection will be sent as a one-octet-long payload
        with the value 0xFF, preceded by the two byte Length specifying a length of 1.

###

        for which purpose the standard IKEv2 mechanism of
        exchanging empty INFORMATIONAL messages is used

I believe these INFORMATIONALs are not neccessarilly empty, even though they started
out that way. I would just leave out the word "empty".

###

Section 6.7 mentions QoS, but we are also working on per-CPU IPsec SA's, which would
have the same problem. Perhaps that can be worked into the existing text? I would
perhaps also state here that the effects on performance are not very important, as doing
TCP encapsulation in itself is already reducing performance significantly.

###

nit: Section 7.4 starts with a broken reference to [RFC6311]

###

Section 8:

        TCP encapsulation of IKE should therefore use common TCP behaviors to
        avoid being dropped by middleboxes.

I'm not sure why this text is here? Perhaps you mean to say:

        If the IKE implementation has its own minimal implementation of TCP,
        it SHOULD still use common TCP behaviors to avoid being dropped by middleboxes.

That at least clarifies that one needs to do nothing if one uses the OS TCP stack.

###

Section 9:

        Implementations SHOULD favor using direct ESP
        or UDP encapsulation over TCP encapsulation whenever possible.

I understand the SHOULD relates to "whenever possible", but since we are talking
about "SHOULD favor", I think we can say "MUST favor". It's only favoring after all :)

###

Section 10:

nit: [RFC5961] is a broken reference.

nit: it will be re-created by TCP Originator [add "the"]

###

        Alternatively, implementations MAY try to re-sync after they receive
        unknown SPIs by searching the TCP stream [...]

This is an odd paragraph. "You can do this, but really it is futile". I would
remove it.

###

        An attacker capable of blocking UDP traffic can force peers to use
        TCP encapsulation, thus degrading the performance and making the
        connection more vulnerable to DoS attacks.  Note, that attacker
        capable to modify packets on the wire or to block them can prevent
        peers to communicate regardless of the transport being used.

I don't think this paragraph is useful either. There is nothing an implementer
can do with this information.

###

        TCP Responders should be careful to ensure that (1) the stream prefix
        "IKETCP" uniquely identifies incoming streams as streams that use the
        TCP encapsulation protocol and (2) they are not running any other
        protocols on the same listening port (to avoid potential conflicts).

I thought (2) was actually a good thing. One can run a HTTPS server while also
acting as a VPN server and demultiplex based on the prefix. So I don't think the
advise in (2) is appropriate and just limits the deployment possibilities.

###

        The successful delivery of valid IKE or ESP messages over a new TCP connection is used

I think this should say "valid new IKE or ESP messages" (as explained right below it)

Though if an attacker can block packets, they can take a valid new message, and stuff it
in their own source IP packet and send it to cause the TCP stream to be deviated. Perhaps
recommend sending a liveness probe once a TCP connection is redirected? (although even
then, we only detect we are dead - we cannot go back to the original stream)

###

Section B.4


    1)  ----------------- IKE_SA_INIT Exchange -----------------
        (IP_I1:UDP4500 -> IP_R:UDP4500)
        Non-ESP Marker          ----------->
        Initial IKE_AUTH

The marker ------ foo ------ has been used to describe what follows, but what
follows here is an IKE_AUTH exchange, not an IKE_SA_INIT


    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
                            HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                N(NAT_DETECTION_DESTINATION_IP) }

This seems to miss the line "INFORMATIONAL" on the responder side. Same
for step 7.

  1.  During the IKE_SA_INIT exchange, the client and server exchange
      MOBIKE_SUPPORTED notify payloads to indicate support for MOBIKE.

See above, step 1 shows an IKE_AUTH, not IKE_SA_INIT so does not match this description.


  6.  The client sends the UPDATE_SA_ADDRESSES notify payload on the
      TCP-encapsulated connection.

I find this wording misleading. The UPDATE_SA_ADDRESSES payload is not send on the TCP connection,
but a whole IKE message containing this payload is sent.

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07
CC @evyncke

Thank you for the work put into this document. There must be several use cases for it.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus, but it lacks the justification of the intended status.

Thanks as well to Brian Haberman for his INT directorate review, his review has a 'ready' status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### UDP blocked even with QUIC

As there are more and more traffic relying on QUIC (a wild guess of mine...), is it still the case that middle boxes are blocking UDP ? Just out of curiosity... feel free to ignore.

### Section 1

```
Devices on these
  networks that need to use IPsec (to access private enterprise
  networks, to route Voice over IP calls to carrier networks, or
  because of security policies) are unable to establish IPsec SAs.
```

The above appears like an exhaustive list while it is not. Suggest to add ", etc.".

### Section 1

`Some peers default to using UDP encapsulation` is "peer" so well-defined in the IPsec world ? 'some' is also rather vague, perhaps cite one implementation ? or use "some peers may default to" ?

### Section 2

Should "Implementations of this specification" be used in `Implementations MUST support TCP encapsulation on TCP port 4500, which is reserved for IPsec NAT traversal.` ?

### Section 3 No AH

Even if AH is nearly no more used, I wonder whether there is a reason why AH is not supported by this I-D.

The sentence about AH should really come earlier in the document.

### Section 3

```
  Although a TCP stream may be able to send very long messages,
  implementations SHOULD limit message lengths to typical UDP datagram
  ESP payload lengths.
```

What is the 'typical' length ?

### Section 3.1

Suggest to add a description of "Non-ESP" header field below the description of the "length" field rather than in the text above.

### Section 5.1

`Since UDP is the preferred method of transport for IKE messages,` hem... previous text (and common sense) stated that direct is the preferred method.

### Section 6.1 what about IP address changes ?

```
  Since new TCP connections
  may use different ports due to NAT mappings or local port allocations
  changing, the TCP Responder MUST allow packets for existing SAs to be
  received from new source ports.
```
For some NAT devices (or IPv6 nodes w/o NAT but with temporary addresses), the IP address could also change. This document should describe what to do in this case.

### Section 6.5

The very last sentence deserves a paragraph on its own.

### Section 6.7

Please add that the DF bit is obvioulsy only for IPv4 (Hi, Tommy, I had to insert my mandatory IPv6-related comment ;-) )

### Section 9.3

I am not a transport person, but I would have used "MUST NOT" rather than "MAY NOT" in:
```
  Individual packets
  SHOULD NOT use different markings than the rest of the connection,
  since packets with different priorities may be routed differently and
  cause unnecessary delays in the connection.
```

Even if somehow obvious, should there be a statement about the IPv6 Flow-ID header field ?

### TCP Fast Open support

Is TCP fast open supported by this doc ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# Internet AD comments for {draft-ietf-ipsecme-rfc8229bis-07}
CC @ekline

## Comments

### S1.1

* In "Cellular Network Access", is there a particular TS number to reference
  for this claim about preferring TLS for IWLAN setup?

### S2

* "Implementations MUST support TCP encapsulation on TCP port 4500":

  which implementations, exactly?  Only TCP-supporting implementations, or
  all IKE/IPsec implementations?

### S6.1,6.3+,7.1,7.3,B.1,B.3,B.4

* Can the "IKETCP" be sent in a 7413 Fast Open (say, when reconnecting)?

  Can other IKE initiating messages be included with the SYN?

  Alternatively: are there concerns with use of Fast Open such that it should
  be forbidden?  I don't see any mention of Fast Open anywhere in this doc,
  and I kinda think /something/ should maybe be said, but IANATP... (I am not
  a transport person)

### App. A

* Is there an ALPN that is typically used with TLS?

## Nits

### S3.1

* "MUST close TCP connection" -> "MUST close the TCP connection"

### S6.4

* "after receiving error notification" ->
  "after receiving an error notification"?

### S6.7

* "stack manages DF bit" -> "stack manages the DF bit"

### S9.1

* "between all flows" -> "among all flows", perhaps

### S10

* "Note, that attacker capable to modify" ->
  "Note that an attacker able to modify"

### Acknowledgements

* It seems a bit weird for an Author to Acknowledge himself (Tommy Pauly),
  but oh well  ;-)

  :-)

[Ballot comment]
Thanks to Joe Touch for the TSVART review. There are no showstoppers in this document,
but some non-normative text makes inaccurate statements about TCP and RFC6040, and there
are some odd decisions with respect to TLS that are worth asking about:

(Sec 9.1)
"TCP-in-TCP can also lead to "TCP meltdown", where stacked instances
  of TCP can result in significant impacts to performance
  [TCP-MELTDOWN].  For the case in this document, such meltdown can
  occur when the window size of the outer TCP connection is smaller
  than the window sizes of the inner TCP connections.  The resulting
  interactions can lead to packets backing up in the outer TCP
  connection's send buffers.  In order to limit this effect, the outer
  TCP connection should have limits on its send buffer size and on the
  rate at which it reduces its window size."

Which "window" are you referring to? Receive window, congestion window, or the send buffer? My reading of [TCP-MELTDOWN] is that the tunnel ingress should set its send buffer size to the BDP of the tunnel, which is easier said than done. It appears you are using "window" and "send buffer" interchangeably here in a way that is confusing.

(9.5)
Implementations SHOULD follow the ECN compatibility mode for tunnel
  ingress as described in [RFC6040].  In compatibility mode, the outer
  tunnel TCP connection marks its packet headers as not ECN-capable.
  If upon egress, the arriving outer header is marked with CE, the
  implementation will drop the inner packet, since there is not a
  distinct inner packet header onto which to translate the ECN
  markings.

This is not an accurate summary of compatibility mode. In compatibility mode,
the outer packet is marked Not-ECT, which means it will not be marked CE. In
normal mode, the outer packet is marked as the inner, and this might result in
an outer CE marking.

It's a shame that there is no attempt to figure out a mapping between inner and
outer that would make normal mode work, as this reviewer is optimistic that ECN marks
will become increasingly important. But regardless, this section should be clear and
make correct statements.

(Appendix A) Why not provide an in-band way to determine TLS support? There could be
another port number, or different magic bytes to indicate that TLS handshake messages
follow.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-rfc8229bis-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

The existing registration for TCP port 4500:

Keyword Decimal Description
----------- -------- -------------------
ipsec-nat-t 4500/tcp IPsec NAT-Traversal

will have its reference changed from RFC8229 to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-05-31):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-rfc8229bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TCP Encapsulation of IKE and IPsec Packets) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'TCP
Encapsulation of IKE and IPsec Packets'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-31. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a method to transport Internet Key Exchange
  Protocol (IKE) and IPsec packets over a TCP connection for traversing
  network middleboxes that may block IKE negotiation over UDP.  This
  method, referred to as "TCP encapsulation", involves sending both IKE
  packets for Security Association establishment and Encapsulating
  Security Payload (ESP) packets over a TCP connection.  This method is
  intended to be used as a fallback option when IKE cannot be
  negotiated over UDP.

  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.  This documents obsoletes RFC 8229.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    Proposed Standard as indicated on the title page header and
    in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes a method to transport Internet Key Exchange
  Protocol (IKE) and IPsec packets over a TCP connection for traversing
  network middleboxes that may block IKE negotiation over UDP.  This
  method, referred to as "TCP encapsulation", involves sending both IKE
  packets for Security Association establishment and Encapsulating
  Security Payload (ESP) packets over a TCP connection.  This method is
  intended to be used as a fallback option when IKE cannot be
  negotiated over UDP.

  TCP encapsulation for IKE and IPsec was defined in [RFC8229].  This
  document updates the specification for TCP encapsulation by including
  additional clarifications obtained during implementation and
  deployment of this method.  This documents obsoletes RFC8229.

Working Group Summary:

    This work started in 2018 with document "Clarifications and Implementation
    Guidelines for using TCP Encapsulation in IKEv2", but during the process IPsecME
    WG decided to make bis document of RFC8229 instead as some of the clarifications
    were actually modifying the protocol. The first version of the rfc8229bis document
    was published as individual draft in May 2020 as individual draft, and  it was adopted
    by the WG in April 2021.

Document Quality:

    There are several implementations of the RFC8229 and during those implementations
    few issues were found that required modifications. Because of that this RFC8229bis
    document was created, when it was obvious that simple clarifications are not enough.
    There are already some implementations implementing changes described in this bis
    document.

Personnel:

  Shepherd: Tero Kivinen
  Responsible AD: Roman Danyliw

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document was a subject of several reviews in the WG.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  Some transport area review might be needed, but as this document uses
  TCP without modifications there should not be big issues there.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    All authors confirmed that they are not aware of any IPR related to this
    draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Idnits reports few warnings, all of them seem to be false positive.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    None are applicable.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    Yes. This document will obsolete the RFC8229.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    This document requests the IANA to update references for already
    allocated TCP Port Number to this document.

    Requests to IANA are consistent with document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    No new registries are defined by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

    The document contains no YANG module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    Proposed Standard as indicated on the title page header and
    in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes a method to transport Internet Key Exchange
  Protocol (IKE) and IPsec packets over a TCP connection for traversing
  network middleboxes that may block IKE negotiation over UDP.  This
  method, referred to as "TCP encapsulation", involves sending both IKE
  packets for Security Association establishment and Encapsulating
  Security Payload (ESP) packets over a TCP connection.  This method is
  intended to be used as a fallback option when IKE cannot be
  negotiated over UDP.

  TCP encapsulation for IKE and IPsec was defined in [RFC8229].  This
  document updates the specification for TCP encapsulation by including
  additional clarifications obtained during implementation and
  deployment of this method.  This documents obsoletes RFC8229.

Working Group Summary:

    This work started in 2018 with document "Clarifications and Implementation
    Guidelines for using TCP Encapsulation in IKEv2", but during the process IPsecME
    WG decided to make bis document of RFC8229 instead as some of the clarifications
    were actually modifying the protocol. The first version of the rfc8229bis document
    was published as individual draft in May 2020 as individual draft, and  it was adopted
    by the WG in April 2021.

Document Quality:

    There are several implementations of the RFC8229 and during those implementations
    few issues were found that required modifications. Because of that this RFC8229bis
    document was created, when it was obvious that simple clarifications are not enough.
    There are already some implementations implementing changes described in this bis
    document.

Personnel:

  Shepherd: Tero Kivinen
  Responsible AD: Benjamin Kaduk

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document was a subject of several reviews in the WG.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  Some transport area review might be needed, but as this document uses
  TCP without modifications there should not be big issues there.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    All authors confirmed that they are not aware of any IPR related to this
    draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Idnits reports few warnings, all of them seem to be false positive.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    None are applicable.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    Yes. This document will obsolete the RFC8229.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    This document requests the IANA to update references for already
    allocated TCP Port Number to this document.

    Requests to IANA are consistent with document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    No new registries are defined by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

    The document contains no YANG module.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

    Proposed Standard as indicated on the title page header and
    in the datatracker.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes a method to transport Internet Key Exchange
  Protocol (IKE) and IPsec packets over a TCP connection for traversing
  network middleboxes that may block IKE negotiation over UDP.  This
  method, referred to as "TCP encapsulation", involves sending both IKE
  packets for Security Association establishment and Encapsulating
  Security Payload (ESP) packets over a TCP connection.  This method is
  intended to be used as a fallback option when IKE cannot be
  negotiated over UDP.

  TCP encapsulation for IKE and IPsec was defined in [RFC8229].  This
  document updates the specification for TCP encapsulation by including
  additional clarifications obtained during implementation and
  deployment of this method.  This documents obsoletes RFC8229.

Working Group Summary:

    This work started in 2018 with document "Clarifications and Implementation
    Guidelines for using TCP Encapsulation in IKEv2", but during the process IPsecME
    WG decided to make bis document of RFC8229 instead as some of the clarifications
    were actually modifying the protocol. The first version of the rfc8229bis document
    was published as individual draft in May 2020 as individual draft, and  it was adopted
    by the WG in April 2021.

Document Quality:

    There are several implementations of the RFC8229 and during those implementations
    few issues were found that required modifications. Because of that this RFC8229bis
    document was created, when it was obvious that simple clarifications are not enough.
    There are already some implementations implementing changes described in this bis
    document.

Personnel:

  Shepherd: Tero Kivinen
  Responsible AD: Benjamin Kaduk

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No. The document was a subject of several reviews in the WG.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  Some transport area review might be needed, but as this document uses
  TCP without modifications there should not be big issues there.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    All authors confirmed that they are not aware of any IPR related to this
    draft.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

    No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    Idnits reports few warnings, all of them seem to be false positive.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

    None are applicable.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    Yes. This document will obsolete the RFC8229.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    This document requests the IANA to update references for already
    allocated TCP Port Number to this document.

    Requests to IANA are consistent with document's body.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    No new registries are defined by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    No automated checks are applicable.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

    The document contains no YANG module.