Hi Valery,
I agree with you that the TLS/HTTPS should be separated from the main TCP encapsulation descriptions, but I think it must stay in the current draft and moved to an appendix section at the end of the draft. The purpose is to show why TCP encapsulation is required in the first place. Thanks. Samy. From: IPsec <ipsec-boun...@ietf.org> on behalf of Valery Smyslov <sva...@gmail.com> Date: Wednesday, March 23, 2016 at 5:03 AM To: Tommy Pauly <tpa...@apple.com>, "ipsec@ietf.org" <ipsec@ietf.org> Subject: Re: [IPsec] New version of IKEv2 TCP Encapsulation draft 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. 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? 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. 4. Section 5. A peer must discard a partially received message due to a broken connection. s/must/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? 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. 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. 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. Regards, Valery Smyslov. ----- Original Message ----- From: Tommy Pauly To: 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/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 https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec