tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8111

 
 
 

Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)

Part 2 of 2, p. 23 to 44
Prev Section

 


prevText      Top      ToC       Page 23 
8.  Pseudocode and Decision Tree Diagrams

   To illustrate the DDT algorithms described above and to aid in
   implementation, each of the major DDT Map-Server and DDT Map-Resolver
   functions are described below, first using simple "pseudocode" and
   then in the form of a decision tree.

8.1.  Map-Resolver Processing of ITR Map-Request

8.1.1.  Pseudocode Summary

    if ( request pending, i.e., (ITR,EID) of request same ) {
        replace old request with new, & use new request nonce
         for future requests
    } else if ( no match in refcache ) {
        return Negative Map-Reply to ITR
    } else if ( match type DELEGATION-HOLE ) {
        return Negative Map-Reply to ITR
    } else if ( match type MS-ACK ) {
        fwd DDT Map-Request to Map-Server
    } else {
        store & fwd DDT Map-Request w/o security material
         to node delegation
    }

Top      Up      ToC       Page 24 
8.1.2.  Decision Tree Diagram

   +------------+
   | Is request | Yes
   |  pending?  |----> Replace old request with
   |            |      new nonce for future requests
   +------------+
         |
         |No
         |
         V
   +------------+
   | Match in   | No
   | referral   |----> Send Negative Map-Reply
   | cache?     |      (not a likely event, as root or
   +------------+       hint configured on every Map-Resolver)
         |
         |Yes
         |
         V
   +-------------+
   | Match type  | Yes
   | DELEGATION- |----> Send Negative Map-Reply
   | HOLE?       |
   +-------------+
         |
         |No
         |
         V
   +------------+
   | Match type | Yes
   | MS-ACK?    |----> Forward DDT Map-Request to Map-Server
   |            |
   +------------+
         |
         |No
         |
         V
   Store original request & send DDT Map-Request w/o security material
    to DDT node delegation

Top      Up      ToC       Page 25 
8.2.  Map-Resolver Processing of Map-Referral Message

8.2.1.  Pseudocode Summary

      if ( authentication signature validation failed ) {
          silently drop
      }

      if ( no request pending matched by referral nonce ) {
          silently drop
      }

      if ( pfx in referral less specific than last referral used ) {
          if ( gone through root ) {
              silently drop
          } else {
              send request to root
          }
      }

      switch (map_referral_type) {

          case NOT_AUTHORITATIVE:
              if ( gone through root ) {
                  return Negative Map-Reply to ITR
              } else {
                  send request to root
              }

          case DELEGATION_HOLE:
              cache & send Negative Map-Reply to ITR

          case MS_REFERRAL:
              if ( referral equal to last used ) {
                  if ( gone through root ) {
                      return Negative Map-Reply to ITR
                  } else {
                      send request to root
                  }
              } else {
                  cache
                  follow the referral; include security material
              }

Top      Up      ToC       Page 26 
          case NODE_REFERRAL:
              if ( referral equal to last used ) {
                  if ( gone through root ) {
                      return Negative Map-Reply to ITR
                  } else {
                      send request to root
                  }
              } else {
                  cache
                  follow the referral; strip security material
              }

          case MS_ACK:
              if ( security material stripped ) {
                  resend request with security material
                  if { !incomplete } {
                      cache
                  }
              }

          case MS_NOT_REGISTERED:
              if { all Map-Server delegations not tried } {
                  follow delegations not tried
                  if ( !incomplete ) {
                      cache
                  }
              } else {
                  send Negative Map-Reply to ITR
                  if { !incomplete } {
                      cache
                  }
              }

          case DEFAULT:
              drop
          }
      }

Top      Up      ToC       Page 27 
8.2.2.  Decision Tree Diagram

                          +----------------+
                          | Auth signature | No
                          |     valid?     |----> Silently drop
                          +----------------+
                                  | Yes
                                  V
                            +------------+
                            | Is request | No
                            |  pending?  |----> Silently drop
                            +------------+
                                  | Yes
                                  V
                    +------------------------------+ Yes
                    | Pfx less specific than last? |----> Silently drop
                    +------------------------------+
                                  |No
                                  V
       +---------------------------------------------------+
       |             What is Map-Referral type?            |--Unknown-+
       +---------------------------------------------------+          |
         |        |         |       |         |          |            V
         |        |         |       |         |       DEL_HOLE      Drop
         |        |         |       |      MS_ACK        |
         |        |         |       |         |          V
         |        |     MS_REF   NODE_REF     |      Cache & return
         |        |         |       |         V      Negative Map-Reply
         |        |         |       |    +---------+
         |   NOT_AUTH       |       |    | Was sec | Yes
         |        |         |       |    | material|
         |        |         |       |    |stripped?|----> Done
         |        |         V       V    +---------+
         |        |       +------------+      | No
         |        |   Yes | Pfx equal  |      V
MS_NOT_REGISTERED |   +---| to last    |  +------------+
         |        |   |   | used?      |  |"Incomplete"| Yes
         |        |   |   +------------+  | bit set?   |---> Resend DDT
         |        V   V          |No      +------------+     request w/
         |  +------------+       |               |No         security
         |  |  Gone      |       V               |           material
         |  |  through   |   Cache & follow      V
         |  |  root?     |   the referral     Cache & resend DDT
         |  +------------+                    request with
         |    |No      |Yes                   security material
         |    |        |
         |    V        V

Top      Up      ToC       Page 28 
         |  Send req   Send Negative Map-Reply
         |  to root
         V
 +-----------+ Yes                       +------------+ Yes
 | Other MS  |---Follow other MS-------->|"Incomplete"|----> Don't cache
 | not tried?|                           | bit set?   |
 |           |--Send Negative Map-Reply->|            |----> Cache
 +-----------+ No                        +------------+ No

8.3.  DDT Node Processing of DDT Map-Request Message

8.3.1.  Pseudocode Summary

  if ( I am not authoritative ) {
      send Map-Referral NOT_AUTHORITATIVE with
       "Incomplete" bit set and TTL 0
  } else if ( delegation exists ) {
      if ( delegated Map-Servers ) {
          send Map-Referral MS_REFERRAL with
            TTL 'Default_DdtNode_Ttl'
      } else {
          send Map-Referral NODE_REFERRAL with
            TTL 'Default_DdtNode_Ttl'
      }
  } else {
      if ( EID in site) {
          if ( site registered ) {
              forward Map-Request to ETR
              if ( Map-Server peers configured ) {
                  send Map-Referral MS_ACK with
                   TTL 'Default_Registered_Ttl'
              } else {
                  send Map-Referral MS_ACK with
                   TTL 'Default_Registered_Ttl' and "Incomplete" bit set
              }
          } else {
              if ( Map-Server peers configured ) {
                  send Map-Referral MS_NOT_REGISTERED with
                   TTL 'Default_Configured_Not_Registered_Ttl'
              } else {
                  send Map-Referral MS_NOT_REGISTERED with
                   TTL 'Default_Configured_Not_Registered_Ttl'
                   and "Incomplete" bit set
              }
          }

Top      Up      ToC       Page 29 
      } else {
          send Map-Referral DELEGATION_HOLE with
           TTL 'Default_Negative_Referral_Ttl'
      }
  }

   where architectural constants for TTL are set as follows:

   Default_DdtNode_Ttl                      1440 minutes
   Default_Registered_Ttl                   1440 minutes
   Default_Negative_Referral_Ttl            15 minutes
   Default_Configured_Not_Registered_Ttl    1 minute

Top      Up      ToC       Page 30 
8.3.2.  Decision Tree Diagram

 +------------+
 |    Am I    | No
 |  authori-  |----> Return NOT_AUTHORITATIVE
 |   tative?  |       Incomplete = 1
 +------------+       TTL = Default_DdtNode_Ttl
       |
       |Yes
       |
       V
 +------------+     +-------------+
 | Delegation | Yes | Delegations | Yes
 |   exists?  |---->| are         |----> Return MS_REFERRAL
 |            |     | Map-Servers?|       TTL = Default_DdtNode_Ttl
 +------------+     +-------------+
       |                  \ No
       |No                 +--> Return NODE_REFERRAL
       |                        TTL = Default_DdtNode_Ttl
       V
 +------------+     +------------+                  +------------+
 | EID in     | Yes | Site       | Yes              | Map-Server |
 |  site      |---->| registered?|----> Forward---->| peers      |
 | config?    |     |            |      Map-Request | configured?|
 +------------+     +------------+      to ETR      +------------+
       |                |                           |        |
       |                |No                       No|        |Yes
       |                |                           |        |
       |                |                           V        V
       |                |                Return MS_ACK    Return MS_ACK
       |                V                with INC=1
       |         +------------+          TTL = Default_Registered_Ttl
       |         | Map-Server | Yes
       |         | peers      |----> Return MS_NOT_REGISTERED
       |         | configured?|      TTL = Default_Negative_Referral_Ttl
       |         +------------+
       |                \ No
       |No               +--> Return MS_NOT_REGISTERED
       |                      Incomplete = 1
       V                      TTL = Default_Negative_Referral_Ttl
 Return DELEGATION_HOLE
  TTL = Default_Negative_Referral_Ttl

Top      Up      ToC       Page 31 
9.  Example Topology and Request/Referral Following

   This section shows an example DDT tree and several possible scenarios
   of Map-Requests coming to a Map-Resolver and subsequent iterative DDT
   referrals.  In this example, RLOCs of DDT nodes are shown in the IPv4
   address space while the EIDs are in the IPv6 AF.  The same principle
   of hierarchical delegation and pinpointing referrals is equally
   applicable to any AF whose address hierarchy can be expressed as a
   bit string with associated length.  The DDT "tree" of IPv4 prefixes
   is another AF with immediate practical value.  This section could
   benefit from additional examples, perhaps including one using IPv4
   EIDs and another using IPv6 RLOCs.  If this document is moved to the
   Standards Track, consideration should be given to adding such
   examples.

Top      Up      ToC       Page 32 
   To show how referrals are followed to find the RLOCs for a number of
   EIDs, consider the following example EID topology for DBID=0, IID=0,
   AFI=2, and EID=0/0:

      +---------------------+  +---------------------+
      |  root1: 192.0.2.1   |  |  root2: 192.0.2.2   |
      | authoritative: ::/0 |  | authoritative: ::/0 |
      +---------------------+  +---------------------+
                 |         \   /        |
                 |          \ /         |
                 |           X          |
                 |          / \         |
                 |         /   \        |
                 |        |     |       |
                 V        V     V       V
  +-------------------------+  +--------------------------+
  |  DDT node1: 192.0.2.11  |  |  DDT node2: 192.0.2.12   |
  |      authoritative:     |  |      authoritative:      |
  |       2001:db8::/32     |  |       2001:db8::/32      |
  +-------------------------+  +--------------------------+
                 |         \   /        |
                 |          \ /         |
                 |           X          |
                 |          / \         |
                 |         /   \        |
                 |        |     |       |
                 V        V     V       V
 +--------------------------+  +---------------------------+
 | Map-Server1: 192.0.2.101 |  |  DDT node3: 192.0.2.201   |
 |      authoritative:      |  |      authoritative:       |
 |    2001:db8:0100::/40    |  |    2001:db8:0500::/40     |
 | site1: 2001:db8:0103::/48|  +---------------------------+
 | site2: 2001:db8:0104::/48|     |                    |
 +--------------------------+     |                    |
                                  |                    |
                                  |                    |
                                  V                    V
           +---------------------------+   +---------------------------+
           | Map-Server2: 192.0.2.211  |   | Map-Server3: 192.0.2.221  |
           |      authoritative:       |   |      authoritative:       |
           |    2001:db8:0500::/48     |   |    2001:db8:0501::/48     |
           |site3: 2001:db8:0500:1::/64|   |site5: 2001:db8:0501:8::/64|
           |site4: 2001:db8:0500:2::/64|   |site6: 2001:db8:0501:9::/64|
           +---------------------------+   +---------------------------+

   DDT nodes are configured for this "root" at IP addresses 192.0.2.1
   and 192.0.2.2.  DDT Map-Resolvers are configured with default
   referral cache entries for these addresses.

Top      Up      ToC       Page 33 
   The root DDT nodes delegate 2001:db8::/32 to two DDT nodes with IP
   addresses 192.0.2.11 and 192.0.2.12.

   The DDT nodes for 2001:db8::/32 delegate 2001:db8:0100::/40 to a DDT
   Map-Server with RLOC 192.0.2.101.

   The DDT Map-Server for 2001:db8:0100::/40 is configured to allow ETRs
   to register the sub-prefixes 2001:db8:0103::/48 and
   2001:db8:0104::/48.

   The DDT nodes for 2001:db8::/32 also delegate 2001:db8:0500::/40 to a
   DDT node with RLOC 192.0.2.201.

   The DDT node for 2001:db8:0500::/40 is further configured to delegate
   2001:db8:0500::/48 to a DDT Map-Server with RLOC 192.0.2.211 and
   2001:db8:0501::/48 to a DDT Map-Server with RLOC 192.0.2.221.

   The DDT Map-Server for 2001:db8:0500::/48 is configured to allow ETRs
   to register the sub-prefixes 2001:db8:0500:1::/64 and
   2001:db8:0500:2::/64.

   The DDT Map-Server for 2001:db8:0501::/48 is configured to allow ETRs
   to register the sub-prefixes 2001:db8:0501:8::/64 and
   2001:db8:0501:9::/64.

9.1.  Lookup of 2001:db8:0103:1::1/128

   The first example shows a DDT Map-Resolver following a delegation
   from the root to a DDT node followed by another delegation to a DDT
   Map-Server.

   ITR1 sends an Encapsulated Map-Request for 2001:db8:0103:1::1 to one
   of its configured (DDT) Map-Resolvers.  The DDT Map-Resolver proceeds
   as follows:

   1.  Send a DDT Map-Request (for 2001:db8:0103:1::1) to one of the
       root DDT nodes (192.0.2.1 or 192.0.2.2).

   2.  Receive (and save in the referral cache) the Map-Referral for
       EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set
       (192.0.2.11, 192.0.2.12).

   3.  Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.

   4.  Receive (and save in the referral cache) the Map-Referral for
       EID-prefix 2001:db8:0100::/40, action code MS-REFERRAL, RLOC set
       (192.0.2.101).

Top      Up      ToC       Page 34 
   5.  Send a DDT Map-Request to 192.0.2.101; if the ITR-originated
       Encapsulated Map-Request had a LISP-SEC signature, it is
       included.

   6.  The DDT Map-Server at 192.0.2.101 decapsulates the DDT
       Map-Request and forwards the Map-Request to a registered site1
       ETR for 2001:db8:0103::/48.

   7.  The DDT Map-Server at 192.0.2.101 sends a Map-Referral message
       for EID-prefix 2001:db8:0103::/48, action code MS-ACK, to the DDT
       Map-Resolver.

   8.  The DDT Map-Resolver receives the Map-Referral message and
       dequeues the pending request for 2001:db8:0103:1::1.

   9.  The site1 ETR for 2001:db8:0103::/48 receives the Map-Request
       forwarded by the DDT Map-Server and sends a Map-Reply to ITR1.

9.2.  Lookup of 2001:db8:0501:8:4::1/128

   The next example shows a three-level delegation: root to first DDT
   node, first DDT node to second DDT node, and second DDT node to DDT
   Map-Server.

   ITR2 sends an Encapsulated Map-Request for 2001:db8:0501:8:4::1 to
   one of its configured (DDT) Map-Resolvers, which are different from
   those for ITR1.  The DDT Map-Resolver proceeds as follows:

   1.   Send a DDT Map-Request (for 2001:db8:0501:8:4::1) to one of the
        root DDT nodes (192.0.2.1 or 192.0.2.2).

   2.   Receive (and save in the referral cache) the Map-Referral for
        EID-prefix 2001:db8::/32, action code NODE-REFERRAL, RLOC set
        (192.0.2.11, 192.0.2.12).

   3.   Send a DDT Map-Request to 192.0.2.11 or 192.0.2.12.

   4.   Receive (and save in the referral cache) the Map-Referral for
        EID-prefix 2001:db8:0500::/40, action code NODE-REFERRAL, RLOC
        set (192.0.2.201).

   5.   Send a DDT Map-Request to 192.0.2.201.

   6.   Receive (and save in the referral cache) the Map-Referral for
        EID-prefix 2001:db8:0501::/48, action code MS-REFERRAL, RLOC set
        (192.0.2.221).

Top      Up      ToC       Page 35 
   7.   Send a DDT Map-Request to 192.0.2.221; if the ITR-originated
        Encapsulated Map-Request had a LISP-SEC signature, it is
        included.

   8.   The DDT Map-Server at 192.0.2.221 decapsulates the DDT
        Map-Request and forwards the Map-Request to a registered site5
        ETR for 2001:db8:0501:8::/64.

   9.   The DDT Map-Server at 192.0.2.221 sends a Map-Referral message
        for EID-prefix 2001:db8:0501:8::/64, action code MS-ACK, to the
        DDT Map-Resolver.

   10.  The DDT Map-Resolver receives a Map-Referral(MS-ACK) message and
        dequeues the pending request for 2001:db8:0501:8:4::1.

   11.  The site5 ETR for 2001:db8:0501:8::/64 receives a Map-Request
        forwarded by the DDT Map-Server and sends a Map-Reply to ITR2.

9.3.  Lookup of 2001:db8:0104:2::2/128

   This example shows how a DDT Map-Resolver uses a saved referral cache
   entry to skip the referral process and go directly to a DDT
   Map-Server for a prefix that is similar to one previously requested.

   In this case, ITR1 uses the same Map-Resolver used in the example in
   Section 9.1.  It sends an Encapsulated Map-Request for
   2001:db8:0104:2::2 to that (DDT) Map-Resolver.  The DDT Map-Resolver
   finds an MS-REFERRAL cache entry for 2001:db8:0100::/40 with RLOC set
   (192.0.2.101) and proceeds as follows:

   1.  Send a DDT Map-Request (for 2001:db8:0104:2::2) to 192.0.2.101;
       if the ITR-originated Encapsulated Map-Request had a LISP-SEC
       signature, it is included.

   2.  The DDT Map-Server at 192.0.2.101 decapsulates the DDT
       Map-Request and forwards the Map-Request to a registered site2
       ETR for 2001:db8:0104::/48.

   3.  The DDT Map-Server at 192.0.2.101 sends a Map-Referral message
       for EID-prefix 2001:db8:0104::/48, action code MS-ACK, to the DDT
       Map-Resolver.

   4.  The DDT Map-Resolver receives the Map-Referral (MS-ACK) and
       dequeues the pending request for 2001:db8:0104:2::2.

   5.  The site2 ETR for 2001:db8:0104::/48 receives a Map-Request and
       sends a Map-Reply to ITR1.

Top      Up      ToC       Page 36 
9.4.  Lookup of 2001:db8:0500:2:4::1/128

   This example shows how a DDT Map-Resolver uses a saved referral cache
   entry to start the referral process at a non-root, intermediate DDT
   node for a prefix that is similar to one previously requested.

   In this case, ITR2 uses the same Map-Resolver used in the example in
   Section 9.2.  It sends an Encapsulated Map-Request for
   2001:db8:0500:2:4::1 to that (DDT) Map-Resolver, which finds a
   NODE-REFERRAL cache entry for 2001:db8:0500::/40 with RLOC set
   (192.0.2.201).  It proceeds as follows:

   1.  Send a DDT Map-Request (for 2001:db8:0500:2:4::1) to 192.0.2.201.

   2.  Receive (and save in the referral cache) the Map-Referral for
       EID-prefix 2001:db8:0500::/48, action code MS-REFERRAL, RLOC set
       (192.0.2.211).

   3.  Send a DDT Map-Request to 192.0.2.211; if the ITR-originated
       Encapsulated Map-Request had a LISP-SEC signature, it is
       included.

   4.  The DDT Map-Server at 192.0.2.211 decapsulates the DDT
       Map-Request and forwards the Map-Request to a registered site4
       ETR for 2001:db8:0500:2::/64.

   5.  The DDT Map-Server at 192.0.2.211 sends a Map-Referral message
       for EID-prefix 2001:db8:0500:2::/64, action code MS-ACK, to the
       DDT Map-Resolver.

   6.  The DDT Map-Resolver receives the Map-Referral (MS-ACK) and
       dequeues the pending request for 2001:db8:0500:2:4::1.

   7.  The site4 ETR for 2001:db8:0500:2::/64 receives a Map-Request and
       sends a Map-Reply to ITR2.

Top      Up      ToC       Page 37 
9.5.  Lookup of 2001:db8:0500::1/128 (Nonexistent EID)

   This example uses the cached MS-REFERRAL for 2001:db8:0500::/48
   learned above to start the lookup process at the DDT Map-Server at
   192.0.2.211.  The DDT Map-Resolver proceeds as follows:

   1.  Send a DDT Map-Request (for 2001:db8:0500::1) to 192.0.2.211; if
       the ITR-originated Encapsulated Map-Request had a LISP-SEC
       signature, it is included.

   2.  The DDT Map-Server at 192.0.2.211, which is authoritative for
       2001:db8:0500::/48, does not have a matching delegation for
       2001:db8:0500::1.  It responds with a Map-Referral message for
       2001:db8:0500::/64, action code DELEGATION-HOLE, to the DDT
       Map-Resolver.  The prefix 2001:db8:0500::/64 is used because it
       is the least-specific prefix that does match the requested EID
       but does not match one of the configured delegations
       (2001:db8:0500:1::/64 and 2001:db8:0500:2::/64).

   3.  The DDT Map-Resolver receives the delegation, adds a negative
       referral cache entry for 2001:db8:0500::/64, dequeues the pending
       request for 2001:db8:0500::1, and returns a Negative Map-Reply
       to ITR2.

10.  Securing the Database and Message Exchanges

   This section specifies the DDT security architecture that provides
   data origin authentication, data integrity protection, and
   XEID-prefix delegation.  Global XEID-prefix authorization is out of
   scope for this document.

   Each DDT node is configured with one or more public/private key pairs
   that are used to digitally sign Map-Referral Records for
   XEID-prefix(es) for which the DDT node is authoritative.  In other
   words, each public/private key pair is associated with the
   combination of a DDT node and an XEID-prefix for which it is
   authoritative.  Every DDT node is also configured with the public
   keys of its child DDT nodes.  By including the public keys of target
   child DDT nodes in the Map-Referral Records and signing each Record
   with the DDT node's private key, a DDT node can securely delegate
   sub-prefixes of its authoritative XEID-prefixes to its child DDT
   nodes.  A DDT node configured to provide hints must also have the
   public keys of the DDT nodes to which its hints point.  DDT node keys
   can be encoded using LCAF Type 11 to associate the key to the RLOC of
   the referred DDT node.  If a node has more than one public key, it
   should sign its Records with at least one of these keys.  When a node
   has N keys, it can sustain up to N-1 key compromises.  The revocation
   mechanism is described in Section 10.2.1.

Top      Up      ToC       Page 38 
   Map-Resolvers are configured with one or more trusted public keys,
   referred to as "trust anchors".  Trust anchors are used to
   authenticate the DDT security infrastructure.  Map-Resolvers can
   discover a DDT node's public key by either (1) having it configured
   as a trust anchor or (2) obtaining it from the node's parent as part
   of a signed Map-Referral.  When a public key is obtained from a
   node's parent, it is considered trusted if it is signed by a trust
   anchor or if it is signed by a key that was previously trusted.
   Typically, in a Map-Resolver, the root DDT node's public keys should
   be configured as trust anchors.  Once a Map-Resolver authenticates a
   public key, it locally caches the key along with the associated DDT
   node RLOC and XEID-prefix for future use.

10.1.  XEID-Prefix Delegation

   In order to delegate XEID sub-prefixes to its child DDT nodes, a
   parent DDT node signs its Map-Referrals.  Every signed Map-Referral
   MUST also include the public keys associated with each child DDT
   node.  Such a signature indicates that the parent DDT node is
   delegating the specified XEID-prefix to a given child DDT node.  The
   signature is also authenticating the public keys associated with the
   child DDT nodes, and authorizing them to be used by the child DDT
   nodes, to provide origin authentication and integrity protection for
   further delegations and mapping information of the XEID-prefix
   allocated to the DDT node.

   As a result, for a given XEID-prefix, a Map-Resolver can form an
   authentication chain from a configured trust anchor (typically the
   root DDT node) to the leaf nodes (Map-Servers).  Map-Resolvers
   leverage this authentication chain to verify the Map-Referral
   signatures while walking the DDT tree until they reach a Map-Server
   authoritative for the given XEID-prefix.

10.2.  DDT Node Operation

   Upon receiving a Map-Request, the DDT node responds with a
   Map-Referral as specified in Section 7.  For every Record present in
   the Map-Referral, the DDT node also includes the public keys
   associated with the Record's XEID-prefix and the RLOCs of the child
   DDT nodes.  Each Record contained in the Map-Referral is signed using
   the DDT node's private key.

10.2.1.  DDT Public Key Revocation

   The node that owns a public key can also revoke that public key.  For
   instance, if a parent DDT node advertises a public key for one of its
   child DDT nodes, the child DDT node can at a later time revoke that
   key.  Since DDT nodes do not keep track of the Map-Resolvers that

Top      Up      ToC       Page 39 
   query them, revocation is done in a pull model, where the
   Map-Resolver is informed of the revocation of a key only when it
   queries the node that owns that key.  If the parent DDT node is
   configured to advertise that key, the parent DDT node must also be
   signaled to remove the key from the Records it advertises for the
   child DDT node; this is necessary to avoid further distribution of
   the revoked key.

   To securely revoke a key, the DDT node creates a new Record for the
   associated XEID-prefix and locator, including the revoked key with
   the R bit set.  (See Section 4.7 of [RFC8060] for details regarding
   the R bit.)  The DDT node must also include a signature in the Record
   that covers this Record; this is computed using the private key
   corresponding to the key being revoked.  Such a Record is termed a
   "revocation record".  By including this Record in its Map-Referrals,
   the DDT node informs querying Map-Resolvers about the revoked key.  A
   digital signature computed with a revoked key can only be used to
   authenticate the revocation and SHOULD NOT be used to validate any
   data.  To prevent a compromised key from revoking other valid keys, a
   given key can only be used to sign a revocation for that specific
   key; it cannot be used to revoke other keys.  This prevents the use
   of a compromised key to revoke other valid keys as described in
   [RFC5011].  A revocation record MUST be advertised for a period of
   time equal to or greater than the TTL value of the Record that
   initially advertised the key, starting from the time that the
   advertisement of the key was stopped by removal from the parent
   DDT node.

10.3.  Map-Server Operation

   Similar to a DDT node, a Map-Server is configured with one or more
   public/private key pairs that it must use to sign Map-Referrals.

   However, unlike DDT nodes, Map-Servers do not delegate prefixes and
   as a result do not need to include keys in the Map-Referrals they
   generate.

10.4.  Map-Resolver Operation

   Upon receiving a Map-Referral, the Map-Resolver MUST first verify the
   signature(s) by using either a trust anchor or a previously
   authenticated public key associated with the DDT node sending the
   Map-Referral.  If multiple authenticated keys are associated with the
   DDT node sending this Map-Referral, the Key Tag field (Section 6.4.1)
   of the signature can be used to select the correct public key for
   verifying the signature.  If the key tag matches more than one key
   associated with that DDT node, the Map-Resolver MUST try to verify
   the signature with all matching keys.  For every matching key that is

Top      Up      ToC       Page 40 
   found, the Map-Resolver MUST also verify that the key is
   authoritative for the XEID-prefix in the Map-Referral Record.  If
   such a key is found, the Map-Resolver MUST use it to verify the
   associated signature in the Record.  If (1) no matching key is found,
   (2) none of the matching keys is authoritative for the XEID-prefix in
   the Map-Referral Record, or (3) such a key is found but the signature
   is not valid, the Map-Referral Record is considered corrupted and
   MUST be discarded.  This may be due to expired keys.  The
   Map-Resolver MAY try other siblings of this node if there is an
   alternate node that is authoritative for the same prefix.  If not,
   the Map-Resolver CAN query the DDT node's parent to retrieve a valid
   key.  It is good practice to use a counter or timer to avoid
   repeating this process if the Map-Resolver cannot verify the
   signature after several attempts.

   Once the signature is verified, the Map-Resolver has verified the
   XEID-prefix delegation in the Map-Referral.  This also means that
   public keys of the child DDT nodes were authenticated; the
   Map-Resolver must add these keys to the authenticated keys associated
   with each child DDT node and XEID-prefix.  These keys are considered
   valid for the duration specified in the Record's TTL field.

11.  Open Issues and Considerations

   There are a number of issues with the organization of the mapping
   database that need further investigation.  Among these are:

   o  Defining an interface to implement interconnection and/or
      interoperability with other mapping databases, such as LISP+ALT.

   o  Additional key structures for use with LISP-DDT, such as key
      structures to support additional EID formats as defined in
      [RFC8060].

   o  Management of the DDT Map-Resolver referral cache -- in
      particular, detecting and removing outdated entries.

   o  Best practices for either configuring hint referrals or avoiding
      their use.

   Operational experience will help answer open questions surrounding
   these and other issues.

Top      Up      ToC       Page 41 
12.  IANA Considerations

   IANA has made the following early assignment per this document:

   o  Message type 6, "LISP DDT Map-Referral", was added to the
      "LISP Packet Types" registry.  See Section 6.4 ("Map-Referral
      Message Format").

   As this document is an Experimental RFC, this is an early allocation
   as per [RFC7120].

13.  Security Considerations

   Section 10 describes a DDT security architecture that provides data
   origin authentication, data integrity protection, and XEID-prefix
   delegation within the DDT infrastructure.

   Global XEID-prefix authorization is beyond the scope of this
   document, but the Secure Inter-Domain Routing (SIDR) working group
   [RFC6480] is developing an infrastructure to support improved
   security of Internet routing.  Further work is required to determine
   if SIDR's Public Key Infrastructure (PKI) and the distributed
   repository system it uses for storing and disseminating PKI data
   objects may also be used by DDT devices to verifiably assert that
   they are the legitimate holders of a set of XEID-prefixes.

   This document specifies how DDT security and LISP-SEC [LISP-SEC]
   complement one another to secure the DDT infrastructure, Map-Referral
   messages, and the Map-Request/Map-Reply protocols.  In the future,
   other LISP security mechanisms may be developed to replace LISP-SEC.
   Such future security mechanisms should describe how they can be used
   together with LISP-DDT to provide similar levels of protection.

   LISP-SEC can use the DDT public-key infrastructure to secure the
   transport of LISP-SEC key material (the One-Time Key) from a
   Map-Resolver to the corresponding Map-Server.  For this reason, when
   LISP-SEC is deployed in conjunction with a LISP-DDT mapping database
   and the path between the Map-Resolver and Map-Server needs to be
   protected, DDT security as described in Section 10 should be enabled
   as well.

Top      Up      ToC       Page 42 
14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              DOI 10.17487/RFC6830, January 2013,
              <http://www.rfc-editor.org/info/rfc6830>.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              DOI 10.17487/RFC6833, January 2013,
              <http://www.rfc-editor.org/info/rfc6833>.

   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120,
              January 2014, <http://www.rfc-editor.org/info/rfc7120>.

   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
              "PKCS #1: RSA Cryptography Specifications Version 2.2",
              RFC 8017, DOI 10.17487/RFC8017, November 2016,
              <http://www.rfc-editor.org/info/rfc8017>.

   [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
              February 2017, <http://www.rfc-editor.org/info/rfc8060>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <http://www.rfc-editor.org/info/rfc8174>.

Top      Up      ToC       Page 43 
14.2.  Informative References

   [AFI]      IANA, "Address Family Numbers",
              <http://www.iana.org/assignments/address-family-numbers/>.

   [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
              "LISP-Security (LISP-SEC)", Work in Progress,
              draft-ietf-lisp-sec-12, November 2016.

   [LISP-TREE]
              Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
              and O. Bonaventure, "LISP-TREE: a DNS Hierarchy to Support
              the LISP Mapping System", IEEE Journal on Selected Areas
              in Communications, Volume 28, Issue 8,
              DOI 10.1109/JSAC.2010.101011, September 2010,
              <http://ieeexplore.ieee.org/xpls/
              abs_all.jsp?arnumber=5586446>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
              September 2007, <http://www.rfc-editor.org/info/rfc5011>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <http://www.rfc-editor.org/info/rfc6480>.

   [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
              January 2013, <http://www.rfc-editor.org/info/rfc6836>.

   [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
              Routing Locator (RLOC) Database", RFC 6837,
              DOI 10.17487/RFC6837, January 2013,
              <http://www.rfc-editor.org/info/rfc6837>.

Top      Up      ToC       Page 44 
Acknowledgments

   The authors would like to express their thanks to Lorand Jakab,
   Albert Cabellos, Florin Coras, Damien Saucez, and Olivier Bonaventure
   for their work on LISP-TREE [LISP-TREE] and LISP iterable mappings
   that inspired the hierarchical database structure and lookup
   iteration approach described in this document.  Thanks also go to
   Dino Farinacci and Isidor Kouvelas for their implementation work; to
   Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for
   work on security processing; and to Job Snijders, Glen Wiley, Neel
   Goyal, and Mike Gibbs for work on operational considerations and
   initial deployment of a prototype database infrastructure.  Special
   thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa, all of
   whom have participated in (and put up with) seemingly endless hours
   of discussion of mapping database ideas, concepts, and issues.

Authors' Addresses

   Vince Fuller
   VAF.NET Internet Consulting

   Email: vince.fuller@gmail.com


   Darrel Lewis
   Cisco Systems

   Email: darlewis@cisco.com


   Vina Ermagan
   Cisco Systems

   Email: vermagan@cisco.com


   Amit Jain
   Juniper Networks

   Email: atjain@juniper.net


   Anton Smirnov
   Cisco Systems

   Email: as@cisco.com