[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                         L. Iannone
Internet-Draft                              TU Berlin - Deutsche Telekom
Intended status: Experimental                            Laboratories AG
Expires: September 4, 2009                                     D. Saucez
                                                          O. Bonaventure
                                        Universite catholique de Louvain
                                                           March 3, 2009


                        LISP Mapping Versioning
              draft-iannone-lisp-mapping-versioning-00.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 4, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Iannone, et al.         Expires September 4, 2009               [Page 1]


Internet-Draft           LISP Mapping Versioning              March 2009


Abstract

   The present document sketches an alternative approach to provide
   information about changes to EID-to-RLOC mappings in the context of
   LISP.  The proposed approach is based on a versioning system for the
   EID-to-RLOC mapping itself.  When there is a change in the mapping
   (where change could mean adding/removing an RLOC or just a
   modification in the priority or weight of one or more RLOCs) a new
   version number is generated and propagated in the LISP data packet.
   In the LISP context, ETRs do not keep state that allows to know when
   an ITR changes a mapping.  The versioning system is a data-driven
   mechanism to annonce those changes.

   In order to support such an approach, the LISP encapsulation need to
   be modified.  In particular LISP-encapsulated data packets have to
   contain the version number of the mapings used to select the RLOCs in
   the outer header.  These version numbers are contained in a "new"
   LISP header.

   The mappings are distributed as usual through the mapping
   distribution system (e.g., CONS, ALT); versioning is only a mean to
   announce that something has changed in the mapping.  The
   infrastructure built by each specific mapping protocol does not
   change anyhow.  Nevertheless, two modifications are needed.  The
   first modification consist in including version number in the Map-
   Reply messages.  The second modification consist in the introduction
   of a new message, the "Map-Update-Notification" message used by ETRs
   to notify ITRs that the mapping used to encapsulate the packet is old
   and needs to be updated.  This message does not contain the mapping,
   it just suggests ITRs to perform a Map-Request in order to retrieve
   the updated mapping.




















Iannone, et al.         Expires September 4, 2009               [Page 2]


Internet-Draft           LISP Mapping Versioning              March 2009


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  EID-to-RLOC Mapping Version Number . . . . . . . . . . . . . .  7
   4.  Version Numbers wrap-around  . . . . . . . . . . . . . . . . .  8
   5.  Dealing with Version Numbers . . . . . . . . . . . . . . . . .  9
     5.1.  Handling Destination Mapping Version Number  . . . . . . .  9
     5.2.  Handling Source Mapping Version Number . . . . . . . . . . 10
   6.  Proposed changes to the LISP header  . . . . . . . . . . . . . 12
   7.  Proposed changes to the Map-Reply Packet format  . . . . . . . 14
   8.  Map-Update-Notification Message  . . . . . . . . . . . . . . . 15
   9.  Further Observations . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Mapping Versioning and RLOCs reachability  . . . . . . . . 16
     9.2.  Mapping Versioning to simplify LISP implementation . . . . 16
     9.3.  Mapping Versioning and original LISP cohexistence  . . . . 17
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
     10.1. Robustness against reachability information spoofing.  . . 18
     10.2. Robustness against traffic disruption  . . . . . . . . . . 18
     10.3. Robustness of the Map-Update-Notification message  . . . . 18
     10.4. About robusteness of Reachability bits . . . . . . . . . . 19
   11. Aknoledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22

























Iannone, et al.         Expires September 4, 2009               [Page 3]


Internet-Draft           LISP Mapping Versioning              March 2009


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Iannone, et al.         Expires September 4, 2009               [Page 4]


Internet-Draft           LISP Mapping Versioning              March 2009


2.  Introduction

   The present document introduces the use of version numbers in order
   to provide information on a change in the EID-to-RLOC mappings used
   in the LISP ([I-D.farinacci-lisp] ) context to perform encapsulation.
   The approach is based on the idea that version numbers are associated
   to each mapping.  When a mapping is changes, a new version number is
   assigned to the updated mapping.  A change in a EID-to-RLOC mapping
   can be a change in the RLOCs set, by adding or removing one or more
   RLOCs, but it can also be a change in the priority or weight of one
   or more RLOCs.  The change can even consist in the reachability of
   one or more RLOCs.  Reachability information is intended from the
   local-domain perspective, and can be obtained for instance monitoring
   IGP's routing tables.  This should not be confused with the intra-
   domain "Locator Path Liveness problem" described in
   [I-D.meyer-loc-id-implications].

   With this approach, LISP-encapsulated data packets have to contain
   the version number of the mapings used to select the RLOCs in the
   outer header.  These version numbers are contained in a "new" LISP
   header (described in Section 6).  When an ITR encapsulates a packet,
   it puts in the LISP-specific header two version numbers:

   1.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Database) used to select the source RLOC.

   2.  The version number assigned to the mapping (contained in the EID-
       to-RLOC Cache) used to select the destination RLOC.

   This operation is two-fold.  On the one hand it enables the ETR
   receiving the packet to know if the ITR that sent it is using the
   latest mapping for the destination EID.  If it is not the case the
   ETR will send a "Map-Update-Notification" message (newly defined in
   Section 8) to notify the ITR that a more recent version of the
   mapping is available and can be retrieved as usual from the mapping
   distribution system.  Due to security issues (discussed in
   Section 10.3), this message does not contain the mapping.  On the
   other hand, it enables the ETR receiving the packet to know if it has
   in its cache the latest mapping for the source EID.

   The versioning approach does not need to re-design the mapping
   distribution infrastructure, which is always done through the mapping
   distribution protocol (e.g., CONS [I-D.meyer-lisp-cons], ALT
   [I-D.fuller-lisp-alt]).  The mappings are distributed as usual
   through the Map-Request/Map-Reply message exchange.  There are only
   the following two modifications that need to be introduced:





Iannone, et al.         Expires September 4, 2009               [Page 5]


Internet-Draft           LISP Mapping Versioning              March 2009


   1.  Map-Reply messages need to include the mapping version (described
       in Section 7).

   2.  Support has to be added for the new Map-Update-Notification
       message.














































Iannone, et al.         Expires September 4, 2009               [Page 6]


Internet-Draft           LISP Mapping Versioning              March 2009


3.  EID-to-RLOC Mapping Version Number

   The EID-to-RLOC Mapping Version Number consist in an unsigned 15-bit
   integer.  The version number is assigned in a per-mapping fashion,
   meaning that different mappings will have assigned a different
   version number, which is also updated independently.  An update in
   the version number (i.e., a newer version) consist in incrementing by
   one the older version number.

   The space of version numbers has a circular order where half of the
   version numbers is greater than the current Mapping Version Number
   and the other half is smaller than Mapping Version Number.  In a more
   formal way, assuming we have two version numbers V1 and V2 and that
   the numbers are expressed on N bits, the following three cases may
   happen:

   V1 = V2 :  This is the exact match case.

   V1 < V2 :  True if and only if V1 < V2 < (V1 + 2**(N-1)).

   V1 > V2 :  True if and only if V1 > V2 > (V1 - 2**(N-1)).

   As an example, using 24 bits, if the Mapping Version Number is 0,
   versions in ]1; (2**14)-1[ are greater and versions in [2**14;
   (2**15)-1[ are smaller.


























Iannone, et al.         Expires September 4, 2009               [Page 7]


Internet-Draft           LISP Mapping Versioning              March 2009


4.  Version Numbers wrap-around

   The proposed 15 bits size for the Mapping Version Number based on the
   assumption that Map-Requests are rate limited with a granularity of
   seconds.  Using a granularity of seconds and assuming that a new
   version is issued each second, we have around 9 hours of autonomy
   before the versions wraps around, which is a reasonable time.
   Alternatively a granularity of minutes can also be used, as for the
   TTL of the Map-Reply([I-D.farinacci-lisp]).  Nevertheless, using a
   granularity of minutes leads to very long (pointless) wrap-around
   periods.  Hereafter there is a table with a rough estimation of the
   obtained autonomy with different sizes of the version number and
   different time granularity.

   +---------------+--------------------------------------------+
   |Version Number |           Time before wrap around          |
   |  Size (bits)  +--------------------------------------------+
   |               |Granularity: Minutes | Granularity: Seconds |
   +------------------------------------------------------------+
   |          32   |   8171 Years        |  136 Years           |
   |          30   |   2042 Years        |   34 Years           |
   |          24   |     31 Years        |  194 Days            |
   |          16   |     45 Days         |   18 Hours           |
   |          15   |     22 Days         |    9 Hours           |
   |          14   |     11 Days         |    4 Hours           |
   +---------------+---------------------+----------------------+

                                 Figure 1























Iannone, et al.         Expires September 4, 2009               [Page 8]


Internet-Draft           LISP Mapping Versioning              March 2009


5.  Dealing with Version Numbers

   The main idea of using Mapping Version Numbers is that whenever there
   is a change in the mapping (e.g., adding/removing RLOCs, a change in
   the weights due to new TE policies, or a change in the priorities) or
   an ISP realizes that one or more of its own RLOCs are not reachable
   anymore from a local perspective (e.g., through IGP, due to route
   flap, or policy changes) the ISP updates the mapping with a new
   mapping version number.

   In order to announce in a data-driven fashion that the mapping has
   been updated, the version numbers used to encapsulate the packet are
   embedded in the packets encapsulation.  This means that the header
   needs to contain two mapping version numbers.  A first one from the
   EID-to-RLOC mapping in the EID-to-RLOC Database used to select the
   source RLOC, and called Source Mapping Version Number.  A second one
   from the EID-to-RLOC mapping in the EID-to-RLOC Cache used to select
   the destination RLOC, and called Destination Mapping Version Number.
   The purpose of carring these version numbers is two-fold, allowing
   the ETR receiving the encapsulated packet to check if i) the ITR has
   an up-to-date mapping; ii) the mapping in the local cache for the
   source EID is up-to-date.  If the first condition does not hold the
   Map-Update-Notification (see Section 8) is used to make the ITR aware
   that a newer mapping is available.  The ITR will retrieve the mapping
   with the normal Map-Request/Map-Reply mechanism.  If the second
   condition does not hold the ETR sends a Map-Request for the source
   EID (obtained from the inner header of the packet) in order to
   retrieve the up-to-date mapping.

   Further details on how to handle the Source and Destination Mapping
   Version Numbers are provided hereafter, while the proposed new LISP
   header format is detailled in Section 6 (Figure 2).

5.1.  Handling Destination Mapping Version Number

   When an ETR receives a packet, the destination mapping version number
   relates to the mapping of the domain the ETR is part of, thus the ETR
   has the correct and up-to-date Version Number for the destination
   mapping.  A check on this version number is done, where the following
   cases can arise:

   o  The packets arrive with the same destination mapping version
      number stored in the LEID-to-RLOC Database.  This is the correct
      regular case.  The ITR sending the packet has in its EID-to-RLOC
      Cache an up-to-date mapping.  No further actions are needed.

   o  The packets arrive with an destination mapping version number
      smaller (i.e., older) than the one stored in the EID-to-RLOC



Iannone, et al.         Expires September 4, 2009               [Page 9]


Internet-Draft           LISP Mapping Versioning              March 2009


      Database.  This means that the ITR sending the packet has an old
      mapping, in its EID-to-RLOC Cache, containing stale information.
      Further actions are needed.  The ITR sending the packet should be
      informed that a newer mapping is available.  This is done with a
      "Map-Update-Notification" message sent back to the ITR, soliciting
      an update of the mapping.  This message should be rate limited and
      if after a certain amount of retries the mapping is not updated
      packets coming from that ITR with smaller mapping version number
      can be silently dropped, since most likely there is a spoof or the
      ITR is not behaving correctly.  Note that the rule can be even
      more restrictive.  If the mapping has been the same for a period
      of time as long as the TTL (defined in LISP [I-D.farinacci-lisp])
      of the previous version of the mapping, all packets arriving with
      an old mapping version can be silently dropped right away.
      Indeed, if the new mapping with the updated version number has
      been stable for at least the same time as the TTL of the older
      mapping, all the entries in the caches of ITRs must have expired.
      If packets with old mapping version number are still received, the
      reason is that either someone has not respected the TTL, or it is
      a spoof, or a not valid behaviour w.r.t. the specifications.  In
      all those cases the packet can be silently dropped.

   o  The packet arrives with a destination mapping version number
      greater (i.e., newer) than the one stored in the EID-to-RLOC
      Database.  Since the ETR is in the domain owning the mapping, this
      means that someone is not behaving correctly w.r.t. the
      specifications, thus the packets carries a not valid version
      number and can be silently dropped.

5.2.  Handling Source Mapping Version Number

   When an ETR receives a packet, the source mapping version number
   relates to the mapping owned by the domain the ITR is part of and
   whose copy should be present in the EID-to-RLOC Cache of the ETR
   (except for the first packet that generates a cache miss triggering a
   Map-Request message).  A check on this version number is done, where
   the following cases can arise:

   o  The packet arrives with the same source mapping version number
      stored in the EID-to-RLOC Cache.  This is the correct regular
      case.  The ETR has in its EID-to-RLOC Cache an up-to-date copy of
      the mapping.  No further actions are needed.

   o  The packet arrives with a source mapping version number smaller
      (i.e., older) than the one stored in the local EID-to-RLOC Cache.
      Such a case is not valid w.r.t. the specifications and hence the
      packet is silently dropped.  If the mapping is already present in
      the EID-to-RLOC Cache, this means that an explicit Map-Request has



Iannone, et al.         Expires September 4, 2009              [Page 10]


Internet-Draft           LISP Mapping Versioning              March 2009


      been send and a Map-Reply has been received.  The latter sent by
      the "owner" of the mapping.  Assuming the mapping system is not
      corrupted anyhow, the mapping version in the EID-to-RLOC Cache is
      the correct one, hence the packet is not valid.

   o  The packet arrives with a source mapping version number greater
      (i.e., newer) than the one stored in the local EID-to-RLOC Cache.
      The ETR has in its EID-to-RLOC Cache a mapping that is stale and
      needs to be updated.  The packet is considered valid but further
      actions are needed.  In particular a Map-Request must be sent to
      the owner of the source mapping to retrieve the new mapping.  This
      should be rate limited.







































Iannone, et al.         Expires September 4, 2009              [Page 11]


Internet-Draft           LISP Mapping Versioning              March 2009


6.  Proposed changes to the LISP header

   In order for the versioning approach to work, the LISP encapsulation
   format needs to be changed.  In particular the LISP header is
   modified to include the source mapping version number and the
   destination mapping version number.

   Here is the new packet format, changes occur only on the LISP header:

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /|Version|  IHL  |Type of Service|          Total Length         |
     / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /  |         Identification        |Flags|      Fragment Offset    |
   /   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   \   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \  |                    Source Routing Locator                     |
     \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \|                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Res|    Source Mapping V.N.      |  Destination Mapping V. N.  |
   LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                            Nonce                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /|Version|  IHL  |Type of Service|          Total Length         |
     / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /  |         Identification        |Flags|      Fragment Offset    |
   /   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   \   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    \  |                           Source EID                          |
     \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      \|                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 2

   Reserved (2 bits):  Reserved for future use.  Sent as 0 and ignored
      on reception.  A possible use of these two bits is proposed in
      Section 9.3.





Iannone, et al.         Expires September 4, 2009              [Page 12]


Internet-Draft           LISP Mapping Versioning              March 2009


   Source Mapping Version Number (15 bits):  Version of the mapping used
      by the ITR to select the RLOC to put in the "Source Routing
      Locator" field.  Note that the mapping used for such a selection
      is determined by the Source EID, used as lookup key in the EID-to-
      RLOC Database of the ITR.

   Destination Mapping Version Number (15 bits):  Version of the mapping
      used by the ITR to select the RLOC to put in the "Destination
      Routing Locator" field.  Note that the mapping used for such a
      selection is determined by the Destination EID, used as lookup key
      in the EID-to-RLOC Cache of the ITR.

   Note that the change proposed concerns only the part of the LISP
   specific header originally containing the reachability bits.





































Iannone, et al.         Expires September 4, 2009              [Page 13]


Internet-Draft           LISP Mapping Versioning              March 2009


7.  Proposed changes to the Map-Reply Packet format

   To accommodate the proposed mechanism, also the Map-Reply packet
   format needs to be changed (original definition of the Map-Reply
   packet format can be found in [I-D.farinacci-lisp]).  This is a
   simple change to carry the version number assigned to the mapping in
   this message.  It does not mean a change in the mapping distribution
   system from an architectural point of view.


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             Nonce                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type=2 |                  Reserved             | Record Count  |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record  TTL                          |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   |A|           Reserved            |   Mapping Version Number    |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Locator Count | EID mask-len  |            EID-AFI            |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Loc|      Unused Flags           |R|           Loc-AFI             |
   | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mapping Protocol Data                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Mapping Version Number:  Version Number of the mapping in the Record.

   The proposed change does not make the whole packet bigger.  Indeed,
   the proposed solution is to put the fields "Locator Count", "EID
   mask-len" and "EID-AFI" in the same 32 bits block.  In
   [I-D.farinacci-lisp] "locator Count" and "EID mask-len" are in the
   same 32 bits block but "EID-AFI" is in a different 32 bits block.
   The first two fields are alligned left, while the latter is alligned
   right, with a gap of 32 bits, from which only one is used (the
   authoritative bit "A") while the other 31 are just marked as
   "Reserved".  After compacting the fields, the "A" bit is now placed
   in the same 32 bits block like the mapping version number.  Even, if
   fields have been displaced, they keep their original definition
   described in [I-D.farinacci-lisp].





Iannone, et al.         Expires September 4, 2009              [Page 14]


Internet-Draft           LISP Mapping Versioning              March 2009


8.  Map-Update-Notification Message

   From the LISP packet that triggered a Map-Update-Notification, it is
   known the ITR has to be notified about the existence of a newer
   mapping.  It is not possible to send the mapping directly with a Map-
   Reply message, since this can introduce security threats.  This is
   why the Map-Update-Notification message is needed and must only be a
   notification that a new version of the mapping is available.  The
   message is meant to trigger a Map-Request from the ITR, in order to
   update its copy of the mapping.

   In [I-D.farinacci-lisp], the equivalent of the Map-Update-
   Notification message is the SMR bit set in the LISP header of the
   data packets.  The SMR bit approach does not work in the case of
   unidirectional traffic (e.g., due to unidirectional flows or Traffic
   Engineering).  The ETR has no mean to send back to the ITR that a new
   mapping is available.  Moreover,with the SMR bit only there is not
   enough information for understanding if ITRs have updated the mapping
   so that the SMR bit can be reset.

   The format for the Map-Update-Notification message will be provided
   in future versions of this draft.





























Iannone, et al.         Expires September 4, 2009              [Page 15]


Internet-Draft           LISP Mapping Versioning              March 2009


9.  Further Observations

   In the following sections we provide more discussion on various
   aspects of the mapping versioning.  Security observations are instead
   grouped in Section 10.

9.1.  Mapping Versioning and RLOCs reachability

   When the reachability problem occurs on the path between two RLOCs of
   different LISP sites (this is called path-liveness problem in the
   recent draft by D. Meyer and D. Lewis
   [I-D.meyer-loc-id-implications]), the versioning approach does not
   help.  In this case other mechanisms are necessary, however, such an
   issue is not new and is part of all loc/ID split solutions, thus
   versioning does not introduce a new issue.

9.2.  Mapping Versioning to simplify LISP implementation

   The use of versioning numbers for mapping has also the effect of
   simplifying operations.  The set of RLOCs can always be maintained
   ordered, since no consistency must be preserved with the reachability
   bits.

   In other words it is not necessary to "append" new locators to the
   existing ones as explained in Section 6.5 of the LISP draft.  A new
   mapping with a new version number will be issued, and since the old
   locators are still valid the transition will be disruptionless.  The
   same applies for the case a RLOC is withdrawn.  There is no need to
   maintain holes in the list of locators, as previously, for sites that
   are not using the RLOC that has been withdrawn, the transition will
   be disruptionless.

   It is even possible to perform a graceful shutdown.  This is obtained
   by simply issuing a mapping where the specific RLOC to be shut down
   is withdrawn, but without actually turning it off.  Once no more
   traffic is received by the RLOC, because all sites have updated the
   mapping the RLOC can be shut down safely.

   All of these operations, as already stated, do not need to maintain
   any consistency among reachability bits, and the way RLOC are stored
   in the cache.  This eases implementation.

   Finally, with the versioning approach there is no need to perform a
   "clock sweep" as described in Section 6.5.1 of the LISP draft.  Every
   LISP site communicating to a specific LISP site that has updated the
   mapping will be informed of the available new mapping in a data-
   driven manner.




Iannone, et al.         Expires September 4, 2009              [Page 16]


Internet-Draft           LISP Mapping Versioning              March 2009


9.3.  Mapping Versioning and original LISP cohexistence

   The solution proposed in this draft includes changes in the LISP
   header.  However, and for experimentation purpose, it could be worth
   instead of replacing the original LISP header, to extend the original
   LISP header by appending the one proposed in this draft.

   Alternatively, the first two bits of the LISP specific header can be
   used to select the type of header.  For instance the second leftmost
   bit can be used to state if the following bits have to be interpreted
   as reachability bits or version numbers.

   Note that the reference document for LISP implementation and
   interoperability tests remains [I-D.farinacci-lisp].  The present
   draft proposes an alternative approach that needs experimental
   validation and should not be considered as a permanent design of the
   LISP protocol.


































Iannone, et al.         Expires September 4, 2009              [Page 17]


Internet-Draft           LISP Mapping Versioning              March 2009


10.  Security Considerations

   Mapping Versioning present the same reactivity of Reachability bits
   and SMR bit, however, provides more robustness to possible attacks.

10.1.  Robustness against reachability information spoofing.

   Compared to the reachability bits solution, since the new mapping is
   obtained through the mapping system the data plane results robust to
   reachability information spoofing.  Such a statement is true assuming
   that the mapping distribution system is secure.  Security issues
   concerning specific mapping distribution system are described in the
   documents specific to each proposal.

10.2.  Robustness against traffic disruption

   Attackers can try to use the Mapping version number to trigger either
   Map-Update-Notification messages or Map-Request messages, by simply
   sending packets for all the possible version numbers.  Nevertheless,
   as described in Section 5 it is possible to easily filter a large
   part of the packets containing a wrong version number.  If the
   version number is sufficiently large, exploring all the possible
   numbers will take too much time to be really feasible.

   Furthermore, even if the attacker is able to "guess" the correct
   version number to trigger a Map-Request, the traffic is not stopped.
   The normal behavior will be that the xTR continue to use the mapping,
   while asking in parallel for a new one, in a rate limited fashion.
   This is not the case with explicit reachability bits where an
   attacker can set all RLOCs to down with one single packet, with
   disruptive consequences on the traffic.

   It is clear, that mapping versioning does not protect against DoS and
   DDoS attacks, where an xTR looses processing power doing version
   number checks on packets sent by attackers.

10.3.  Robustness of the Map-Update-Notification message

   The Map-Update-Notification should never include the new mapping
   inside the packet itself, otherwise a security threat would be
   introduced, where attackers send fake Map-Update-Notifications
   messages poisoning the cache.

   The mapping could be included in the Map-Update-Notification only in
   the case where the sender can be clearly identified (e.g., using
   certificates or a PKI).





Iannone, et al.         Expires September 4, 2009              [Page 18]


Internet-Draft           LISP Mapping Versioning              March 2009


10.4.  About robusteness of Reachability bits

   The scenarii presented in the previous sections are correct if ETR
   react to Reachability bits change without performing a further check
   with the ITR.  In other ways the ETR blindly trusts the content of
   the Reachability bits.  If ETR does not trust such a content and
   before changing the reachability state of the RLOCs it can send a
   Map-Request in order to confirm the change.  On the one hand, having
   such a confirmation improves the robusteness of the reachability bits
   mechanism.  On the other hand, this is very close to the mapping
   versioning system, with the only difference that the use of version
   numbers enables a fine control on when to update a mapping or when to
   notify that a mapping has been updated.






































Iannone, et al.         Expires September 4, 2009              [Page 19]


Internet-Draft           LISP Mapping Versioning              March 2009


11.  Aknoledgements

   The authors would like to thank Pierre Francois and Dino Farinacci
   for their comments and review.















































Iannone, et al.         Expires September 4, 2009              [Page 20]


Internet-Draft           LISP Mapping Versioning              March 2009


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [I-D.farinacci-lisp]
              Farinacci, D., Fuller, V., Oran, D., Meyer, D., and S.
              Brim, "Locator/ID Separation Protocol (LISP)",
              draft-farinacci-lisp-11 (work in progress), December 2008.

   [I-D.fuller-lisp-alt]
              Fuller, V., Meyer, D., and D. Farinacci, "LISP Alternative
              Topology (LISP+ALT)", draft-fuller-lisp-alt-03 (work in
              progress), October 2008.

   [I-D.meyer-lisp-cons]
              Brim, S., "LISP-CONS: A Content distribution Overlay
              Network Service for LISP", draft-meyer-lisp-cons-04 (work
              in progress), April 2008.

   [I-D.meyer-loc-id-implications]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", draft-meyer-loc-id-implications-00
              (work in progress), December 2008.























Iannone, et al.         Expires September 4, 2009              [Page 21]


Internet-Draft           LISP Mapping Versioning              March 2009


Authors' Addresses

   Luigi Iannone
   TU Berlin - Deutsche Telekom Laboratories AG
   Ernst-Reuter Platz 7
   Berlin
   Germany

   Email: luigi@net.t-labs.tu-berlin.de


   Damien Saucez
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain la Neuve
   Belgium

   Email: damien.saucez@uclouvain.be


   Olivier Bonaventure
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain la Neuve
   Belgium

   Email: olivier.bonaventure@uclouvain.be
























Iannone, et al.         Expires September 4, 2009              [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/