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

["Scharf, Michael (Nokia - DE)" <[e-mail]>]

Regarding the statement that my comment is incorrect:


·         I did not want to imply that the QUIC connection ID *is* unique per subscriber in the current prototype. I haven’t checked the code but for sure I assume that it is not implemented this way. My concern is about a protocol that by design *does not prevent* that and leaves the decision e.g. up to an application developer decision.

·         The root cause of the problem may be that draft-tsvwg-quic-protocol-02 lacks a security consideration section. The privacy implications of the connection ID require IMHO significant attention there. But, indeed, this discussion does not belong on this list.

·         I disagree that any connection ID that is meant to be location-independent (i.e., independent of the 5-tuple) exactly exposes the same information as the 5 tuple. A trivial counter-example is a connection ID that is build from the MAC address concatenated by some random bits. For instance, this would be an easy way to construct a unique 64bit identifier that would survive NAT rebinding, but, well, this would have some privacy impact, no? Specifically, since it may show up in every packet at a constant offset, one could use this ID for “interesting” purposes, or do I miss something? What prevents a user-space transport protocol implementation from picking the MAC address? Some MUST in some I-D?

Furthermore, I believe that this discussions matters for PLUS/SPUD, since:


·         If two different, worked-out candidate users of the common substrate seem to have similar requirements for signaling information in clear-text, this could be some lessons learnt for what may be required in the common substrate.

·         Even if this is not the case, the current excessive use of the term “encryption” in the PLUS/SPUD charter IMHO has to be reviewed, since at least two potential candidate protocols actually seems to use information in clear text. Example: “The primary goal of PLUS is to enable the deployment of arbitrary, fully encrypted transport protocols”. Well, at least I learn now that not everything is “fully” encrypted…

·         Finally, from the current charter I don’t understand whether PLUS/SPUD would consider the requirements of middleboxes designed to provide user anonymity (e.g., TOR-like). I’d personally be fine with flagging their specific requirements as out-of-scope. But for sure there is a user community of that sort of infrastructure and it may make sense to discuss early how to deal with that.

Michael

From: Jana Iyengar [mailto:[e-mail]]
Sent: Sunday, May 22, 2016 5:03 AM
To: Tom Herbert
Cc: Toerless Eckert (eckert); [e-mail]; Christian Huitema; Joe Touch; Scharf, Michael (Nokia - DE)
Subject: Re: [Spud] Fwd: New Version Notification for draft-herbert-transports-over-udp-00.txt


Possibly unsurprisingly, I like this draft. I'd like to argue some of the choices made in the draft but I'll do that separately. For now, I just wanted to articulate a few thoughts as I caught up on this thread:

- The ship has sailed on new native-IP transports. I worked on SCTP for 6 years and tried and watched it get nowhere in terms of deployment over native-IP. It wasn't because it was in the kernel, it was primarily because of NATs and various middleboxes. Yes this is definitely my opinion, but arguing this point is silly. No new native IP transport has seen significant deployment over the internet over the past 20 years, and it's not for lack of trying.

- People reasonably consider timescales of a few years when thinking about building and deploying a new transport. QUIC took a few years to build and deploy over UDP, and the Adobe folks did RTMFP over UDP as well (a while ago) in a reasonable time frame.

- Encryption is the *only* way to attempt avoiding ossification. Its certainly reasonable to consider that it may not do the job, but without an alternative, I'm afraid it will have to do for now.

- Michael raised a point about QUIC connection ID, which is incorrect: The QUIC connection ID is NOT unique per user. It's a connection ID, and on a single-path connection, it exposes exactly as much as TCP, DCCP, or SCTP do (unique per 4-tuple). On a multipath connection, it exposes exactly as much as MPTCP does. We can perhaps do better than MPTCP for multipath in terms of privacy, I don't want to engage on this point on this thread since it's not relevant to this thread.

- jana
On May 21, 2016 8:53 AM, "Tom Herbert" <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, May 20, 2016 at 4:38 PM, Christian Huitema
<[e-mail]<mailto:[e-mail]>> wrote:
> On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote:
>> To: Tom Herbert <[e-mail]<mailto:[e-mail]>>; Toerless Eckert
>> <[e-mail]<mailto:[e-mail]>>
>> Cc: Joe Touch <[e-mail]<mailto:[e-mail]>>; spud <[e-mail]<mailto:[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
>
>

_______________________________________________
Spud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spud