Re: Advantages and disadvantages of using CB64 type of identifiers

Iljitsch van Beijnum <[email protected]>
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
On 7-jul-04, at 19:35, Erik Nordmark wrote:

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

Actually this is more an RFC 246x thing.

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

:-)

Note that there are very different requirements for servers, clients 
and participants in peer-to-peer communication. I'm going to assume 
that there are few privacy issues for servers as they need to be known 
to do their job. For clients there are privacy issues but they don't 
need long-lived ids so it's not too bad. For peer-to-peer participants 
it's harder because they can't switch ids as easily.

Also, for clients it should be possible to hide any additional locators 
and just send over auth info. Then, if there is loss of connectivity, 
the client switches locators and says "hi, it's me, remember my hash 
chain?" or something similar.

Obviously this way it's still fairly trivial for an adversarial 
correspondent to find out additional locators.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.