Re: Identifiers

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 29-mrt-04, at 21:14, Erik Nordmark wrote:

> If a separate identifier is used this means that the initial setup must
> appear before (or at the same time) as the first ULP packets are 
> exchanged.

Yes. This also means the negotiation protocol must be able to get 
through in order for anything to work, piggybacking will be very hard 
here.

(Aside: I always thought it was a big flaw in the IKE design that the 
negotiation is done with the target host. Maybe it's too hard to make 
this work safely with a third party host, but it would have some nice 
security benefits and solve rendezvous for mobility.)

> But if we just have a locator-agile mechanism without a new identifier 
> space
> it makes sense to allow a deferred exchange (and verification) of the 
> locator
> sets e.g. to avoid this cost when the connections are very short.

Right.

> I don't have a good feeling for how complex it would be to design
> a protocol which can do both immediate and deferred setup.

I'd think it wouldn't really matter. Immediate setup can be viewed as 
deferred after 0 bytes of data have crossed the line. The only 
difference is that with deferred negotiation some information we need 
(locators) is by definition available, while with immediate negotiation 
we may need to go look for it ourselves. Or am I missing something?

> Will a scheme which introduces a new ID name space by necessity need
> different security mechanisms?

Not by definition. But some types of identifiers could support security 
mechanisms that others can't. For instance, with crypto based 
identifiers it is possible to find out whether the other side is the 
real holder of the identifier with nothing more than information 
received from the correspondent. With non-crypto IDs you need some 
chain or web of trust if the identifier is cryptographically protected. 
Alternatively, the information may not be learned from the 
correspondent but rather from a mapping service. The way such a mapping 
service works depends on the nature of the identifiers (hierarchical or 
otherwise).

So basically we have four permutations of identifiers:

- non-crypto, non-hierarchical
- crypto, non-hierarchical
- non-crypto, hierarchical
- crypto, hierarchical

We probably don't need four different security mechanisms, but more 
than one is likely if we're going to use identifiers from more than one 
category.

> Will be immediate vs. deferred state setup have implications on this?

I don't see how we can defer state setup for identifiers that aren't 
reachable locators. And identifiers that ARE locators aren't always 
reachable, placing part of the multihoming burden on applications.

> Is there a common "message sequence" which can apply independently of
> the actual security mechanism being used?

Does it matter? The messages are presumably passed back and forth 
transparently. The only important part is that we have some 
well-defined state transitions, and the security mechanism triggers the 
right one at the right time.

BTW, without knowing the details, I think 802.1x, PPP and EAP solve a 
fairly similar problem.

Iljitsch