Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

[Tom Herbert <[e-mail]>]

On Mon, Aug 1, 2016 at 1:15 PM, Christian Huitema <[e-mail]> wrote:
> On Monday, August 1, 2016 1:10 PM, Spencer Dawkins wrote:
>>
>> AH - I didn't realize you were talking about your proposal. I've read that. I lost any
>> reference to it in the post I replied to - hence my confusion.
>
> The question was whether it is a good idea to have special marks for packets that "start a connection," and specifically for packets sent over UDP by encrypted transports. Tom's point is that this will create breakage in many conditions, such as multi-homed nodes. I can see at least two scenarios in which we could see breakage with QUIC:
>
> 1) Client is sitting behind a nonplussed NAT. The QUIC session with the server becomes silent for a short period, and the client's NAT releases the UDP mapping. The client then sends more data. The NAT will assign a different port mapping. The server will use the connection-ID field in the QUIC header to route the packets to the right server, and automatically repair the connection. Suppose now that somewhere on path, maybe at the ISP router, some piece of software traces the connections and relies on "start of connection" marks. The "repair" packet comes from a different UDP port, and does not carry any "start" mark. Will it be dropped?
>
> 2) Client is sitting on a multi-homed network, managed by outgoing NAT. At some point, NAT management causes the packets to the server to be routed through the "fall back" ISP. The packets reach the server, the connection-ID filed does its magic, and the connection is automatically repaired. But of course, the routers on the new path don't see any "start of connection" mark.
>
> There are probably more cases, but these two can happen today, with shipping code and existing hardware. The NAT mapping refresh, in particular, is quite common. This is why I much prefer "implicit start" processes to "explicit marks."
>
The question is also whether we need to send an explicit "end
connection" signal. Network devices want this to know when to free
their connection tracking state, but in a multipath Internet I don't
readily how this would be a useful signal either.

Tom