[e2e] a means to an end

[Jon Crowcroft]

the "level of indirection" is exactly what I am talking about
but noone appears to be designing a service that implements 
this with a view to the workload (including secure
update rate) it should sustain.

the two way mapping is needed  because of audit/accountability
trails

In missive <4910A456.6030700 at employees.org>, Scott Brim typed:

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

 cheers

   jon