[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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,
and a Level 2 architecture where something that can be authenticated
is used (and the ULP needs to be profoundly modified).
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.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
- From: Iljitsch van Beijnum <email@example.com>