RE: Identifiers

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Brian,

[...]
>
> Good input. We might think in terms of a Level 1 architecture in which
> the ULP still fondly believes that an IP address is a good identifier,

By address, do you mean any 128 bit long string or a routable IPv6 address?
I guess that ULP protocol can work fine with any identifier whose
representation can fit into 128 bits.

Regards, marcelo

> and a Level 2 architecture where something that can be authenticated
> is used (and the ULP needs to be profoundly modified).
>
>    Brian
>
> Iljitsch van Beijnum wrote:
> >
> > Looking at the proposed solutions, it seems that we have been
> > gravitating towards locator agility without explicit identifiers. While
> > that's certainly a valid approach, I think we should take a few moments
> > to consider identifier issues.
> >
> > The main reason to forego having identifiers is that it is hard to
> > determine if a correspondent is rightfully using an identifier.
> > However, this is not the case for two classes of potential identifiers:
> >
> > 1. Identifiers with a cryptographic nature, such as the ones proposed
> > for HIP. Since the identifier is a hash of a public key, proving
> > ownership is trivial given a few round trips and CPU cycles.
> >
> > 2. FQDNs with a certificate that leads back to a trusted authority.
> > These are in relative wide use today for SSL.
> >
> > It stands to reason that future developments will lead to new types of
> > verifyable identifiers. I think this invalidates the assumption that
> > verifying the authenticity of identifiers is too hard a priori. Rather,
> > the question should be whether we are willing to accept the necessary
> > complexity to allow extensible identifier authentication in our multi6
> > solution of choice. In this regard, it should be interesting to see
> > what the MOBIKE people are up to.
> >
> > Personally, I think the best choice would be to remain agnostic about
> > the identifier issue for now, but build our negotiation protocol such
> > that they can be added easily later. For now, we build a "no
> > identifier" type solution. Solving the problem of how a correspondent
> > proves ownership of an identifier can then be deferred until such time
> > that someone actually wants to extend the multi6 solution to support
> > identifiers. So the only thing we have to do now is make sure the
> > protocols are flexible enough to allow such extensions.
> >
> > Thoughts?
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
>