[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                          D. Saucez
Internet-Draft                          Universite catholique de Louvain
Intended status: Standards Track                              L. Iannone
Expires: April 22, 2010                     TU Berlin - Deutsche Telekom
                                                         Laboratories AG
                                                          O. Bonaventure
                                        Universite catholique de Louvain
                                                        October 19, 2009


            Notes on LISP Security Threats and Requirements
                   draft-saucez-lisp-security-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.  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.

   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 April 22, 2010.

Copyright Notice




Saucez, et al.           Expires April 22, 2010                 [Page 1]


Internet-Draft                LISP Security                 October 2009


   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.

Abstract

   The present document is a preliminary collection of notes about LISP
   security threats and requirements.  Its purpose is to start a
   discussion on the subject among people that have shown interest in
   working on the matter.




































Saucez, et al.           Expires April 22, 2010                 [Page 2]


Internet-Draft                LISP Security                 October 2009


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   4.  Data-plane threats . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Security of the data stream  . . . . . . . . . . . . . . .  5
     4.2.  LISP-encapsulated packet spoofing  . . . . . . . . . . . .  5
     4.3.  Nonce  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  LISP-Cache threats . . . . . . . . . . . . . . . . . . . .  6
       4.4.1.  LISP-Cache poisoning . . . . . . . . . . . . . . . . .  6
       4.4.2.  LISP-Cache overflow  . . . . . . . . . . . . . . . . .  7
     4.5.  LISP-Database threats  . . . . . . . . . . . . . . . . . .  8
     4.6.  DoS threats  . . . . . . . . . . . . . . . . . . . . . . .  8
       4.6.1.  Locator Status Bits  . . . . . . . . . . . . . . . . .  8
       4.6.2.  Gleaning . . . . . . . . . . . . . . . . . . . . . . .  8
       4.6.3.  Rate Limitation  . . . . . . . . . . . . . . . . . . .  9
       4.6.4.  Mapping System and Filtering . . . . . . . . . . . . .  9
     4.7.  Other Attacks  . . . . . . . . . . . . . . . . . . . . . . 10
       4.7.1.  Time-shifted attacks . . . . . . . . . . . . . . . . . 10
       4.7.2.  Amplification attacks  . . . . . . . . . . . . . . . . 10
   5.  Control-plane threats  . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Control-plane Requirements . . . . . . . . . . . . . . . . 11
     5.2.  LISP-Database coherence  . . . . . . . . . . . . . . . . . 11
     5.3.  LISP Map Server  . . . . . . . . . . . . . . . . . . . . . 12
   6.  Interaction between Data- and Control-plane  . . . . . . . . . 12
     6.1.  Data-plane side effects on the control-plane . . . . . . . 12
     6.2.  Control-plane side effects on the data-plane . . . . . . . 12
     6.3.  Data-plane threats leveraging on the control-plane . . . . 12
     6.4.  Control-plane threats leveraging on the data-plane . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
















Saucez, et al.           Expires April 22, 2010                 [Page 3]


Internet-Draft                LISP Security                 October 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].


2.  Introduction

   The Locator/ID Separation Protocol (LISP) is defined in
   draft-ietf-lisp-05.txt [I-D.ietf-lisp].  The present document aims at
   identifying threats in the current LISP specification and possibly
   list a set of requirements or mechanism needed to improve its
   security.  A preliminary security analysis on LISP has been conducted
   by M. Bagnulo in [I-D.bagnulo-lisp-threat].

   This document is split in two main parts; one concerning the data-
   plane and one concerning the control-Plane.

   The LISP data-plane consists of LISP packet encapsulation,
   decapsulation, and forwarding and includes the LISP-Cache and LISP-
   Database data structures used to perform these operations.  The
   present document will try to analyze the possible threats of the
   data-plane.

   The LISP control-plane consists in the mapping distribution system,
   which can be one of the mapping distribution protocols proposed so
   far (e.g., [I-D.ietf-lisp-ms], [I-D.ietf-lisp-alt],
   [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd] ), and the set of
   Map-Request and Map-Reply messages.  The present document will not
   analyze all possible threats of each specific mapping distribution
   protocol.  Rather, this document will try to find a common set of
   requirements that every present and future mapping distribution
   protocol should satisfy in order to reduce as much as possible
   threats related to the LISP control-plane.


3.  Definition of Terms

   See [I-D.ietf-lisp]


4.  Data-plane threats

   This section contains some threats and attacks related to the LISP
   data-plane.  By LISP data-plane it is intended the operations of
   encapsulation, decapsulation, and forwarding as well as the content
   of the LISP-Cache and LISP-Database as specified in the original LISP



Saucez, et al.           Expires April 22, 2010                 [Page 4]


Internet-Draft                LISP Security                 October 2009


   document ([I-D.ietf-lisp]).

4.1.  Security of the data stream

   In some context it could be necessary to secure the data stream that
   is LISP encapsulated.  This can be achieved with two different
   approaches:

   o  Securing messages.  In this approach a field needs to be added to
      the LISP header in order to secure the content.

   o  Securing the transport protocol.  An example of this approach is
      the use of IPSEC to secure the content of the original, non LISP-
      encapsulated, packet.

   What is the approach suitable in the LISP context?

4.2.  LISP-encapsulated packet spoofing

   Like any other type of packet in the Internet, LISP encapsulated
   packets can also be spoofed.  Generally the term "spoofed packet"
   indicates a packet containing a source IP address which is not the
   one of the actual originator of the packet.  Since LISP uses
   encapsulation, this translates in two types of spoofing:

   o  EID Spoofing: The originator of the packet puts in it a spoofed
      EID.  The packet will be normally encapsulated by the ITR of the
      site.

   o  RLOC Spoofing: The originator of the packet generates directly a
      LISP-encapsulated packet with a spoofed source RLOC.

   Note that the two types of spoofing are not mutually exclusive,
   rather all combinations are possible and can be used to perform
   several kind of attacks.

   The work done in the SAVI WG ([SAVI]) can be useful in mitigating
   spoofing.

   It is worth to notice that in the context of LISP, there is also the
   possibility to spoof part of the content of the LISP-specific header
   in order to perform some attacks.  The various possibilities are
   listed in the following sections, while describing the possible
   attacks.







Saucez, et al.           Expires April 22, 2010                 [Page 5]


Internet-Draft                LISP Security                 October 2009


4.3.  Nonce

   The "Nonce" gives some basic security support by acting as a "session
   cookie", similar to what is used in L2TP
   ([I-D.ietf-l2tpext-l2tp-base]).  The use of the Nonce to mitigate
   some of the possible attacks is described in the following sections.

   There should be an explicit discussion on the limits of the Nonce?

4.4.  LISP-Cache threats

   A key component of the overall LISP architecture is the LISP-Cache.
   The LISP-Cache is the data structure that stores the bindings between
   EID and RLOC (namely the "mappings") to be used later on.  Attacks
   against this data structure can happen either when the mappings are
   first installed in the cache (see also Section 5) or by corrupting
   (poisoning) the mappings already present in the cache.

4.4.1.  LISP-Cache poisoning

   The content of the LISP-Cache can be poisoned by spoofing LISP
   encapsulated packets.  Example of LISP-Cache poisoning are:

   Fake mapping:  The cache contains entirely fake mappings that do not
         originate from an authoritative mapping server.  This can be
         achieved either through gleaning as described in Section 4.6.2
         or by attacking the control-plane as described in Section 5.

   EID Poisoning:  The EID-Prefix in a specific mapping is not owned by
         the originator of the entry.  Similarly to the previous case,
         this can be achieved either through gleaning as described in
         Section 4.6.2 or by attacking the control-plane as described in
         Section 5.

   EID redirection/RLOC poisoning:  The EID-Prefix in the mapping is not
         bound to (located by) the set of RLOCs present in the mapping.
         This can result in packets being redirected elsewhere,
         eavesdropped, or even blackholed.  Note that not necessarily
         all RLOCs are fake/spoofed.  The attack works also if only part
         of the RLOCs, the highest priority ones, are compromised.
         Again, this can be achieved either through the gleaning as
         described in Section 4.6.2 or by attacking the control-plane as
         described in Section 5.

   Reachability poisoning:  The reachability information stored in the
         mapping could be poisoned, redirecting the packets to a subset
         of the RLOCs (or even stopping it if locator status bits are
         all set to 0).  If reachability information is not verified



Saucez, et al.           Expires April 22, 2010                 [Page 6]


Internet-Draft                LISP Security                 October 2009


         through the control-plane this attack can be simply achieved by
         sending a spoofed packet with swapped or all locator status
         bits reset.  The same result can be obtained by attacking the
         control-plane as described in Section 5.

   Traffic Engineering information poisoning:  The LISP protocol defines
         two attributes associated to each RLOC in order to perform
         inbound Traffic Engineering: namely priority and weight.  By
         injecting fake TE attributes, the attacker is able to break
         load balancing policies and concentrate all the traffic on a
         single RLOC or put more load on a RLOC than what is expected,
         creating congestion.  Corrupting the TE attributes can be
         achieved by attacking the control-plane as described in
         Section 5.

   Mapping TTL poisoning:  The LISP protocol associates a Time-To-Live
         to each mapping that, once expired, allows to delete a mapping
         from the LISP-Cache (or forces a Map-Request/Map-Reply exchange
         to refresh it if still needed).  By injecting fake TTL values,
         an attacker can either shrink the Cache (using very short TTL),
         thus creating an excess of cache miss causing a DoS on the
         mapping system, or it can increase the size of the cache by
         putting very high TTL values, up to a cache overflow (see
         Section 4.4.2).  Corrupting the TTL can be achieved by
         attacking the control-plane as described in Section 5.

   If the above listed attacks succeed, the attacker has the means of
   controlling the traffic.

4.4.2.  LISP-Cache overflow

   Depending on how the LISP-cache is managed (e.g., LRU vs. LFU) and
   depending on its size, an attacker can try to fill the cache with
   fake mappings.  Once the cache is full, some mappings will be
   replaced by new fake ones, causing traffic disruption.

   This can be achieved either through the gleaning as described in
   Section 4.6.2 or by attacking the control-plane as described in
   Section 5.

   Another way to generate a LISP-Cache overflow is by injecting mapping
   with a fake and very large TTL value.  In this case the cache will
   keep a large amount of mappings ending with a completely full cache.
   This type of attack can also be performed through the control-plane.







Saucez, et al.           Expires April 22, 2010                 [Page 7]


Internet-Draft                LISP Security                 October 2009


4.5.  LISP-Database threats

   The LISP-Database data structure is meant to contain the mappings
   that are "owned" locally, i.e., the mappings that are used for
   selecting the source RLOC when encapsulating, and binding the EID-
   Prefix behind the xTR and the RLOCs present on the xTR.

   The simplest way to fill the LISP-Database is by configuration on
   each single xTR.  This secure the data structure as much as the xTR
   itself is robust to intrusions.

   Nevertheless, part of the information contained in the mappings that
   are in the LISP-Database are subject to change in time, e.g.,
   reachability information, TE attributes, etc.  The way mappings are
   updated can open security breaches allowing attackers to poison or
   corrupt the LISP-Database in a way similar to the LISP-Cache.  These
   attacks are more related to the control-plane and will be discussed
   in Section 5.

4.6.  DoS threats

   This section tries to list all possible DoS attacks and suggests,
   when possible, mechanisms that help in mitigating the threat.

4.6.1.  Locator Status Bits

   Locator Status Bits should be used only as a hint, meaning that upon
   reception of a packet having Locator Status Bits different from what
   is stored in the mapping present in the LISP-Cache, a Map-Request is
   issued in order to have confirmation of the change.  However, with
   this behavior, an attacker can send a burst of packets with different
   locato status bits in order to trigger a burst of Map-Request
   packets, thus again attacking the control-plane.  The echo nonce
   machanisme is proposed, we still have to analyze it in details.
   Several counter-measures can be introduced to mitigate its effects:

   o  Ignore Locator Status Bits if nonce does not change.

   o  Rate limitation can be used to reduce the number of issued Map-
      Request packets.

4.6.2.  Gleaning

   Gleaning is used to install in the LISP-Cache a partial mapping
   created by gleaning the source EID and source RLOC from the first
   packet of a flow.  The mapping is considered "partial" because it
   just associate an EID (/32) to one single RLOC, not the EID-Prefix
   the EID belongs to with the complete set of RLOCs.  Gleaning can be



Saucez, et al.           Expires April 22, 2010                 [Page 8]


Internet-Draft                LISP Security                 October 2009


   used to perform several different attacks:

   o  LISP-Cache poisoning: an attacker can use gleaning to install fake
      mappings in the LISP-Cache (by spoofing the EID).  See LISP-Cache
      poisoning in Section 4.4.1.

   o  LISP-Cache overflow: an attacker can use gleaning to install a
      large number of mappings in the LISP-Cache until filling it up.
      See LISP-Cache overflow in Section 4.4.2.  Since the mapping
      installed in the LISP-Cache is not for a EID-Prefix but for a full
      EID, by sending a burst of packet for several different spoofed
      EIDs, an attacker could end up filling the Cache.

   o  Map-Request burst: if for each mapping installed by a gleaning a
      Map-Request is issued to retrieve the full mapping, an attacker
      can send a burst of packets with different EIDs generating a burst
      of Map-Request.  Note that in this case, if Map-Request rate
      limitation is done on a per-EID basis, the attacker can easily
      bypass the rate limitation by putting different EIDs in the
      packets causing the gleaning.

   Possible counter-measure to mitigate this issue:

   o  The LISP-Cache poisoning and overflow issues can be solved by
      filtering spoofed EIDs on the ITR (see Section 4.2).

   o  To reduce the Map-Request burst an approach is to send a Map-
      Request only if a certain amount of packets has been sent using
      the gleaned entry, as suggested in [Saucez09].

4.6.3.  Rate Limitation

   The Rate-Limitation policy, used to reduce the effects of some types
   of DoS attacks can be itself used for a DoS attack.  An attacker can
   send some fake packets in order to generate a burst of Map-Request
   packets that will be rate limited.  When a legitimate packet
   generates a legitimate Map-Request, this will be delayed or dropped
   due to rate limitation, causing an increased latency.

   o  Any solution for this?

4.6.4.  Mapping System and Filtering

   The use of some form of filtering can help in avoid or at least
   mitigate some types of attacks.

   On ITRs, packets should be encapsulated only if the source EID is
   effectively part of the EID-Prefix downstream the ITR.  Further,



Saucez, et al.           Expires April 22, 2010                 [Page 9]


Internet-Draft                LISP Security                 October 2009


   still on ITRs, packets should be encapsulated only if a mapping
   obtained from the mapping system is present in the LIP-Cache.

   On ETRs, packets should be decapsulated only if the destination EID
   is effectively part of the EID-Prefix downstream the ETR.  Further,
   still on ETRs, packets should be decapsulated only if a mapping for
   the source EID is present in the LISP-Cache and has been obtained
   through the mapping system (not gleaned).

   Note that this filtering, since complete mappings need to be
   installed in both ITRs and ETRs, can introduce a higher connection
   setup latency and hence potentially more packets drops due to the
   lack of mappings in the LISP-Cache.

4.7.  Other Attacks

4.7.1.  Time-shifted attacks

   A time-shifted attack is an attack where the attacker is temporarily
   on the path between two communicating hosts.  While it is on-path,
   the attacker sends specially crafted packets or modifies packets
   exchanged by the communicating hosts in order to disturb the flow of
   packets (e.g., by performing a man in the middle attack).  An
   important issue for time shifted attacks is the duration of the
   attack once the attacker has left the path between the two
   communicating hosts.

4.7.2.  Amplification attacks

   An amplification attack occurs when an attacker sends a small packet
   with a spoofed source to a host or router that replies by sending a
   longer packet to the spoofed source.  To reduce the impact of such
   attacks, protocol designers try to avoid sending a long response
   after having received a small packet from a potentially spoofed
   source.


5.  Control-plane threats

   As pointed out in the previous sections, a good share of attacks can
   be avoided by securing the LISP control plane.

   Here the focus is not to analyze the security threats of any specific
   mapping distribution protocol.  Rather, the focus is to find a common
   set of requirements that existing or future mapping distribution
   protocols have to fulfill in order provide a sufficient level of
   security.




Saucez, et al.           Expires April 22, 2010                [Page 10]


Internet-Draft                LISP Security                 October 2009


   The LISP Map Server protocol will instead be analyzed since it is not
   related to any specific mapping distribution protocol.

   Work and experience performed in the DNSSEC [RFC4033] and SIDR [SIDR]
   can be useful here.

5.1.  Control-plane Requirements

   o  Authenticate the origin of a message.

   o  Identify the origin of a message.

   o  Prove that the mapping is generated by the owner of the EID or a
      third party allowed to generate such a mapping.

   o  Inject mappings in the mapping system only if the EID is allowed
      to be in the mapping system.

   o  Prove that the RLOCs associate to a mapping belong to the xTRs
      owning the mapping's EID.

   o  Low message overhead.

   o  Low traffic overhead.

   o  Low time overhead (avoid multiple RTTs).

   o  Other?

5.2.  LISP-Database coherence

   The mappings present on the LISP-Database of the different xTRs of a
   site should always be coherent.  An attacker should not be able to
   install different mappings for different xTRs.

   A simple approach is to have a central authority in the site that
   pushes all the mappings in the xTRs.  When a xTR decides to change
   something it informs the central authority, which will push the
   information to the other xTRs.

   Each xTR is authoritative on the reachability of its locator.  An xTR
   is not allowed to send updates to the central entity only if it is
   one of its RLOC.

   The central authority knows the configuration which RLOC is owned by
   which xTR.

   All of this does not prevent from securing the exchanges between the



Saucez, et al.           Expires April 22, 2010                [Page 11]


Internet-Draft                LISP Security                 October 2009


   xTRs and the central authority in order to avoid spoofing attacks.

5.3.  LISP Map Server

   The LISP Map Server is a fundamental building block of the whole LISP
   architecture, providing an additional level of indirection allowing
   to run mapping distribution protocols on machines different from
   xTRs.  From this point of view it can be considered a security
   improvement since xTR are not directly involved in the mapping
   distribution system.

   Things to look closer:

   o  Threats concerning messages.

   o  DoS attacks.

   o  Threats concerning LISP Map Server with caching.

   o  Others?


6.  Interaction between Data- and Control-plane

   It is clear that attacks targeting the data-plane can have side-
   effects on the control-plane and vice-versa.  Furthermore, attacks to
   the control-plane can be performed leveraging on the data-plane and
   vice-versa.

   An analysis of the possible threats has been performed in the
   previous sections.  Here we just characterize them following the
   above mentioned classification.

6.1.  Data-plane side effects on the control-plane

   To be done.

6.2.  Control-plane side effects on the data-plane

   To be done.

6.3.  Data-plane threats leveraging on the control-plane

   To be done.







Saucez, et al.           Expires April 22, 2010                [Page 12]


Internet-Draft                LISP Security                 October 2009


6.4.  Control-plane threats leveraging on the data-plane

   To be done.


7.  IANA Considerations

   This document makes no request of the IANA.


8.  Security Considerations

   Security considerations are the core of this document and do not need
   to be further discussed in this section.


9.  Acknowledgments

   This work has been partially supported by the INFSO-ICT-216372
   TRILOGY Project (www.trilogy-project.org).


10.  Normative References

   [I-D.bagnulo-lisp-threat]
              Bagnulo, M., "Preliminary LISP Threat Analysis",
              draft-bagnulo-lisp-threat-01 (work in progress),
              July 2007.

   [I-D.ietf-l2tpext-l2tp-base]
              Lau, J., "Layer Two Tunneling Protocol (Version 3)",
              draft-ietf-l2tpext-l2tp-base-15 (work in progress),
              December 2004.

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

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

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




Saucez, et al.           Expires April 22, 2010                [Page 13]


Internet-Draft                LISP Security                 October 2009


   [I-D.lear-lisp-nerd]
              Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-04 (work in progress), April 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.

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

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [SAVI]     IETF, "Source Address Validation Improvements Working
              Group", <http://tools.ietf.org/wg/savi/>.

   [SIDR]     IETF, "Secure Inter-Domain Routing Working Group",
              <http://tools.ietf.org/wg/sidr/>.

   [Saucez09]
              Saucez, D. and L. Iannone, "How to mitigate the effect of
              scans on mapping systems",  Submitted to the Trilogy
              Summer School on Future Internet.


Authors' Addresses

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

   Email: damien.saucez@uclouvain.be


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

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





Saucez, et al.           Expires April 22, 2010                [Page 14]


Internet-Draft                LISP Security                 October 2009


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

   Email: olivier.bonaventure@uclouvain.be












































Saucez, et al.           Expires April 22, 2010                [Page 15]