draft-ietf-lisp-sec-13.txt   draft-ietf-lisp-sec-14.txt 
Network Working Group F. Maino Network Working Group F. Maino
Internet-Draft V. Ermagan Internet-Draft V. Ermagan
Intended status: Experimental Cisco Systems Intended status: Standards Track Cisco Systems
Expires: March 24, 2018 A. Cabellos Expires: April 28, 2018 A. Cabellos
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
D. Saucez D. Saucez
INRIA INRIA
September 20, 2017 October 25, 2017
LISP-Security (LISP-SEC) LISP-Security (LISP-SEC)
draft-ietf-lisp-sec-13 draft-ietf-lisp-sec-14
Abstract Abstract
This memo specifies LISP-SEC, a set of security mechanisms that This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process. LISP-SEC also enables verification of authorization on EID- process. LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages. prefix claims in Map-Reply messages.
Requirements Language Requirements Language
skipping to change at page 1, line 37 skipping to change at page 1, line 37
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2018. This Internet-Draft will expire on April 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 43 skipping to change at page 2, line 43
5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14
5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15
5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15
5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16
5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17
6.2. Random Number Generation . . . . . . . . . . . . . . . . 17 6.2. Random Number Generation . . . . . . . . . . . . . . . . 17
6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17
6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17
6.5. Provisioning of the shared keys . . . . . . . . . . . . . 18 6.5. Shared Keys Provisioning . . . . . . . . . . . . . . . . 18
6.6. Reply Attacks . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 18
6.7. Denial of Service and Distributed Denial of Service
Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19
7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19
7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 20
7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20
7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [RFC6830] is a network-layer-based The Locator/ID Separation Protocol [RFC6830] is a network-layer-based
protocol that enables separation of IP addresses into two new protocol that enables separation of IP addresses into two new
numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators
(RLOCs). EID-to-RLOC mappings are stored in a database, the LISP (RLOCs). EID-to-RLOC mappings are stored in a database, the LISP
skipping to change at page 4, line 23 skipping to change at page 4, line 25
Authentication Data used to protect the integrity of the Map-Reply Authentication Data used to protect the integrity of the Map-Reply
message. message.
For definitions of other terms, notably Map-Request, Map-Reply, For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server
(MS), and Map-Resolver (MR) please consult the LISP specification (MS), and Map-Resolver (MR) please consult the LISP specification
[RFC6830]. [RFC6830].
3. LISP-SEC Threat Model 3. LISP-SEC Threat Model
LISP-SEC addresses the control plane threats, described in [RFC7835], LISP-SEC addresses the control plane threats, described in section
that target EID-to-RLOC mappings, including manipulations of Map- 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including
Request and Map-Reply messages, and malicious ETR EID prefix manipulations of Map-Request and Map-Reply messages, and malicious
overclaiming. LISP-SEC makes two main assumptions: (1) the LISP ETR EID prefix overclaiming. LISP-SEC makes two main assumptions:
mapping system is expected to deliver a Map-Request message to their (1) the LISP mapping system is expected to deliver a Map-Request
intended destination ETR as identified by the EID, and (2) no man-in- message to their intended destination ETR as identified by the EID,
the-middle (MITM) attack can be mounted within the LISP Mapping and (2) no man-in-the-middle (MITM) attack can be mounted within the
System. How the Mapping System is protected from MITM attacks LISP Mapping System. How the Mapping System is protected from MITM
depends from the particular Mapping Systems used, and is out of the attacks depends from the particular Mapping Systems used, and is out
scope of this memo. Furthermore, while LISP-SEC enables detection of of the scope of this memo. Furthermore, while LISP-SEC enables
EID prefix overclaiming attacks, it assumes that Map-Servers can detection of EID prefix overclaiming attacks, it assumes that Map-
verify the EID prefix authorization at time of registration. Servers can verify the EID prefix authorization at time of
registration.
According to the threat model described in [RFC7835] LISP-SEC assumes According to the threat model described in [RFC7835] LISP-SEC assumes
that any kind of attack, including MITM attacks, can be mounted in that any kind of attack, including MITM attacks, can be mounted in
the access network, outside of the boundaries of the LISP mapping the access network, outside of the boundaries of the LISP mapping
system. An on-path attacker, outside of the LISP mapping system can, system. An on-path attacker, outside of the LISP mapping system can,
for example, hijack Map-Request and Map-Reply messages, spoofing the for example, hijack Map-Request and Map-Reply messages, spoofing the
identity of a LISP node. Another example of on-path attack, called identity of a LISP node. Another example of on-path attack, called
overclaiming attack, can be mounted by a malicious Egress Tunnel overclaiming attack, can be mounted by a malicious Egress Tunnel
Router (ETR), by overclaiming the EID-prefixes for which it is Router (ETR), by overclaiming the EID-prefixes for which it is
authoritative. In this way the ETR can maliciously redirect traffic authoritative. In this way the ETR can maliciously redirect traffic
skipping to change at page 18, line 26 skipping to change at page 18, line 26
As an example at the other end of the spectrum, in certain other As an example at the other end of the spectrum, in certain other
deployments, attackers may be very sophisticated, and force the deployments, attackers may be very sophisticated, and force the
deployers to enforce very strict policies in term of HMAC algorithms deployers to enforce very strict policies in term of HMAC algorithms
accepted by an ITR. accepted by an ITR.
Similar considerations apply to the entire LISP-SEC threat model, and Similar considerations apply to the entire LISP-SEC threat model, and
should guide the deployers and implementors whenever they encounter should guide the deployers and implementors whenever they encounter
the key word SHOULD across this memo. the key word SHOULD across this memo.
6.5. Provisioning of the shared keys 6.5. Shared Keys Provisioning
Provisioning of the shared keys between the ITR and the Map-Resolver Provisioning of the keys shared between the ITR and the Map-Resolver
as well as between the ETR and the Map-Server should be performed via as well as between the ETR and the Map-Server should be performed via
an orchestration infrastructure and it is out of the scope of this an orchestration infrastructure and it is out of the scope of this
draft. It is recommended that both shared keys are refreshed at draft. It is recommended that both shared keys are refreshed at
periodical intervals to address key aging or attackers gaining periodical intervals to address key aging or attackers gaining
unauthorized access to the shared keys. Shared keys should be unauthorized access to the shared keys. Shared keys should be
unpredictable random values. unpredictable random values.
6.6. Reply Attacks 6.6. Replay Attacks
An attacker can capture a valid Map-Request and/or Map-Reply and An attacker can capture a valid Map-Request and/or Map-Reply and
reply it, however once the ITR receives the original Map-Reply the replay it, however once the ITR receives the original Map-Reply the
<nonce,ITR-OTK> pair stored at the ITR will be discarded. If a <nonce,ITR-OTK> pair stored at the ITR will be discarded. If a
replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK> replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK>
that matches the incoming Map-Reply and will be discarded. that matches the incoming Map-Reply and will be discarded.
In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR
will have to do a LISP-SEC computation. This is equivalent to a will have to do a LISP-SEC computation. This is equivalent to a
valid LISP-SEC computation and an attacker does not obtain any valid LISP-SEC computation and an attacker does not obtain any
benefit. benefit.
6.7. Denial of Service and Distributed Denial of Service Attacks
LISP-SEC mitigates the risks of Denial of Service and Distributed
Denial of Service attacks by protecting the integrity and
authenticating the origin of the Map-Request/Map-Reply messages, and
by preventing malicious ETRs from overclaiming EID prefixes that
could re-direct traffic directed to a potentially large number of
hosts.
7. IANA Considerations 7. IANA Considerations
7.1. ECM AD Type Registry 7.1. ECM AD Type Registry
IANA is requested to create the "ECM Authentication Data Type" IANA is requested to create the "ECM Authentication Data Type"
registry with values 0-255, for use in the ECM LISP-SEC Extensions registry with values 0-255, for use in the ECM LISP-SEC Extensions
Section 5.1. The registry MUST be initially populated with the Section 5.1. The registry MUST be initially populated with the
following values: following values:
Name Value Defined In Name Value Defined In
skipping to change at page 21, line 28 skipping to change at page 21, line 34
The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino
Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt
Noll for their valuable suggestions provided during the preparation Noll for their valuable suggestions provided during the preparation
of this document. of this document.
9. Normative References 9. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2104>. editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <https://www.rfc-editor.org/info/rfc3394>. September 2002, <https://www.rfc-editor.org/info/rfc3394>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc4086>. editor.org/info/rfc4086>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5869>. editor.org/info/rfc5869>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6234>. editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6830>. editor.org/info/rfc6830>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc6833>. editor.org/info/rfc6833>.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>. January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7835>. editor.org/info/rfc7835>.
Authors' Addresses Authors' Addresses
Fabio Maino Fabio Maino
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: fmaino@cisco.com Email: fmaino@cisco.com
 End of changes. 24 change blocks. 
45 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/