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" <tom@herbertland.com> wrote:

> On Fri, May 20, 2016 at 4:38 PM, Christian Huitema
> <huitema@microsoft.com> wrote:
> > On Friday, May 20, 2016 9:14 AM, Michael Scharf wrote:
> >> To: Tom Herbert <tom@herbertland.com>; Toerless Eckert
> >> <eckert@cisco.com>
> >> Cc: Joe Touch <touch@isi.edu>; spud <spud@ietf.org>
> >> 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
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>