Subject: [rrg] Today's "IP addr. = ID = Loc" naming model should be retained

From: Robin Whittle <[email-masked]>
Date: Tue, 02 Feb 2010 00:31:59 +1100

Short version:    The current 2 level Internet naming model:

                    Role             Level

                    Text name  <---- FQDN
                    Identifier <---] IP address
                    Locator    <---]

                  is superior for supporting host communications and
                  should be retained.  Core-Edge Separation (CES)
                  architectures such as LISP, APT and Ivip retain
                  this model.  (CES architectures separate "edge"
                  addresses from the remaining "core" subset - they
                  do not separate Identifiers from Locators.)

                  Core-Edge Elimination (CEE) architectures AKA
                  "Locater / Identifier separation" (not the
                  LISP CES protocol, which is confusingly named)
                  remove the linkage and provide separate objects,
                  in separate namespaces, to perform the roles of
                  Identifier and Locator.

                  The CEE approach is widely regarded as
                  "architecturally cleaner" - but the most open-
                  ended, generalised, approach is not always the one
                  which leads to the best overall system performance.

                  Please see the companion message:

                     CES & CEE are completely different (graphs)

                  for why I believe CES to be superior to CEE. This
                  is primarily because CES allows the current IP
                  naming model to remain, and secondarily due to CES
                  being much easier to introduce, with immediate
                  compelling benefits for adoptors and for routing

                  scalability.

Hi Joel,

In "Re: [rrg] Multiple critiques, choice of single proposal, ..."
(msg05846) you wrote:

> If someone wants to add text on Identifier / Locator separation as
> a useful architectural principle, I guess I can't object.

Do you mean Core-Edge Elimination (CEE) or Core-Edge Separation
(CES)?  Please see this recent message for my concerns about how this
term may mean different things to different people:

  Terminology: Loc/Id sep., LISP, CEE & CES, namespace
  http://www.ietf.org/mail-archive/web/rrg/current/msg05858.html

I assume you mean that you support changing the IP protocols so hosts
use separate things for Identifier and Locator.  I assume you do not
mean the LISP CES protocol, which does not involve "Locator /
Identifier separation".

CES architectures retain the current 2 level IP naming structure
where the FQDN performs the "Text name" role and the Identifier and
Locator roles are both performed by the IP address.

          Role             Level           Conventional IP & with CES

          Text name  <---- FQDN
          Identifier <---] IP address
          Locator    <---]

CEE architecture such as HIP, ILNP, GLI-split, Name Based Sockets
etc. involve Locator / Identifier Separation.

There are several naming models, but what they have in common is that
the Identifier and Locator roles are performed by different levels of
the model, with the Identifier object being interpreted according to
a different namespace from the Locator object.

I think most CEE approaches use 3 levels - FQDNs for the "Text
names", and separate levels to perform the Identifier and Locator
roles.  In some CEE architectures such as ILNP, the lower part of the
IPv6 address performs the Identifier role and the upper part of
performs the Locator role.

          Role             Level            Some CEE architectures

                                            such as HIP
          Text name  <---- FQDN
          Identifier <---- HIT
          Locator    <---- IPv6 address

          Role             Level            Some CEE architectures
                                            such as ILNP
          Text name  <---- FQDN
          Identifier <----           IIII IIII } Combined into
          Locator    <---- LLLL LLLL           } one IPv6 address

    (Actually, the LLLL LLLL 64 bits are a locator within
     the DFZ - enough to get the packet to the right ISP, and
     probably further within the ISP to the correct end-user
     network.  IIII IIII is both the [usually globally unique]
     Identifier of the host, and also may be used as a Locator
     within the end-user network.  Or perhaps some of the least
     significant bits in IIII IIII function as a Locator within
     the end-user network, and the remaining bits in IIII IIII
     function as a Locator sufficient to get the packet across
     the DFZ, to the correct ISP, and then within that ISP's
     network to the correct end-user network.)

As best I understand Name Based Sockets, its naming model resembles:

          Role             Level            Name Based Sockets?

          Text name  <---] FQDN
          Identifier <---]
          Locator    <---- IPv6 address

However, if Name Based Sockets is to support a single Text name
enabling a host to get a list of multiple separate hosts, any one of
which can be used (as with "round-robin DNS) then the model must be
somewhat different.  Name Based Sockets is intended to do this, and I
am seeking guidance from Christian Vogt on how it does so.  My best
guess is that the Identifier role must be performed by some kind of
combination of FQDN and IP address.

Anyway, in all CEE architectures, the roles of Identifier and Locator
are performed by separate levels of the naming structure.

This is good if you want to have a simple routing system - because
you can have hosts be more responsible for routing and addressing
than they are today.  Then, Portability, multihoming, TE and perhaps
mobility can be achieved as I describe in the companion message.

All these benefits can be achieved without PI space - so this solves
the routing scaling problem.  The only thing which needs to be added
to the network is a mapping system so any host can look up an
Identifier and securely receive the current Locators which the host
with that Identity might be using.  This is usually done with a
DNS-like arrangement or with extensions to the existing DNS system.
In the case of Name Based Sockets, the existing DNS is used.  In all
these CEE proposals I know of, this mapping system is a global query
server system, like DNS. This means it tends to be slow and may be
unreliable due to packet losses.

Also, the mapping systems for CEE architectures frequently require
multiple lookups to find an authoritative server.  The mapping system
for Identifier -> Locator lookups may not be suitable for caching.
So these CEE mapping systems cannot be as fast and reliable as those
for CES schemes (APT and Ivip) which use local full-database query
servers.

This Loc/ID split arrangement will delay the establishment of most
communication sessions, and create further burdens in terms of:

   a - Extra management information to be included in some
       host-to-host packets.

   b - Perhaps extra packets flowing between the hosts.

   c - Extra packets flowing between hosts and the mapping system.

   d - Extra complexity and state in each host.

Here are my arguments for why the current 2 level IP naming model is
superior to the 3 level "Loc/ID split" model:

   While CEE does involve a simpler network, this benefit is far
   too slight to make up for greater effort hosts must make when
   beginning new sessions and the delay this introduces.  This
   delay is typically forced on both the Initiating Host (IH) and
   the Responding Host (RH).

   There are delays in the Identifier -> Locators lookup which
   both hosts typically have to do.

   With today's IP naming structure - which remains unaltered with
   a CES architecture - the IH may do a DNS lookup, if it starts
   with a Text Name  but this is not always required.  If the IH
   starts with an IP address (which is also the Identifier of the
   RH) then there is no need to do a lookup.

   With the Loc/ID split CEE naming structure, the IH always has to
   do a lookup to get the one or more Locator addresses of the RH.
   So, sometimes, this involves the same sorts of delays as is
   currently the case.  But in every case where the current 2 level
   IP naming structure enables the direct use of an IP address,
   the Loc/ID spit CEE system would be slower.

   With the Loc/ID split CEE approach, if the RH should only reply
   to packets after it establishes that the host it is going to
   send the reply to really is the one whose Identifier is in the
   request packet, then the RH needs to do an Identifier -> Locator
   mapping lookup before sending the reply packet.

       (This is not always the case.  For instance a DNS server
        might not need to know the Identity of the host to which
        it will send the reply - so as long as the query packet
        supplies a Locator which the DNS server can use to send
        the reply to, then there's no need for the DNS server to
        do a Identifier -> Locator(s) lookup to find the one or
        more Locators which the host with this Identifier
        currently has.)

       (Neither an ordinary IP host or a CEE host can be sure
        the request packet was sent by the host which has
        the Identifier specified in the source field of the
        packet.)

   So there are at least one and frequently two extra lookup
   delays before the IH gets the reply packet.

   With today's 2 level IP naming structure, the RH knows the
   Identifier of the host which will (probably) get its reply
   packet - the Identifier is the IP address.

   More particularly, while a host using today's 2 level IP
   naming structure doesn't know for sure that the host with the
   Identity signified by the destination address will get the
   packet, it knows for sure that no other host will get it.
                                  ========

   Without doing a lookup, the CEE host can't be sure that a
   packet it sends with Identifier = X, Locator = 123 will not
   be delivered to a host with an Identifier other than X.

*  The basic problem with the CEE Loc/ID split naming model is
*  that every host, when it wants to send a packet to host with
*  Identifier = X needs to look up X in the mapping system to
*  securely find the one or more Locators X has at present.  Then
*  it can send a packet to X using any one of these Identifiers, and
*  know the packet will firstly probably get to X, and perhaps more
*  importantly definitely will not go to any host other than X.

   Typical conventional IP communication session establishment
   protocols work like this.  I am using the first two packets of
   TCP as an example, but almost all protocols involve sending at
   least a packet in one direction and getting a reply before
   anything much can be achieved.  IH and RH are the Initiating and
   Responding hosts.

     1 -    IH has FQDN of RH.
            IH sends DNS query.
                               \
                                \
                                 \ DNS server replies (perhaps there
                                 / are two or more lookups by the
                                /  IH, or the resolver).
            IH gets IP address /
            of the RH.
            IH sends SYN to IP
            address of RH.     \
                                \
                                 \ RH receives SYN.
                                 / RH sends back SYN-ACK
                                /
            IH gets SYN-ACK.   /

         This is 2 host-to-host packets and 1 global DNS lookup,
         which may take a while, since it often involves long
         distances, may involve packet loss and may require more
         further lookups to find an authoritative DNS server.

     2 -    IH has IP address of RH.
            IH sends SYN to IP
            address of RH.
                               \
                                \
                                 \ RH receives SYN.
                                 / RH sends back SYN-ACK
                                /
            IH gets SYN-ACK.   /

         This is 2 host-to-host packets.

   With the Loc/ID split CEE arrangement, assuming the RH only wants
   to send the SYN-ACK packet once it knows that the packet will go
   only to the host whose Identifier was in the SYN request packet,
   here is what must occur.  This is assuming the DNS lookup provides
   not just the Identifier, but also the currently valid Locators.

   It would be worse if the DNS only returned an Identifier and the
   IH had to do a further Identifier -> Locator lookup.

     3 -    IH has FQDN of RH.
            IH sends DNS query.
                               \
                                \
                                 \ DNS server replies (perhaps there
                                 / are two or more lookups by the
                                /  IH, or the resolver).
            IH gets Identifier /
            and one or more
            Locators of RH.

            IH sends a SYN to
            one of these Locators
            and includes the
            Identifier of RH in
            the packet.  It also
            includes in the source
            fields its own
            Identifier and at
            least one Locator.
                               \
                                \
                                 \ RH receives the SYN packet.
                                   RH initiates a mapping lookup
                                   using RH's Identifier, to find
                                   securely what one or more Locators
                                   the IH can be reached on.
                                 /
                                /
                               /
                              /
           Mapping server gets
           request and sends
           reply.             \
                               \
           (This may involve    \
            more than one        \ RH receives one or more Locators
            lookup.)               for IH.  If the SYN packet's
                                   source Locator matches one of
                                   the Locators in the mapping reply,
                                   then RH will proceed with a reply.
                                   If not, RH will take no further
                                   action.

                                   RH sends SYN-ACK packet with IH in
                                   the destination Identifier field
                                   and the Locator from the SYN
                                   packet in the destination Locator
                                 / field.
                                /
                               /
          IH gets SYN-ACK.

         This is 2 host-to-host packets and 2 global DNS or DNS-like
         lookups.

   So Loc/ID split frequently, typically or perhaps always involves
   extra traffic and extra delays due to the lookups in one or two
   global query server systems - before the IH gets a response.

   There are workarounds for these problems.  The RH could send the
   SYN-ACK packet anyway, while waiting for the lookup of IH's
   Identifier - and then close or ignore the session if it found
   that the SYN packet's Locator did not match one of those returned
   by looking up the Identifier in that packet.  This is more complex
   and wasteful than waiting for the mapping lookup, but it is
   faster.

   CEE architectures typically require sending extra stuff with
   initial packets.  However, for those which put both the Identifier
   and Locator in the IPv6 address, there is no extra effort to
   communicate both the Identifier and Locator of the host which
   sent the packet.

   There may also be exchanges during the session when one host
   tells the other either that it has a new Locator, or that it
   is no longer using a Locator it previously told the other
   host about.  Also, one host may tell the other host to send
   packets to itself on another Locator from now on - either one
   which it had previously told the other host about, or perhaps
   another one.

   Such communications need to be securely protected, such as with
   a nonces which were exchanged during or shortly after the
   session establishment.  I have not shown this, or an initial
   exchange of Locators (those to be used, which are a subset of
   those to returned by DNS or the Identifier -> Locator mapping
   lookup) in the diagrams above.

   Without a nonce or some other form of protection, for any
   host-to-host message regarding the use of Locators outside the
   set returned from DNS or the mapping system, then an off-path
   attacker could  spoof such a request would be able to divert the
   session to his or her own host.  These extra exchanges of
   new Locators to use may need to be sent to many correspondent
   hosts, each of which has previously sent a different nonce during
   session establishment.  Perhaps these "new Locator(s)" messages
   can be sent in traffic packets - but most likely they need to be
   sent in special packets.  Furthermore, there needs to be an
   acknowledgement that the message has been received, with retries
   if no Ack arrives.

   For mobility in a CEE architecture, a Mobile Node (MN) which
   has just gained a new Locator (a new IP address) needs to tell
   all its correspondent hosts about this, and whether or not to
   start using it in preference to the currently used Locator.
   This may be done securely between the hosts, and there is
   typically a need for the mobile host to securely update its
   entry in the DNS and in whatever mapping system is used by
   hosts to securely determine the one or more Locators which a
   host with a given Identifier may be using.

   The burden of all this on a MN is heavy.  All these packets
   need to flow in and out of its links, while the link is
   likely to be busy with ordinary user traffic.  Any lost
   packets due to link congestion, or wireless reception
   problems, will slow down the process and burden the MN with
   waiting longer, sending more packets etc.

   With the TTR Mobility architecture - which is based on CES -
   the MN only needs to establish new tunnels to its one or
   more TTRs (Translating Tunnel Routers) which are usually
   nearby.  Corresponding hosts are unaware of the changed
   Locators, since they send packets to the MN's SPI address -
   and the ITRs tunnel these to the currently chosen TTR.

   So the CEE architecture always involves extra work for hosts
   and almost always further delays.

   Its bad enough having to depend more on global query server
   systems such as DNS, but it is worse having each session
   establishment typically involve two such lookups.

   Any delays or packet losses on the wireless link to a
   mobile node will make the whole process slower still.

> And I don't the the RG has a clear agreement on this at all.

Not yet.

We have just over four weeks to get this right - which involves going
against many years of widely held beliefs about the superiority of
Loc/ID separation.

Whether by accident or design, I think the current 2 layer IP naming
structure is the best.

  - Robin