Subject: [Hipsec] Re: What end-point identifiers are needed for?

From: [email-masked] (Keith Moore)
Date: Tue Sep 16 09:48:00 2003

>    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

this is similar to what I had come up with.

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

> 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

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.

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

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

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

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
> to be very fast or dynamic, as long as the given locator
> will reach the given end-point.

this seems like a dubious assertion to me.

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

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

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

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]> (Erik Nordmark)
Date: Tue Sep 16 23:09:00 2003

> 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]> (Dave Crocker)
Date: Wed Sep 17 01:27:01 2003

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: [email-masked] (Pekka Nikander)
Date: Wed Sep 24 02:53:00 2003

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