Kathleen Moriarty writes:
> >> "There have been middle boxes blocking IKE negotiation over UDP. To
> >> make IKE work in these environments, IKE packets need to be
> >> encapsulated in a TCP tunnel.
> >
> >
> > "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
> > tunnel was not meant. Instead, we meant "encapsulated in TCP".
>
> OK, I am changing this text too, thanks.
> >
> >> The group will define a mechanism to
> >> tunnel IKE and IPsec over a TCP-based connection. This method is
> >> intended to be used as a fallback when IKE cannot be negotiated over
> >> UDP. The group will create a method where IKEv2 and IPsec packets can
> >> be encapsulated in the TCP connection."
> >
> >
> >
> >> going for external review, but I'd love to understand better what the
> >> resulting protocol stack looks like. I get the part about encapsulating
> >> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
> >> general-purpose "IP over TCP" mechanism?
> >
> >
> > It will be "ESP over TCP" similar to how we now have "ESP over UDP".
>
> We should be more explicit here, I agree with Spencer. The IKE part
> is clear since that's UPD 500. Would this be transport mode ESP only?
> If that's the case, how is the following alteration to the text:
>
> The group will define a mechanism to
> tunnel IKE and IPsec over a TCP-based connection. This method is
> intended to be used as a fallback when IKE cannot be negotiated over
> UDP. The group will create a method where IKEv2 and IPsec ESP
> transport mode packets can
> be encapsulated in the TCP connection."
>
> Working group: If I've changed the intent too much, please suggest
> other wording.
The traffic inside the TCP-based connection is usually ESP tunnel
mode, not transport mode, so the change you made is limiting it too
much.
I.e., this is intended for mobile phones / laptops etc doing VPN
connection from the hotel to the enterprice vpn gateway and where the
hotel etc firewall blocks all UDP traffic. So when UDP does not work
we make TCP connection and encapsulate all IKE and ESP packets to that
TCP connection. On those cases the VPN gateway usually assigns
internal IP-address to the mobile device using configuration payloads
in IKE, and then the mobile device uses tunnel mode ESP to send data
to the internal enterprice network.
So at least remove the "transport mode" and then it should be ok.
The protocol stack will look like this:
Data packet: IKEv2 packet
Application data
TCP header IKEv2 packet
Inner IP-header IKEv2 header
ESP Non-ESP Marker
Length Length
TCP header TCP header
Outer IP-header Outer IP-header
(Of course as this runs over normal TCP connection, the Length ESP +
Inner IP-header + TCP header + Application data might get splitted to
multiple actual packets, or there might be multiple inner packets
inside the same TCP packet).
This is similar than what we already have when doing UDP encapsulation
of IPsec (RFC3948):
3.4. Tunnel Mode ESP Encapsulation
...
AFTER APPLYING ESP/UDP
--------------------------------------------------------------
IPv4 |new h.| UDP | ESP |orig IP hdr | | | ESP | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--------------------------------------------------------------
|<------------ encrypted ----------->|
|<------------- authenticated ------------>|
but instead of "UDP Hdr" we have TCP connection.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
