Re: [Spud] Multipath/Mobility (was Questions based on draft-trammell-spud-req-00)

[Christian Huitema <[e-mail]>]

On Monday, August 10, 2015 10:53 AM, Ted Hardie wrote:

> ...
> I've split off a small chunk here to focus on the multipath/mobility question.
>
> On Mon, Aug 10, 2015 at 12:28 AM, Toerless Eckert <[e-mail]> wrote:
>
>> My preference for Tube-ID is to identify a single bidirectional multipath or
>> mobile transport connection consisting of one or more 5-tuple flows between
>> two endpoints.
>
​> First, I'm guessing that you want a single tube-id for multiple flows because you 
> want to tell the network that they are part of a single, multipath whole.  If I have 
> guessed that wrong and you have a different view, can you please explain?​

I don't know what Toerless really means, but I am a bit concerned by the use of a "unique identifier" here. Specifically, I am concerned with the privacy implications of using unique identifiers. If the same identifier is used with multiple 5 tuples, then it can be used to tie together these tuples. There are cases when it doesn't matter too much, e.g. when just the client port changed, presumably after a NAT remapping. But if the client IP address changes, the unique identifier provides a neat way to track successive locations of a mobile device.

I understand that using a unique identifier simplifies the device greatly. For example, a load balancer can use the unique identifier to ensure that packets are always routed to the "right" context. But we can do better than that. In fact, we should, because without a good alternative protocol designers will just pick the simple design, without worrying too much about privacy. The alternative is to design a privacy preserving way to bind two contexts together. 

That shouldn't be too hard. For example, the client could send a "tying" parameter encrypted with the server public key, tying the new context to a previous one. But we probably want to start this kind of design sooner rather than later, especially if we care about privacy.

-- Christian Huitema