identifiers and security

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

As I've said before, I think it would be useful to allow for 
multihoming solutions that add a new identifier space, and also for 
multihoming solutions that don't. (The new identifier space may or may 
not be expressible as something that looks like an IPv6 address, but if 
it is, it's not a routable IPv6 address.)

The advantages of not having identifiers are that it's easier to be 
backward compatible and less new stuff to worry about. The downside is 
that it's probably prohibitively complex to fully secure any 
negotiations that are needed for this, and/or it's necessary to rely on 
the DNS which also has security problems, and isn't always very 
reliable.

The irony of explicit identifiers is that they are so insecure, that 
they must be protected using strong security, so they effectively 
become more secure than any identifierless solution. The reason 
explicit identifiers are insecure to start with is that without a 
secure mapping mechanism of some sort, a correspondent is unable to 
determine whether someone claiming to hold an identifier is the 
legitimate owner of this identifier.

In an identifierless solution the routing system provides some level of 
assurance as obviously packets addressed at the initial locator (that 
functions as an identifier) make it to the host claiming to hold this 
locator (assuming a handshake of some sort, such as the TCP one). 
However, it's sometimes possible for third parties to gain access to a 
link and claim to hold addresses routed over that link, so this only 
provides a very basic level of security. However, single homed 
operation is also insecure in these situations so there is no 
obligation for any multihoming solution to solve this problem, just to 
make sure the additional multihoming mechanisms don't add to this 
problem in a material way.

I think it's important to recognize that "regular" IP operation without 
the benefit of IPsec, TLS or similar authentication and what comes with 
it (such as SSH) is very often insecure, and in most cases this isn't a 
problematic situation. So mandating strong security in all situations 
is probably a mistake. However, IPsec/TLS and the like are in wide use 
for communication that must remain confidential. In those cases, the 
key management problem is solved in some way or another. It would be 
very beneficial to take advantage of this situation and leverage IPsec 
or TLS mechanisms that are already in operation towards securing 
multihoming. One way to do this is taking the IPsec or TLS "identifier" 
and use it as the multihoming identifier. Architecturally this is a 
nice approach, but in practice it will be hard to get off the ground, 
especially with TLS as it's not always possible to determine the 
authenticity of a single packet with TLS. Another approach would be to 
exchange a session key that's protected using the IPsec or TLS that's 
already there and protect the multihoming exchanges using this session 
key.