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

[Toerless Eckert <[e-mail]>]

Sigh... resending. [e-mail] mailing list owner hansn't bumped up the Cc limit...

On Mon, Aug 10, 2015 at 06:13:28PM +0000, Christian Huitema wrote:
> 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.

Sure, thats the purpose. As i said too, nobody forces higher layer protocols to
reuse the same Tube-ID. They would do it, when it gives any of the benefits
that i've listed in my last reply to Ted.

> 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. 

forgot the load balancing example , thanks.

> 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.

Well, the problem with the security is always how to establish a trust
relationship between middlebox and endpoints. As i mentioned, there
should be some good resistance to reinvent the wheel, but i don't think
threre is a good wheel yet.
> 
> -- Christian Huitema

-- 
---
Toerless Eckert, [e-mail]