Re: Advantages and disadvantages of using CB64 type of identifiers

On 8-jul-04, at 20:58, Erik Nordmark wrote:

>> Note that there are very different requirements for servers, clients
>> and participants in peer-to-peer communication.

> Are you talking about clients, servers, and p2p participants as
> different products that contain different protocol stacks (or
> differently configured stacks) which make different assumptions?

I was thinking about systems running a single type of application. 
(Obviously the real world is more complex but we can backport that 
later when we have a better understanding of the issues.)

> I think there are *communication roles* called client, server,
> and p2p participant, but the same application might play different 
> roles
> over time or depending on usage, so I don't see how a given protocol 
> stack
> can have different defaults unless that stack is bundled with a 
> non-extensible set of applications.

I'm certainly not arguing for different stacks. But I think it's 
possible that the three types of systems are configured with different 
identifiers or different constraints on the use of their identifiers.

> Thus, while the application that different roles have different 
> requirements,
> I don't see that being useful unless we think it makes sense to define 
> APIs
> by which an application is required to express its role or its 
> requirements.

Are you saying we should treat applications as black boxes and be 
prepared to handle any combination of actions from all of them?

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

> That doesn't prevent the curious peer from discovering them by
> pretending that locator the client is using is having a problem
> (worst case the peer should be able to force this by just
> dropping the packets from the client until the client
> tries a different locator).

Well, yes. But in this scenario the client hasn't committed to anything 
at session start, it may very well decide later that it doesn't want to 
reveal any information after all. For instance, the client may want to 
forego multihoming for shortlived, non-TLS or otherwise unimportant 
sessions.

But it seems trying to hide locators/identifiers is pretty much a dead 
end.

> So it isn't clear to me what problem we are actually trying to solve
> in the privacy space.

That's what I asked Christian.

Iljitsch