Subject: Re: where the indirection layer belongs

From: Robert Honore <[email-masked]>
Date: Fri, 29 Aug 2003 14:39:53 -0400

Dear Folks,

Regarding this discussion about an indirection layer, I am thinking we 
really should propose the formation of some forum for discussion of 
these issues.  It does not seem to fit cleanly into the IPv6 working 
group, and out here in no-man's-land, I don't think it is getting the 
kind of attention it needs.

I had already made my position clear.  We need something.  Call it an 
indirection layer or a stabilisation layer or whatever you want, but we 
need a forum where we can specify the problem we are trying to solve and 
to consider the possible solutions for it.  Does anybody agree?

Yours sincerely,
Robert Honore.

---

From: Robert Honore <[email-masked]>
Date: Fri, 29 Aug 2003 16:14:12 -0400

Dear Folks,

I have been trying to understand the problem we are trying to solve in 
this thread and trying to see if I could produce for myself something 
resembling a specific description of that problem.

I might have mentioned in passing earlier today that perhaps we are 
trying to treat as a single problem, separate problems that might be 
better treated as separate.  I am becoming more convinced of this as we 
go on.  As such, I can distinguish the following issues as aspects of 
the problem given all that was mentioned in this thread, the "solving 
the real problem" thread and the one on the IPv6 mail list about 
deprecating Site Local addresses and the usage of IPv6 Link Local 
addresses.  They are as far as I can tell the following.

*	Stable (or reliable) end-point identifiers
*	Resiliency of application (protocol) in the face of sudden IP address 
changes
*	Self-organised networks

With respect to stable end-point identifiers, we must in my opinion, 
still specify what we are calling an end-point and settle once and for 
all the question of whether an IP address is a suitable candidate for 
such an identifier.

With respect to the resiliency of applications in the face of [sudden] 
IP address changes, we need to determine if, as Keith Moore argues it 
cannot be solved in a single layer, or if it can as Tony Hain argues, as 
well as where best to situate such a layer.

The one about the self-organised networks materialises out of the 
discussion going on in the IPv6 mail list about the deprecation of Site 
Local IP addresses and the proper usage of IPv6 Link Local addresses. 
Many of the contributors to those threads were basically arguing that we 
should retain either or both of Site Local and Link Local addresses 
because of intermittently connected sites, nodes or subnetworks, as well 
as being to maintain communications between two locally adjacent when 
the local subnetwork either connects to -  or disconnects from - a 
larger network.

My question following from all that, are two.  Is it worth it to attempt 
a solution to any of the aforementioned problems?  If so, which one 
should we tackle first?

Yours sincerely,
Robert Honore.

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 02 Sep 2003 21:26:54 +0300

Robert,

Robert Honore wrote:
> ...  As such, I can distinguish the following issues as aspects of 
> *    Resiliency of application (protocol) in the face of sudden IP 
>      address changes

I like your analysis very much.  Thank you for writing it up.

However, I also see a kind of causality here:  it looks to me
that stable end-point identifiers are mainly needed to make
applications survive IP address changes.  Dave Crocker's MAST
is a good example how you can do that without having stable
end-point identifiers.

On the other hand, security looks to me as a good reason for
having stable end-point identifiers.  If you can securely
recognize an end-point (with emphasis on the *re-* part of
re-cognize), you can develop trust.  Trust, in turn, is very
handy for lowering transaction costs.

> all the question of whether an IP address is a suitable candidate for 

Even facing the danger of opening yet another rat hole, in my
opinion we should not have a very strict definition for end-point.
That is, IMHO end-point should and could be a fuzzy concept,
somewhat like the concept of a site is today.

 From my point of view, an end-point may be a process, a group of
processes, a host, or even a server cluster offering services as
a unit.  To me, it looks like fate sharing and common semantics
are the key points here.  An end-point should either work or fail,
it should not be usual for half of an end-point fail while the
other half is continuing.  An end-point should also be considered
at the application level as a single unit.

> a solution to any of the aforementioned problems?  If so, which one 

In my opinion, we clearly need solutions to all of these problems.
Furthermore, it looks like introducing stable end-point identifiers
to the stack almost automatically protect applications from
the changes of IP addresses.  I also tend to believe that stable
end-point identifiers may also help to build self-organized
networks.  However, IMHO the problem of self-organized networks
is more researchy in nature than the other two.

Now, even though I believe that we should solve the problems (and
apparently believe that there are sensible solutions), achieving
consensus on solutions that require architectural change may take
too long.  Hence, I also believe that we need some kind of a road
map, with some "temporary" or intermediate solutions along the way
to a more long-standing set of solutions.

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Tue, 2 Sep 2003 12:09:32 -0700

Pekka,

PN> that stable end-point identifiers are mainly needed to make
PN> applications survive IP address changes.  Dave Crocker's MAST
PN> is a good example how you can do that without having stable
PN> end-point identifiers.

In general I suggest we find some specific scenarios that require a new
construct for end-point identifiers. Most discussions treat the
abstraction without being clear about the details of use. With concrete
scenarios, it is possible to consider alternatives... or agree that none
is viable.

PN> On the other hand, security looks to me as a good reason for
PN> having stable end-point identifiers.

and rendezvous.

any reference to an object that requires use outside of an existing
context.

PN> Even facing the danger of opening yet another rat hole, in my
PN> opinion we should not have a very strict definition for end-point.
...
PN>  From my point of view, an end-point may be a process, a group of
PN> processes, a host, or even a server cluster offering services as

Just for fun, let's start by using the term "domain name" and try to
understand why it will not suffice.

domain names have been successfully used for all of the examples you
give.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 03 Sep 2003 09:08:50 +0300

Dave,

Dave Crocker wrote:
DC> In general I suggest we find some specific scenarios that require a new
DC> construct for end-point identifiers. ...

Concrete scenarios are very good indeed.

DC> and rendezvous.

DC> any reference to an object that requires use outside of an existing
DC> context.

Well, I consider an *identifier* as something that is more or
less intrisically bound to an identity and a *name* as something
that merely indicates an entity, i.e., involves indirection.
In other words, an identifier implies sameness and stability of
the identified entity, while a name does not have those connotations
to the same extent.

 From this point of view, IP addresses are identifiers.  However, they
are not end-point identifiers but identifiers for topological
locations within the routed network.

Now, you may be able to do rendezvous with just names, e.g.,
with domain names.  And for referencing external objects, it
is often much better to use names than identifiers.  Furthermore,
I find it hard to imagine situations where you want to reference
objects that are really outside of any context; IMHO there is
always some context, and names are always bound to such a context.

PN> ...

DC> Just for fun, let's start by using the term "domain name" and try to
DC> understand why it will not suffice.
DC>
DC> domain names have been successfully used for all of the examples you
DC> give.

In my opinion, domain names are probably good for coarse grain
rendezvous and expecially object reference (e.g. URLs).  They have
their problems in disconnected networks, but LLMNR / mDNS seems
to help there.  On the other hand, domain names are not very good
for security.  You need some external infrastructure, and unfortunately
our strawman economic analysis shows that secure DNS may be
economicly infeasibile.  The cost of security is a crusial issue here.
One of the success factors of SSH has been the low deployment cost.

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Sep 2003 08:33:30 -0700

Pekka,

(new subject, to define what I think is a new thread.)

PN> Well, I consider an *identifier* as something that is more or
PN> less intrisically bound to an identity and a *name* as something
PN> that merely indicates an entity,

I had not run into this distinction before.  Now that you raise the
point, I guess I have been thinking of identifier as an intentionally
fuzzy, general term, with name being a more specific reference.

Separate from discussing the merits and details of the specific
distinction you draw, I think your note highlights the need to make sure
we have some common terminology.

I do not understand "intrinsically bound", but it sounds interesting.

I am used to terminology use that derives from Shoch.  A name says what
a thing is, but nothing about where or how to get to it. It can be a
random bit string that unique identifies the entity. Any non-randomness
to the string will be relevant to administration of the string
assignment, but will not provide any information about the location of
the entity or how to reach it.  Two entities that are topological
neighbors are free to have unrelated names.

Addresses contain information about location -- typically topological
location. (The possibility of geographic location gets bandies about,
sometimes.) Addresses are also globally unique.

Routes give directions about how to reach the entity. Routes are
relative to the starting point.

PN> In other words, an identifier implies sameness and stability of
PN> the identified entity, while a name does not have those connotations
PN> to the same extent.

I guess I need some examples to understand this.

PN>  From this point of view, IP addresses are identifiers.

IP addresses have bits that are structured, semantic indicators of
topological location. There is serious semantics in an IP address, not
just guaranteed uniqueness.

That said, an address at one layer of processing is usually a name to
the next layer down.  For example an email "address" divides into two
names, one for the mailbox and one for the containing host.

PN> However, they
PN> are not end-point identifiers but identifiers for topological
PN> locations within the routed network.

In trying to think about mobility, I have been finding this point
extremely helpful. IP addresses define a point of attachment -- a
network interface -- rather than a host interface, as we are used to
saying. As the host interface moves, relative to network attachments, it
needs new IP addresses.

Hence a mobility mechanism needs to support end-to-end exchanges that
may have changing IP addresses over the life of the association.

PN> Now, you may be able to do rendezvous with just names, e.g., with
PN> domain names. And for referencing external objects, it is often much
PN> better to use names than identifiers.

I probably need to see some examples, here, to understand your point.

PN> Furthermore, I find it hard to
PN> imagine situations where you want to reference objects that are
PN> really outside of any context; IMHO there is always some context,
PN> and names are always bound to such a context.

darn.  you caught me in a fuzzy specification.

What I meant by 'context' was an existing relationship between the two
entities.  When I first contact a server, there is no context.
Afterwards there might be.  How do I find the server that first time?
Is there -- or can there be -- any difference in how I find it later?

The simple example of my finding a server is the difference between
using its domain name versus using its IP address (in the TCP control
block or, at least, the client DNS cache.

It's worth noting that client-side mobility is a very different problem
from peer-to-peer mobility.  Hence, something like MAST is entirely
adequate when it is only the client that is moving around.  The client
can re-find the server the same way it originally did.  With P2P, that
does not work, unless each moving host updates its entry in the
mechanism used to find it.  So, we might consider using dynamic DNS for
this, though I suspect it's not the right solution.

If the mobility is rapid and frequent, the extra traffic and delay of
DNS queries is likely not to be the right answer.

However note that the Internet infrastructure has no problem sending
consecutive packets to different places, as long as they have different
IP addresses.  Hence, the infrastructure can handle mobility just fine
(as long as we ignore the question of forwarded packets that arrive
after the recipient has moved.)

PN> In my opinion, domain names are probably good for coarse grain
PN> rendezvous and expecially object reference (e.g. URLs).  They have
PN> their problems in disconnected networks, but LLMNR / mDNS seems
PN> to help there.

I think the question for disconnected networks is what would work
better, and why.  There might be a way to have domain names satisfy
them, just so we do not have to deal with multiple name spaces.

PN>   On the other hand, domain names are not very good
PN> for security.

I've been trained to prefer separating security from naming.
Overloading the two gets confusing and often doesn't work very well.

In any event, please clarify what security concerns you have.

PN> You need some external infrastructure, and unfortunately
PN> our strawman economic analysis shows that secure DNS may be
PN> economicly infeasibile.

huh?

d/

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 03 Sep 2003 22:01:19 +0300

Dave,

DC> I had not run into this distinction before.  Now that you raise the
DC> point, I guess I have been thinking of identifier as an intentionally
DC> fuzzy, general term, with name being a more specific reference.

Merriam-Webster on-line defines as follows:

identifier:    one that identifies

identify (1b): to conceive as united
identify (2a): to establish the identity

identity (1b): sameness in all that constitutes the
                objective reality of a thing

    Etymology: probably from Latin identidem repeatedly,
    contraction of idem et idem, literally, same and same

My perhaps flawed understanding is that at least some
epistemological texts use the term "identity" to denote
the stable and distinguishable existence of entities.
Respectively, identify is used to denote the process of
establishing the previously learned and recorded identity
of an entity, and identifier is used for such names
that can be used to unambigously denote the identity of
entities that can be identified.

[My apologies if the text above is hard to parse,
but it starts to be late here, and English *is*
a foreign language to me.]

DC> I do not understand "intrinsically bound", but it sounds interesting.

Well, in my thinking a specific identifier is only able
to denote a specific entity.  That is, the relationship
between an identifier and the corresponding identity should
be a function, i.e., there must not be any identifiers
that denote more than one entities.  Typically the
relationship is (or should be) bijective.

DC> I am used to terminology use that derives from Shoch....

I have no difficulty with your terminology, perhaps other
than that I sometimes use the term name in a perhaps more
generic sense.  Furthermore, I think that a name always
requires some name space where the name is defined.  Most of
the existing name spaces are local, or bound to a restricted
context, while some are global, or usable in some fairly
generic and well understood context.

When using the more generic sense of the term, a name can
be considered to be *bound* to an entity.  Furthermore, usually
names can be re-bound.  Hence, only the triple <context,
name, bindings> identifies the entity.  (Alternatively, the
bindings can be considered to be a part of the context.)
Hence, a single name can denote different entities depending
on the context (and bindings).

The same applies to identifiers, of course, since I consider
the category of identifier sets to be a subcategory of the
category of name sets.  There is one exception, though.
It should not be possible to re-bind identifiers.  That is,
if an identifier has been created to denote a specific entity,
the same identifier should not be used to denote any other
entity at any other point of time.

DC> I guess I need some examples to understand this.

Well, as I wrote above, I think that a name can be re-bound
while an identifier should not be re-bindable.  Consequently,
using an identifier implies that the referred entity remains
the same (as long as the identifier is valid) while a name does
not necessarily have this property.  On the other hand, we have
to remember that sameness (i.e. identity) is a semantic property,
and depends on the (overall, epistemological) context.

PN>  However, [IP addresses]
PN>  are not end-point identifiers but identifiers for topological
PN>  locations within the routed network.

DC> In trying to think about mobility, I have been finding this point
DC> extremely helpful. IP addresses define a point of attachment -- a
DC> network interface -- rather than a host interface, as we are used to
DC> saying. As the host interface moves, relative to network attachments, it
DC> needs new IP addresses.

Very true.  We also have to remember the reason for this, that is,
the scalability limitations of the current routing technology.  In a
micro-mobility solution, it may make sense to use IP addresses more
like topology-unrelated names, and record a route for each address
separately.  For example, consider Cellular IP.

DC> Hence a mobility mechanism needs to support end-to-end exchanges that
DC> may have changing IP addresses over the life of the association.

I concur.  Furthermore, not only (macro)mobility mechanisms but
also multi-address multi-homing mechanisms.

PN>  Now, you may be able to do rendezvous with just names, e.g., with
PN>  domain names. And for referencing external objects, it is often much
PN>  better to use names than identifiers.
DC>
DC> I probably need to see some examples, here, to understand your point.

Rendezvous is needed for two purposes:
- to allow initial connections
- to resolve the loss of working addresses caused by
   simultaneous movement

Making an initial connection does not require identifiability
(in the sense of sameness), and indeed does not imply it unless
the parties can use identity authentication.  Resolving the
new location of a party after loss of working addresses can be
based on a mere name of the party; the name does not need to be
an identifier.  Upon reconnection, the parties can authenticate
the identity of each other even without stable identifiers, as you
have even shown yourself.

PN> [referencing objects outside of any context]

DC> What I meant by 'context' was an existing relationship between the two
DC> entities.  When I first contact a server, there is no context.
DC> Afterwards there might be.  How do I find the server that first time?
DC> Is there -- or can there be -- any difference in how I find it later?
DC>
DC> The simple example of my finding a server is the difference between
DC> using its domain name versus using its IP address (in the TCP control
DC> block or, at least, the client DNS cache.

Well, when you learn the domain name of the server, you already enter
a relation with the server.  This relation may be a weak one, but IMHO
it creates a (communication) context, as you define it.  Learning the
IP address of the server then creates another, related context.
(I would call your definition for context as a communication context,
while my definition above could be called a naming context.)

 From the client point of view, there is no intrinsic difference
between these relationships.   For the client, both the domain name
and the IP address act as names, referring to the server in their
respective (naming) contexts.

The difference lies in the stability of the names.  In a typical
case, the domain name may be more stable, as it better identifies
the server at the level of application semantics.

DC> It's worth noting that client-side mobility is a very different problem
DC> from peer-to-peer mobility.  Hence, something like MAST is entirely
DC> adequate when it is only the client that is moving around.  The client
DC> can re-find the server the same way it originally did.  With P2P, that
DC> does not work, unless each moving host updates its entry in the
DC> mechanism used to find it.  So, we might consider using dynamic DNS for
DC> this, though I suspect it's not the right solution.

As you write, the difference between client-side mobilty and P2P
mobility lies in rendezvous.  On the other hand, we also have to
remember that more and more servers are becoming mobile, in some way
or another (re-hosting, network re-numbering, etc).  Hence, I would
not consider these two types of mobility that different.

IMHO, more important than client-side vs. p2p is time granularity.
Mobility that involves rapidly changing IP addresses is different
from one where the IP addresses only occasionally change.  The rate
of simultaneous movements will be different, as well as the ability
of possibly using proxy packet forwarders at the old addresses.

In both cases the parties need to have some kind of a name-to-address
resolving mechanism for rendezvous.  Whether the name is a domain name
or some different name depends mostly on whether DynDNS is fast enough
compared to the rate of mobility.

DC> If the mobility is rapid and frequent, the extra traffic and delay of
DC> DNS queries is likely not to be the right answer.

Obviously, I concur.

DC> However note that the Internet infrastructure has no problem sending
DC> consecutive packets to different places, as long as they have different
DC> IP addresses.  Hence, the infrastructure can handle mobility just fine
DC> (as long as we ignore the question of forwarded packets that arrive
DC> after the recipient has moved.)

No problem here.  On the other hand, if we had proper and secure
identifiers, packet forwarding would not be an architectural
problem, either.  That is, if a mobile host sends packet forwarding
instructions to a previous access router, and if the access router
is able to authenticate them, setting up a temporary forwarding
path does not cause any architectural problems.  In fact, Jari and
I have written an I-D describing exactly that (using CGAs), but we
haven't bothered to publish it, since we don't want to add more cooks
to the already fairly foul tasting FMIP soup.  (My apologices to
anyone who may take offence; I am merely stating my personal opinions,
and not any objective judgements.)

DC> I've been trained to prefer separating security from naming.
DC> Overloading the two gets confusing and often doesn't work very well.

With all respect, IMHO separating naming and security is a
serious mistake.  All security is based on identifiability.
If you cannot securely identify you peers, you can't do much.
Even opportunistic but secure identification is better than
nothing; see our 2002 Cambridge Security Protocols Workshop
paper for details.

There is another angle in security, namely real world semantics,
that is best left separated from naming.  (With real world
sementics I mean things like database access control, Chinese
wall or Clark Wilson security policies, etc.)  However, as long
as we are discussing routing, addressing, rendezvous, etc., real
world semantics don't count much.  The cyberlaws rule.

DC> In any event, please clarify what security concerns you have.

Well, I am mostly concerned secure identifiability.  Is that
clear enough, or should I pursue the issue more?

PN>  .... and unfortunately
PN>  our strawman economic analysis shows that secure DNS may be
PN>  economicly infeasibile.

DC> huh?

That's a topic of a completely different thread, or
perhaps even a paper, later.  For now, it suffices to
notice that the immediate incentives for people to start
using decure DNS are fairly slim, at least compared to the
efford required.

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Sep 2003 00:31:51 +0200

> fuzzy, general term, with name being a more specific reference.

Funny, I would assume the opposite. I'm sure there are truckloads of 
people who have the name "John Smith" in their passport (although I 
have no idea what parents called Smith are thinking when they name 
their poor offspring John), but unless there is a serious screwup 
somewhere, each passport uniquely identifies the bearer, traditionally 
using such distinguishing properties such as date and place of birth, 
height, hair and eye color and so on. I assume that these days everyone 
has their country's take on the social security number in there too.

When we translate this to IP, we notice that there are indeed many 
systems with identical canonical names, but the domain name system 
comes to the rescue and provides us with a naming hierarchy that makes 
it possible to turn locally used canonical names into globally unique 
names. However, it's important to note that an FQDN often isn't the 
"real" name of that which is referred to, but rather a compromise 
between the properties that make for good names in the real world and 
on the net, and, of course, availability of the desired name.

I don't think we have any real identifiers in IP. If there is something 
you want to identify, it's usually possible to find some handle to do 
this. A host can be identified by its fully qualified domain name or 
its attachment to the network, for lack of a property that really 
identifies a host, if something is even possible. (Think about it: 
which part constitutes the essence of a host, the part that you can't 
take away without changing its identity?) But all of this is subject to 
change.

So we should probably be pragmatic and use existing identifying 
properties if they are usable, or create new ones where necessary. It 
seems silly to identify a host by the mathematical property of the 
contents of a small file on the file system, but it works very well for 
SSH. The same thing for the highest or lowest IP address that a box 
has, but BGP and OSPF seem to thrive on it.

FQDNs and IP addresses make more sense but lack a property that is 
sometimes important: they identify something, but don't don't bring 
enough information about the nature of what they identify with them. 
Does a FQDN point to a host or a service? Does an IP address point to a 
point of attachment or a host? Usually we don't care, but sometimes we 
do.

> relative to the starting point.

Everything is relative to a starting point. "Globally unique" just 
means we agree on the starting point.

> PN> the identified entity,

Obviously the stability of the identifier is limited by that of the 
entity being identified. And an identifier is what you make it.

> PN> while a name does not have those connotations to the same extent.

Yes, names can change, but that doesn't disqualify them as identifiers 
automatically.

> PN>  From this point of view, IP addresses are identifiers.

So what do they identify for what purpose?

I have no trouble identifying my webserver by its IP address, which 
hasn't changed in three years. Not so much with my laptop, as its 
address changes several times a day.

> PN> locations within the routed network.

In other words, addresses are addresses.

> saying.

Do they? What is the point of attachment? The subnet or the individual 
address? I don't think it can be the latter (within this context) as 
the interface brings as much to the table as "the network" in this 
case, in IPv6 at least. (64 bit prefix learned from a router + EUI-64. 
Guess what the I in EUI stands for, BTW.)

> can re-find the server the same way it originally did.

Very good point.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 3 Sep 2003 16:54:10 -0700

Pekka,

PN> Merriam-Webster on-line defines as follows:

uh oh.  when discussion starts including dictionary definitions, it is
often worth stepping back and making sure that the right issue is being
discussed.

I was not criticising your usage, but rather noting that it was
different from mine. And that observation was only intended to be
relevant as an indicator that we (the community) probably do not have
sufficient commonality to our use of the terms, for this line of
discussion.

This being a technical discussion, we had better have some useful,
technical definitions. Then we can switch to having a debate about
problems and solutions. There is technical history to the terms at
issue, here. However they suffer different definitions in different
technical discussions.

That's bad, at least until we all agree on a single set of definitions.

DC>> I do not understand "intrinsically bound", but it sounds interesting.

PN> Well, in my thinking a specific identifier is only able
PN> to denote a specific entity.  That is, the relationship
PN> between an identifier and the corresponding identity should
PN> be a function, i.e., there must not be any identifiers
PN> that denote more than one entities.  Typically the
PN> relationship is (or should be) bijective.

Apologies, but I am still not understanding well enough, I think.  By
way of seeing whether I am understanding at all:

Some mappings between strings and objects are by arbitrary assignment.
Some have a "semantic" process so that the string actually can be
analyzed. Calling a computer "aland" does not really tell you anything
about it, nevermind also not telling you where it is. Calling it
"aland.bbn.com" at least tells you something about the
administrative agency that assigned the name. (It still does not tell
you anything about where it is, even though you might think it does.)

Also, aland is likely not to have a unique, whereas aland.bbn.com is
required to be unique.

(The question of uniqueness depends on context. For most
computer-related assignment processes, uniqueness is required.)

PN>>  In other words, an identifier implies sameness and stability of
PN>>  the identified entity, while a name does not have those connotations
PN>>  to the same extent.

DC>> I guess I need some examples to understand this.

PN> Well, as I wrote above, I think that a name can be re-bound
PN> while an identifier should not be re-bindable.

In the Internet context. what would be an example of an identifier that
cannot be re-bound? (And let me alert you to my belief that all of them
can be.  So when you provide your example, please anticipate that I will
be likely to cite examples that show the non-rebinding feature is a
matter of policy, or otherwise itself is "re-bindable"... In other
words, all this stuff depends on precise -- and often arbitrary --
definitions and policy.)

PN>   In a
PN> micro-mobility solution, it may make sense to use IP addresses more
PN> like topology-unrelated names, and record a route for each address
PN> separately.

right. as you noted later in your reply, whenever we talk about mobility
we need to be careful to specify scope of possible change and rate of
possible change. extremes seem to demand very different solutions.

DC>> Hence a mobility mechanism needs to support end-to-end exchanges that
DC>> may have changing IP addresses over the life of the association.
PN> I concur.  Furthermore, not only (macro)mobility mechanisms but
PN> also multi-address multi-homing mechanisms.

I'm finding myself viewing multi-homing as a simple (ie, degenerate)
case of mobility.

PN>>  Now, you may be able to do rendezvous with just names, e.g., with
PN>>  domain names. And for referencing external objects, it is often much
PN>>  better to use names than identifiers.
PN> Rendezvous is needed for two purposes:
PN> - to allow initial connections
PN> - to resolve the loss of working addresses caused by
PN>    simultaneous movement

ack.

PN> As you write, the difference between client-side mobilty and P2P
PN> mobility lies in rendezvous.  On the other hand, we also have to
PN> remember that more and more servers are becoming mobile, in some way
PN> or another (re-hosting, network re-numbering, etc).  Hence, I would
PN> not consider these two types of mobility that different.

In the long term, no.  but it's worth considering a simpler solution,
for the simpler case, if a) we think there will be significant benefit,
and b) deferring the more difficult part does not make it harder or less
likely to be solved.

The mobile-client/stable-server example requires no new rendezvous
mechanism and I think it covers a very, very large portion of current
mobility needs.  And I think that the rendezvous function needed for
mutual mobility can be solved independently.  So there is no real
disadvantage to deferring it from the "addressing" problem.

PN> No problem here.  On the other hand, if we had proper and secure
PN> identifiers, packet forwarding would not be an architectural
PN> problem, either.

we probably disagree.  packet forwarding requires creating additional
infrastructure, as we have been seeing for the considerable number of
years of effort for the mobile ip work.  that's another reason for
carving off forwarding to be separate from higher-level
(non-infrastructure) mobility support.  At that point, forwarding
becomes an optimization, rather than a necessity.

PN>> On the other hand, domain names are not very good
PN>> for security.

DC>> I've been trained to prefer separating security from naming.
DC>> Overloading the two gets confusing and often doesn't work very well.

PN> With all respect, IMHO separating naming and security is a
PN> serious mistake.  All security is based on identifiability.
PN> If you cannot securely identify you peers, you can't do much.

I didn't mean that security wasn't important.  I mean that separating
the security mechanism from the name administration (and, therefore, the
"meaning" of the name) is usually better.

Clearly, the ability to hijack a name can be a very serious danger.

DC>> In any event, please clarify what security concerns you have.

PN> Well, I am mostly concerned secure identifiability.  Is that
PN> clear enough, or should I pursue the issue more?

a bit more, please.  remember that we are trying to understand why
end-point identifiers are required, or at least what they are required
for.  i'm not seeing how security is a serious issue for that goal.

PN>   For now, it suffices to
PN> notice that the immediate incentives for people to start
PN> using decure DNS are fairly slim, at least compared to the
PN> efford required.

Alas, the IETF has an essentially unbroken track record of failing to
gain large-scale use for any security technology created in the IETF.

>> I am used to terminology use that derives from Shoch

ASUS> Shoch convention of "names, addresses, routes" was
ASUS> found to be ambigous in many contexts. Please refer
ASUS> RFC 1498 - where Saltzer points out some of the 
ASUS> problems with shoch terminology.

That's why I said "derived".

d/

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 4 Sep 2003 12:26:26 +0859 ()

Dave;

> technical definitions.

Technical definitions?

On the problems, yes. On the terminology, no.

> Then we can switch to having a debate about
> problems and solutions.

It is a useful approach to continue the debate forever.

However, to solve the problem, anyone proposing a solution may
use any terminology, as long as it is clearly defined.

> There is technical history to the terms at

Different technology needs different definitions.

We really suffer, if you try to unify them.

							Masataka Ohta

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 04 Sep 2003 09:38:02 +0300

Dave Crocker wrote:
DC> uh oh.  when discussion starts including dictionary definitions, it is
DC> often worth stepping back and making sure that the right issue is being
DC> discussed.

My apology.  I was merely trying to be precise.  Sorry for the detour.

DC> .... And that observation was only intended to be
DC> relevant as an indicator that we (the community) probably do not have
DC> sufficient commonality to our use of the terms...

I see.  And tend to agree.  Furthermore, for me and perhaps a
number of other non-natives the issues are sometimes fairly
difficult since we often don't know the everyday meanings of
many words.  That is, at least I sometimes know a word from a
very specific technical (linguistic) context and have no idea
about its everday meaning and connotations.  "Identifier" may
be one such word.

DC> Apologies, but I am still not understanding well enough, I think. ...
DC>
DC> Some mappings between strings and objects are by arbitrary assignment.
DC> Some have a "semantic" process so that the string actually can be
DC> analyzed. ...

I completely agree.  My thinking about identifiers (as names
that identify) is that an identifier is a different from a mere
name in the sense that an identifier does have such a "semantic"
process associated with it.

For example, consider IP addresses.  They can be considered to
be identifiers for topological locations.  In that sense, the
IP address can be analyzed and understood to act as a pointer
to a certain topological location.

Let me take another example, public cryptographic keys.
A public key can be "analysed" and understood as a pointer
to (the sole holder of) the corresponding private key.

Thus, we can say that IP addresses are identifiers for locations
and public keys are identifiers for (the holders of) private keys.

Let me take this the other way around.  It seems to be a
fairly common practise in computer science to create an
identifier space, and then to make the assumption that
the set of potentially identifiable entities is isomorphic
with the set of identifiers.  That is, you first create a
set of identifiers, and then define that the world consist of
a subset of the set of entities that can be named with those
identifiers.

This seems to be the case with IP addresses.  Even though
we have NAT today, we still seem to think that the set of
topological locations in the Internet is the set of locations
that can be given a unique globally routable IP address.

The same more or less applies to public keys.  If we use the
set of public keys as the set of identifiers, then the set of
identifiable entities consists of things that are able to hold and
process corresponding private keys.

DC> In the Internet context. what would be an example of an identifier that
DC> cannot be re-bound?

As I wrote, identifiers *should* not be re-bindable, not that
it is impossible to re-bind them.  The desired property can
be achieved by at least two ways:
  - through some administrative procedure that ensures uniqueness
  - by using the "reverse process", as described above, i.e. by
    defining identity from identifiers and not vice versa.

Take the public keys example above.  If you define that the
identity of an entity is intrinsically bound to the private
key, then if you move the private key to another device, the
"entity" and its identity move at the same time, too.

DC> (And let me alert you to my belief that all of them
DC> can be.  ... In other words, all this stuff depends
DC> on precise -- and often arbitrary -- definitions and policy.)

We seem to agree :-)

---------------
[Moving from the definition of identifiers and identity to mobility.]
---------------

DC> I'm finding myself viewing multi-homing as a simple (ie, degenerate)
DC> case of mobility.

Well, I tend to view multi-homing as a dual of mobility.
If you are mobile, your topological presense spans several
locations over time.  If you are multi-homed, your topological
presense spans several locations over space.

DC> In the long term, no.  but it's worth considering a simpler solution,
DC> for the simpler case, if a) we think there will be significant benefit,
DC> and b) deferring the more difficult part does not make it harder or less
DC> likely to be solved.

So far so good.  We seem to agree....

DC> The mobile-client/stable-server example requires no new rendezvous
DC> mechanism and I think it covers a very, very large portion of current
DC> mobility needs.

... But now comes the problem point.  While I agree with what you
say, I am concerned about the implications.  That is, if we limit
out view to stable servers, we loose the possibility of deminishing
the importanse of stable addresses.  That is, the current Internet
practise requires stable addresses, and the mobile-client/stable-server
approach also requires stable addresses, for the server.  The
requirement of stable addresses, in turn, is the reason why people
are crying for provider independent addresses, and for much of the
recent brawl at the IPv6 mailing list.

DC> And I think that the rendezvous function needed for
DC> mutual mobility can be solved independently.

While I tend to agree, I'd also like to see that whatever solution
we adopt, it would also allow servers to change their IP addresses
while they have active connections.  In other words, IMHO we may
well leave the problem of simultaneous movements for later, but
we should create a rendezvous function that allows slow movements
of servers.  DynDNS may be sufficient for that.

PN>  No problem here.  On the other hand, if we had proper and secure
PN>  identifiers, packet forwarding would not be an architectural
PN>  problem, either.
DC>
DC> we probably disagree.  packet forwarding requires creating additional
DC> infrastructure, as we have been seeing for the considerable number of
DC> years of effort for the mobile ip work.  That's another reason for
DC> carving off forwarding to be separate from higher-level
DC> (non-infrastructure) mobility support.  At that point, forwarding
DC> becomes an optimization, rather than a necessity.

Actually I think that we agree.  I forgot that some people
may consider packet forwarding as a fundamental mobility mechanism;
for me it has been a mere optimization for at least four or five yers
now.  Hence, as an optimization, I don't necessarily consider it
as an architectural problem.  However, without proper security
support, even as an optimization it may become an architectural
problem.

---------------
[Moving from mobility to security.]
---------------

DC> I didn't mean that security wasn't important.  I mean that separating
DC> the security mechanism from the name administration (and, therefore, the
DC> "meaning" of the name) is usually better.

Well, I am not quite sure what you mean with name administration.

At least since 1996 or so I have been fairly convinced that most
probably only public keys (or other similar "things") are good
primary identifiers for entities in the network.  That is, it is
better first to assign a public key pair to an entity, and then
worry about "naming" the entity with some name that has any semantic
meaning to the applications.

DC> Clearly, the ability to hijack a name can be a very serious danger.

Under fairly benign assumptions, it is fairly hard to hijack
public keys.  (But not impossible, of course.)  Other names
are then assigned by the application, and only meaningful in
the application context.  The application is also responsible
for establishing the secure relationship between the application
specific names and the entity identifiers, i.e., public keys.
This is the approach used in SDSI, SPKI, and related work.

DC> a bit more, please.  remember that we are trying to understand why
DC> end-point identifiers are required, or at least what they are required
DC> for.  i'm not seeing how security is a serious issue for that goal.

In our 2002 Cambridge paper, we use the following classes
of "weak authentication" methods:

   - challenge response (e.g. Return Routability)
   - anonymous encryption (e.g. unauthenticated D-H)
   - leap of faith (e.g. SSH)

With secure, long lasting identifiers we are able to achieve
leap of faith.  That is, we can recognize a party the next time
we encounter it.  Without secure, long lasting identifiers we
can't do more but simultaneous challenge response and anonymous
authentication.

These two different security models have different implications
to the cost of attacks, and to the overall level of trust that
can be achieved.

DC> Alas, the IETF has an essentially unbroken track record of failing to
DC> gain large-scale use for any security technology created in the IETF.

I have started to think that one reason behind this may be
lack of economic understanding.

--Pekka Nikander

---

From: Robert Honore <[email-masked]>
Date: Fri, 05 Sep 2003 16:48:28 -0400

Dear Pekka Nikander,

Please forgive the late reply.

Where can I find out more about Dave Crocker's MAST?

See the rest of my message embedded among the qoutation of your text.

Pekka Nikander wrote:
> However, I also see a kind of causality here:  it looks to me that 
> stable end-point identifiers are mainly needed to make applications 
> survive IP address changes.  Dave Crocker's MAST is a good example 
> how you can do that without having stable end-point identifiers.

There is more to stable end-point identifiers than just the ability to
make an application resilient.  I will argue that IP addresses *do not*
identify end-points, but node interfaces.  That is, they only specify
objects on the path to the end-points.  Applications, users and system
administrators need to specify more than node interfaces  They try to do
so by twisting IP addresses to all kinds of usages for which they were
not intended and are ill-suited in my opinion.  Indeed it is a feature
that IP addresses and their definition as an identifier for a node
interface are so flexible that it is possible to contemplate extending
their usage for those purposes.

> 
> On the other hand, security looks to me as a good reason for having 
> stable end-point identifiers.  If you can securely recognize an 
> end-point (with emphasis on the *re-* part of re-cognize), you can 
> develop trust.  Trust, in turn, is very handy for lowering 
> transaction costs.
> 

Indeed it is, and I would add that end-point identifiers (together with
node interface identifiers) are the thing that system administrators and
system security officers want.

> 
> Even facing the danger of opening yet another rat hole, in my opinion
>  we should not have a very strict definition for end-point. That is,
>  IMHO end-point should and could be a fuzzy concept, somewhat like
> the concept of a site is today.
> 
> processes, a host, or even a server cluster offering services as a 
> unit.  To me, it looks like fate sharing and common semantics are the
>  key points here.  An end-point should either work or fail, it should
>  not be usual for half of an end-point fail while the other half is 
> continuing.  An end-point should also be considered at the 
> application level as a single unit.
> 

The question that that raises is, whether it is reasonable to use such
an inclusive notion of an end-point, and what is the simplest kind of
structure or object we can use to implement an end-point identifier?  We
might have to restrict the notion of an end-point somewhat.

> to the stack almost automatically protect applications from the 
> changes of IP addresses.  I also tend to believe that stable 
> end-point identifiers may also help to build self-organized networks.
>  However, IMHO the problem of self-organized networks is more 
> researchy in nature than the other two.

With respect to the protection of applications from changes of IP
addresses, the effectiveness of that protection (or its robustness) will
depend on what the final specification of end-point identifiers is.
With respect to the problem of self-organised networks, that might be a
research problem, but I would argue that it is a here-and-now research
problem.

> consensus on solutions that require architectural change may take too
> long.  Hence, I also believe that we need some kind of a road map, 
> with some "temporary" or intermediate solutions along the way to a 
> more long-standing set of solutions.
> 

I agree, and your statement corresponds to what Keith Moore says about 
the solutions fitting into a framework that is yet to be specified.  I 
believe specification of that framework begins with our defining what an 
end-point is.

Yours sincerely,
Robert Honore.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 5 Sep 2003 16:15:01 -0500

Dear Robert,

Dave's MAST proposal was announced at
http://www.ietf.org/mail-archive/ietf-announce/Current/msg25938.html.

It is not entirely clear where this draft should be discussed. I
bailed and sent my comments to Dave offlist, and asked him to reply on
SOME list if my comments were helpful (candidates include MULTI6, but
I can't speak definitively). I'm sure guidance would be graciously
accepted.

Spencer

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Sep 2003 23:45:31 +0200

On vrijdag, sep 5, 2003, at 23:15 Europe/Amsterdam, Spencer Dawkins 

> I can't speak definitively). I'm sure guidance would be graciously

Similar stuff has been discussed on the multi6 list in the past, so I 
see no reason why this couldn't be discussed there. Doing so isn't even 
in direct contradiction with the charter.   :-)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 5 Sep 2003 16:03:27 -0700

Folks,

Multi6 seems like the right choice for discussing MAST, to me too.

SD> Dave's MAST proposal was announced at
SD> http://www.ietf.org/mail-archive/ietf-announce/Current/msg25938.html.

SD> It is not entirely clear where this draft should be discussed. I
SD> bailed and sent my comments to Dave offlist,

I'm formulating a reply.  Please re-post your comments to the multi6
list.

d/

SD>  and asked him to reply on
SD> SOME list if my comments were helpful (candidates include MULTI6, but
SD> I can't speak definitively). I'm sure guidance would be graciously
SD> accepted.

SD> Spencer

SD> ----- Original Message ----- 
SD> From: "Robert Honore" <[email-masked]>
SD> To: "Pekka Nikander" <[email-masked]>
SD> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
SD> Sent: Friday, September 05, 2003 3:48 PM
SD> Subject: Re: where the indirection layer belongs

d/

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Sep 2003 11:30:04 +0300

Dear Robert,

>> [...]  it looks to me that 
>> survive IP address changes.  ...
> 
> identify end-points, but node interfaces. 

I think we agree.  At least I think we agree pretty much on the role of
IP addresses.  I would even go further, and state that IP addresses
identify network interfaces, not node interfaces, as Dave Crocker
recently put it.

Personally, I do believe that we should have explicit names for
end-points, e.g., due to the reasons that you explained.  However,
I am not quite sure if everybody agrees with that.  Hence, what I
am merely trying to say is that we probably *could* continue to live
without explicit end-point identifiers, and still get the desired
mobility and multi-homing properties.

>> continuing.  An end-point should also be considered at the application 
>> level as a single unit.
> 

Well, as I tried to say, I'd prefer to have some functional and
semantic restrictions, and not just denotational restrictions.  That is,
if we say that an end-point must fail as a unit, that is a reasonable
restriction.  Likewise, if we say that an end-point must act as
if it had unique state, that is a good restriction, too.  That does
not preclude one from creating distributed end-points, as long as
each distributed end-point appears to have a unique state at each
point of time.

A related question is also the structure and semantics of the
end-point identifiers.  The simplest identifiers would be sufficiently
long random numbers, with a probability of collisions low enough.
However, I tend to believe in identifiers that have more structure,
and preferably even cryptographic semantics.

More on a new thread.

--Pekka Nikander

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Sep 2003 11:52:32 +0300

[Please direct replies either to the IPv6 or the IETF
mailing lists, but not both.  The default should be IPv6,
imho.]

Robert Honore replied:
 > believe specification of that framework begins with our defining
 > what an end-point is.

Good that we agree on a need for a roadmap.  Now, I want to return
back to your original problem analysis:

 > *    Resiliency of application (protocol) in the face of sudden
 >      IP address changes

These are the goals that we need to focus on.  While designing
the longer term architectural solutions, we need to preserve
the current functionality, and think about transition mechanisms.
 From this point of view, the only (semi-)stable end-point
identifiers we have today are IP addresses.  We both agree, and
I think quite a few others agree, that IP addresses are not very
good end-point identifiers.  However, they are used as such today.

Furthermore, it will take quite a long time to get something to replace
the IP addresses as end-point identifiers.  As has been discussed
several times, domain names do not work well enough, and therefore
we need a new name space, I think.

Consequently, we have to provide (semi-)stable IP addresses
for IPv6 networks.  Based on the recent discussion at the IPv6
WG, apparently people think that PA addresses are not stable
enough.  Hence, at least to me, the Hinden/Haberman addresses
look like a good temporary solution.  It seems to provide stable
IP addresses, which can temporarily be used as end-point identifiers,
with the expectation that they will be eventually replaced with
"proper" end-point identifiers.

What comes to application resiliency, Christian Huitema's
approach of (mis)using Mobile IP may work well enough for a while.
However, it has a number of architectural problems that make
me to think about it only as a temporary solution.  Going further,
if we did not have any other reasons for "proper" end-point
identifiers, I think that Dave Croker's MAST might be good next
step.  However, since I do think that we most probably do need
stable and secure end-point identifiers, I think that something
like HIP will be more appropriate.

[I'm relatively ignorant to the exact details of self-organized
  networks, and therefore I don't want to comment that.]

Given the above, I think we could have a roadmap that might
look something like the following:

  Stable identifiers:    Hinden/Haberman -------------> New name space
                                                        for end-point
  Resiliency on          Huitema MIPv6  --> (MAST) ---> identifiers
  address changes:       multi-homing                   (maybe HIP)

--Pekka Nikander