Subject: [RRG] Authentication of authority to control mapping

From: Robin Whittle <[email-masked]>
Date: Thu, 21 Feb 2008 11:10:48 +1100

Hi Scott,

In "Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4
address depletion, you wrote:

>> so I think they are aiming their system to do "network" (many
>> IP addresses and hosts per EID prefix) multihoming, not "host"
>> multihoming.
>
> There is an authentication problem with map-n-encap and wandering
> EIDs. Suppose a device visits a site and wishes to use an EID
> that is not in a prefix that that site normally announces, and
> the site agrees to announce it.  Why should the mapping
> infrastructure, whatever it is, listen to the announcement of
> that new EID?  You could have it trust whatever it's told, but
> more likely there will be filters in place to defend against
> bogus announcements, intentional or otherwise.  Compare BGP route
> filters.

This may be a problem for LISP-ALT, where the ALT network somehow
has to be configured to know which particular ETR or ETRs are the
authoritative query servers for every EID prefix.

LISP-NERD has some other arrangement, I think, since there is one or
more centralised sources of mapping data, and I guess end-users
control this by a user-password system which is entirely unrelated
to ETRs or any trust-giving global network of routers, such as ALT.

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.

There are some diagrams of this in Fig 1:

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

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Scott Brim <[email-masked]>
Date: Wed, 20 Feb 2008 21:11:45 -0500

> to ETRs or any trust-giving global network of routers, such as ALT.

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. 
  You can't change the mapping for a prefix, in the mapping system, 
instantly.  It's the wrong time scale.  If you want rapid change you 
need to use some mechanism outside of the mapping system.  Either that 
or make yourself vulnerable to attacks and mistakes.  You can support 
rapid change, but you shouldn't jiggle the mapping system to do it.

> 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.  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?  How 
far are you going to push the changed information?

swb

---

From: Robin Whittle <[email-masked]>
Date: Thu, 21 Feb 2008 15:39:50 +1100

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

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