Hi Daniel, Thanks for the in-depth review! I've incorporated your comments into a new update: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02 <https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02>. Specific responses to your comments inline!
Any other comments are welcome on the new version. I agree with Daniel that we're in good shape to go into WGLC. Best, Tommy > On Jul 27, 2016, at 11:24 AM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi, > > I reviewed draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we > are doing a pre-WGLC. I think the draft is in pretty good shape for a WGLC. > Please see my comments below. > > > BR, > Daniel > > TCP Encapsulation of IKE and IPSec Packets > draft-ietf-ipsecme-tcp-encaps-01 > > 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 all packets for tunnel establishment > > >MGLT: Maybe that would be clearer to have: > >OLD: > >This method, referred to as TCP > >encapsulation, involves sending all packets for tunnel establishment > >as well as tunneled packets over a TCP connection. > > > >NEW: > >This method, referred to as TCP > >encapsulation, involves both sending all IKE packets for tunnel establishment > >as well as tunneled packets with ESP over a TCP connection. Tweaked the wording, thanks! > > > as well as tunneled packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. > > > 1. Introduction > > IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using > > >MGLT: I think IPSec should be replaced by IPsec. Replaced throughout the draft. Thanks for pointing this out. > > Direct use of ESP or UDP Encapsulation should be preferred by IKE > implementations due to performance concerns when using TCP > Encapsulation Section 12. > > >MGLT: This looks a bit strange to have Section 12 at the end of the > >sentence. Maye it would be preferred something like "More details > >are provided in Section 12" Adjusted formatting. > > 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. > > 1.1. Prior Work and Motivation > > > Some previous solutions include: > > >MGLT: I would prefer "alternatives" then "solutions" as solutions > > imply there is not anymore a problem to solve.. In addition, we > >can add some justification for this document. The justifications for > >me are 1) defining a standard that provides interoperability as well > >as 2) reduce the additional overhead over some tof the solutions. I > >do not know if that is easier to have a sentence to position the > >document toward each alternative or if it can be summed up in the > >beginning. > I switched the wording to "alternatives", and added some text after the list about the goal of this document with regards to how it is different from other approaches. > > > 2. Configuration > > One of the main reasons to use TCP encapsulation is that UDP traffic > may be entirely blocked on a network. Because of this, support for > TCP encapsulation is not specifically negotiated in the IKE exchange. > Instead, support for TCP encapsulation must be pre-configured on both > the initiator and the responder. > > The configuration defined on each peer should include the following > parameters: > > o One or more TCP ports on which the responder will listen for > incoming connections. Note that the initiator may initiate TCP > connections to the responder from any local port. > > >MGLT: I would also add a note that the port the responder > >may listen to may be limited as such networks may only let > >a very limited set of outgoing ports over TCP. Obviously ports > >could be 80 or 443. On the other hand on an IPsec point of > >view port 4500 seems also a natural cnadidate. Added a note that the ports that will be chosen is likely based on the ones allowed on very restrictive networks. > > > > 3. TCP-Encapsulated Header Formats > > >MGLT: Maybe it would help to specify in the begining of the section > >something like : > >"TCP encapsulation follows > >the UDP encapsulation marking to differentaite ESP to IKE. > >In addition, TCP stream also require the length to be specified." > > Reworded the section to compare it to UDP encapsulation and point out the similarities. > In order to encapsulate IKE and ESP messages within a TCP stream, a > 16-bit length field precedes every message. If the first 32-bits of > the message are zeros (a Non-ESP Marker), then the contents comprise > an IKE message. Otherwise, the contents comprise an ESP message. > Authentication Header (AH) messages are not supported for TCP > encapsulation. > > > MGLT: I think the restriction to ESP should be mentioned earlier in > > the document. (Abstract or introduction) I looked for a better place to mention that only ESP is supported, and I didn't find a better place earlier in the document. This section on how to actually encapsulate the messages is the first part that gets into the details of ESP, etc. If you have a specific place you'd like to see AH mentioned earlier, let me know. > > > 3.1. TCP-Encapsulated IKE Header Format > > > The IKE header is preceded by a 16-bit length field in network byte > order that specifies the length of the IKE packet within the TCP > stream. > > > MGLT: Reading the text it looks that length does not include the Non-ESP > > Marker. This is specified later, but maybe we coudl replace: > > > > OLD: > > The IKE header is preceded by a 16-bit length field in network byte > > order that specifies the length of the IKE packet within the TCP > > stream. > > NEW: > > The IKE header is preceded by a 16-bit length field in network byte > > order that specifies the length of the encapsulated IKE packet within the > > TCP > > stream. Actually, the length should include the Non-ESP marker, and the text in the bullet point did mention that. I added another comment above where you were quoting to make this more clear. > > > > > 4. TCP-Encapsulated Stream Prefix > > >MGLT: Maybe that would be helpful for te reader to provide motivations > >for these "IKETCP" stream. I would have something like this at the > >beginign of the section: > > >"TCP encapsulation has not been assigned any specific port, as > > this port may not be allowed in a network. As a result, TCP > > encapsulation may not be announced with a specific port. In > > addition, port allowed by the network for TCP may happen to be > > well known port used by other applications such as port 80, or 443. > > When such port are used, peers should signal that the TCP connection > > is not associated to the well known port but instead for TCP > > encapsulation. In addition, such signaling needs to be performed > > at the TCP layer to make TCP encapsulation as generic as possible. > > For example, the used of ALPN for such signalling would restrict > > the signaling to TLS. TCP could use TCP options, but these options > > are unlikely to go through most networks. As a result, this document > > uses in-band signaling." > > Each stream of bytes used for IKE and IPSec encapsulation MUST begin > with a fixed sequence of six bytes as a magic value, containing the > characters "IKETCP" as ASCII values. This allows peers to > differentiate this protocol from other protocols that may be run over > TCP streams, since the bytes do not overlap with the valid start of > any other known stream protocol. This value is only sent once, by > the Initiator only, at the beginning of any stream of IKE and ESP > messages. I've reworded the section slightly. I think it already did communicate some of the reasons that we need a prefix, but I've tried to make it more clear. I've also explained why we don't use the inner protocol markings for 'framing protocols' (read: TLS). > > > >MGLT: Maybe that will be in the security considerations, but I think > >we should explain that we hope there is not matching with an existing > >packet. Added a comment in security considerations as well. > > > > > 5. Applicability > > > If TCP encapsulation is being used for a specific IKE SA, all > messages for that IKE SA and its Child SAs MUST be sent over a TCP > connection until the SA is deleted or MOBIKE is used to change the SA > endpoints and/or encapsulation protocol. > > >MGLT: The sentence below looks to me redundant with the first sentence. > > I would also add a reference to section below where intercations with > > MOBIKE is provided in more details. Agreed, I've removed the second sentence to make the wording less redundant. Added a reference as well. > > > No packets should be sent > over UDP or direct ESP for the IKE SA or its Child SAs while using > TCP encapsulation. > > > 8. Using MOBIKE with TCP encapsulation > > > > MGLT: From this section my understanding is that MOBIKE message > > from the new interface uses first a UDP encapsulation. If that > > does not work, it switches to TCP encapsulation. In other work > > there is no fall back from TCP to NO encapsulation. Shouldn't we > > use the NAT detection to determine whether UDP encapsulation or > > no encapsulation be used? > > My understanding is that ESP is UDP encapsulated or not depending > > if NAT has been detected on the initial interface. In other words, > > if the new network has no NAT, the mobile is likely to perform > > encapsulation on this network. Am I correct ? We do support raw ESP, ESP-over-UDP and ESP-over-TCP in this draft, and MOBIKE can use any of them. The IKE messages will either be over UDP or TCP, and if UDP, will use the NAT detection payloads to determine if ESP needs to be encapsulated in UDP (like normal). On every MOBIKE attempt, IKE should use UDP first, and then try TCP if UDP doesn't get a reply. I think the confusion was because of the sentence I had that said that the encapsulation of ESP needed to match the encapsulation of IKE. I have removed this sentence. Can you take another look and see if it is clearer now? > > > 13. Security Considerations > > > > MGLT: I think we should also add some text regarding the matching with the > > IKETCP string. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
