Skip to main content

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

Yes


No Objection

(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 09 and is now closed.

Warren Kumari
No Objection
Comment (2017-04-24 for -09) Unknown
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)
Eric Rescorla Former IESG member
Yes
Yes (2017-04-24 for -09) Unknown
I reviewed this document privately before becoming AD.
Kathleen Moriarty Former IESG member
Yes
Yes (2017-04-25 for -09) Unknown
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.
Adam Roach Former IESG member
No Objection
No Objection (2017-04-24 for -09) Unknown
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.
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-04-26 for -09) Unknown
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.
Alia Atlas Former IESG member
No Objection
No Objection (2017-04-26 for -09) Unknown
I agree with Mirja's discuss.
Alissa Cooper Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2017-04-26 for -09) Unknown
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.
Benoît Claise Former IESG member
No Objection
No Objection (2017-04-27 for -09) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2017-06-14) Unknown
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."
Spencer Dawkins Former IESG member
No Objection
No Objection (2017-04-26 for -09) Unknown
I support Mirja's Discuss, and am happy with the direction that discussing is headed.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -09) Unknown