[e2e] a means to an end

[Scott Brim]

On 11/4/08 10:57 AM, Jon Crowcroft allegedly wrote:
> so a lot of IANG (Internet Arch Ng)
> work is on addressing - 
> 
> and a lot of nice work
> has come out on how to do secured
> id+loc split 
> in terms of requirements and technologies 
> on the address space...
> 
> there's all the usual reasons for doin this split 
> (seamless mobility, with transport doin its thing on the id
> part only; multicast; multihome; multipath; etc)
> 
> but, BUT this is sidestepping the big problem
> which is to have a service which hosts the 
> id<->loc mapping, which actually 
> scales to the size of the expected workload...

Jon: Why do you think that is necessary at all?

There are two uses for identifiers: (1) to find things in the first
place and (2) for AAA for sessions once nodes have been located.

For (1), to find things in the first place, you do not need to know
exactly where they are at all points in time, you can use another level
of indirection: a rendezvous point that knows where they are.  MIP6, for
example, provides this in its home agent, without any special id->loc
mapping server (unless you consider the HA itself to be a mapping
server).  You *could* have a central mapping system that everyone
updates, but having another level of indirection, e.g. DNS -> HA -> MN,
makes everything more robust and places the operational burden on the
nodes that benefit.  Also, persistent rendezvous points may be generally
useful idea for all initial contacts, because that way some policy can
be invoked at the rendezvous point (for example routing you to
voicemail), and for those packets that are forwarded to the target node,
the node itself gets to decide whether and how to respond.

For (2), ongoing sessions, you do not need any central server.  You need
mechanisms for initially authenticating identifiers and possibly
re-authenticating, but not an id-loc mapping server.

Finally, I don't see any use for a server for mapping in the opposite
direction, from locator to identifier, although your "<->" implies you
want one.  If you want to know what is at a particular location, it is
better to require you to ask it directly.  The node in question might
consider some identifiers to be privileged information, and not be
willing to give them away to anyone querying a locator in general.  Also
there can be many identifiers in use for a particular locator, and many
of them will be transient.  What is the point of a third party service
for this?

So I question your assumptions.  Come to Minneapolis and let's talk
about it :-).

Scott