Internet DRAFT - draft-saucez-lisp-iterable-mapping

draft-saucez-lisp-iterable-mapping






Network Working Group                                          D. Saucez
Internet-Draft                                            O. Bonaventure
Intended status: Informational          Universite catholique de Louvain
Expires: October 23, 2011                                 April 21, 2011


                         LISP Iterable Mappings
                 draft-saucez-lisp-iterable-mapping-02

Abstract

   The Mapping System is a key component of the Locator Identifier
   Separation Protocol (LISP).  In this document, we describe Iterable
   Mappings allowing the mappings to point to Map-Server addresses
   instead of ETR addresses.  Iterable mappings open the possibility of
   performing iterative queries that could be used to deploy mapping
   systems without requiring overlays or to optimize current mapping
   systems.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 23, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Saucez & Bonaventure    Expires October 23, 2011                [Page 1]

Internet-Draft           LISP Iterable Mappings               April 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Additional LISP Packet Type Allocation . . . . . . . . . . . .  7
   3.  Extension to Map-Request Message Format  . . . . . . . . . . .  7
   4.  Iterable-Mapping Message Format  . . . . . . . . . . . . . . .  8
   5.  Message Processing . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Map-Server Deployment and Adaptations  . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   10. Informative References . . . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11






















Saucez & Bonaventure    Expires October 23, 2011                [Page 2]

Internet-Draft           LISP Iterable Mappings               April 2011


1.  Introduction

   LISP Mapping systems can be decomposed in three components: the
   querier, the resolver and the server.  First, the querier initiates a
   request for a mapping resolution by querying a resolver.  Second, the
   resolver sends a Map-Request to a server.  Third, the server returns
   a Map-Reply containing the mapping to the resolver.  The Map-Reply
   gives the mapping for the identifier present in the Map-Request.
   Finally, the resolver can return the mapping to the requester.
   Depending on the mapping system, there can exist intermediate
   elements between the resolver and the server.  It is also possible to
   have redundant resolvers or servers.

   When the querier is not able to send the Map-Request directly to a
   server that can provide a mapping for the identifier in the request,
   the Map-Request must be transmitted to intermediate elements.  Three
   options can be followed to transmit Map-Request when going through
   intermediate elements:

   o  Forwardable queries: when an intermediate element receives a Map-
      Request, it transmits it as-is to another intermediate element
      that, at its turn, transmits the Map-Request to another
      intermediate element and so on until the Map-Request can be
      transmitted to the server.

   o  Recursive queries: when an intermediate element receives a Map-
      Request, it interprets the Map-Request and acts as a resolver.  It
      then generates a new Map-Request and sends it to another
      intermediate element, and so on until the server is reached.

   o  Iterative queries: when an intermediate element receives a Map-
      Request, it sends back the address of the next intermediate
      element to the resolver.  The resolver then sends the Map-Request
      to this other intermediate element until a server is reached.

   A mapping system working with forwardable queries can be seen as a
   routing overlay.  The intermediate elements are overlay routers that
   forward Map-Request messages step by step on the overlay to reach a
   server that can provide a mapping for the identifier in the Map-
   Request.  LISP+ALT [I-D.ietf-lisp-alt] is an example of such mapping
   system.

   The figure below presents an example of messages exchanged in LISP+
   ALT.  In LISP+ALT, the ITRs are at the same time the queriers and the
   resolvers (an ITR is its own resolver).  Labels postfixed by a ?
   represent Map-Requests and those postfixed with a ! are the Map-
   Replies.  Intermediate elements are operated by ALT routers (depicted
   as ALTx in the figure) and the server role is supported by the ETRs.



Saucez & Bonaventure    Expires October 23, 2011                [Page 3]

Internet-Draft           LISP Iterable Mappings               April 2011


   The figure shows that messages are sent step-by-step through the ALT
   routers until an ETR that can return a mapping is reached.  The ETR
   directly returns the mapping to the ITR without traversing the ALT
   routers.  We can see that troubleshoot a problem occurring at an ALT
   router is an issue for the ITR as it does not control the ALT routers
   the Map-Request traverses.  In addition, the ITRs do not even know
   the ALT routers that are traversed.

                                                                      e
                                                                     +
       1.(ITR, e)?             2.(ITR,e)?            3.(ITR,e)?     +
ITR ---------------> ALT1 ----------------> ALT2 --------------->ETR --.
 ^                                                                     |
 |                               4.(R,e)!                              |
 `<--------------------------------------------------------------------'

LEGEND: (x,e)?: Map-Request sent by x for EID e
        (x,e)!: Map-Reply sent to x with the mapping for EID e
        ALTx: ALT router

    Figure 1: Example of message exchanged in a forwarding mode mapping
                         system: the LISP+ALT case

   The operation of mapping systems working in recursive mode can be
   abstracted as a directed graph of resolvers, each node being a
   resolver for its predecessor.  The figure below shows that when an
   intermediate element receives a Map-Request, it originates a new Map-
   Request for the same EID.  When the server receives the request, it
   replies to the intermediate element that, at its turn can return a
   reply to the node that it receives a request from and so on until the
   mapping arrives the resolver.  In the figure, we omitted the
   requester to start directly at the resolver (R).

                                                            e
                                                           +
       1.(R,e)?          2.(I1,e)?          3.(I2,e)?     +
   R -------------> I1 --------------> I2 -------------> ETR --.
   ^                |^                 |^                      |
   |    6.(R,e)!    ||    5.(I1,e)!    ||     4.(I2,e)!        |
   `<---------------'`<----------------'`<---------------------'

   LEGEND: (x,e)?: Map-Request sent by x for EID e
           (x,e)!: Map-Reply sent to x with the mapping for EID e
           R: resolver
           Ix: intermediate element x

   Figure 2: Example of message exchanged in a recursive mapping system




Saucez & Bonaventure    Expires October 23, 2011                [Page 4]

Internet-Draft           LISP Iterable Mappings               April 2011


   In mapping systems operating in iterative mode, the intermediate
   elements do not exchange requests among themselves.  As presented in
   the figure below, when an intermediate element receives a request, it
   replies with the address of another intermediate element that can
   potentially provide the mapping (labels postfixed with a @).  When
   the resolver receives this address, it sends it a Map-Request for the
   identifier.  This operation is repeated until a server is reached.
   At a first glance, the iterative mode is the option that is likely to
   present the longer delay.  However, the resolver can cache the
   intermediate elements and servers and for any subsequent Map-Request,
   it can directly contact the server or intermediate element close to
   the server.


   .----.                                                       e
   |    |                                                      +
   |    \/   1.(R,e)?                                         +
   |  ,.R -------------> I1                 I2              ETR-.
   |  |^|^               |                  ^|                ^ |
   |  ||||   2(e,I2)@    |                  ||                | |
   |  |||`<--------------'    3.(R,e)?      ||                | |
   |  ||`-----------------------------------'|                | |
   |  ||                                     |                | |
   |  ||             4.(e,S)@                |                | |
   |  |`<------------------------------------'    5.(R,e)?    | |
   |  `------------------------------------------------------>' |
   |                                                            |
   |                          6.(R,e)!                          |
   `<-----------------------------------------------------------'

   LEGEND: (x,e)?: Map-Request sent by x for EID e
           (x,e)!: Map-Reply sent to x with the mapping for EID e
           (e,x)@: the Map-Request for EID e has to be sent to x
           R: resolver
           Ix: intermediate element

      Figure 3: Example of messages exchanged in an iterative mapping
                                  system

   An advantage of using the iterative mode is for the troubleshooting.
   The figure below presents a case where the intermediate element I2 is
   replicated with intermediate element I2'.  The resolver first tries
   to contact I2, but as no answer arrives within a given time frame, it
   contacts the replicas I2' instead.  Similar troubleshooting exists in
   recursive mode but the recovery is done locally at the intermediate
   element suppressing any control from the resolver.  In forwarding
   mode, and particularly in LISP+ALT, the troubleshooting is performed
   locally but relies on the routing layer.  Therefore, if an



Saucez & Bonaventure    Expires October 23, 2011                [Page 5]

Internet-Draft           LISP Iterable Mappings               April 2011


   intermediate element is overloaded but present on the network, i.e.,
   the routing layer does not detect any failure, requests will continue
   to be forwarded to the overloaded intermediate element.


  .----.                                                      e
  |    |                                                     +
  |    \/      1.(R,e)?                                     +
  | ,,.R ----------------> I1              I2         I2' ETR-.
  | ||||^                   |                         ^|    | |
  | |||||   2(e,[I2,I2'])@  |              X          ||    | |
  | ||||`<------------------'    3.(R,e)?  |          ||    | |
  | |||`---------------------------------->'          ||    | |
  | |||                                               ||    | |
  | |||                  4.(R,e)?                     ||    | |
  | ||`---------------------------------------------->'|    | |
  | ||                                                 |    | |
  | ||                   5.(e,S)@                      |    | |
  | ||`<-----------------------------------------------'    | |
  | |                                                       | |
  | |                         6.(R,e)?                      | |
  |  `----------------------------------------------------->' |
  |                                                           |
  |                          7.(R,e)!                         |
  `<----------------------------------------------------------'

  LEGEND: (x,e)?: Map-Request sent by x for EID e
          (x,e)!: Map-Reply sent to x with the mapping for EID e
          (e,[x,y])@: the Map-Request for EID e has to be sent to x or y
          R: resolver
          Ix: intermediate node

   Figure 4: Intermediate node failure troubleshooting example with the
                              iterative mode

   The analogy can be done with DNS that supports both iterative and
   recursive modes.  Experience with the DNS on the Internet showed that
   using redundant servers coupled with iterative mode has been key in
   handling various types of failures.

   This memo presents the new Iterable-Mapping LISP message.  We also
   propose a one bit modification of the Map-Request for supporting the
   iterative mode.  Because of security and scalability issues, we do
   not discuss the recursive mode even if it could be implemented by
   using our solution.






Saucez & Bonaventure    Expires October 23, 2011                [Page 6]

Internet-Draft           LISP Iterable Mappings               April 2011


2.  Additional LISP Packet Type Allocation

   Mappings, as defined in the LISP specifications [I-D.ietf-lisp],
   associate locator lists to EID prefixes.  To associate Map-Server
   addresses to EID, we propose a new LISP control plane message: the
   LISP Iterable-Mapping.  We suggest the following type allocation:

   LISP Iterable-Reply:        5    b'0101'


3.  Extension to Map-Request Message Format

   To support iterable mappings, we propose to add the I-bit flag in the
   Map-Request message.  When this bit is at 1, the ITR (or the Map-
   Resolver) indicates that it accepts iterable mappings.  If the I-bit
   is at zero, the ITR (or the Map-Resolver) does not accept iterable
   mappings meaning that the only acceptable answer to the request is a
   Map-Reply.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=1 |A|M|P|S|I|     Reserved      |   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Saucez & Bonaventure    Expires October 23, 2011                [Page 7]

Internet-Draft           LISP Iterable Mappings               April 2011


4.  Iterable-Mapping Message Format


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=5 |               Reserved                | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
  +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    |                          Record  TTL                          |
  |    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  R    | Locator Count | EID mask-len  |            EID-AFI            |
  e    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  c    |                          EID-prefix                           |
  o    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  r L--|           Unused Flags        |           Loc-AFI             |
  d o  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | c--|                             Locator                           |
  +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

      Type: 5 (Iterable-Reply)

      Reserved: Set to 0 on transmission and ignored on receipt.

      Record Count: The number of records in this reply message.  A
      record is comprised of that portion of the packet labeled 'Record'
      above and occurs the number of times equal to Record count.

      Nonce: A 64-bit value from the Map-Request is echoed in this Nonce
      field of the Map-Reply.

      Record TTL: The time in minutes the recipient of the Iterable-
      Mapping will store the mapping.  If the TTL is 0, the entry SHOULD
      be removed from the cache immediately.  If the value is
      0xffffffff, the recipient can decide locally how long to store the
      mapping.

      Locator Count: The number of Locator entries.  A locator entry
      comprises what is labeled above as 'Loc'.  The locator count can
      be 0 indicating there are no locators for the EID-prefix.
      Locators are Map-Server addresses.





Saucez & Bonaventure    Expires October 23, 2011                [Page 8]

Internet-Draft           LISP Iterable Mappings               April 2011


      EID mask-len: Mask length for EID prefix.

      EID-AFI: Address family of EID-prefix according to [RFC5226].

      EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
      address-family.

      Loc-AFI: Address family of locator according to [RFC5226].

      Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI'
      field) assigned to a Map-Server.


5.  Message Processing

   When an ITR (or a Map-Resolver) needs to retrieve a Mapping for an
   EID, it sends a Map-Request as specified in the LISP specifications
   [I-D.ietf-lisp].  If the ITR (or Map-Resolver) desires to operate in
   the iterable mode, it sends the Map-Request with the I-bit set to
   one.  When the Map-Request is processed, two possible replies are
   possible, either a Map-Reply or an Iterable-Mapping.  A Map-Reply is
   returned if the node that processed the Map-Request has a mapping for
   the EID in the Map-Request.  If the node knows a list of Map-Servers
   associated to the requested EID, an Iterable-Mapping is returned.
   When an Iterable-Mapping arrives the ITR (or Map-Resolver), it
   extracts one locator.  The ITR (or Map-Resolver) then sends a Map-
   Request to the selected Map-Server and follows the same procedure
   until a Map-Reply is received.  To speed-up further requests, the ITR
   (or Map-Resolver) can cache the Iterable-Mappings.  It is also
   possible to imagine the ITR (or Map-Resolver) to send the Map-Request
   to several Map-Server in parallel.


6.  Map-Server Deployment and Adaptations

   With the iterable mappings, it is no longer required to have an
   overlay deployed to ensure the forwarding.  Indeed, one could imagine
   to have a hierarchy of Map-Server exclusively storing iterable
   mappings that eventually point to ETRs.  Such a general tree-based
   deployment of EID is presented in LISP-TREE [lisptree]

   Deploying a mapping system in iterative mode does not require to
   maintain an overlay with its tunnels (e.g., GRE) and routing scheme
   (e.g., BGP) making it more flexible, simple and cost effective than
   LISP+ALT.






Saucez & Bonaventure    Expires October 23, 2011                [Page 9]

Internet-Draft           LISP Iterable Mappings               April 2011


7.  Security Considerations

   An attacker controlling a Map-Server can provide an iterable mapping
   pointing to a less specific EID that it should and thus control the
   mapping to reply for EIDs it is not responsible for.  This problem is
   a variation of the same case for "normal" mappings.  Globally, the
   security issues are not different than those presented in
   [I-D.saucez-lisp-security].


8.  Conclusion

   This draft presents the iterable mappings that, at the contrary of
   "normal" mappings, do not point to ETR RLOCs but to Map-Server RLOCs.
   The existence of such pointers to Map-Server permit to deploy mapping
   system relying on iterative querying of Map-Requests.  The iterative
   way of querying the mapping system helps in troubleshooting mapping
   system failures and can be used to optimize current mapping systems.


9.  Acknowledgments

   This work is partially funded by the European Commission funded ECODE
   ICT- 223936 project.


10.  Informative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-08 (work in progress), August 2010.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-04
              (work in progress), April 2010.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-05 (work in progress), April 2010.

   [I-D.saucez-lisp-security]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP
              Security Threats", draft-saucez-lisp-security-02 (work in
              progress), January 2011.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an



Saucez & Bonaventure    Expires October 23, 2011               [Page 10]

Internet-Draft           LISP Iterable Mappings               April 2011


              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [lisptree]
              Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
              and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support
              the LISP Mapping System.", JSAC 2010, October 2010.


Authors' Addresses

   Damien Saucez
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain-la-Neuve,   B-1348
   Belgium

   Email: damien.saucez@uclouvain.be
   URI:   http://inl.info.ucl.ac.be


   Olivier Bonaventure
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain-la-Neuve,   B-1348
   Belgium

   Email: olivier.bonaventure@uclouvain.be
   URI:   http://inl.info.ucl.ac.be






















Saucez & Bonaventure    Expires October 23, 2011               [Page 11]