RE: Security requirements for identification

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

> Agree, but i think we are making some progress here.
> I think i would be a good idea to accept Pekka's offert, and put some of his
> postings in a ID format. IMHO this could be good starting point to
> understand the requirements.

Agreed.

> We should also preserve the security of communications that don't use the
> DNS i.e. they use IP address directly. I mean, it is safer to use directly
> IP addresses than using names (without DNS). This capability has to be
> preserved. This means that not only the chain starting from a FQDN and
> ending in the packet delivery has to remain as safe as it is today, but also
> it has to be possible to establish a communication with the same level of
> security of the one obtained today when sending packets directly to ip
> addresses without using the DNS.

You use the term "IP address" which I've removed from
my vocabulary in this context; are you talking about an identifier or
a locator?

> Ok, this depends on what do you call stable.
> But, i guess we agree that in order to able to establish a communication,
> the initiating party has to be capable of identifying the other party, so
> that it can define who he wants to talk to. This means that some form of
> stable identifier is needed at least for the server party of the
> communication.

Yes, but potentially such a number doesn't need to be globally unique.
I can envision potential solutions, their desirability aside,
where each server would pick a random number at its identifier
with no global coordination, publish that number in the DNS
(e.g. using a new ID record) together with the locators published as AAAA 
records.
This would allow the client to use the fqdn to find both this identifier
and the locators for the service and communicate. Such "identifiers" do
not need to be globally unique, and they might change as frequently
as it is feasible to update the DNS ID record.
So I hope the above illustrates that there isn't an inherent requirement
from the multi6 problem set to make the identifiers globally unique or stable.

That doesn't mean that it is a good idea to make them unstable. Since we need
to prevent redirection attacks there has to be a way to check who is authorized
to redirect the packet flow for a given identifier to some new locator. That
would be quite confusing if multiple nodes happen to use the same identifier
while communicating with the same peer; "redirect packets for id=X" would then
affect traffic to two separate nodes thus the authorization question can't be
answered.

So I think the multi6 problem set requires very low probability that two
nodes use the same identifier when communicating with a given peer.

But I don't think it is until you also look at other problems, like
identifiers that can be used by applications for rendez-vous and referral,
that the stability issue comes to the forefront.
(One could argue that from the perspective of the UDP/IP stack, an
application over UDP behaves in ways that look like applications doing
rendez-vous; the only difference might be implicit assumptions about what
the elapsed time is between receiving something and trying to send something
back.)

So I'm all for stable identifiers for general application using being
part of the free lunch; but oops - there is no free lunch :-)
Thus we need to try to tease apart the different uses of identifiers
and understand the requirements a bit more.

> Perhap we can see the IPv4 situation and evaluate which kind of identifiers
> are needed.
> An intersting point is that some hosts never have a permanent identifier and
> perhaps they don't need it (for instance hosts through dial-up with dhcp)
> On the other hand, servers need stable identifiers so they can be reached.

But is this ("clients" not have stable IP or DNS names) a feature or a bug?

Turning things around, one could ask what the benefits would be of having
an identifier which 1) doesn't change when you change ISP and 2) doesn't
change due to some administrative mistake (like not renewing your domain
name with the registrar).

  Erik