Subject: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

From: Eric Rescorla <[email-masked]>
Date: Sat, 18 Mar 2017 19:04:29 -0700

[Now with the right address]

I just finished reading this document. Some comments below.

- You have a uniform 16 bit length field followed by a 4 byte all-zeros
   sentinel value to indicate that a packet is IKE rather than ESP.
   Given that in S 3 graf 2 you have a SHOULD-level requirement
   to use typical UDP payload lengths, why not instead explicitly
   limit lengths to 15 bits and use the top bit to indicate IKE versus
   ESP. This would be slightly more efficient and seems simpler.
   I suppose that the counterargument is that IKE over UDP behaves
   differently, but in terms of implementation, that doesn't seem like
  much of an argument.

- If you're going to have a framing disambiguator, why not choose
  one that has higher entropy. If there is a protocol with a random
  start, then you are going to get some collisions with 2^48 bits.

- It seems like IKE associations can span TCP connections (S 6)
  so why not instead of doing UDP first then TCP, do happy eyeballs.

" when TLS is used on the TCP connection, both the TCP Originator and TCP
Responder SHOULD allow the NULL cipher to be selected for performance
reasons."

This seems like you are going to have some problems with TLS 1.3

- If you are going to use TLS, shouldn't you be using ALPN?

Feel free to tell me that these ideas have been considered and rejected. :)

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Mar 2017 08:29:25 +0200

Hi, Eric.

> On 19 Mar 2017, at 4:04, Eric Rescorla <[email-masked]> wrote:
> 

Another counter-argument is that we sometimes need the entire theoretical length of a UDP packet. The IKE_AUTH messages typically carry a certificate chain and sometimes even a CRL. And there is no way to split a certificate chain over several messages. With remote access VPN you also get a CFG payload with configuration information that can also encode an unbounded amount of data. So I would not want to constrain the certificate chains that we are able to send any more than the IP packet length already does.

Early on there was a proposal to increase the length field to 4 bytes to do away with these IKE limitations, but that was rejected.

>   start, then you are going to get some collisions with 2^48 bits.

I don’t think anyone plans to implement this on any port other than 443. And on that port we’re worrying about exactly one protocol and it doesn’t start with “IKETCP"

>   so why not instead of doing UDP first then TCP, do happy eyeballs.

I don’t think it’s necessary to prescribe for or against this, but that is what we do, and I think that is what Apple intends to do.

> " when TLS is used on the TCP connection, both the TCP Originator and TCP Responder SHOULD allow the NULL cipher to be selected for performance reasons."
> 

The idea of using TLS (rather than just IKE on port 443) is to get past firewalls and IDP that examine the TCP traffic to determine that it “really looks like HTTPS”. There was some discussion about whether this was a good idea or whether we should in such a case either give up or standardize some kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this group or any other (there was a bar bof a few IETFs ago)

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 19 Mar 2017 12:24:25 +0300

Hi Eric,

>    differently, but in terms of implementation, that doesn't seem like

That won't work. An application protocol running over UDP
is free to send messages up to 64Kbytes. While in tunnel mode we can
first fragment these messages and then apply ESP (so that each ESP
packet is rather small) , in transport mode it's impossible, and the ESP
datagram can reach 64Kbytes in size. I agree that in wild there are few 
protocols that send such long UDP messages, but it is not prohibited.

>   so why not instead of doing UDP first then TCP, do happy eyeballs.

I don't think it's a good idea. The TCP encapsulation has a lot of 
drawbacks in terms of performance (see Section 12), so it is considered
as a last resort if UDP doesn't work. In general UDP (or no encapsulation) 
is a preferred transport. If we start trying TCP and UDP in parallel, then
in some cases TCP will win even if UDP works, resulting in non-efficient 
connection, even when UDP could be used. 

> -Ekr

Regards,
Valery Smyslov.

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Mar 2017 12:14:01 +0200

Hi Valery.

> On 19 Mar 2017, at 11:24, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Eric,
> 
> I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section 12), so it is considered
> as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start trying TCP and UDP in parallel, then
> in some cases TCP will win even if UDP works, resulting in non-efficient connection, even when UDP could be used.

So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head start. The reason is that in many places where a UDP packet can go, a fragmented UDP packet gets dropped, so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get dropped.

In by the end of IKE we have determined that UDP also works, we move to that for IPsec. And if TCP is blocked, we will try the IKE negotiation on UDP.

Note that we do all that only for remote access VPN. Site-to-site VPN is ESP or UDP only.  There’s just a lot of crappy routers out there.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 19 Mar 2017 14:20:58 +0300

Hi Yoav,

> So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head 
> start.
> The reason is that in many places where a UDP packet can go, a fragmented UDP packet gets dropped,
> so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get 
> dropped.

With IKE Fragmentation that's not a problem anymore.

> try the IKE negotiation on UDP.

Your TCP encapsulation protocol seems to be more flexible than what is described in the draft.

The current draft doesn't allow moving existing SA from TCP to UDP unless MOBIKE is negotiated (see Section 5).
So, if you start with TCP first (or do happy eyeballs and TCP wins), you never switch back to UDP, even if it appears
that UDP works for that path too, unless both sides support MOBIKE. And even with MOBIKE it's not clear if switching
is alowed unless interface address changes. That's why UDP is given a preference.

> Yoav

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 19 Mar 2017 13:45:23 +0200

> On 19 Mar 2017, at 13:20, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Yoav,
> 
>> > I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section > 12), so it is considered
>> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start > trying TCP and UDP in parallel, then
>> So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head start.
>> so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get dropped.
> 

IKE over TCP solves the same problem (and a few others).

> Your TCP encapsulation protocol seems to be more flexible than what is described in the draft.

Yes, and we (the working group) decided to simplify things by not incorporating this flexibility.

> is alowed unless interface address changes. That's why UDP is given a preference.

Yes, and that’s why the cost of using this as an alternative to IKE fragmentation is too high.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 06:47:42 -0700

On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <[email-masked]> wrote:

> Another counter-argument is that we sometimes need the entire theoretical
> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
> chain and sometimes even a CRL. And there is no way to split a certificate
> chain over several messages. With remote access VPN you also get a CFG
> payload with configuration information that can also encode an unbounded
> amount of data. So I would not want to constrain the certificate chains
> that we are able to send any more than the IP packet length already does.
>

OK.

Early on there was a proposal to increase the length field to 4 bytes to do
> away with these IKE limitations, but that was rejected.
>
> I don’t think anyone plans to implement this on any port other than 443.
> And on that port we’re worrying about exactly one protocol and it doesn’t
> start with “IKETCP"
>

Fair enough.

> I don’t think it’s necessary to prescribe for or against this, but that is
> what we do, and I think that is what Apple intends to do.
>

Right, but the text here actively discourages this.
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1

"   to reduce connection setup delays. It is recommended that theinitial
message over UDP is retransmitted at least once before falling back to TCP,
unless the Initiator knows beforehand that the   network is likely to block
UDP."

> The idea of using TLS (rather than just IKE on port 443) is to get past
> firewalls and IDP that examine the TCP traffic to determine that it “really
> looks like HTTPS”. There was some discussion about whether this was a good
> idea or whether we should in such a case either give up or standardize some
> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this
> group or any other (there was a bar bof a few IETFs ago)
>

OK. You're still going to have a problem with 1.3...

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 19 Mar 2017 11:25:51 -0700

> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Eric.
> 
>> On 19 Mar 2017, at 4:04, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 <https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1> 
> 
> "   to reduce connection setup delays. It is recommended that theinitial message over UDP is retransmitted at least once before falling back to TCP, unless the Initiator knows beforehand that the   network is likely to block UDP."

There's a tradeoff here between the Happy Eyeballs approach and the long-term benefits of choosing one option. I'm definitely a big proponent of Happy Eyeballs between address families, interfaces, and protocol options in general. However, these IKE connections will often be long-lived and tunnel a large amount of traffic used for many different applications. Since we view tunneling over UDP as so much preferable to tunneling over TCP, we want to weight the race more heavily in UDP's favor. The draft does not specifically say that attempts over UDP are ceased once the TCP attempt has begun, so there is room to keep 'racing' at this point. The main point we wanted to get across is that UDP should be given a fair shot, since it should be the preference.

Note that a Happy Eyeballs approach should always have one option be attempted first anyhow, since simultaneous racing just adds extra load to the network and servers.

Thanks,
Tommy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 11:40:05 -0700

I haven't fully thought this through, but if yu can switch-hit between TCP
and UDP,
why can't you just race the setup between TCP and UDP and then if you start
getting packets on UDP, cut over to that.

Maybe I'm just too influenced by ICE :)

-Ekr

On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <[email-masked]> wrote:

> Early on there was a proposal to increase the length field to 4 bytes to
>> do away with these IKE limitations, but that was rejected.
>>
>> I don’t think it’s necessary to prescribe for or against this, but that
>> is what we do, and I think that is what Apple intends to do.
>>
>
> There's a tradeoff here between the Happy Eyeballs approach and the
> long-term benefits of choosing one option. I'm definitely a big proponent
> of Happy Eyeballs between address families, interfaces, and protocol
> options in general. However, these IKE connections will often be long-lived
> and tunnel a large amount of traffic used for many different applications.
> Since we view tunneling over UDP as so much preferable to tunneling over
> TCP, we want to weight the race more heavily in UDP's favor. The draft does
> not specifically say that attempts over UDP are ceased once the TCP attempt
> has begun, so there is room to keep 'racing' at this point. The main point
> we wanted to get across is that UDP should be given a fair shot, since it
> should be the preference.
>
> Note that a Happy Eyeballs approach should always have one option be
> attempted first anyhow, since simultaneous racing just adds extra load to
> the network and servers.
>
> Thanks,
> Tommy
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 19 Mar 2017 11:45:52 -0700

Some servers may support that, but some may not. These sessions are often used for VPN access, and we've seen cases in which a particular user/certificate combination is only allowed to be connected once-at-a-time. That makes switching more complicated. Also, since the recommendation is to try sending the UDP first packet at least twice, the amount of time required for the user to wait before the fallback would kick in is only on the order of a few RTT.

I think if these session were more likely to be used for user-interactive, short-lived connections, I'd see more value in a nuanced racing algorithm. However, we often see IKE brought up in the background and stay associated for a very long time, making the protocol that wins the race more important, and the time to wait to establish slightly less important.

Thanks,
Tommy

> On Mar 19, 2017, at 11:40 AM, Eric Rescorla <[email-masked]> wrote:
> 
>>> that we are able to send any more than the IP packet length already does

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Mar 2017 11:46:27 -0700

Thanks for the explanation...

-Ekr

On Sun, Mar 19, 2017 at 11:45 AM, Tommy Pauly <[email-masked]> wrote:

> Some servers may support that, but some may not. These sessions are often
> used for VPN access, and we've seen cases in which a particular
> user/certificate combination is only allowed to be connected
> once-at-a-time. That makes switching more complicated. Also, since the
> recommendation is to try sending the UDP first packet at least twice, the
> amount of time required for the user to wait before the fallback would kick
> in is only on the order of a few RTT.
>
> I think if these session were more likely to be used for user-interactive,
> short-lived connections, I'd see more value in a nuanced racing algorithm.
> However, we often see IKE brought up in the background and stay associated
> for a very long time, making the protocol that wins the race more
> important, and the time to wait to establish slightly less important.
>
> Thanks,
> Tommy
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 11:38:05 -0400 (EDT)

On Sun, 19 Mar 2017, Eric Rescorla wrote:

> I haven't fully thought this through, but if yu can switch-hit between TCP and UDP,why can't you just race the setup between TCP and UDP and then if you
> start

There should really be a STRONG preference for UDP:

- (encrypted) TCP in TCP with packetloss _really_ performs poorly and
   should be avoided at all costs

- there is a reason IKE/IPsec uses UDP and ESP and not TCP. It is not
   susceptible to (spoofed) TCP-RST packets :P

> Maybe I'm just too influenced by ICE :)

Yes, we are not limited to flow-level security :)

Paul