[RAM] 4 User-interface and delegation tree for central database (LISP/Ivip)

Here are some ideas about how a central database of mapping
information might be controlled.  This is different from keeping
the authoritative data in multiple locations and having to work
backwards to find the authoritative server, as in the DNS, and as
described in draft-meyer-lisp-cons.

Nonetheless, the authority to change the mapping for the IP
addresses is delegated in a distributed fashion similar to the DNS.

The initial action which leads to the database being changed is a
user generated (manually or by the user's equipment or by a system
authorised by the user) "Update Command".

For authorising and feeding Update Commands to the central database,
I think there needs to be some kind of tree-structured system
similar to the DNS in the way that the authority is delegated.
However, this tree structure involves data flowing back towards the
root of the tree as well.  The idea is that the single Ivip central
database system would delegate control of one or more of its ranges
of addresses to some other system, which in turn would delegate
control to other systems.  There would be no absolute limit on the
depth of this.

Ultimately, from the point of view of the end-user, there needs to
be a username and password (or some crypto private key challenge
response system) by which they manually (via a web interface), or
some automated way, can control the mapping of their one or more
Ivip-mapped addresses.  The servers which handle the end-user
interaction needs to be the leaves of this tree structure, so as not
to burden the central database servers themselves with this messy
stuff.  This enables various companies to give different kinds of
control for the Ivip-mapping of the IP addresses their branch of the
tree controls.

It would be especially important for multihoming that some
reasonably trusted company could run an automated monitoring
system, and have the credentials (username, password, key etc.)
stored in their system so their system can change the mapping of
one or more IP addresses the moment one link seems not to be
working.  Also, the company which controls a particular range of
the Ivip-mapped space may offer such a multihoming monitoring
system itself.

Theoretically, the multihomed end-user's host or router could
detect that the link to ISP-A was dead and send one or more
packets out the ISP-B link to whatever server controlled the
mapping of its IP address.  However, this would probably be a
one-way transition, because at that time, the Ivip-mapping for its
IP address is pointing to the ETR in ISP-A.  However, maybe the
server which handles such packets could be smart enough to send a
reply by encapsulating it to the ETR of ISP-B . . .   Two way
challenge response exchanges are typically required to stop replay
attacks which would be possible with a single-packet command to do
something as crucial as changing the Ivip-mapping of an IP address.

Here is a rough diagram of a tree of servers, which could be
physically separate servers, or could be implemented on the one
machine.  I assume, but don't show, that each such server is
actually two or more servers, geographically distributed, like the
DNS, so the whole system is robust.

The tree in this example controls the address range 20.0.0.0 to
20.3.255.255.   This is what I would call a "master-subnet",
because it is a prefix of address space which is advertised in BGP
and controlled by the Ivip system, so all ITRs advertise this
prefix.  Over time, it may be joined by other prefixes, such as
20.4.0.0 to 20.7.255.255, and so it may be advertised as part of a
larger subnet (shorter prefix).  Maybe that second range would be
controlled by the same company and so be part of this tree of
authority, or maybe it would be controlled by another company, with
its own tree of delegation.

Let's say company X has authority (direct from the Ivip system,
perhaps because it assigned this space which it got from an RIR to
the Ivip system) over the entire range 20.0.0.0 to
20.3.255.255.  It sublets to Y a quarter of this: 20.1.0.0 to
20.1.255.255.  I am making these examples on binary boundaries,
but there is no reason why the divisions should be like this.  It
would be just as possible for X to delegate to Y an arbitrary
subset of the whole range, or the entire range, or just one IP
address.

X's Update Authorisation Server (UAS) has a private key for
signing all the update messages it sends to the central database
system.  That central system trusts any message with such a signature.

However the central database system neither knows nor cares about
company Y or Z.  All it knows about is the various instances like
X, each an organisation with a public key for authenticating
update messages, for a given subset of the total Ivip-mapped
address space.  This could be any arbitrary subset, but for
simplicity I will assume that X only has authority over this one
subnet 20.0.0.0 to 20.3.255.255.

Let's say Y delegates control of some of its space to company Z,
and that Z has an end-user U, who needs to control the mapping of
one or more IP addresses in Z's range.

Z has various interfaces by which U can do this, with its own
arrangements for authentication, for monitoring a multihoming
system and making changes automatically etc.  Hopefully there
would be one or more automated, host-to-server, IETF-standardised
protocols so all end users could have standardised software for
talking to whichever company's servers they use to control the
mapping of their IP address(es).

           User-R   User-S  User-T  User-U       Multihoming
                 \        \      |       |       Monitoring
                  \        \     |       |       Inc.
                   \      .................     /
                    \----. Web interface   .---/
                         . other protocols .
                         . etc.            .
                          ....UAS-Z........
                                |
Other companies                 |
like Y and Z                    |
                     /-----<----/
|   |           \ | /
|   |            \|/
|   |           UAS-Y
\   |             |
 \  |  /----<-----/
  \ | /
   \|/
  UAS-X
    |
    |
    V
    |
    |
    |      Tree-structured system of delegated
    |      authority and servers which at its
    |      leaves, have the facilities for end-users
    |      to securely control the Ivip-mapping of
    |      their one, few or many IP addresses.
     \
      \
       \
        \      |    |    |      /
         \     |    |    |     /
          \    |    |    |    /
           \   |    |    |   |
           |   |    |    |   |
           V   V    V    V   V

             ...............
         .                    .
       .   CDSB1---------CDSB2  .    Distributed,
      .       \           /      .   redundant,
      .        \         /       .   central
      .         \       /        .   database.
      .          \     /         .
      .           \   /          .
       .          CDSB3         .
         .                     .
             ...............

           |  |  |  |  |  |  |       Generates periodic
           |  |  |  |  |  |  |       complete database
          /   |  |  |  |  |   \      files and a stream
         /   /   |  |  |   \   \     of second-by-second
        /   /   /   |  |    \   \    updates.

Let's say User-U wants to change the mapping of their IP address
via a web interface.  User-U does this via Z's website,
authenticating him-, her- or it-self, by whatever means Z requires,
and and gives the command to map to a new IP address (typically the
address of another ETR).  This causes UAS-Z to sign an update
command message (according to some future IETF standard, of course)
and to send it to UAS-Y.

In fact there would be two or more UAS-Zs and likewise two or more
UAS-Ys.  I guess they use TCP and ensure they get a response from
whichever UAS they are sending the signed command to.

UAS-Y trusts this update command because of Z's signature.  It
strips off the signature and adds its own.

UAS-X plays the same game and within a fraction of a second, the
central database system receives the update command.

Authority is delegated up the tree, because UAS-Y will only accept
update commands if they are signed by one of its branch UASes, and
for the particular address range that UAS has been authorised to
control.

User-U may have given their username and password etc. to
Multihoming Monitoring Inc. so this company can monitor their
multihoming links and change the mapping as soon as one link goes
down.  UAS-Z doesn't know or care who actually makes the change -
as long as they can authenticate themselves for whatever address
or addresses they want to change the mapping of.

There is no need for PKI in any of this, I think.

I think there really needs to be a central database system and
some kind of distributed input system like this.  Without a
centralised control system (for instance the distributed CARs in
draft-meyer-lisp-cons) there is no way of producing a unified
stream of second-by-second updates, or a snapshot of the database
for a freshly booted ITRD to load.

I am convinced that a pure "pull" system such as
draft-meyer-lisp-cons will be too slow to respond.
(draft-meyer-lisp-cons has "push" elements, but that is not
pushing data towards ITRs, just information about where the
authoritative CAR can be found.)

I guess it may be possible for there to be multiple separate
"central database" systems, each with their own trees of delegated
update input control.  Each such separate system could cover a
subset of the entire Ivip-mapped space.

Then each ITRD would need to get update streams from all these
systems.  Alternatively, there needn't be a single ITRD which
handles every Ivip mapped IP address.  This could be an important
scaling consideration, reducing the amount of RAM and FIB capacity
in each ITRD, and performing the entire ITRD function with several
 routers (or just plain servers with a gigabit Ethernet link to a
router) each handling a subset of the total range of Ivip-mapped
address space.

 - Robin         http://www.firstpr.com.au/ip/ivip/

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram