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

[Tommy Pauly <[e-mail]>]

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 <[e-mail]> 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
> 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 <[e-mail]> wrote:
> 
>> 
>> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <[e-mail]> wrote:
>> 
>> 
>> 
>> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <[e-mail]> wrote:
>> 
>>> 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