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.
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.
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"
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.
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.
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."
>
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)
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.
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.
>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.
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.
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 ?
13. Security Considerations
> MGLT: I think we should also add some text regarding the matching with
the IKETCP string.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
