[e2e] a means to an end
Jon.Crowcroft at cl.cam.ac.uk
Wed Nov 5 01:48:46 PST 2008
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
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
>>So I question your assumptions. Come to Minneapolis and let's talk
>>about it :-).
More information about the end2end-interest