Skip to main content

TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-10

Revision differences

Document history

Date Rev. By Action
2017-08-09
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-08-01
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-07-18
10 Tero Kivinen Added to session: IETF-99: ipsecme  Fri-1150
2017-07-14
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2017-06-27
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-06-27
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-06-20
10 (System) RFC Editor state changed to EDIT
2017-06-20
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-06-20
10 (System) Announcement was received by RFC Editor
2017-06-19
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-06-19
10 (System) IANA Action state changed to In Progress
2017-06-19
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-06-19
10 Amy Vezza IESG has approved the document
2017-06-19
10 Amy Vezza Closed "Approve" ballot
2017-06-19
10 Amy Vezza Ballot approval text was generated
2017-06-17
10 Eric Rescorla IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-06-14
10 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-)

Two more tiny things that I would …
[Ballot comment]
Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-)

Two more tiny things that I would recommend to change but can be done by the RFC editor:

OLD
"Implementations SHOULD favor using direct ESP
  or UDP encapsulation over TCP encapsulation whenever possible."
NEW
"Implementations SHOULD use direct ESP
  or UDP encapsulation over TCP encapsulation whenever possible."

OLD
"TCP Responders should be careful to ensure that the stream prefix
  "IKETCP" uniquely identifies incoming streams as ones that use the
  TCP encapsulation protocol, and they are not running any other
  protocols on the same listening port that could conflict with this."
NEW
"TCP Responders should be careful to ensure that the stream prefix
  "IKETCP" uniquely identifies incoming streams as ones that use the
  TCP encapsulation protocol, and MUST not run any other
  protocols on the same listening port that could conflict with this."
2017-06-14
10 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-06-14
10 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-06-14
10 Mirja Kühlewind
[Ballot comment]
Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-)

Two more tiny things that I would …
[Ballot comment]
Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-)

Two more tiny things that I would recommend to change but can be done by the RFC editor:

OLD
"Implementations SHOULD favor using direct ESP
  or UDP encapsulation over TCP encapsulation whenever possible."
NEW
"Implementations SHOULD use direct ESP
  or UDP encapsulation over TCP encapsulation whenever possible."

OLD
"TCP Responders should be careful to ensure that the stream prefix
  "IKETCP" uniquely identifies incoming streams as ones that use the
  TCP encapsulation protocol, and they are not running any other
  protocols on the same listening port that could conflict with this."
NEW
"TCP Responders should be careful to ensure that the stream prefix
  "IKETCP" uniquely identifies incoming streams as ones that use the
  TCP encapsulation protocol, and MUST not run any other
  protocols on the same listening port that could conflict with this."
2017-06-14
10 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2017-05-31
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-05-31
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2017-05-31
10 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-10.txt
2017-05-31
10 (System) New version approved
2017-05-31
10 (System) Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha
2017-05-31
10 Tommy Pauly Uploaded new revision
2017-05-04
09 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2017-04-27
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup
2017-04-27
09 Benoît Claise
[Ballot comment]
Just sharing some random thoughts. No action is needed here.

  Most implementations should use TCP
  Encapsulation only on networks where negotiation …
[Ballot comment]
Just sharing some random thoughts. No action is needed here.

  Most implementations should use TCP
  Encapsulation only on networks where negotiation over UDP has been
  attempted without receiving responses from the peer, or if a network
  is known to not support UDP.

On one side, some companies deny IKE/IPSEC on purpose.
In the future, they will just block port 4500.

  This document leaves the selection of TCP ports up to
  implementations.  It is suggested to use TCP port 4500, which is
  allocated for IPsec NAT Traversal.

Well, if any port can be used, that becomes difficult.
On the other hand, just is like any tunneling mechanisms, which exist for some time already.

QoS within TCP will be a real operational issues, as inner to outer ToS mapping is not possible.
2017-04-27
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-04-26
09 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-04-26
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-04-26
09 Alia Atlas [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from No Record
2017-04-26
09 Spencer Dawkins [Ballot comment]
I support Mirja's Discuss, and am happy with the direction that discussing is headed.
2017-04-26
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-04-26
09 Ben Campbell
[Ballot comment]
Update: Thanks for proposing text to address my DISCUSS point. I've cleared the discuss, with the assumption the proposed edit (or similar) will …
[Ballot comment]
Update: Thanks for proposing text to address my DISCUSS point. I've cleared the discuss, with the assumption the proposed edit (or similar) will make it into the draft.

Substantive Comments:

-2:
-- 2nd bullet (and elsewhere)
I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.)

-- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations."
I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability.

-3, first paragraph:
Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.)

-4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol?

-6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point.

-8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change?

- Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?)

Editorial Comments:

- Please expand IKE and ESP on first mention in both the abstract and body.

-3, 2nd paragraph: s/"may be able"/"is able".

-3.2, " The SPI field in the ESP header MUST NOT be a zero value."
Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. 

-5.1: "...SHOULD always attempt negotiate IKE over UDP first"
This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords.

-6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references.

-10, title: Please expand DPD.

-12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section.

- Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant.
2017-04-26
09 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss
2017-04-26
09 Alia Atlas [Ballot comment]
I agree with Mirja's discuss.
2017-04-26
09 Alia Atlas Ballot comment text updated for Alia Atlas
2017-04-26
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-04-26
09 Alexey Melnikov
[Ballot comment]
2.  Configuration

  o  Optionally, an extra framing protocol to use on top of TCP to
      further encapsulate the stream …
[Ballot comment]
2.  Configuration

  o  Optionally, an extra framing protocol to use on top of TCP to
      further encapsulate the stream of IKE and IPsec packets.  See
      Appendix A for a detailed discussion.

As Appendix A just talks about TLS, why not say this here explicitly? The sentence above make it sound like this
is something outside of scope for the document and Appendix A talks about generic way to encapsulate.
2017-04-26
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-04-25
09 Ben Campbell
[Ballot discuss]
I have one (hopefully easy) point that I think needs to be fixed before progressing.

Section 6, paragraph 6 says : "... if …
[Ballot discuss]
I have one (hopefully easy) point that I think needs to be fixed before progressing.

Section 6, paragraph 6 says : "... if the TCP Originator stream is missing the stream prefix, or message frames are not parsable as IKE or ESP messages), it MUST close the TCP connection."

IIUC, the entire point of having the stream prefix is to allow the TCP responder to demux between this protocol, and some other protocol that would normally run on that port. Saying it MUST close the TCP session seems to completely remove that value. I assume people meant to allow the respondent to delegate a stream out to some other protocol handler if the prefix is not present?
2017-04-25
09 Ben Campbell
[Ballot comment]
Substantive Comments:

-2:
-- 2nd bullet (and elsewhere)
I think this needs a discussion about how those configured ports are likely to be …
[Ballot comment]
Substantive Comments:

-2:
-- 2nd bullet (and elsewhere)
I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.)

-- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations."
I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability.

-3, first paragraph:
Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.)

-4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol?

-6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point.

-8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change?

- Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?)

Editorial Comments:

- Please expand IKE and ESP on first mention in both the abstract and body.

-3, 2nd paragraph: s/"may be able"/"is able".

-3.2, " The SPI field in the ESP header MUST NOT be a zero value."
Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. 

-5.1: "...SHOULD always attempt negotiate IKE over UDP first"
This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords.

-6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references.

-10, title: Please expand DPD.

-12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section.

- Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant.
2017-04-25
09 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2017-04-25
09 Kathleen Moriarty
[Ballot comment]
Thank you for documenting this practice to improve interoperability.  This practice has been in place for a while and I think this is …
[Ballot comment]
Thank you for documenting this practice to improve interoperability.  This practice has been in place for a while and I think this is a helpful document.  I have a few comments.

I think it would be good for the introduction to be more explicit on where the problem lies that has resulted in this common practice of tunneling this traffic through TCP.  The following sentence could be modified:

OLD:
  Many network middleboxes that filter traffic on public
  hotspots block all UDP traffic, including IKE and IPsec, but allow
  TCP connections through since they appear to be web traffic.

NEW (or something along these lines):
  Many network edge  middleboxes that filter traffic on public
  hotspots block all UDP traffic, including IKE and IPsec, but allow
  TCP connections through since they appear to be web traffic.

I think it's important to note that this is happening at the edge in case that is not clear enough with the phrase "public hotspots".  If it's more than the edge where this is happening, and I'm not right about this suggested change, please just say so. 

For section 11 - I think it's worth adding more text to hit on the concerns Warren raised in one of his comments.  Here are some thoughts in case it is helpful:
I agree with Warren that the result of operators not being able to identify this traffic should be mentioned, although this is tricky.  The port discussion in other AD reviews and discouraging the use of 443 may change this to be identifiable traffic over TCP 4500 with the required stream prefix only for legitimate uses, or in reality, 443 if this stays undocumented because of existing implementations.  Warren commented on operators not being able to detect this traffic is an important one, but I think it's fine to say the intent is to circumvent ACLs or firewall rules as opposed to avoiding detection.  Then saying that avoiding detection is a result or unintended side effect. 
Side comment not intended for any new text:  It would be good if operators observed the blocked ports (UDP 500) and figured out that they should open the port, but this has been a problem for some time and not all networks have dedicated operators (who want to fix this and similar issues) or ones with the time and skill sets to fix the problem.
2017-04-25
09 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2017-04-25
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-04-25
09 Mirja Kühlewind
[Ballot discuss]
This draft suggests that ports that are assigned to other services can simply be used. This is not okay. If a port is …
[Ballot discuss]
This draft suggests that ports that are assigned to other services can simply be used. This is not okay. If a port is assigned to a certain service, this service and/or the respective RFC defines how this port is used. Simply changing the specified behavior by requiring a check for a magic number cannot be done without updating the RFC that the port assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as the IANA registry would need to be updated.

Further, as also mentioned in the tsv-art review (Thanks Wes!), this draft does not sufficiently handle the case of TCP in TCP encapsulation. Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

This document is clear and well-written.  It can easily be implemented
based on the description.

There are a few additional issues that should be considered with
advice to implementers in Section 12 on performance considerations:
1) Invisibility of packet loss - Inner protocols that require packet
losses as a signal of congestion (e.g. TCP) will have a challenge due
to not being able to see any packet losses since the outer TCP will
repair them (unless sending into a full outer TCP socket buffer shows
up back to the inner TCP as a packet loss?).
2) Nesting of ECN -  Inner TCP connections will not be able to use
effectively ECN on the portion of the path covered by the outer TCP
connection.
3) Impact of congestion response on aggregate - The general "TCP in
TCP" problem is mentioned, and is mostly appropriate for a single
flow.  If an aggregate of flows is sharing the same outer TCP
connection, there may be additional concerns about how the congestion
response behavior impacts an aggregate of flows, since it may cause a
shared delay spike even to low-rate flows rather than distributing
losses proportional to per-flow throughput.
4) Additional potential for bufferbloat - Since TCP does not bound
latency, some applications in the IPsec-protected aggregate could
drive latency of the shared connection up and impact the aggregate of
flows that may include real-time applications.  The socket buffer for
the outer TCP connection might need to be limited in size to ensure
some bounds?

Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

In the security considerations section, there are several RFCs on
mechanisms to increase robustness to RST attacks and SYN floods that
could be mentioned if it's worthwhile.
2017-04-25
09 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2017-04-24
09 Warren Kumari
[Ballot comment]
Please also see  Mahesh Jethanandani's OpsDir review - https://www.ietf.org
/mail-archive/web/ops-dir/current/msg02602.html

Having run into this issue of middle boxes blocking non-UDP/non-TCP, I think
that …
[Ballot comment]
Please also see  Mahesh Jethanandani's OpsDir review - https://www.ietf.org
/mail-archive/web/ops-dir/current/msg02602.html

Having run into this issue of middle boxes blocking non-UDP/non-TCP, I think
that this is valuable. The document also covers a bunch of the standard
operational and management considerations, and things like MTU issues,
performance implications, etc.; thanks for this.

One thing that I'd like to note is that this makes it significantly harder for
an operator to simply block IPsec, but, well, that's kinda the point I guess... :-)


I did have a number of minor questions and comments:
(bikeshedding) Section 1, Bullet 2: "and ESP packets are sent out over UDP port
4500" - "sent out over" confused me (especially because ESP UDP is somewhat unusual
to begin with)  - perhaps "sent using UDP with source and destination port of 4500"?

Section 1.2: "the role of IKE Initiator and Responder may swap for a given SA
(as with IKE SA Rekeys)" -- a reference to rekeying would be good - perhaps
RFC 7296 ?

Section 4: The table containing "IKETCP" should be referenced (e.g: "containing
the characters "IKETCP" as ASCII values (Figure 3).")

Section 5: "If a Responder is configured to use    TCP encapsulation, it MUST
listen on the configured port(s) in case    any peers will initiate new IKE
sessions." 
s/will// (spurious will)

"all of the endpoints equally support TCP encapsulation." -- what does
  equally" mean? All must do it, same TCP port, etc.?

"MOBIKE" needs a reference.

Section 11: "A network device that monitors up to the application layer will
commonly expect to see HTTP traffic ..." - it might be useful to explain that
this is simply an example. (the same thing happens if non-SMTP is seen on
port 25, etc)
2017-04-24
09 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-04-24
09 Adam Roach
[Ballot comment]
Suggest expanding "IKE" and "ESP" in the Abstract on first use.

The "MUST support dynamically enabling and disabling TCP" in section 8 seems …
[Ballot comment]
Suggest expanding "IKE" and "ESP" in the Abstract on first use.

The "MUST support dynamically enabling and disabling TCP" in section 8 seems unnecessarily strong. Every other normative statement in the document indicating the use of direct ESP or UDP encapsulation is only at a SHOULD level. This "MUST" is the sole statement that would make a TCP-only MOBIKE implementation noncompliant (rather than conditionally compliant), where non-MOBIKE implementations have no such restriction. Is that the intention?

Section 12.2 claims that retransmission is a source of issues for delay-sensitive UDP applications. In practice, the retransmission is just fine; it's the head-of-line blocking that occurs upon packet loss that causes issues. Suggest stating issue in those terms.
2017-04-24
09 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-04-24
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-04-24
09 Eric Rescorla [Ballot comment]
I reviewed this document privately before becoming AD.
2017-04-24
09 Eric Rescorla Ballot comment text updated for Eric Rescorla
2017-04-24
09 Eric Rescorla Ballot has been issued
2017-04-24
09 Eric Rescorla [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla
2017-04-24
09 Eric Rescorla Created "Approve" ballot
2017-04-24
09 Eric Rescorla Ballot writeup was changed
2017-04-21
09 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani.
2017-04-21
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2017-04-21
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani
2017-04-19
09 Francis Dupont Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont.
2017-04-19
09 Jean Mahoney
2017-04-19
09 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2017-04-18
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-04-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2017-04-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jon Mitchell
2017-04-11
09 Mahesh Jethanandani Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani. Sent review to list.
2017-04-11
09 Wesley Eddy Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Wesley Eddy. Sent review to list.
2017-04-04
09 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2017-04-04
09 Sabrina Tanamal
Request for Last Call review by GENART is assigned to Wassim Haddad(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-ipsecme-tcp-encaps-09.txt, which …
Request for Last Call review by GENART is assigned to Wassim Haddad(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-ipsecme-tcp-encaps-09.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-04-04
09 Wesley Eddy Request for Last Call review by TSVART is assigned to Wesley Eddy
2017-04-04
09 Wesley Eddy Request for Last Call review by TSVART is assigned to Wesley Eddy
2017-03-29
09 Amy Vezza Shepherding AD changed to Eric Rescorla
2017-03-29
09 Tero Kivinen Added to session: IETF-98: ipsecme  Wed-1300
2017-03-28
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-03-28
09 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: ipsecme-chairs@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: ipsecme-chairs@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-ipsecme-tcp-encaps@ietf.org
Reply-To: ietf@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
ietf@ietf.org mailing lists by 2017-04-18. 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 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 ESP packets over a TCP connection.
  This method is intended to be used as a fallback option when IKE
  cannot be negotiated over UDP.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ballot/


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




2017-03-28
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-03-28
09 Kathleen Moriarty Telechat date has been changed to 2017-04-27 from 2017-04-13
2017-03-28
09 Kathleen Moriarty Last call was requested
2017-03-28
09 Kathleen Moriarty Last call announcement was changed
2017-03-28
09 Kathleen Moriarty Last call was requested
2017-03-28
09 Kathleen Moriarty Ballot approval text was generated
2017-03-28
09 Kathleen Moriarty Ballot writeup was generated
2017-03-28
09 Kathleen Moriarty from AD Evaluation
2017-03-28
09 Kathleen Moriarty Last call announcement was generated
2017-03-19
09 Francis Dupont Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont.
2017-03-19
09 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2017-03-19
09 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2017-03-16
09 Jean Mahoney Closed request for Telechat review by GENART with state 'Withdrawn'
2017-03-15
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Russ Mundy
2017-03-15
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Russ Mundy
2017-03-14
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mahesh Jethanandani
2017-03-14
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Mahesh Jethanandani
2017-03-12
09 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-09.txt
2017-03-12
09 (System) New version approved
2017-03-12
09 (System) Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha
2017-03-12
09 Tommy Pauly Uploaded new revision
2017-03-09
08 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2017-03-09
08 Jean Mahoney Request for Telechat review by GENART is assigned to Francis Dupont
2017-03-09
08 Kathleen Moriarty IESG state changed to AD Evaluation from Publication Requested
2017-03-09
08 Kathleen Moriarty Placed on agenda for telechat - 2017-04-13
2017-03-01
08 Tero Kivinen
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 …
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 24 February 2012.

(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?

The type of RFC being requested is Standard track document. This document defines a framing protocol and network peer behavior that allows implementations to run the existing IKEv2 and ESP protocols over TCP. This is the type of RFC indicated on the draft.

(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 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 ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.

Working Group Summary

The draft came to the working group out of a need to standardize a push towards adding TCP support for IKE that was coming from several sources (VPN vendors and cellular carriers using IKE for telephony services). Some of the major changes that the WG made early on compared to existing proposals from external bodies was to remove the reliance on encapsulating IKE traffic within TLS. Much of the other WG discussion later on in review revolved around how to best manage the connection establishment and teardown transitions.

Document Quality

There are several early implementations of the protocol that were made to test interoperability (notably, Cisco and Apple). The draft also received input from vendors that have previously deployed proprietary versions of IPsec over TCP.

Personnel

The Document Shepherd is Tero Kivinen. The responsible AD is Kathleen Moriarty.

(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 document few times, and provided some feedback, which has been taken in to the account for latest versions. The document seems to be ready to be published.

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

There has been several reviews from the active IPsecME WG members of this draft, and I think we have had enough 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.

No broader review is needed. There is the normal issue with TCP inside TCP (or TCP inside the ESP, which is then inside the TCP) but the performance considerations sections already point this out.

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

No concerns came up in the WG with the current version of the document.

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

Yes.

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

No.

(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 active members of the WG have all participated in the discussion about this draft, and given their feedback. We've discussed the draft over the course of several IETF meetings, and there is agreement on the document.

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None found. Idnits compains about several in-document references being missing as it does not understand that [section 12] refers to this document, not external document. Similarly idnits complains about the [CERTREQ], [CP] etc, i.e., the optional parts of the exchanges, as it confuses them as references.

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

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

No.

(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 5226).

Not applicable. The document does not include any IANA requests.

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

Not applicable. The document does not include any IANA requests.

(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, etc.

No applicable.
2017-03-01
08 Tero Kivinen Responsible AD changed to Kathleen Moriarty
2017-03-01
08 Tero Kivinen
2017-03-01
08 Tero Kivinen IESG state changed to Publication Requested
2017-03-01
08 Tero Kivinen IESG process started in state Publication Requested
2017-02-27
08 Samy Touati New version available: draft-ietf-ipsecme-tcp-encaps-08.txt
2017-02-27
08 (System) New version approved
2017-02-27
08 (System) Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha
2017-02-27
08 Samy Touati Uploaded new revision
2017-02-24
07 Tero Kivinen Changed document writeup
2017-02-09
07 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-07.txt
2017-02-09
07 (System) New version approved
2017-02-09
07 (System) Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha"
2017-02-09
07 Tommy Pauly Uploaded new revision
2017-02-08
06 Tero Kivinen WG Consensus: Waiting for Write-Up from In WG Last Call
2017-02-03
06 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-06.txt
2017-02-03
06 (System) New version approved
2017-02-03
06 (System) Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha"
2017-02-03
06 Tommy Pauly Uploaded new revision
2017-01-23
05 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-05.txt
2017-01-23
05 (System) New version approved
2017-01-23
05 (System) Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha"
2017-01-23
05 Tommy Pauly Uploaded new revision
2017-01-11
04 Tero Kivinen IETF WG state changed to In WG Last Call from WG Document
2017-01-11
04 Tero Kivinen Changed consensus to Yes from Unknown
2017-01-11
04 Tero Kivinen
2016-12-04
04 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-04.txt
2016-12-04
04 (System) New version approved
2016-12-04
04 (System) Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha"
2016-12-04
04 Tommy Pauly Uploaded new revision
2016-10-31
03 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-03.txt
2016-10-31
03 (System) New version approved
2016-10-31
02 (System) Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha"
2016-10-31
02 Tommy Pauly Uploaded new revision
2016-10-06
02 David Waltermire Notification list changed to "Tero Kivinen" <kivinen@iki.fi>
2016-10-06
02 David Waltermire Document shepherd changed to Tero Kivinen
2016-08-17
02 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-02.txt
2016-07-07
01 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-01.txt
2016-06-27
00 David Waltermire This document now replaces draft-pauly-ipsecme-tcp-encaps instead of None
2016-06-27
00 Tommy Pauly New version available: draft-ietf-ipsecme-tcp-encaps-00.txt