Re: Identifiers

[Brian E Carpenter <brc@zurich.ibm.com>]

marcelo bagnulo wrote:
> 
> 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.

Exactly. That is all a ULP knows - a binary string shaped like an IPv6 address.
It has no knowledge of the locator-like properties.

    Brian

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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM