Subject: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Aug 2016 18:21:22 -0700

Spencer Dawkins has entered the following ballot position for
charter-ietf-ipsecme-10-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ipsecme/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This sentence doesn't parse for me - or maybe I just need more security
clue?

"IKEv1 using shared secret authentication was partially resistance to
quantum computers."

I don't object to this text 

"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. 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?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Aug 2016 23:28:37 -0400 (EDT)

s/resistance/resistant

> 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".

> The group will define a mechanism to

> general-purpose "IP over TCP" mechanism?

It will be "ESP over TCP" similar to how we now have "ESP over UDP".

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 30 Aug 2016 15:05:39 -0400

>> "IKEv1 using shared secret authentication was partially resistance to

Update has been made, thanks.

> tunnel was not meant. Instead, we meant "encapsulated in TCP".

OK, I am changing this text too, thanks.
> 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.

Thanks

-- 

Best regards,
Kathleen

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 31 Aug 2016 13:23:44 +0300

> Working group: If I've changed the intent too much, please suggest

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-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 31 Aug 2016 06:57:21 -0700

> On Aug 31, 2016, at 3:23 AM, Tero Kivinen <[email-masked]> wrote:
> 

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.

> 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

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec