Re: [RRG] Authentication of authority to control mapping

[Robin Whittle <rw@firstpr.com.au>]

Hi Scott,

You wrote, in part:

> I'm not talking about who a source is specifically, but the fact
> that inputs to the mapping system need to be controlled.  Inputs
> might be from "users" (probably site managers), but there will be
> policy on them. 

Who, other than the end-user whose micronet or EID prefix the
mapping is for, should control the mapping?  With Ivip the
restrictions will be not to map it to an address which is any of:

  Inside a Mapped Address Block - that is, the address is not
  and RLOC address.

  Multicast, 10.0.0.0/8 etc.

  Maybe some other list of prefixes which, for some reason are
  agreed by all to be where ETRs should never be.

If end-user A has two ISPs X and Y, then each ISP gives them an ETR
which connects to the end-user's network.  Then, its up to the
end-user where their micronet / EID prefix is mapped.  They can
point it to one or the other ETR or they can point it wherever they
like.

How would the overall map-encap system decide that someone other
than the end-user should have a say in where their micronet / EID
prefix is mapped?

> You can't change the mapping for a prefix, in the
> mapping system, instantly.  It's the wrong time scale.  

Ivip aspires to doing it in less than five seconds, globally, from
end-user command to all ITRs changing their tunnelling - for a small
fee.

> . . .

>> Ivip control of mapping is on this basis - the end-user
>> controls the division of their UAB (User Address Block) in
>> terms of splitting it into micronets and mapping those
>> micronets to an ETR address, in a system which has nothing to
>> do with ETRs.  The most obvious way to do it is by a username
>> and password over an encrypted link, or a challenge response
>> system with a secret key, password etc.  This would happen in a
>> session with some organisation which directly or indirectly
>> controls the mapping for a particular Mapped Address Block
>> (MAB) - a BGP advertised prefix which typically contains many 
>> UABs and therefore typically this many, or probably more,
>> micronets.
> 
> If I understand correctly, you are proposing that wandering
> devices that want to keep their "addresses" intact will talk to
> an agent which will be authorized to make changes to the mapping
> system.  

Yes - or have some other system talk to this "agent".  The agent is
a UAS - Update Authorisation System - which goes between users and
the RUAS (Root Update Authorisation System), of which there are
multiple.  Each RUAS controls the mapping for one Mapped Address
Block.  This has been documented since July, but the new ID will
take you through it faster, with some updated and simpler terminology:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.html

Also, the 5.5 pages of summary:

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

> That solves the authentication problem (you separate the
> wandering device from updating the mapping system) but not the
> time scale problem.  How many roaming events per second do you
> want to support with your mapping system?  

With IPv4 the raw change data is about 12 bytes.  IPv6 is a lot longer.

I will write a separate message on this in the next week or two.

I look forward to your response to my questions at the end of my
message "Future mapping DB size, small micronets/EIDs":

    Can you write about how LISP-ALT or LISP-NERD could support
    mobility or not?

    Also, given the answer to that question, how many EIDs do you
    think - as an outside but not unrealistic estimate - a LISP
    scheme would ever have to support, say in 2015, 2020, 2030, 2040
    and 2050?

> How far are you going to push the changed information?  

As far as operators feel like pushing it into their networks.
Beyond that, they use caching ITRs querying their local query servers.

In any event, as long as the full mapping database is pushed to a
few hundred sites around the Net, that is going to be much faster
and more reliable to have query servers there than to rely on a
global network like ALT.

I think a worst-case estimate, in terms of how small a distance the
full database might be pushed, is something like as far as one or
more sites with a bunch of full database query servers in every
major ISP.  A best case estimate is that it could be pushed further,
so there are lots of full database ITRs and query servers all over
ISP networks and in many large end-user networks.

  - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg