Subject: What end-point identifiers are needed for?

From: Pekka Nikander <[email-masked]>
Date: Tue, 16 Sep 2003 08:39:51 +0300

[Cross-posting to hipsec since this analysis seems to
  be important for HIP, too.  CC:s appropriately, please.]

The recent discussion on the ML has led me to believe
that we have a fairly poor understanding on what we
are speaking about.  (Dave Crocker has also privately
pointed this out, thereby making my mind clearer.)
This is yet another strawman attempt to try to clarify
the  problem scope, or at least something.

After some thought, I think that we have at least
three main classes of needs for (loosely speaking)
end-point identifiers, and some subclasses:

   1) Identification

      1a) identification for the purpose of mobility and
          multi-homing

      1b) identification for the purpose of referral
          or rendezvous (related to 1a but slightly
          different)

      1c) identification for other, e.g. administrative,
          purposes

   2) Referral

   3) Rendezvous

      3a) initial rendezvous with no existing connection

      3b) subsequent rendezvous, e.g., after concurrent movement

There are probably others, but these are the ones that
my poor brains managed to (small pun) identify.

The *point* of this mail is that the different needs have
different requirements, and that it may be very difficult
or even impossible to design one class of identifiers that
would fulfil all of the primary needs plus the related
secondary needs, such as privacy and security.

Let me try to brefly analyze the above outlined needs
one by one, in reverse order.

3) Rendezvous
-------------

I haven't seen any good definition for rendezvous in the
meaning that we seem to be using it.  (If you have, please
post a reference).  So, here is an attempt:

   End-point rendezvous refers to the situation where
   one end-point makes a contact with an explicitly identified
   other end-point over the network.

To be able to perform rendezvous, the first end point seems
to need

   - a means to identify the second end-point (1a or 1b)
   - a means to reach the second end-point, i.e., locator

In the case of 3b), the end-points have been in contact
with each other and share explicit "fresh" state.  Hence,
they can identify each other just based on this state,
and they do not necessarily need any stable, long-living
end-point identifiers.  Due to mobility, they need a
service that gives the currently active locator for the
other end-point, i.e., the equivalent of mobile IP home
agent.

In the case of 3a), the end-points have not been in contact
with each other, and the only "state" that they share is
that the first end-point has an identifier that denotes
the second one.  The service giving locators does not seem
to be very fast or dynamic, as long as the given locator
will reach the given end-point.  That is, if we have the
equivalent of mobile ip home agent, the locator used for
3a) can be the equivalent of mobile ip home address.

2) Referral
-----------

Again, I haven't seen any good definitions (and again,
please post if you have).  Another attempt:

   Inter-end-point referral refers to a situation where one
   end-point hands over information about a second end-point
   to a third end-point, with the purpose of allowing the
   third end-point to make a rendezvous with the second end-point.

For referral to succeed, the transferred information must give
the receiving end-point

   - a means to identify the second end-point (1b)
   - a means to reach the second end-point

Note that in this case the "means to reach" does not need
to be a locator.  It can be a name that the rendezvous (3b)
service is able to convert to a locator.

1) Identification
-----------------

Now we get to the real business.  Just to refresh the mind,
here are again the suggested subclasses:

   1a) identification for mobility and multi-homing
   1b) identification for referral or rendezvous
   1c) identification for other, e.g. administrative, purposes

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.

[There is also the need of keeping the apparent identifier to
  TCP or UDP stable, but that is really a secondary need, created
  by the desire of backwards compatibility.]

For the purposes of 1a) it seems to be sufficient to create
an ephemeral identifier, only known to the participating end-points
(and a sufficiently limited class of potential attackers).
There is no need for long-lasting stable identifiers.

Identification at the mobility related rendezvous (3b) is
really a special case of the generic mobility related
identification, and therefore the argumentation above holds.

1b) For initial rendezvous and referral, we need something stable.
     That is, we need to have an identifier that allows us to
identify the peer end-point even if it does not share any state
(but the identifier/identity) with us.

Note that I have explicitly separated the function of locating
the end-point from the function of identifying the end-point.
For rendezvous and referral we naturally need both.  However,
they are distinct functions, and it is technically *possible*
to use different tokes for these purposes.  On the other hand,
if there is a need for two tokens, we can also define that the
end-point identifier (for referral or initial rendezvous)
consists of a *pair* of tokens, ones used for identification and
one used for finding the current address.

1c) The final class of needs for identification seems to have
     nothing to do with mobility, multi-homing or even referral
or even rendezvous.  There are other needs for identifying
end-points:
   - Human GUI needs: to allow humans to type in names that
     refer to end-points
   - Various administrative needs:
      - configuration management
      - inventory management
      - monitoring and intrusion detection
      - etc.
   - (running out of coffee....  can't think of others)

-------------------------------------------------------------

The next step is to analyse the security and privacy threats
associated with all of the above mentioned needs for identifiers.
However, that is a subject of another mail.

--Pekka Nikander

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 10:02:22 -0400

>       3b) subsequent rendezvous, e.g., after concurrent movement

this is similar to what I had come up with.

>    - a means to reach the second end-point, i.e., locator

agreed.  note that currently these tend to involve the same address, which
means that the distinction looks subtle.  but basically you do have to 
do both of these things.

> end-point identifiers.  

this would require apps to define their own unique identifiers, which is
harder than it might seem at first.   (they can't use an IP address since
these change.  they could use the MAC address of an interface but interfaces
can be unplugged, etc.)

> the second one.  

this is what I have been calling referral - the end point wishing to make the
connection needs to talk to a specific process but hasn't made contact with it
yet.

> The service giving locators does not seem
> will reach the given end-point.

this seems like a dubious assertion to me.

> That is, if we have the

maybe, but it's hard to know what you mean by "equivalent" here.

> 2) Referral
right.  it's just like what you were calling 3b except with the added
constraint that the identifiers need to have the same meaning and be
resolvable to locators from any point in the network.

> 1) Identification
> -----------------
> 
> Now we get to the real business. 

in your way of thinking :)

> Just to refresh the mind,

disagree.  the problem is that you don't always know how many participating
end points there will be. and an application - especially one that encompasses
large numbers of hosts - can run indefinitely, meaning that the identifiers
may need to last indefinitely.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Sep 2003 14:54:30 -0700 (PDT)

> There is no need for long-lasting stable identifiers.

Even if it is ephemeral you still need to be concerned about
two parties, both attempting to communicate with a particular node,
claiming to have the same identifier.

Thus a high probability of uniqueness is a requirement.

  Erik

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Sep 2003 22:51:46 -0700

Folks,

PN> [Cross-posting to hipsec since this analysis seems to
PN>   be important for HIP, too.  CC:s appropriately, please.]

I have to admit to being pretty confused about choosing the right venue for
the various discussion going on.

    Absent better guidance, I am pointing mobility/multihoming discussions to
    multi6.

I just sent that list the following announcement, which includes an I-D that
discusses choices including endpoint identifier.  Hence, it tries to go
through some of the exercise in Pekka's query.

- - - - -

I've just submitted some new mobility/multihoming I-Ds for distribution.
Meanwhile, they are available from my website, in text and MS Word formats.

The first breaks out the "discussion" section of the original MAST paper and
expands on it:

     Choices for Support of Multiaddressing

     Text:
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.txt>
     MSWord :
       <http://brandenburg.com/specifications/draft-crocker-mast-analysis-00.doc>

The second is the revised draft proposal:

     Multiple Address Service For Transport (MAST):
     An Extended Proposal

     Text:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.txt>
     MSWord:
        <http://brandenburg.com/specifications/draft-crocker-mast-proposal-01.doc>

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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 23 Sep 2003 19:14:34 +0200

Keith,

[Sorry for late reply.]

> resolvable to locators from any point in the network.

Thanks for this clarification.  It made my thinking more crystal.

> may need to last indefinitely.

Well, I think that you are slightly mixing things here.

While I agree with you than in most real life situations you
most probably would not be done with ephemeral identifiers,
the reason for that is that such situations involve other
needs but pure mobility or multi-homing (multi-addressing
in Dave Croker's terminology).  '

If your application encompasses more than two hosts, either
they talk pairwise (in which case my statement holds), or
they make referrals (in which case the reason for identification
is not pure mobility or multi-homing any more).

If your application encompasses only two hosts, but lasts
"indefinitely", then the "ephemeral" identifier can last
"indefinitely".  If picked from a large enough space, the
chance of collisions is still neglible enough.  (We have to
remember that "indefinitely" in our field appears to be
around 50 years, at most 200 I guess.)  Besides, if you
application runs that long, then you most probably also
need occasional rendezvous, again imposing other reasons
(and other requirements) for identification but pure
mobility and multi-homing.

--Pekka Nikander