Re: Advantages and disadvantages of using CB64 type of identifiers

[Erik Nordmark <Erik.Nordmark@sun.com>]

Brian wrote:
> > i mean it would be possible, as Erik mentions, to create a new crypto 
> > based id every day, i guess
> 
> Or at whatever frequency you like... every DHCP refresh for example.
> 
> The question for us is whether such a mechanism would set bounds on
> multihoming sessions. What happens to TCP sessions that live longer
> than the IID?

A reasonable approach would be to apply the RFC 3041 way, but for
the identifiers instead of the addresses, that is an identifier
would become deprecated and not used for some outbound communication
at time T1, but packets to that identifier would be accepted until time T2 >>
T1.

If you want sessions that survive longer than T2 you'd need to
use an identifier that has longer stability.

Christian wrote:
> No, I don't think so. It would break correlation in time, but it would
> still enable correlation in space, as in "these two locators lead to the
> same location". That may or may not be a problem for *site* multihoming,
> but it definitely is a problem for *host* multihoming, e.g. a host with
> a WiFi and a GPRS connection.
> 
> Come to think of it, the only way to not disclose these relations to
> third parties is to (1) make sure that the identifier is not disclosed
> as part of the IPv6 address and (2) make sure that the identifier is
> only exchanged over an encrypted channel between the corresponding
> hosts.

I guess there is a difference between making the correlation discoverable
from a publicly available infrastructure (e.g., the DNS) and requiring
that the node, malicious or not, that wants to discover the correlation  
has to communicate with the host in question.
But in any case, to be able to prove to a peer that some communcation
can fail over to use different locators, the host will need to disclose 
the correlation between those locators to the peer.

I don't think we can argue that all peers with which a host communications
(based on URLs embedded in whatever web pages the host might access, for
instance for ad insertion) are uninterested in discovering such correlation.

So I don't see how you can have your cake an eat it too;
if the host doesn't want the correlation between its locator on WiFi and GPRS
to be discoverable then it must not enable multihoming support which allows
rehoming between those locators.

  Erik