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

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 <tpauly@apple.com> wrote:

>
> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>> Hi, Eric.
>>
>> On 19 Mar 2017, at 4:04, Eric Rescorla <ekr@rtfm.com> 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.
>>
>
> 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.
>>
>> - 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"
>>
>
> Fair enough.
>
>
>> - 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.
>>
>
> 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."
>
>
> 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
>
>
> " 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)
>>
>
> OK. You're still going to have a problem with 1.3...
>
> -Ekr
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>