Subject: RE: Identifiers

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 1 Apr 2004 11:00:24 -0300

> So basically we have four permutations of identifiers:
>
> - non-crypto, non-hierarchical
> - crypto, non-hierarchical
> - non-crypto, hierarchical
> - crypto, hierarchical

Well, there are also reachable identifiers, i.e. locators used as
identifiers, i.e. IP addresses

A generic non-crypto identifier may not provide any inherent security means
like for instance a MAC address.
However, IP addresses do provide a light security feature based on
routability. while this security is light, it is probably good enough to
provide the required security for the initial state when using deferred
setup. OTOH, if you use a generic id (non routable) it is possible that you
need a minimum check for it (like for instance verifying the direction of
the communications that are using it)

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

I just include in the same packet the identifier that i am claiming to own
and _a_ locator where i am reachable. As long i don't introduce a new
locator, i don't do any security checks at all.

Note that the threat draft states that source address is not to be trusted,
so i guess that a source address is as trustworthy as any other identifier
that i may be claiming to own.
The problem here IMHO is that while this binding between the source id and
the source locator (without any security feature) may be good enough for
incoming communications, it cannot be used for outgoing communications.
If this is so, perhaps you can address this problem, by simply not using the
binding in the reverse sense.