Re: identifiers and security

[Erik Nordmark <Erik.Nordmark@sun.com>]

[Still catching up on older mail]

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

Agreed.

> The advantages of not having identifiers are that it's easier to be 
> backward compatible and less new stuff to worry about.

This is a terminology nit, but I think all approaches to multihoming
support have some identifier - whether it is a FQDN, or a list of locators.
What is interesting is whether there is a new ID name space, as you said in
the first paragraph, and whether those IDs are visible to the applications.

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

Taking NOID as an example of with no new ID namespace, the amount of
work (in the form of DNS lookups in forward and reverse maps) 
will also result in stronger association between FQDNs and locators
than we have today. 
So I think it is inevitable that providing "do no harm" security for
the multihoming will accidentally improve security a bit in some cases.

I've certainly entertained ideas that are a lot weaker than NOID,
for instance just have the peers exchange their sets of locators
plus a cleartext cookie/context tag when the setup the state,
and then do a RR check before sending packets to a new locator,
but I've received pushback from folks that I wouldn't characterize as
security geeks, that this would be too weak.
But perhaps it is time to writeup something like that and subject it
to wider scruteny, combined with your suggestion below.


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

I've been trying to layer things so that IPsec and TLS benefit from
the multihoming support by sitting above the layer that handles the
multiple locators, and HIP essentially is layered in the same place.
So perhaps one should explore, taking into account IKEv2 and MOBIKE work,
an approach which layers the multihoming support above IPsec when IPsec
is used?

Thus something which is quite insecure (weaker than NOID as above) when
IPsec isn't used, but when IPsec is used it is as strong as with IPsec in
today's Internet.
Is anybody interested in exploring these ideas further?

  Erik