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]