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