Hi Valery, Thanks for reviewing the draft. I appreciate your time looking at it!
Regarding the status of mentioning TLS in the draft, I think it is important for the standardization aspect of running IKEv2/IPSec over a stream. While much of the reason to run IPSec over TCP/TLS is to work on networks that currently do not pass UDP traffic, there is broader benefit in describing how the IKEv2 protocol should work over a streaming protocol, and when a layer like TLS is used. The main points I want to make sure we retain in the spec are: - If you use a streaming protocol like TCP to transport your IKEv2/IPSec traffic, use the framing described in the document to define the boundaries of IKE and ESP messages - TCP segments and TLS frames (if used) should not affect the creation or parsing of IKEv2/IPSec messages - Extra layers that use a security protocol, like TLS, should not be considered to provide any security or authentication assurances at the IKE level. Since we expect deployments for the short to use TLS, I want to make sure we are clear on these details so that deployments do the right thing. I do believe there is a need for the basic elements of this in a standards document. I do like the idea of having a follow-on draft that is not Standards Track that describes current best practices for how to use TLS and TCP encapsulation to solve current problems. Note that the current draft does not specify what port to use, etc, and only mentions that implementations may end up choosing to use port 443. This follow-on draft can go into detail about exactly what algorithms deployments end up choosing (try first over UDP with N packets, then try over TLS port 443, etc). Responses to specific points inline. Thanks, Tommy > On Mar 23, 2016, at 5:03 AM, Valery Smyslov <sva...@gmail.com> wrote: > > Hi Tommy, > > I reviewed the draft. > > Generally, the draft is in a good shape. It is well written and contains > almost no > editorial issues. There are however some places where I'd like to see more > clarification, all of them are listed below. > > My main problem with the draft is that it has an intended status Standards > Track and > at the same time its main goal, as specified in the Introduction, is to invent > some hack to cheat middleboxes that don't pass UDP. In this context > the proposal to use TLS (and port 443) looks especially ugly, however it is > probably > the most "penetrating" solution. I understand that the world is not perfect > and > we must deal with it. However I think that the Standards Track documents must > try > to model more or less ideal world (to some extent) and should not standardize > hacks, > tricks and so on. > > On the other hand, TCP encapsulation per se doesn't look bad, and I think it > is worth > to have standard interoperable solution to encapsulate IKE and ESP in TCP. > I would have had much less problems with this proposal it the draft was > splitted > into two documents - one Standards Track document describing TCP encapsulation > per se, and the other Informational document describing all the hacks and > tricks > to cheat the middleboxes that try not to pass anything except e.g. http > and/or https. > And I'd like all the TLS encapsulation stuff go into that draft. > > > > 1. The requirement that direct use of ESP or UDP Encapsulation SHOULD be > preferred over using TCP > Encapsulation is present twice in the document (in Sections 1 and 2). I > think it's OK to reemphasize > this requirement, however since both of them use RFC2119 language, they > look duplicated. > I'd suggest to change one of the SHOULDs to lower case. Good point, will change one of the SHOULDs to lower case in the next version. > > 2. 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. The maximum message length is used as the > effective MTU for connections that are being encrypted using ESP, so > the maximum message length will influence characteristics of inner > connections, such as the TCP Maximum Segment Size (MSS). > this text is not clear for me. IKE and ESP message length can be up > to 64Kbytes, so how it can be used as effective MTU (that is less than or > equal to the interface MTU, that is usually about 1500 bytes)? > How it can influence MSS, that is usually less than or equal to > path MTU to avoid IP fragmentation? Am I missing something? The point I’m trying to get at is this: if the IPSec tunnel is represented to the client system as a virtual interface, that virtual interface will have an MTU which determines the packet size of packets within the tunnel. Depending on how IPSec over TCP is implemented on the server end, the ESP packets could eventually be sent over UDP before being decrypted (specifically, if the TCP connection is terminated at a device before the IKE endpoint). As such, we want to make sure that there are not very large (such as 64K bytes) IKE and ESP messages being sent on a tunnel that may have to then fragmenting the ESP datagrams before decrypting them. > > 3. Section 4. > > Any specific IKE SA, along with its Child SAs, is either TCP > encapsulated or not. A mix of TCP and UDP encapsulation for a single > SA is not allowed. The exception to this rule is SAs that are > migrated between addresses using MOBIKE Section 7. > > the last sentence is not accurate. As far as I understand, if IKE SA > (along with > its Child SAs) migrated from one address to another via MOBIKE, then > either all these SAs (IKE & its children) use TCP encapsulation > or all them use traditional encapsulation. So, it is not an exception > from the rule. Well, my reading of the rule that "the mix is not allowed" > is that by "mix" you mean situation when IKE SA uses one type > of encapsulation while some of its children use different type. > I'd suggest to clarify this text so that any ambiguity is eliminated. You are correct that there is not a case in which there is a mix between IKE and Child SAs. We will clarify this in the next version. > > 4. Section 5. > > A peer must discard a partially received message due to a broken > connection. > > s/must/MUST ? I think we can make this a MUST. > > 5. Section 9. > > NAT keep-alive packets over a TCP > encapsulated IPSec connection will be sent with a length value of 1 > byte, whose value is 0xFF Figure 2. > > Shouldn't "Figure 2" be enclosed in brackets? Agreed, this can be in brackets. > > 6. Section 11. > > There is no subsection describing additional overhead to the size of the > ESP > and IKE messages when using TCP encapsulation. > This overhead may be important for some implementations. Consider some > application (e.g. VoIP) that sends small packets, e.g. about 50 bytes in > size. > With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = 36 > bytes. > With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) = 52 > bytes. > The difference may be significant for low bandwith networks or low power > consumption > devices. With TLS the situation will be worse. This calculation does not work exactly, since TCP is a stream and the IKE/ESP payloads will not correspond directly with TLS frames or TCP segments. We can mention the overhead in general, but it is not a deterministic factor. > > 7. Section 11.3 > > It is not clear from the text where NULL cipher should be used - in ESP > or in TLS? If it is about TLS, then does by NULL cipher you mean > TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS > (I'm not a TLS expert)? If it is about ESP NULL cipher, > then it contradicts to last para in Section 12... I think it should be > clarified. This should refer to the TLS NULL cipher, not ESP. > > 8. The draft is silent about ESP Sequence Numbers. I think a few words could > be added that while the ESP SN are unnecessary with TCP encapsulation, > the sender still must increnet it in every sent packet. Okay, we can add a comment for that. > > Regards, > Valery Smyslov. > > > > >> ----- Original Message ----- >> From: Tommy Pauly <mailto:tpa...@apple.com> >> To: ipsec@ietf.org <mailto:ipsec@ietf.org> >> Sent: Tuesday, February 16, 2016 12:52 AM >> Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft >> >> Hello all, >> >> I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation >> draft. The changes include: >> >> - Making the use case (as a last resort if UDP is blocked) more clear in the >> introduction >> - Clarify connection establishment and teardown section (allowing a resumed >> connection to start with either IKE or ESP traffic, allowing multiple SAs on >> one TCP connection) >> - Adding more details about interactions with IKEv2 fragmentation, and TCP >> MSS and QoS markings >> - Clarifying the keep-alive/DPD section >> - A new appendix written by a new author from Cisco giving four example >> exchanges with TCP encapsulation of IKEv2. >> >> https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt >> <https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt> >> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 >> <https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03> >> >> I believe this should address many of the comments the last draft received. >> Please take a look and provide your feedback! If the working group is in >> favor, I’d like to see if this can be adopted by the working group. >> >> Thanks, >> Tommy >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
