Subject: Persistent or opportunistic IDs

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 May 2004 17:07:00 +0200

Yesterday at the RIPE meeting Geoff talked about the difference between 
doing address agility using long-lived identifiers vs pragmatic, 
short-lived identifiers. This is indeed a useful way to classify multi6 
solutions. Pragmatic identifiers would generally be regular (locator) 
IP address. However, selecting such a pragmatic approach doesn't 
necessarily close the door on persistent identifiers, as it's possible 
to "hide" such a persistent identifier in the lower 64 bits of a PA 
IPv6 address. This is basically what I propose in my crypto-based host 
identifier draft.

Two questions:

- do we agree that going the pragmatic route first and adding 
persistent identifiers later is indeed possible?
- if this is the case, does this mean such is also the preferable way 
forward?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 May 2004 17:28:28 +0200

Iljitsch van Beijnum wrote:
> solutions. Pragmatic identifiers would generally be regular (locator) IP 
> address. However, selecting such a pragmatic approach doesn't 
> to "hide" such a persistent identifier in the lower 64 bits of a PA IPv6 
> address. This is basically what I propose in my crypto-based host 
> identifier draft.
> 
> Two questions:
> 
> - do we agree that going the pragmatic route first and adding persistent 
> identifiers later is indeed possible?

We need a proof-of-concept proposal before we can agree or disagree.
I'm not sure your draft really provides that. NOID for example is a
proof of concept for the pure pragmatic scenario.

> - if this is the case, does this mean such is also the preferable way 

Too soon for that question. We need an agreed architectural analysis...

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 May 2004 17:45:30 +0200

> proof of concept for the pure pragmatic scenario.

What would need to be part of such a proof of concept draft?

As the drafts I've written so far aren't intended to become RFCs 
anyway, I try to be as concise as possible, maybe overdoing it 
slightly...

But are there any "oldfashioned" id/loc approaches still on the table 
anyway?

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 6 May 2004 18:03:26 +0200

Hi Iljitsch,

> De: [email-masked] [mailto:[email-masked]]En
> nombre de Iljitsch van Beijnum
>
> IP address.

I am not sure i understand this clasification.
Why do you consider that pragmatic identifiers - locators are short lived
when they are used as identifiers? I mean, i consider that the HoA is a
stable identifier of the mobile node, but it is short lived as a locator.

I think i can see the difference between a stable identifier and an
ephemeral identifier, such as the ones used in WIMP, and i think that this
is usefull distinction.

Regards, marcelo

> However, selecting such a pragmatic approach doesn't

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 May 2004 14:48:56 -0700 (PDT)

> persistent identifiers later is indeed possible?

If we are assuming that the persistent identifiers provide a superset
of the functionality/semantics prociuded by the short-lived identifiers,
then taking the step should be easy; the question is what benefit
one would derive, if any, (and at what cost) from taking the step to
the persistent identifiers.

As one example, I think that multihoming with short-lived identifiers
implies a change to the applications that do referrals and/or callbacks
(depending on the actual multi6 approach they might need to change to
pass FQDNs, locator lists, or something else where they today
might pass a single IP address). Thus they need some change.

Will moving from short-lived identifiers to persistent identifiers
imply another change to that class of applications?
[This is just an example; I don't expect anybody to answer this particular
question at this point in time.]

Thus I do think we'd need to understand more details about such a transition
(or probably, coexistence) between different classes of identifiers
before being able to guage the cost/benefit tradeoffs.

  Erik

---

From: Geoff Huston <[email-masked]>
Date: Fri, 07 May 2004 18:05:47 +1000

>ephemeral identifier, such as the ones used in WIMP, and i think that this

My comments in the RIPE meeting were drawn from the text I used
in Section 4.7 of draft-huston-multi6-architectures-00.txt, In particular
the last paragraph of that section.

I was struck by the difference between 'absolute' uniqueness (and the 
implication
that when you have such absolute uniqueness you also can support persistence
and reference and resolution) and relative uniqueness (where the identity
uniqueness is constrained temporally to the lifetime of a session (olr group
of sessions) and constrained in terms of a spatial realm, where the possibility
of identity collision  is admitted in a broader context). This 
classification also
has some implications regarding the cost of uniqueness and the relative level
of overhead in managing a long-lived unique token space and opportunistic 
(probably
self-generated) identity token values.

I'm not sure I'm truly in a position to offer comment from my perspective 
as to which is
'better' than the other - there are aspects of value in persistence, 
resolveability and
referential capability in structured unique identity spaces, and there are 
aspects of
value in terms of overhead and efficiency in terms of protocol behaviour
and dependencies as well as reduced dependence on infrastructure activities 
that
paint a value picture for opportunistic identity spaces.

My suspicion that we will need to come to some closure at some point as to
where the ideal point might lie in the context of multi6, and in the 
context of
an evolving IPv6 architecture, but its way to early to call the
question -- in my view. At this stage its still the careful work of 
attempting to
assemble useful characteristics here, so the essential question I have, as 
the draft
author, is where the draft needs further (or less) consideration and text.

thanks,

    Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 May 2004 08:54:47 +0200

Iljitsch van Beijnum wrote:
> As the drafts I've written so far aren't intended to become RFCs anyway, 
> I try to be as concise as possible, maybe overdoing it slightly...

I take NOID as an example because when I read it, I felt "ah, yes,
there are some details to fill in, but the basic operating principles
are clear."  An author can't assume that what is obvious to her or him
is obvious to everyone else.

> But are there any "oldfashioned" id/loc approaches still on the table 

I'm not sure what you mean by "old fashioned" but (chair hat defintely on)
everything is on the table until the architectural analysis has reached
consensus.

     Brian

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 7 May 2004 17:56:32 +0200

Hi Geoff,

thanks for the clarification.
some comments below...

> paint a value picture for opportunistic identity spaces.

Ok. In previous discussions i think we use to use the terms ephemeral
identifiers versus stable identifiers to make that distinction.
Most of the proposals use some sort of stable identifiers that can be placed
in the DNS or some other directory.
I guess that one of the difficulties when using ephemeral identifiers is
that since they are ephemeral by nature, the initiating host does not know
the identifier of the other end a priori, so how do the apps use to initiate
the communication?
I mean, suppose that an app wants to communicate with another node, so it
decides to start a communication. If stable identifiers are available, the
app will open a socket (or equivalent) with the stable identifier and
somewhere lower in the stack a conversion from identifier to locator is
done.
However, if ephemeral identifiers are used, the initiating node does not
know which is the identifier to be used until the other node is contacted.
This means, that for instance, when the app asks the resolver for a FQDN,
the resolver would need to contact the other end, negotiate an ephemeral
identifier and the present it to the application, so it can start the
communication. This is indeed more complex than using stable identifiers.
However, the cool thing about ephemeral identifiers IMHO, is that you don't
have to protect them so much as you do with stable identifiers. I mean, if a
ephemeral identifier is stolen, it will only affect a limited group of
communications of that host. OTOH if a stable identifier is stolen, the
complete identity of the host is stolen. So a solution with ephemeral
identifiers probably will require less security measures than one with
stable identifiers, perhaps something like return routability would be
enough for ephemeral ids?
In any case, i am not aware of any proposal that explain in detail how
ephemeral identifiers could be used, so I guess that Brian comments apply
also here, we would need a proof of concept for this too.

An interesting middle ground is provided by WIMP, because if i understand
correctly, they use a stable identifier of the target host (the hash of the
FQDN) but they use an ephemeral identifier for the initiating host. In this
case the endpoint has multiple ephemeral identifiers and a well known stable
identifier for incoming communications.

> author, is where the draft needs further (or less) consideration and text.

I guess that this depends on how much do you want to include about security
considerations in this draft. I mean, there is no mention to crypto based
identifiers in the draft, which is an important identifier name space. But,
if you include this you probably will have to mention something about
security, i guess.
The same goes for security implications of using ephemeral identifiers, as
IMHO one of the benefits of using ephemeral ids is about security, as
described above.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 7 May 2004 18:04:26 +0200

> before being able to guage the cost/benefit tradeoffs.

Yes, and additionally, i guess we have to understand why, if the stable
identifiers are the long term goal, are we adopting the transition solution
in the first place.
I mean, any solution will imply the modification of all the hosts, so why is
that an intermediate solution is adopted instead of the definitive one?
(this was a very good point mentioned by Iljitsch a while ago)
So, perhaps the case for an intermediate solution exists but i guess it
still not clear yet.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 May 2004 19:07:40 +0200

> of the functionality/semantics prociuded by the short-lived 

No, that's not the case. Unfortunately we all seem to mean something 
slightly different when talking about these two types of identifiers. 
The difference I'm interested in is the one between a NOID-like 
approach where we have FQDNs and locators, but no new identifier space, 
vs the FQDN -> long lived ID -> locators approach. We had solutions in 
this area on the table a little under a year ago, but this type of 
approach isn't so much in vogue any more now. (This is what I was 
getting at with "old fashioned id/loc approaches".)

Anyway, to get to the point: in NOID-type approaches it's possible to 
be backward compatible with existing transport protocols. This isn't 
really possible with approaches that introduce a new ID namespace. So 
the latter isn't a proper superset of the former.

> the persistent identifiers.

Three things:

1. It's possible to set up new sessions when some locators are 
unreachable without cooperation from applications.
2. References work.
3. If the identifiers are properly secured (secure mapping service such 
as DNSSEC or the identifiers are crypto-based) there are more and 
better ways to secure the multihoming solution.

> might pass a single IP address). Thus they need some change.

Yes.

> question at this point in time.]

If we can make these identifiers fit inside locators (= they must be 62 
bits or shorter) I don't think we need to change anything that's 
visible to applications. Obviously the multi6 solution must be extended 
to support the identifiers, there will probably have to be a mapping 
service of some kind and we need changes to address configuration so 
hosts can configure themselves with an appropriate identifier.

> before being able to guage the cost/benefit tradeoffs.

Of course. Let's start with a question that's probably a bit easier to 
answer: is a NOID-like solution that's mostly about keeping existing 
sessions running when there is an outage sufficient?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 May 2004 19:22:03 +0200

> that an intermediate solution is adopted instead of the definitive one?

It makes little sense to implement a solution and then replace it by 
another that's equal or better in every way. However, it may not be. 
For instance, the fist solution may provide better backward 
compatibility than the second one. Also, the second one may be 
"heavier" because it has better security. In situations where a high 
level of security isn't imporant, it could be preferable to use the 
simpler solution.

With two solutions there is less need to compromise. However, I'm not 
advocating building two completely independent solutions, what I'm 
thinking is more along the lines of having two modes of operation: the 
mandatory to implement mode is simple and light weight, but may not 
solve all aspects of the multihoming problem. The more advanced mode 
would be optional, and solve all the remaining problems, but probably 
at some complexity, overhead and compatibility expense.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 7 May 2004 20:14:08 +0200

> -----Mensaje original-----
> Enviado el: viernes, 07 de mayo de 2004 19:08
> Para: Erik Nordmark
> CC: Multi6 List
> Asunto: Re: Persistent or opportunistic IDs
>
>

agree.
I think we need to include a terminology section or at least to include a
explicit definition when a new concept is used in the architectural draft.

> getting at with "old fashioned id/loc approaches".)

I don't have the same feeling about this point. IMHO there are good
proposals on the table that follow this approach, like SIM or HIP. (Thes is
the kind of approaches that you are considering by old fashioned id/loc
right?

> really possible with approaches that introduce a new ID namespace.

Why?
I think you can be backward compatible with HIP or SIM, since the new id is
128 bit long. Am i missing something?

> So

I guess you can do that if you are using something like noid, since you
don't have to use the AID as locator for the first packet (if you know that
the other end supports noid, which is the same for the persistent identifier
case, i think)

> 2. References work.

Well, it would work if have a way to translate from the new id to the
locators, which is not so clear now. Also, if tou are using noid,
refferences may work if the locator that you are using is still working
properly.

> better ways to secure the multihoming solution.

Agree. IMHO this would be the main benefit of a new id namespace.

> sessions running when there is an outage sufficient?

IMHO, something like NOID probably can provide most of the stuff required
for multihoming support. However, since the adoption of a multihoming
solution will impose an important effort becuase it implies the modification
of all the hosts, then it makes sense to adopt a solution that provide most
benefits, even in other areas.
I mean, introducing a new id namespace, for instance a crypto based
namespace, wouldn't be also help to provide a better support in other areas,
like mobility, enhanced security, etc?
I guess this is one of the key outputs of the architectural analysis, a new
namespace or not?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 May 2004 10:12:43 +0200

...
> sessions running when there is an outage sufficient?

I don't see that restriction in NOID. It certainly works for directing
new sessions to a working path (assuming the necessary module for
selecting a working path is present, but every solution needs that).
And if that module is present and handles load balancing, then NOID
also handles load-balancing.

Which of the RFC 3582 goals does NOID not support?

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 May 2004 18:37:49 -0700 (PDT)

> identifier for incoming communications.

It is probably possible to combine this with other ideas such a NOID
(i.e. the server having a NOID-type identifier);
a question is whether we want clients in multihomed sites
where the client either doesn't have a DNS entry or it can't control
its DNS entry, to benefit from the multihoming of the client's site.

Overall there seem to be some "cost" associated with both having
a non-emphemeral identifier and security. In the case of NOID
this "cost" is the need to control your DNS entries.

   Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 11 May 2004 14:50:11 +0200

> its DNS entry, to benefit from the multihoming of the client's site.

Interesting approach indeed.
This would also save us the need to perform the reverse+forward DNS lookup
by the taget nodes, which would reduce the latency imposed by noid, since ,
the client (initiating host) will discover the multiple addresses of the
server using DNS as in noid, but the server will discover the multiple
addresses of the client using WIMP

> a non-emphemeral identifier and security.

Yes, the cost is aosociated with the fact that if you have a non ephemeral
id you need to defend it, i guess

> In the case of NOID

I guess is more than that, it implies the additional round trips to get the
information from the central data base (DNS).

An interesting point of the WIMP noid combination that you suggest is that
you provide just what each end point needs i.e. if it is working as a
server, it gets a mechanisms to be reached and discovered, the RR asociated
with noid. If it is client, it gets an ephemeral identifier, which cannot be
used to initiate contact. In the case pf p2p, i guess that it will be
required to fall back to full noid.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 May 2004 10:57:19 -0700 (PDT)

> addresses of the client using WIMP

And the downside being that the server application will not be able 
do remember the client ID in order to do a "callback" (connect to the
client) a day later, because the ID->locator mapping wouldn't exist
in general - it would only exist when there is active communication
using the ephemeral ID.

Further understanding the pros and cons of such IDs is worth-while.

> id you need to defend it, i guess

Yep. If you use ephemeral IDs, as long as the peer returns a "that ID is
already used by somebody other than you", the client
can pick a new ephemeral and try again.

> information from the central data base (DNS).

Agreed.

> required to fall back to full noid.

Yes. In effect the application need to know and express to the "stack"
whether there is a need to do "callbacks" on referrals, since this
affects which source identifier to use for the communication.
Would such a scheme be acceptable for the applications?

   Erik

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 12 May 2004 11:25:59 +0200

> Would such a scheme be acceptable for the applications?

I wouldn't dare to answer that question considering my limited knowledge on
apps, but, perhaps it would be possible to distinguish the ephemeral ids
from the stable ids (IP addresses in this case) using a ephemeral/stable
(e/s) bit in the id itself.
So, when the app that will perfom a call back discovers its own identifiers,
the noid+wimp layer will show multiple addresses, some stable ids  and some
ephemeral ids. The app can, because of the (e/s) bit on the ids, identify
the ephemeral identifiers, so it can avoid sending them to the other end as
a call back information.
Perhaps, something similar can be done with refferals. I mean, the
application first discovers the ids available in its own endpoint, and then
selects one that fits its needs, (stable or ephemeral), and then it performs
a bind to the selected id.

But perhaps this is too complex and i don't know if it is worthy...

Regards, marcelo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 14 May 2004 07:49:25 -0500

I like the idea here, but this does seem like functionality that
shouldn't be coded application-by-application. It's easier to get
right than congestion avoidance, but it's duplicating a lot of
functionality in every application (that cares about identifier
lifetimes).

Spencer

From: "marcelo bagnulo" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Geoff Huston" <[email-masked]>; "Iljitsch van Beijnum"
<[email-masked]>; "Multi6 List" <[email-masked]>
Sent: Wednesday, May 12, 2004 4:25 AM
Subject: RE: Persistent or opportunistic IDs

---

From: "marcelo bagnulo" <[email-masked]>
Date: Fri, 14 May 2004 15:44:05 +0200

Hi Spencer,

> nombre de Spencer Dawkins
>

As far as i understand, the application would only need to choose the proper
id that suits its needs. That is, if the application is just a client, it
will use a ephemeral id (i.e. the id with the bit xx set), if the
application will perfom refferals or callbacks, it will choose another id,
on with the ephemeral bit off.
As i see it only the application knows whether it will need to do refferals,
call back or pure client, so only the app can make that choice.
What tasks do you think that can be done in common for all the apps?

(The other opcion is just not to use ephemeral ids...)

Regards, marcelo