Re: names, addresses, routes

Dave,

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,

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.

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.

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

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.

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