[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: identifiers and security

On 28-jun-04, at 13:52, Erik Nordmark wrote:

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.

Sure, there always is an identifier, obviously I was getting at the situation where there isn't new/separate value that fulfills this function. BTW, I don't consider a _set_ of locators _a_ identifier, as membership of the set presumably isn't fixed and having more than one way to express the same identity (not the same thing as having more than one identity) is a very bad idea. (X.400 anyone?)

What is interesting is whether there is a new ID name space, as you said in
the first paragraph,

Yes.

and whether those IDs are visible to the applications.

Ah, but that's a very different issue. I think by definition the identifiers are visible to the application. There are other values that may not be visible to the application and relevant, though. (And some of you may prefer to call those identifiers, but then we need another term for the application-visible values.) There are many places in the stack where (currently) the same bit string performs different functions. If we make the identifier/locator split this immediately begs the question whether that's enough, maybe we need to dig deeper. I tried to look at this a while ago in my "9 steps" (or similar) message.

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.

Even if we assume DNSSEC?

So I think it is inevitable that providing "do no harm" security for
the multihoming will accidentally improve security a bit in some cases.

Beware of stuff you get for free...

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.

I don't think this is universally true. Certainly, this is too weak for TLS or IPsec sessions that can now be broken by an attacker, unlike before. But why would this be too weak for talking to Google over unprotected TCP/IP?

But perhaps it is time to writeup something like that and subject it
to wider scruteny, combined with your suggestion below.

Right.

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?

I suppose this wouldn't be much of a problem for IPsec. This could even be done today by piping packets through a multihoming mechanism and then take the resulting packets and feed them through IPsec. Obviously this means more IPsec negotiation and state as now there must be an SA for every locator pair used rather than one for the identifier pair.

I wouldn't want to try something like this with TLS, though. I'm thinking more along the line of violating layers and modify IPsec/TLS such that the wedge or modified IP can obtain keys that are exchanged by modified IPsec/TLS. Something like putting the secret instructions for the messager in the locked briefcase he's carrying. This works well except for the first trip of course...

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?

Apart from me, you mean? (-: