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

[Yoav Nir <[e-mail]>]

Hi, Eric.

> On 19 Mar 2017, at 4:04, Eric Rescorla <[e-mail]> wrote:
> 
> [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.

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.

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

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"

> - It seems like IKE associations can span TCP connections (S 6)
>   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."
> 
> 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?

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