[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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