> On Aug 31, 2016, at 3:23 AM, Tero Kivinen <kivi...@iki.fi> wrote: > > 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?
In effect, yes: we prefer that IKE/IPSec tunnels are run over UDP for various reasons (performance, etc), but having a fallback over TCP allows it to be a generic tunneling mechanism over TCP, such that implementations can use this as a standardized VPN that works on UDP or TCP, and not need a proprietary protocol. >>> >>> >>> 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. Right. If we would specific any mode specifically, it should specify tunnel mode, not transport mode. The proposed change to the text is fine apart from the specification of the mode! Thanks, Tommy > > 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. > -- > kivi...@iki.fi > > _______________________________________________ > 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
