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.