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

Versions: 00

Network Working Group                                          D. Saucez
Internet-Draft                                            O. Bonaventure
Intended status: Informational          Universite catholique de Louvain
Expires: August 24, 2011                               February 20, 2011


                     Securing LISP Mapping replies
                 draft-saucez-lisp-mapping-security-00

Abstract

   The security of the mappings is crucial for the success of the
   Locator/Identifier Separation Protocol (LISP).  This draft discusses
   two options to allow LISP xTR to verify the authenticity of LISP Map-
   Replies.

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 August 24, 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Saucez & Bonaventure     Expires August 24, 2011                [Page 1]


Internet-Draft               LISP Signature                February 2011


   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.  Mapping security levels  . . . . . . . . . . . . . . . . . . .  4
   3.  Requirements to secure Mapping information . . . . . . . . . .  4
   4.  Mapping Authentication Mechanisms  . . . . . . . . . . . . . .  6
     4.1.  Mapping Authenticity Base  . . . . . . . . . . . . . . . .  6
     4.2.  Signed Mappings  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Informative References . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

























Saucez & Bonaventure     Expires August 24, 2011                [Page 2]


Internet-Draft               LISP Signature                February 2011


1.  Introduction

   The Locator/Identifier Separation Protocol (LISP) is currently being
   developed with the LISP IETF working group [I-D.ietf-lisp].  LISP can
   be conceptually divided in two different parts :

   o  LISP data plane that defines the format and the processing of LISP
      encapsulated packets on xTRs

   o  LISP control plane that defines how an ITR obtains mapping
      information about a destination EID and manages this information.

   The LISP control plane plays a key role from a security viewpoint in
   the entire operation of LISP.  LISP xTRs exchange mapping information
   by using Map-Requests and Map-Replies.  It is important to note that
   the LISP control plane messages are used for three different purposes
   by ITRs and ETRs:

   o  When a LISP ITR does not know any mapping information for an EID,
      it sends a LISP Map-Request through the LISP Mapping system.  The
      LISP Mapping system will ensure that the LISP Map-Request will
      reach a LISP Mapping Server or a LISP ETR that is authoritative
      for the requested EID.  A LISP ETR will then send a LISP Map-Reply
      directly to the originating LISP ITR.

   o  When a mapping information times out on a LISP ITR, the ITR will
      need to refresh the mapping by either sending a LISP Map-Request
      through the LISP Mapping System or directly to one of the LISP ETR
      that is responsible for the expired mapping.  One of the
      authoritative LISP ETR will then send a LISP Map-Reply directly to
      the originating LISP ITR.

   o  A LISP ITR may send a LISP Map-Request directly to a LISP ETR to
      verify its reachability.  The ETR will confirm its reachability by
      sending a LISP Map-Reply back.

   The security of the LISP control plane is crucial for the security of
   LISP.  A detailed discussion on the security of LISP may be found in
   [I-D.saucez-lisp-security].  The current LISP specifications do not
   provide a secure LISP Mapping System.  The ALT [I-D.ietf-lisp-alt]
   Mapping system relies on BGP sessions established manually over
   tunnels between LISP xTRs and LISP Mapping Servers.  ALT assumes that
   such a mapping system will be secure since it is operated by trusted
   operators.  Unfortunately, the experience with BGP on the global
   Internet has shown that this is not a valid assumption and that
   additional techniques are required to secure a routing system that
   relies on BGP.




Saucez & Bonaventure     Expires August 24, 2011                [Page 3]


Internet-Draft               LISP Signature                February 2011


   This document is organized as follows.  In Section 2 we present the
   different levels of security that can be provided and analyze their
   respective advantages and drawbacks.  In Section 4 we discuss several
   families of solutions that can be designed to improve the security of
   the LISP control plane.


2.  Mapping security levels

   The level security of a mapping is determined by the level of
   confidence that a LISP xTR can have on information obtained through
   it.

   By using nonce mechanism as described in the LISP specifications, a
   LISP ITR can be confident that a Map-Reply it receives has been sent
   by the LISP ETR that it queried.  This is relevant when an ITR sends
   a Map-Request directly to a LISP ETR that it already knows.  However,
   when a LISP ITR sends a Map-Request through the LISP mapping system,
   the Map-Reply may come from any LISP ETR and that fact that it
   contains the same nonce as in the LISP Map-Request only proves that
   it was generated in response to a specific Map-Request.  Indeed, the
   64-bits nonce that must be returned by the ETR mitigates the risk of
   injection attacks where an attacker inject Map-Replies containing
   invalid information.  Unfortunately, if the attacker is on path, it
   may intercept the Map-Request and extract its nonce.  It can then
   generate a Map-Reply that looks authentic for the ITR as the nonce in
   the reply is valid.  The nonce thus provides only a simple way of
   authenticating the Map-Replies when man-in-the middle attacks are not
   possible.

   If messages can be tampered, or if man-in-the middle attacks are
   possible, or if the mapping system may be abused to deliver to a
   hostile ETR a Map-Request sent by an ITR, we need a better security
   than the nonce.


3.  Requirements to secure Mapping information

   LISP Map-Reply messages contain several types of mapping information.
   In this section, we evaluate the security risks if an attacker is
   able to inject invalid mapping information.  We consider that the
   LISP nonce protects against injection of Map-Reply messages by an
   off-path attacker and discuss two types of attackers:

   An attacker that temporarily resides on the path between an ITR and
   an ETR and is able to perform a man-in-the-middle attack by modifying
   Map-Reply messages exchanged between these xTRs.  We call this
   attacker the on-path attacker in this document.



Saucez & Bonaventure     Expires August 24, 2011                [Page 4]


Internet-Draft               LISP Signature                February 2011


   A malicious xTR or LISP-MS that receives legitimate Map-Request
   messages from ITRs but returns crafted Map-Reply messages.  We call
   this attacker the malicious xTR in this document.

   The mapping information and their associated security risk is
   presented below:

   o  EID prefix and mask length.  By changing the EID prefix in a Map-
      Reply message, an on-path attacker could cause denial of service
      attacks of blackhole traffic by placing in the Map-Reply message a
      less specific EID prefix than in the original Map-Reply.  A
      malicious xTR could also return a less specific prefix and
      blackhole traffic.

   o  Locator.  The locators are probably the most important information
      in the LISP Map-Reply messages since they indicate where
      encapsulated packets should be sent to reach a given EID prefix.
      By changing locators, an on-path attacker could redirect traffic
      to another LISP ETR where it can perform man-in-the-middle attacks
      on encapsulated packets more easily.  By injecting incorrect
      RLOCs, a malicious xTR could also redirect encapsulated traffic to
      a LISP ETR where it can easily perform a man-in-the-middle attack.

   o  Priority and Multicast Priority.  If an attacker is able to change
      the priority associated to a locator in a mapping, it could force
      an ITR to send encapuslated packets over another path than the
      intended path.  It can also make any RLOC unused by setting it a
      255 priority.

   o  Weight and Multicast Weight.  This field is used to influence how
      load balancing should be performed when several locators have the
      same priority.  By changing weight, an attacker could move
      encapsulated packets over different paths.

   o  Record TTL.  By lowering the record TTL, an attacker could force
      an ITR to send more frequently Map-Request messages.  By
      increasing the record TTL, an attacker could ensure that a fake
      mapping information is used for a longer time by its victim.  A
      temporarily on-path attacker could use a long record to ensure
      that a malicious mapping remains in the victim ITR EID-to-RLOC
      cache for a long period of time.

   o  Version.  By changing the Version of a mapping, an attacker could
      trigger a loop of mapping updates at the ITR.  Indeed, if the
      version is invalid, when the ITR receives a packet from the EID it
      received the mapping for, it will send a Map-Request as the
      version does not correspond.  If the attacker can control the
      version of the Map-Reply, this scheme can be repeated



Saucez & Bonaventure     Expires August 24, 2011                [Page 5]


Internet-Draft               LISP Signature                February 2011


      indefinitely.

   o  Reachability.  If an attacker is able to change the reachability
      bit associated to a locator, it could force a LISP ITR to test the
      reachability of this locator.

   Based on the analysis above, the most critical information in the
   mapping placed in LISP Map-Reply messages are the EID prefixes and
   the locators.  From a security viewpoint, it is important for a LISP
   ITR to be able to verify the validity of the link between an EID
   prefix and a set of locators.


4.  Mapping Authentication Mechanisms

   To authenticate the mappings, several techniques can be used.
   Authenticating mapping information is similar to validate DNS
   responses and also related to the validation of BGP prefixes in the
   global interdomain routing system.  In this section, we discuss the
   applicability of two techniques that have been designed to secure
   interdomain routing to secure LISP mappings.

4.1.  Mapping Authenticity Base

   The first technique that was developed to verify the authenticity of
   BGP announcements are the prefix allocation databases maintained by
   the Regional Internet Registries.  Each RIR maintains a database,
   typically in RPSL format, that contains the list of all the prefixes
   that have been allocated to a given AS.  An AS can use this
   information to verify the received BGP advertisements.  Some
   operators use filters that are automatically derived from the RIR
   databases and installed on their BGP import filters.  Experience
   shows that this method works reasonably well in some regions and that
   it is able to prevent misconfiguration problems.  However, it can be
   difficult to maintain the RIR databases up-to-date.

   The allocation of EID prefixes by RIRs has not yet been precisely
   discussed within the LISP working group, but a possible approach
   could be as follows.  Sites obtain EID prefixes from a RIR or a LIR
   and register on the RIR database the locators of the ETR that serve
   each allocated EID prefix.  The list of locators that are associated
   to an EID prefix is only the list of the potential locators.  The RIR
   database, unlike the NERD mapping system would not contain detailed
   information about the mapping such as priorities or weights.  This
   information may change with time and should be obtained by querying
   the mapping system.

   When an ITR needs a mapping for an EID prefix that it does not know,



Saucez & Bonaventure     Expires August 24, 2011                [Page 6]


Internet-Draft               LISP Signature                February 2011


   it queries the mapping system as usual and receives an
   unauthenticated Map-Reply.  Two techniques could be developed to
   allow the ITR to verify the validity of the received Map-Reply based
   on the information stored in the RIR databases.  A first option is
   that the network administrator that is responsible for an ITR
   downloads regularly the RIR database and derives filters for all the
   valid pairs of EID prefix - RLOC.  These filters are regularly pushed
   on the LISP ITRs and are used to verify each received LISP Map-Reply.
   A second solution is to allow each LISP ITR to directly query the RIR
   database by using either an existing protocol such as whois or a new
   protocol to be developed.  This allows the ITR to verify in realtime
   the LISP Map-Replies that it receives, but imposes a possibly high
   load on the RIR databases.

   The advantage of using the RIR databases is that there is already a
   lot of operational experience with them.  However, the load on the
   RIR databases can be high.  Furthermore, updating the RIR databases
   might be difficult for LISP ETRs that use dynamic routing locators,
   e.g.  RLOCs assigned by DHCP.

4.2.  Signed Mappings

   The Mapping Authenticity Base approach has the advantage of keeping
   the Map-Reply processing light at the ITR and the ETR.
   Unfortunately, running the authenticity base could cause
   administrative and cost overhead and the system has still some
   security weaknesses.

   Instead of using a separated infrastructure to authenticate the
   mappings, we can embed the authentication scheme directly in the
   mapping messages.  With this approach, each mapping message is
   signed.

   To reduce the processing at the ETR, we will consider that only the
   Map-Replies are signed.  We still have to determine if it is required
   to authenticate the Map-Requests.

   Depending on the security level that has to be reached, different
   part of the mapping have to be signed.

   Adding a field in the Map-Reply that is the signature of the hash of
   the ETR address and the nonce is not sufficient as it does not
   protect against tempering, it only confirms that the Map-Reply has
   been initially generated by the appropriated ETR the content may have
   been tempered.

   For a higher level of security, a certificate has to be used, the
   certificate gives the EID prefix and the proof that the EID prefix



Saucez & Bonaventure     Expires August 24, 2011                [Page 7]


Internet-Draft               LISP Signature                February 2011


   belongs to the ETR (e.g., the certificate is signed by a well-known
   EID registry).  A field is added to the Map-Reply and contains the
   signature of the hash of the ETR address, the nonce and the EID
   prefix.  This signature prove that the EID prefix belongs to the ETR
   and that the correct ETR has been queried.  The set of RLOCs and the
   mapping attributes may still have been tempered.

   To also prove that the locators are valid and thus avoid divert
   traffic attacks, the same principle as before can be followed but the
   certificate adds the list of valid RLOCs for the EID prefix.  The
   signature covers the ETR address, the nonce, the EID prefix and the
   RLOCs.

   To reach an ultimate security level, the technique from above can be
   used but it has to be applied to all the mapping fields, the ETR
   address and the nonce.

   When signing the entire message improves the security by virtually
   prohibiting any modification of the message, it can cause an
   important overhead at the ETR and the signature cannot be pre-
   computed (i.e., the nonce makes the message changing every time.  On
   the contrary, signing only some parts of the message could allow one
   to pre-compute the signature and thus make the generation of a Map-
   Reply not more complex than the generation of a Map-Reply without a
   signature.

   An attack can at most replay a mapping that has been valid in the
   past.  The injection of old mappings by attackers can be mitigate if
   the certificate associated to the mapping are limited in time.  This
   expiration date has to be set accordingly to the security needs of
   the site generating the mapping.

   When the signature does not cover the all message, pre-computation
   can be used to compute the signature.  In this case, the signature is
   computed when the mapping is installed in the local mapping database.

   The pre-computation of the signature allows to avoid the cost of
   computing the signature at each request on the ETRs and thus make the
   ETR insensible to DDoS attacks that could target an ETR by asking it
   to perform time consuming cryptography operations.

   The validation of the signature at the ITR is always present but its
   impact is limited compared to doing signatures at the ETR on the fly.
   In addition, if the ITR is overloaded, it could decide to postpone
   the authenticity check but use the mapping anyway.

   We can also propose intermediate security level where only some part
   of the mapping are authenticated.  We suggest to cover the TTL, the



Saucez & Bonaventure     Expires August 24, 2011                [Page 8]


Internet-Draft               LISP Signature                February 2011


   EID prefix and the list of [locator, priority, weight] tuples.  We
   removed the reachability information from the authentication as it is
   more volatile than the mappings and signature computation would be
   triggered after every reachability change.  At a first glance, not
   signing the reachability seems to be a mistake because an attacker
   could set all the reachability bit of each RLOC to zero and thus
   block the traffic.  However, as for locator status bits, we are
   considering this information as a hint, a reachability change has to
   be validated first with a reachability algorithm before effectively
   considering the reachability change.  Indeed, the reachability is a
   local consideration.


5.  Security Considerations

   This document is entirely devoted to the security


6.  Conclusion

   TO DO


7.  Acknowledgments

   The authors would like to gratefully acknowledge Luigi Iannone for
   his insights.


8.  Informative References

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

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

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






Saucez & Bonaventure     Expires August 24, 2011                [Page 9]


Internet-Draft               LISP Signature                February 2011


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 August 24, 2011               [Page 10]


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