Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt

[Tom Herbert <[e-mail]>]

On Fri, May 20, 2016 at 4:38 PM, Christian Huitema
<[e-mail]> wrote:
> On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote:
>> To: Tom Herbert <[e-mail]>; Toerless Eckert
>> <[e-mail]>
>> Cc: Joe Touch <[e-mail]>; spud <[e-mail]>
>> Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-
>> transports-over-udp-00.txt
>>
>> > NAT makes life complicated, especially if we want to have connections
>> survive across UDP NAT address/port remapping. Most of the draft is about
>> dealing with this. One nice feature (that I borrowed from > QUIC) is to
>> negotiate a shared session identifier for the connection that is unique to both
>> sides. With this a connection is identified (at the end
>> > nodes) without using the addresses or UDP port numbers. So connection
>> identification becomes location independent which solves the NAP
>> remapping problem and also allows for mobility.
>>
>> Ahhh, Section 3.2 is really cool...
>>
>> I can clearly see the tremendous improvement for user privacy if the highly
>> privacy-sensitive TCP header fields finally get all encrypted, including things
>> like flags, sequence numbers etc., if there is now a new clear text identifier
>> that just happens to be unique per subscriber. What a great improvement for
>> privacy in the Internet! And even better that it seems compatible with QUIC...
>>
>> Sorry, I really could not resist.
>
> Actually, using a 64 bit QUIC-like identifier to support mobility or multi path is a terrible idea. The best way to describe it is, "clear text super cookie." It allows adversaries to link connections originating from different IP addresses. Providing such linkability is a boon for traffic analysis and user tracking, and of course a big loss for privacy. And yes, MP-TCP is doing something similar, but at least they acknowledge the problem and want to find a solution. If we want privacy, the identifiers used to link several connections together have to be placed inside the crypto envelope, not in a clear text header.
>
We assume that strong security must be applied, so unlike MP-TCP the
transport headers are encrypted and the only information sent in plain
text is the session identifier (serving as an SPI) and DTLS headers.
In the case of a connection surviving across NAT remapping an attacker
could observe that the connection has been remapped, but that reveals
no new information about the connection than it had previously except
that the it was remapped by an intermediate device. That does
potentially reveal information about the NAT device, for instance it
could probably ascertain the timeout, but I don't know how useful that
would be in and it could probably be determined by other means.

But even given that, yes, I would prefer that anything that identifies
flows on the network (UDP tuples, session identifiers, flow labels) is
periodically rotated to reduce the ability of intermediate nodes to
track my flows over long periods of time. The protocol to negotiate a
new session identifier can be implemented in the encrypted portion of
the packet. To change the UDP tuple a client can pick a different
ephemeral source port (in userspace sockets implementation this would
close one socket and create a new and do a connect without explicit
bind).

Tom






> -- Christian Huitema
>
>