Subject: Security requirements for identification

From: Pekka Nikander <[email-masked]>
Date: Wed, 24 Sep 2003 09:49:34 +0200

In my previous message (to hipsec&ipv6 ml) I proposed dividing
identification to the following three subcategories:

    a) identification in mobility and multi-homing
    b) identification in referral or rendezvous
    c) identification in other, e.g. administrative, contexts

I also discussed rendezvous and referral, in order to
make the point that identifying a node and locating it
are really two distinct functions.

The previous message is available at
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html

In this message I will try to analyze the security
requirements for identification in the sense of a)
and b).  Analyzing c) in isolation does not make any
sense, since the security requirements depend on the
context.  In the end of this message, I try to give
some conclusions based on the analysis; if you are
busy, you may want to see the conclusions first.

I am focusing here solely on the identification
function, and not touching the security requirements
of the location function.  It should be noted, however,
that these two are related in real life.  Analyzing that
is for another message.

a) identification for mobility and multi-homing
-----------------------------------------------

As I wrote earlier, here we are only interested in gaining
assurance that the peer remains the *same*.  That is, we
do not really care *whom* we are communicating with, but
only that the peer end-point is not changed in mid-
communication.  (We probably did care the "real identity"
of the peer when we first initiated the communication, but
that is a different issue, with different security
requirements.)

There are two basic dangers related identification in mobility
and multi-homing.  One is connection hijacking, i.e., somebody
"stealing" the connection and replacing one of the peers without
being noticed.  The other, less obvious one, is flooding.
Flooding is an attack where a genuine peer lies about its
location(s), with the purpose of choking a victim on excess
traffic.  That is, the attacker claims to move/be better
reachable at the location of a victim, thereby directing the
traffic to the victim.

Flooding is a serious attack since the amounts of redirected
traffic can be large.  Consider a public streaming server.
Anyone can make a connection to it, and start downloading a
stream.  For the stream to run, acknowledgments must be sent
back.  This is easy, since an attacker can open a stream,
redirect the stream (using some mobility or multi-homing
mechanism) to a victim address, and *continue* sending
acknowledgments.  Anticipating when and what kinds of acks to
send is easy enough.  This makes the stream running independent
on the actions by the poor victim.

Hence, for the purpose of mobility and multi-homing, the
identification mechanism has to keep sure that the peer really
remains the same, on all changes of locators.  Furthermore, the
mechanism must not blindly trust what the peer claims about its 
locations, but must check that the same peer really *is*
at all the claimed addresses.

If we really do not care who the initial peer really is,
then a simple protocol is sufficient; the protocol first
creates a shared secret between the peers and then uses
the secret to verify persistence of the identity.  The
protocol may even be vulnerable to MitM attackers in its
initialization state; our requirement states that a MitM
attacker is equally good to the "real" intended peer,
since we don't care about the "real identity".

The requirements can be summarized as follows:

   R1. Verification that the peer is the same one
       after all changes of locators.
   R2. Verification that the same peer is reachable
       at all claimed (and used) locations.

The MIPv6 RR protocol is a (somewhat convoluted) example of
a protocol fulfilling the requirements.  (It also fulfills
other, Mobile IPv6 specific security requirements.)

b) identification for referral or rendezvous
--------------------------------------------

In the case of referral or rendezvous, an initiating party
possesses an identifier that it wants to use as a means
of identifying another party.  The target party may have
no idea of the intentions of the first party, and it may
have never met the first party.  In other words, the parties
do not share any state but the identifier itself and any
state in the target party that is associated with the
identifier.

 From a security point of view, the requirement is that
the party that responds to a communication request really
is the party denoted by the identifier, and someone else.
That is, the requirement is that the target party really
is the intended target party.

If we assumed that everybody is honest, any unique bit
string would serve well as an identifier.  The initiating
party just sends the bit string to the target party, and
asks the target party to verify that the bit string really
is its identifier.  The problem is that we cannot necessarily
assume everybody to be honest.

If we assume dishonest parties, we get two sub cases.  In
the first case, the initiating party must send the identifier
in clear, for some reason, or the identifier is otherwise
public and known by the dishonest parties.  In the second
case, the initiating party is able to keep the identifier in
secret.

In the first case, the only secure way of performing
identification seem to be public key cryptography (or any of
its variants, like zero knowledge protocol).  The reason for
this is the following.  Since the identifier is public
knowledge, we cannot use the identifier directly.  Instead,
there must be some secret that only the right party
knows and is able to prove to know.  The identifier and the
secret must be linked.  Only public key crypto (or a variant)
seems to fulfill these requirements.

The second case is more interesting, since it allows for
some simple cryptographic protocols that show to the
target party that the initiating party knows its secret
identifier without revealing it, and where the target
party is conversely able to show to the initiator that it
also knows the secret identifier.  In effect, in this
case the identifier is a shared secret.  However, it is
also almost completely impractical, since one cannot
share such a secret with anyone, nor put it into a public
directory.  (There are some special cases where this kind
of identification may be useful, but one cannot build a
generic Internet wide architecture on such assumptions.)

Hence, if we want to do referral and rendezvous in a
secure way, we seem to need public keys as identifiers.
It looks best to use public keys as primary identifiers.
It is also possible to use public keys only as secondary
identifiers, and bind them to some primary identifiers,
but that costs more since it requires a PKI.   Using public
keys directly as primary identifiers does not, as such,
require a PKI.

To summarize, the requirement is

   R3. Verification that the target party really is the
       party denoted by the identifier.

With public identifiers and under the assumption that there
may be man-in-the-middle or masquerading attackers, public
keys (or variants) seem like the only known technology
that securely fulfills this requirement.  It should be noted,
however, that we do not necessarily need to care about
potential man-in-the-middle or masquerading attackers.
Whether to do so or not is a design choice.

Discussion
----------

To my best knowledge, the discussion above describes the
essence of the difference between the current architecture
and one where identifiers and locators are separated.
In the current architecture, the mobility and multi-homing
problem does not exist, since one is not allowed to change
ones locators on the fly.  What comes to rendezvous and
referral, the practice of using locators as identifiers
offers a somewhat weak but very important form of security.
Effectively, the practice limits the number of potential
attackers hugely, from all nodes in the Internet to only
those nodes that are on the path between the initiating
party and the target address.

It is extremely important to understand that if we really
separate identifiers and locators, we become more vulnerable.
Fortunately the class of potential attackers will not be
everyone in the Internet, but only those that can tamper
with the identifier -> locator mapping or otherwise get
on the path between the initiating party and some locator.

Conclusions
-----------

Separating identifiers and locators has security implications.
To address these, we basically have a number of possibilities:

   1) Design a _secure enough_ identifier -> locator mapping
      service, thereby limiting the potential attackers to
      those that can either tamper with the service or otherwise
      receive packets sent to the (initially used) locator.
      What is "secure enough" is a design choice.  The service
      must be dynamic because it must be possible to update
      the set of locators.

   2) Decide to use public keys as primary identifiers,
      and rely on public key cryptography for identification.

   3) Design a _secure enough_ identifier -> public key mapping
      service, thereby limiting the potential attackers
      to those that can tamper with the service.  This is
      effectively a PKI, but not necessarily as secure as what
      people traditionally understand with a PKI.  The difference
      to 1) is that here we are not vulnerable to attackers that
      just get to the path but can't tamper with the service.
      The service may be fairly static, since there is seldom
      need to chance one's public key.

   4) Go only half way, and stop where the identifiers can
      be still used as (limited) locators.  The class of
      attackers depends heavily on details, and cannot be
      easily summarized.

I refrain from making comments on any practical designs (like
DNS), since that requires one to consider also other aspects
but security.

Questions
---------

Does this analysis help?
Do we have other choices but the four outlined above?
Should create an I-D from this and the previus message? If so,
should it be accepted by some WG as a working item?

--Pekka Nikander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 24 Sep 2003 18:54:16 +0200

Hi Pekka,

thanks for the posting, some questions below...

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Pekka Nikander
> Enviado el: miercoles, 24 de septiembre de 2003 9:50
> Para: Multi6 WG; [email-masked]
> Asunto: Security requirements for identification
>
>

I am not sure if i understand this...
I mean, we do care about recognizing the other end of a communication,
right?

Usually, when a host establish a communication, the host wants to establish
the communications with a certain host, it is not the case that we want to
communicate with any host available. So this is expressed by the ip address
of the target host. This means that we do care who the other end is.In other
words, IP addresses are used today for recognizing the other end.

So perhpaps i don't agree with a statement from your previous mail:

"1a) To me, identification for mobility and multi-homing seems to
    be the easiest one.  There we are only interested in gaining
assurance that the peer remains the same.  That is, for the
sole purpose of mobility or multi-homing, we do not really
care with whom we are communicating with, but only that the
peer end-point is not changed in mid-communication due to
mobility, multi-homing, or attacks based on mobility or
multi-homing mechanisms."

I guess we always care with who we are communicating with i.e. we always
need a permanent identifier -
This is true for at least for one end of the communication, the end that is
initiating the communication. Perhaps the server side of the communication
does not know who the initiator is and perhaps he doesn't even care, (as
long as it remains the same)

If you use a transient identifier, actually you are using two identifiers:
first the IP address as a permanent identifier to recognize the host and
then the transient identifier to recongnize the host when it changes its
address.

So i guess that what is needed is:
- a permanent identifier (so you can talk with who you really want to talk)
- A locator (so you can reach it)
- something to bind them (which can be a transient identifier, but you can
use some other stuff)

So i would say that ephemeral identifiers are not enough to provide
identification support for multi-homing and mobility support, we need more,
i.e. permanent identifiers.

Regards, marcelo

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 25 Sep 2003 09:29:25 +0200

Marcelo,

> I mean, we do care about recognizing the other end of a communication,

Yes, we do care.  But we do not care for the very specific
purpose of "mobility and multi-homing", as I write.

A very important point in the analysis is to make a distinction
between identification in the beginning of a session,
and subsequent identifications that are needed during the
session, for various purposes.

Hence, the point is that _solely_ for *mobility* or *multi-homing*
you don't care about who, or any application level identity.
You only care about that the peer is not changed in mid communications.
Other parts of the system probably have other concerns, but not
the mobility / multi-homing mechanism.

> words, IP addresses are used today for recognizing the other end.

Yes.  What you describe is what I called in the previous
analysis as "initial rendezvous".  Things do get mixed in
real life.  However, when you try to understand the roots
of phenomena, you have to make distinctions and draw lines,
even if sometimes they first seem bizarre.

> need a permanent identifier -

That may well be the case in most communications.  But _only_,
_solely_, _exclusively_ for mobility and multi-homing, you
do not *need* to care.

This may be deep, but this is one of the very points of the
analysis.  Make distinctions.

> then the transient identifier to recongnize the host when it changes its

Now, that might be perfectly reasonable.  You are using the
permanent IP address for initial rendezvous, and then you use
a transient identifier to secure mobility.  In fact, that is
exactly what happens in Mobile IPv6 RO today.  You have the
home address, and you have Kbm, which is a kind of transient
identifier.

> - a permanent identifier (so you can talk with who you really want to talk)

You need that for identification in the rendezvous sense.

> - A locator (so you can reach it)

You need that for reachability, not for identification.

> - something to bind them (which can be a transient identifier, but you can

Yes.  But I haven't got that far yet :-)

> i.e. permanent identifiers.

I think that we are not (yet) on the same baseline with respect
to understanding the various components in the game.

--Pekka Nikander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Sep 2003 11:12:14 +0200

Pekka,

> Enviado el: jueves, 25 de septiembre de 2003 9:29
> Para: [email-masked]
> CC: Multi6 WG; [email-masked]
> Asunto: Re: Security requirements for identification
>
>
> Marcelo,
>

Ok. I think i see what you mean.

> You need that for identification in the rendezvous sense.

Ok

> You need that for reachability, not for identification.

Ok

> Yes.  But I haven't got that far yet :-)

Well, i been re-considering this point and i think i would like to re-state
it in the following way.

I guess that identifiers make sense if you can prove that you own them.
I mean i can tell you that i have identifier A but if i cannot prove that i
own it it isn't really useful.
So, usually we use IP addresses as identifiers, and the proof of ownership
is provided by the routing system.
Now the problem is that when we move or change the path to alternative
provider, we connot longer prove that we own our identifier.
So here is when a ephemeral identifier can help, since you can start using
the permanent idenfitifier (ip address) when you are capable of proving its
ownership, and at this moment create an ephemeral identifier, which you can
prove that you own by other means than the routing system i.e. crypto. And
then just forget about the permanent identifier and keep track of the
identity of the other end by just using the ephemeral identifier.
So, you don't need the ephemeral identifier to make a safe mapping to a
locator, but you need it to provide an alternative identifier whose
ownership can be proven when you cannot longer prove the ownership of the
permanent identifier.

Obviously, you could just solve the problem by using an identifier that
doesn't uses the routing system in order to prove its ownership, and it uses
a location idenpendent mean to prove it (just like public keys ;-)
However, the problem of initial rendezvous remains in this case.

> to understanding the various components in the game.

I think that your postings are being really useful to understand these
issues.
Thanks, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 25 Sep 2003 23:15:04 +0200 (CEST)

> i.e. permanent identifiers.

I think the security requirements are far from clear.

What is clear is that a mechanism that allows connections to survive
multihoming by being able to replace the identifiers that are used for a
connection, need to prevent redirection attacks where a connection is
accidentally or maliciously redirected to somebody else.

What is also clear is that any new system for mapping identifiers to
locators need to be concerned about security so that the chain
of starting with a FQDN and ending up with a packet received at the
peer isn't weaker than it is today, and that DNSsec applied to the parts
(e.g. FQDN->identifier lookup) can help make the security of that chain
stronger.

But the security requirements beyond this depend on what else we want
to use the locators for.
One possible use is a stable handle on a peer that has a longer lifetime
than both the locators and the FQDNs; if a node receives a packet
from an identifier and its the same identifier as was used 3 years ago, the
node can be sure it is the same node.

Another possible use is as a handle into some policy where the identifer
might have some hirarchy so that a node can tell e.g. whether a peer's
identifer belong to the same or different site as the node.

So I don't know if we have consensus that we need long-term stable identifiers
as part of id/locator separation. Perhaps we need multiple flavors of
identifers with some being long-term stable.

  Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 26 Sep 2003 17:03:29 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Erik,

> De: Erik Nordmark [mailto:[email-masked]]
> Enviado el: jueves, 25 de septiembre de 2003 23:15
> CC: Pekka Nikander; Multi6 WG; [email-masked]
> Asunto: RE: Security requirements for identification
>
>

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.

> peer isn't weaker than it is today,

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.

> and that DNSsec applied to the parts
> as part of id/locator separation.

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.

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.

> Perhaps we need multiple flavors of

indeed, perhaps we do.

Thanks, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 26 Sep 2003 18:45:48 +0200 (CEST)

> understand the requirements.

Agreed.

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

> stable identifier is needed at least for the server party of the

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.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Sep 2003 17:28:37 -0700

Pekka,

I think I said this last time, but just in case:  thanks for working on
cohesive discussion about needs and issues for identification.  It makes it so
much easier to debate specifics...

My comments, below, are tuned for multiaddressing, since that it the
motivation du jour. If the scope of this discussion is meant to be broader
than dealing with mobility and multihoming, please forgive my error.

PN> a) identification for mobility and multi-homing
PN> As I wrote earlier, here we are only interested in gaining
PN> assurance that the peer remains the *same*.

yes.

PN> There are two basic dangers related identification in mobility
PN> and multi-homing.  One is connection hijacking,

yes.

PN> being noticed.  The other, less obvious one, is flooding.

I am only now finally understanding why this is a problem "created" by
multiaddressing.   Hijacking is directing traffic to oneself.  Flooding is
directing traffic to someone else.  One is to intercept data and the other is
to overload a victim.  Both problems are created by being able to ... redirect
traffic to a new address.

Thank you!

PN> Hence, for the purpose of mobility and multi-homing, the
PN> identification mechanism has to keep sure that the peer really
PN> remains the same, on all changes of locators.  Furthermore, the
PN> mechanism must not blindly trust what the peer claims about its 
PN> locations, but must check that the same peer really *is*
PN> at all the claimed addresses.

Hmmm. Carried to the extreme the requirement seems to specify would probably
require having every packet be encrypted -- so it could only be decoded by the
correct recipient -- and acknowledged with a signature.

At most, I suspect you really mean that there must be a "useful" confirmation
when a new target address is used for the first time. For example, if there
are nonce-based association identifiers,

    1) the initiator using the target address for the first includes the
    target's nonce in some sort of "hello again" packet, and

    2) the target responds with a packet containing the initiator's nonce.

This goes beyond the safety provided in current, mono-addressing IP, but
certainly is focused on problems caused (or exacerbated) by the introduction
of multiaddressing.

PN> b) identification for referral or rendezvous

PN> In the case of referral or rendezvous, an initiating party
PN> possesses an identifier that it wants to use as a means
PN> of identifying another party.

In spite of the above language, you do not define rendezvous and referral. I
have been assuming the latter means "moving an association from one endpoint
to another". That is, "hand off" of one end of an association to a new
endpoint.

So, please clarify what you mean by both terms and how they relate to the
distinction between identifying versus locating.

I believe the two terms can, and should, refer to two different things (unless
there is already an established practise of using them synonymously)

Rendezvous is a means of one endpoint finding another. It often uses a
third-party intermediary. It may or may not occur when there already is
context between the two endpoints.

Referral is a means by which one host in an association can replace itself
with another host.  That is, it transfers the association context to a third
host.

PN> If we assumed that everybody is honest, any unique bit
PN> string would serve well as an identifier.  The initiating
PN> party just sends the bit string to the target party, and
PN> asks the target party to verify that the bit string really
PN> is its identifier.  The problem is that we cannot necessarily
PN> assume everybody to be honest.

PN> If we assume dishonest parties, we get two sub cases.  In
PN> the first case, the initiating party must send the identifier
PN> in clear, for some reason, or the identifier is otherwise
PN> public and known by the dishonest parties.  In the second
PN> case, the initiating party is able to keep the identifier in
PN> secret.

This line of thinking appears to go quite a bit beyond the current world of IP
mon-addressing.  And I believe it involves concerns not created by
multiaddressing.

However validly, we trust DNS entries and IP routing.  As soon as you worry
about whether to send an identifier in the clear, you are considering
something far broader than problems caused by multiaddressing.

PN> In the first case, the only secure way of performing
PN> identification seem to be public key cryptography (or any of
PN> its variants, like zero knowledge protocol).  The reason for
PN> this is the following.  Since the identifier is public
PN> knowledge, we cannot use the identifier directly.

Today, we use domain names and IP addresses in the clear.  And things work
pretty well.

To use Marcelo's phrasing, we do not "prove we own" the domain names are IP
addresses we use.

So, why must we start encrypting identifiers?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 25 Sep 2003 17:21:30 +0200

On onsdag, sep 24, 2003, at 09:49 Europe/Stockholm, Pekka Nikander 

> Does this analysis help?

I think it does raise / point out some interesting facts on what can / 
can't be properties of identifiers.

> should it be accepted by some WG as a working item?

I have two question to the WG, and especially to the DT chairs and the 
AD :

1) Would we consider it useful to have a WG document on properties of 
identifiers, in terms of security? Maybe even call it "Security 
requirements"? From Tony's ad-hoc poll, there seems to be a clear 
majority in favor of some sort of id/loc split, with reservations on 
what each of them really is.

2) Do we think we could get rough consensus around such a document? In 
some other words, the WG will still of course be free to choose not to 
adapt a document by Pekka. But as the discussion following Tonys 
question showed, there are very different views on what an identifier 
is/might be. I think we at some point need to start to narrow this 
down. This is of course part of what the DT's are working on, that is 
why I also ask the DT chairs if they would consider this helpful.

I do realize that such a document will have to make certain assumptions 
on what an identifier is. But I also think that might be issues we 
could sort out as the DTs present at we get better understanding.

Ok, so....<making room in mail folder>...:-)

- - kurtis -

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Sep 2003 13:03:29 +0200

> my vocabulary in this context; are you talking about an identifier or

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.

> from the multi6 problem set to make the identifiers globally

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

> 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

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 29 Sep 2003 13:36:49 +0200

Hi Dave,
> certainly is focused on problems caused (or exacerbated) by the

Not really. Current mono-addressing IP security relies on routing (id=loc so
if you trust the routing system then it will deliver the packet to the
correct IP==ID)
So current mono-address ip does perform a verification that the other end of
the communication remains the same in EVERY packet.
This scheme of nonce validation only verifies the id of the other end at the
begining of the communication (or when a new address is included). So, it is
stronger for the moment when this exchange occurs, but it opens the
possibility of attacks shifted in time, since this scheme does not verifies
the identity all the time.
So, the nonce based scheme it is stronger in one sense but it is weaker in
another sense

(To overcome this issue, mip demands a periodical exchange of nonces so that
the identity of the other end of the communication is verified periodically)

> something far broader than problems caused by multiaddressing.

I don't completelly agree.
Today you can establish a communication using only an IP address (you can
avoid using the DNS for security reasons)
So i don't think is reasonable to say that all ip addresses are as weak as a
communication that involves a dns query (if we can say this, the security
problems would be greatly reduced).
I do agree with the routing part.

> To use Marcelo's phrasing, we do not "prove we own" the domain

You do prove that you own the IP address, the routing system does it.
About the DNS, see my comment below i.e. you can establish a communication
without using the DNS today and i don't think it is reasonable to design a
solution imposing the dns security level to all possible communications.

(BTW I read the address ownership expression fro the first time in Pekka's
draft "An Address Ownership Problem in IPv6"
(<draft-nikander-ipng-address-ownership-00.txt>))

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Sep 2003 09:12:36 -0700

marcelo,

(I subscribe under different addresses, to multi6 vs. hipsec.  So my replies
are only making it to multi6. I think that that is the right venue for this
discussion. )

mb> Not really. Current mono-addressing IP security relies on routing (id=loc so
mb> if you trust the routing system then it will deliver the packet to the
mb> correct IP==ID)

The question is how the IP address is obtained. _Using_ an IP address when
there is multiaddressing also relies on the routing system to deliver the
packet to the correct IP address.

What is different is that multiaddressing introduces a way of _changing_ that
original IP address into another one. Although the sender still chooses which
IP address to use, the multiaddressing proposals all provide new, automated
ways of slipping those new addresses in.

So my point is that multiaddressing creates a security challenge not because
delivery is changed but because address selection is changed.  In the past,
address selection really was easy.  Somehow you decided on using one.  Then
you stayed with it.  Now you may not.

mb> So current mono-address ip does perform a verification that the other end of
mb> the communication remains the same in EVERY packet.
mb> This scheme of nonce validation only verifies the id of the other end at the
mb> begining of the communication (or when a new address is included).

With mono-addressing, the target gets a packet with a destination IP address
and validates that it -- the target -- is that IP address.  With multiaddress,
this does not change.

With mono-addressing, the target gets a packet with a source IP addresses.  It
might or might not "validate" it by sending a return packet.  With
multiaddressing, this does not change.

So, the per-packet validation that is created by adding a per-packet nonce
does a validation that is new. It well might be a useful validation, but it
really has nothing to do with multiaddressing.

I claim that the validation that needs to be performed, as a result of using
multiaddressing, is at the time of address _selection_. This is at the
initiator's side, prior to use. The only reasonable way to do that is for the
initiator to have a basis for trusting the pool of available addresses. Hence,
it is the process of building that pool that requires a serious validation
mechanism, not the process of using addresses from the pool.

mb> (To overcome this issue, mip demands a periodical exchange of nonces so that
mb> the identity of the other end of the communication is verified periodically)

Let's ask: What does the periodic exchange detect or fixe? It uses a secure ID
to ensure that the IP addresses being used are legitimately among the pool
associated with the endpoints belonging to their respective identifiers. More
importantly, it validates that things have not _changed_. What could have
changed between uses of the nonce?

Could the routing system have started sending packets with the same IP address
to a different place? If this is the concern, it certainly is legitimate, but
has nothing to do with multiaddressing.

Or is the concern that the IP address now being used for the target is not
valid? This is certainly a problem that already exists with monoaddressing,
but it is significantly exacerbated by multiaddressing, since multiaddressing
introduces an automated mechanism for adding new IP addresses to the pool.
However it is not the _use_ of the address that is the problem.

It is the event of adding a new target address to the initiator's pool of
addresses for the target. Regular use of the nonce in packets might detect a
failure condition. However, strongly protecting the mechanism for adding to
the pool will accomplish the same thing, and it will do it with lower packet
overhead. And it will do it as pre-hoc prevention, rather than post-hoc
detection.

>> something far broader than problems caused by multiaddressing.
mb> I don't completelly agree. Today you can establish a communication using
mb> only an IP address (you can avoid using the DNS for security reasons) So i
mb> don't think is reasonable to say that all ip addresses are as weak as a
mb> communication that involves a dns query (if we can say this, the security
mb> problems would be greatly reduced). I do agree with the routing part.

My reference to DNS was simply not note that domain names serve as identifiers
and that the mapping to IP addresses is a process that is used with serious
expectations of validity. Yes, the packet service does not require you to use
it. But the application-level Internet really does rely on the validity of the
mapping.

>> To use Marcelo's phrasing, we do not "prove we own" the domain
>> names are IP addresses we use.

mb> You do prove that you own the IP address, the routing system does it.

The routing system validates the association between the target (destination)
IP address as an address and the IP address as an identifier.

It does not validate the initiator (source) address. Any such validation is
performed by a return packet, using the larger context of the endpoint
association.

mb> (BTW I read the address ownership expression fro the first time in Pekka's
mb> draft "An Address Ownership Problem in IPv6"
mb> (<draft-nikander-ipng-address-ownership-00.txt>))

Sounds interesting, but I am not finding that in the I-D depository.

d/

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Sep 2003 23:31:34 +0200 (CEST)

> identifier and also with the locator.

Yes.

> know, you need a mean to express his identity, and that is a permanent

Terminology issue alert. It is presumably sufficient to express a name
(and there can be a many to one mapping from name to identity.)

> provide differents types of identifiers, but one of these types should be a

Agreed.
But what does permanence mean?
I think we would all agree that having it be stable across changing ISP
connectivity, whether due to multihoming or renumbering, is a useful
characteristic.
Is it also useful to have it be independent of your fqdn so that if you forgot
to pay the registration fees or there is a domain name dispute, you would
still retain your IP level identifier?

> solution that works, so it is part of the multi-homing problem

Not so fast. If you want to understand the space of epehemeral identifiers
you need to dive a bit deeper.
In that space the identifier might not be needed before communication
is established, but can actually be exchanged as part of establishing
the communication between two hosts.
A concrete example would using FQDNs to find an (initial, possibly not all 
working) set of locators and then exchanging the identifiers of the
endpoints by the peers communicating.
(There are of course several issues in here, such as needing the know
the identifiers in order to get things like TCP initial state established,
but it is still useful to understand that emphemeral identifier corner of
the design space.)

> feature? Would you inlcude them in the MUST list of a loc/id split solution

I think it is part of the tradeoffs in this space.
Having them be independent of your ISP(s) is probably something many want,
so perhaps we must make that.
If it is realatively inexpensive (in terms of complexity, overhead, deployment
constraints, etc) to make it independent of some "registry infrastructure"
that would be a useful thing.

Another tradeoffs with high-level visibility are:
 - whether the ID can be used as the solve information to initiate
communication
   with the entity.
   (one can envision solutions where one can verify that a peer using a
   ID is in fact the same entity that used it a long time ago, without
   being able to use the identifier itself to find the location of the
   entity.)

  Erik

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 30 Sep 2003 11:57:27 +0300

Dave,

> I claim that the validation that needs to be performed, as a result 
> of using multiaddressing, is at the time of address _selection_. ...
> The only reasonable way to do that is for the initiator to have a
> basis for trusting the pool of available addresses. Hence, it is the
> process of building that pool that requires a serious validation

I pretty much agree with the statement above, with a small caveat,
explained below.

mb> (To overcome this issue, mip demands a periodical exchange of
mb> nonces so that the identity of the other end of the communication
mb> is verified periodically)

> Let's ask: What does the periodic exchange detect or fix? ...
> 
> Or is the concern that the IP address now being used for the target 
> is not valid?

More or less yes.  This is one example of what are called
"time shifting" attacks in the MIPv6 security terminology.

> This is certainly a problem that already exists with monoaddressing,
> but it is significantly exacerbated by multiaddressing, since
> multiaddressing introduces an automated mechanism for adding new IP
> addresses to the pool. However it is not the _use_ of the address
> that is the problem.

Well, it is not the _use_ of the address itself which is the
problem.  It is the expected dynamic nature of IPv6 addresses.
That is, if we expect that all IP addresses become more or less
ephemeral in the IPv6 world, then we must also expect addresses
to be passed over from one node to another.  Even subnet prefixes
will be passed from one organization to another.  This may cause
prolems with multi-addressing.

The problem is fairly subtle, though, and may not be very bad.
It becomes bad only if you can *anticipate* an address someone
else is going to use in the future, arrange yourself at that
address (so that you can pass the test of adding the address to
the pool at your peer), leave, and wait for your victim to
arrive.  Then, at that point, you can flood your victim by
claiming that you are no more available at your other addresses,
thereby forcing the peer to use the (now) victim's address.
You claim will be trusted since the address is already in the
pool.

> It is the event of adding a new target address to the initiator's 
> pool of addresses for the target. Regular use of the nonce in packets
> might detect a failure condition. However, strongly protecting the 
> mechanism for adding to the pool will accomplish the same thing, and 
> it will do it with lower packet overhead. And it will do it as 
> pre-hoc prevention, rather than post-hoc detection.

In my opinion, strongly protecting the adding mechanism is really
the most important point.  It may be also useful to include a
check whenever you start to use a locator after a long period of
inactivity, even if the locator is already in the pool.

Arranging an attack where you use a given address and stop using
it just before your victim arrives and starts to use it seems
to be very hard, and probably not worth worrying about.

> mb> (BTW I read the address ownership expression fro the first time 
> in Pekka's mb> draft "An Address Ownership Problem in IPv6" mb> 

It was two or three years back, long expired.  A backup copy can
be found on my web site,

http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 30 Sep 2003 12:19:18 +0300

Dave,

> Hmmm. Carried to the extreme the requirement seems to specify would
> probably require having every packet be encrypted -- so it could only
> be decoded by the correct recipient -- and acknowledged with a
> signature.

Yes.  But going such extreme is probably silly.  See my previous
message on the same topic.

> 
> In spite of the above language, you do not define rendezvous and
> referral. 

I tried in my previous message to ipv6 list, but apparently failed.
Especially, my definition for referral there and yours below
do not match:

> I have been assuming the latter means "moving an
> association from one endpoint to another". That is, "hand off" of one
> end of an association to a new endpoint.

We clearly need two different words for two different actions:

   1. Handing over an "identifier" from one end-point to another,
      with the intention of the receiving end-point being able to
      contact the "identified" end-point in the future.

   2. Handing over an end of an (active) association from one
      end-point to another.

I was using the term "referral" in the first sense, while you
seem to be using in the second sense.

> So, please clarify what you mean by both terms and how they relate to
> the distinction between identifying versus locating.

Maybe you want to reread my message to IPv6:
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html

I tried to give definitions there, but seem to have failed.

> This line of thinking appears to go quite a bit beyond the current
> world of IP mon-addressing.  And I believe it involves concerns not
> created by multiaddressing.

Well, certainly I go well beyound the current architecture.
I am trying to figure out what we need to do if we really separate
identifiers and locators, and cannot rely on the routing infrastructure
to provide any kind of security for the identifiers.  In other
words, the current practise where IP address are also identifiers
is good from a security point of view.  It just doesn't work well
with multi-addressing.

I tried to outline four possibilities:

   - create another kind of an infrastructure to "secure" identifiers
   - use "self-securing" identifiers, i.e., public keys
   - use a PKI
   - go only half way, somehow still relying on the routing
     infrastructure

(Note that I am putting "secure" and "self-secure" in quotes since
I am using them here in a purposefully vague way.  We still don't know
what the real security goals are, other than this "no worse than
mono-addressing IPv4" statement.)

It may well be that I go beyound multi-addressing.  In fact, I don't
so much care just about multi-addressing, but really understanding
the consequences of the id/loc split.

--Pekka Nikander

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 30 Sep 2003 13:03:31 +0200

Hi Pekka,
> to be very hard, and probably not worth worrying about.

Well, then why don't we just extend mip BCE maximum lifetime then?
If i understand correctly, this is exaclty the type of attack that the
maximum BCE lifetime bound prevents.

I mean, if we do extend the maximum BCE lifetime, we can have a very
important part of a multi-homing available easily which is the support of
multi-homing in nodes outside the multi-homed site.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 30 Sep 2003 12:53:29 +0200

Dave,

> you stayed with it.  Now you may not.

Well, i think the problem is that the application (perhaps not even the
transport layer) is not aware of the change.
I mean, suppose you establish a tcp connection with a host far away using
its IP address IPA. In the mono-addressing scheme, you know that this
address will remain the same.
In the multi-address, the  layer below tranpsort may change the address
being used to IPB but this is not visible to the transport layer and above,
i mean, the transport and above still think that the connection is
established with IPA. (this is the case where you use an IP address as
identifier, such as mip)
So now the ip address used in the communication has changed and the only way
to prove the address ownership has been lost, but for the other end of the
communication the IP address involved in the communication is still the same
(IPA)

> and validates that it -- the target -- is that IP address.  With

I guess the key point is who performs the validation...
In multi-addressimg the validation is performed by the new shim-wedge layer
that handles the multiple addresses, but the application is not aware of the
change.

Let's consider an example.
Suppose that i want to establish a communication with a server A. In order
to do that i have to know its address, IPA. HEre is where the validation is
done for this address IPA. I mean i have to know IPA somehow (this is not
part of the things that IP layer does for you). Once that i Know IPA and i
have validated it, i can establish the communication. Now, ip gives me some
guarantees that packets will be delivered to the server A as long as the
destiantion address included in packets is IPA.

If multi-addressing is enabled, and i try to do the same. Then i have to
discover one IP address of the server A, (IPA) and validate it in the same
way than before (i.e. IP layer doesn't do this for me). Now i establish a
communication with server A sending packets to IPA. Now, if multi-addressing
is enabled, alternative IP addresses can be exchanged by the shim layer and
they will be used to reach server A. This means that while my tcp connection
is still established with IPA (that i have validated with some mechanism),
packets can be actually addressed to other addresses that have been
validated by the shim layer (and the worst and also the best part is that
not even tcp is aware of the situation)

The other option is to let the application to be aware of all the addresses.
In this case, the validation of all addresses can be performed in the same
way (not done by the ip layer, done in some other way)
The problem here is that you have to modify all the apps to let them handle
multiple addresses.

> mechanism, not the process of using addresses from the pool.

I think i covered this above but let me synthetize.
With mono addressing all you need to know that a given server A has a given
IP address IPA
With multi-addressing you have two options AFAICS:
First, you idscover all the addresses available in the other end in the same
way that you discover IPA in the mono address sheme, for server A, you
discover somehow that it has IPA1, IPA2,...
This option is not really good enough because you have to know all the
possible addresses to be used a priori (which would be acceptable for
multi-homing but it is not good enough for mobility) and because it implies
that all apps have to be modified to support this. So the goal is to leave
the apps as they are and handle the multiple address issue transparently.

The second option is that you discover one address as in the mono-address
situation IPA, and then the shim layer discover address that are equivalent
to the initial IPA. This validation is different than th initial one and has
to be performed in a transparent manner.

> nonces so that
> multiaddressing

Pekka's has already answered this, i guess.

> it. But the application-level Internet really does rely on the

I agree with you.
My point is that current architecture provides the ability to establish
communication that are more secure than those that use the DNS (i.e. using
IP addresses direclty)
If we introduce a id to locators mapping like the DNS and its usage becomes
mandatory to establish a communication,, the result is that communications
are less secure, since you don't have the cappability of avoiding the
threats introduced by the DNS-like mapping system.

> performed by a return packet, using the larger context of the endpoint

Agree.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 30 Sep 2003 16:34:26 +0200

Hi Erik,

> (and there can be a many to one mapping from name to identity.)

Good point.
I guess that we can try to be a bit more precise about this:

As you mention, there are multiple times that i don't really need to know
the identifier of the end-point that i want to communicate to, but what i
want is the identifier of the service that i want to contact (is this what
you meant?)

So in this case, the fqdn act as a service identifier. So if i have a
permanent service identifier (i.e. a fqdn), it is enough to have ephemeral
end-points identifier, since when i want to establish a communication with a
given service i just look for the currently valid ephermeral endpoint
identifier.

The next question then is whether this is enough... I mean can we just live
with ephemeral endpoint identifiers and stable service identifiers?

> endpoints by the peers communicating.

Not so sure, i mean, you are using the fqdn to make the initial contact, so
the fqdn is an permanent identifier. You can consider that the fqdn is a
service identifier. Ok, then when contact the other end through the locators
that you have obtained through the DNS, you will exchange a ephemeral
identifier, but this ephemeral identifier is a *service* ephemeral
identifier, isn't it? i mean you know that a service is at given location
and then you exchange an identifier to be sure that you always talk to the
same entity, this would be a service identifier, i guess.

So the point is, you can use a fqdn as a service or endpoint stable
identifier and then exchange service or endpoint ephemeral identifiers, but
you always need the stable identifier to make initial contact, so you can
express who do you want to talk to.

>    being able to use the identifier itself to find the location of the

Been re-reading JNC's Endpoints and Endpoint's Names where there is a great
compilation of many relevant characteristics of the endpoint identifer,
where most of these are included somehow, and the point is that there are
many aspects to consider.

So my question is whether we should focus on providing a multi-homing
solution based on the loc/id split or we should design a loc/id split that
covers as many as possible of the apsects related with the overloaded model
of identifiers in current IP, such as the ones that you mention or the ones
covered in JNC's paper.
Clearly the second option seems the wise thing to do, but there are many
operational issues here, such the time requiered for this (during this time
we will not provide a multi-homing solution which seems to be a pressing
issue right now), the appropriate forum for this (not only because of the
formal issues related to this, but more because of the people that should be
involved and whose opinions are relevant for this, may not be here).
So perhaps the practical thing to do is to provide a multi-homing solution
now, focusing only on multi-homing problems.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Oct 2003 00:31:38 +0200 (CEST)

> want is the identifier of the service that i want to contact (is this what

Yep.

> with ephemeral endpoint identifiers and stable service identifiers?

From the perspective of handling at least a narrow interpretation of
multi6 I think this is enough.
But it doesn't make the identifiers first class objects in the architecture;
it would be impossible to use them as the sole handle for referrals and 
perhaps also for rendez-vous (in Keith's definition of that term; "call me back
when you are done")

I think this means that we can use it to make transport protocols
and simple applications protocols unaware of multihoming, but richer
application protocols would need something else. Whether that means passing
around a list of locators to represent a peer, or do use a fqdn to designate
a peer (which requires work to avoid confusing with fqdns which designate
a service), or something else I don't know.

> same entity, this would be a service identifier, i guess.

The FQDN could be viewed as an identifier for the service i.e.
consistent with current usage of fqdns.
You'd exchange the ephemeral identifier with a peer node thus you'd
presumably get an ID for that node (a stack name), and not an ID
for the service.
You would need to find out which of the locators refer to that identity
so that you don't try to redirect the traffic to go to a different node.
Perhaps that could also be exchanged as part of the handshake that exchanges
the emphemeral ids.

> of identifiers in current IP, such as the ones that you mention or the ones

If it was "free" I think the more general problem would be the right one.
But designing and deploying a system capable of looking up identifiers
(with desirable properties; they would be flat or near-flat ids I think)
is clearly something which will take time.
In practice I think we need to figure out something which can be
incrementally deployed providing incremental multihoming benefits along the
way. If we can do this and maintain the ability add the lookup system
along the way it the lookup system wouldn't be a gating factor for deployment
of a solution to the multi6 connection rehoming problem.

   Erik