RE: Security requirements for identification

["marcelo bagnulo" <marcelo@it.uc3m.es>]

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

I am considering the current use of ip addresses i.e. before the loc/id
split, so ip addresses are both locators and identifiers.
What i mean is that currenlty you can use ip addresses in order to obtain
some added security. For instance you can use directly ip addresses (no
FQDN) so that you don't have to turst in the DNS, and you can also use the
IP address to allow incoming communications an so on.


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

Actually what you are really doing is to use fqdn as permanent identifiers
and the DNS as a rendez-vous system, so it provides you with the transient
identifier and also with the locator.

I mean, if you want to establish a communication with someone you already
know, you need a mean to express his identity, and that is a permanent
identifier.

(the other option that i could think of are limited lifetime identifiers
that overlap in time so that you can provide one and obtain the next one,
which will be valid for the next period)
However i think that we could focus on the case that atr least for some
hosts, a permanent identifier is needed, or put it in another way, we can
provide differents types of identifiers, but one of these types should be a
permentent one.

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

But you need initial rendez vous if you want to provide a multi-homing
solution that works, so it is part of the multi-homing problem

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

Agree, i can see many benefits in those cases, but are those features
essential to a multi-homing solution? or are they just a nice-to-have
feature? Would you inlcude them in the MUST list of a loc/id split solution
for multi-homing?

Thanks, marcelo

>   Erik
>
>