draft-ietf-lisp-sec-12.txt   draft-ietf-lisp-sec-13.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: Experimental Cisco Systems
Expires: May 20, 2017 A. Cabellos Expires: March 24, 2018 A. Cabellos
Technical University of Catalonia Universitat Politecnica de Catalunya
D. Saucez D. Saucez
INRIA INRIA
November 16, 2016 September 20, 2017
LISP-Security (LISP-SEC) LISP-Security (LISP-SEC)
draft-ietf-lisp-sec-12 draft-ietf-lisp-sec-13
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 http://datatracker.ietf.org/drafts/current/. Drafts is at https://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 May 20, 2017. This Internet-Draft will expire on March 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://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
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.5. Provisioning of the shared keys . . . . . . . . . . . . . 18
7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 18 6.6. Reply Attacks . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19
7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19
7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19
7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 19 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20
7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. Normative References . . . . . . . . . . . . . . . . . . . . 20 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
Mapping System, and made available via the Map-Request/Map-Reply Mapping System, and made available via the Map-Request/Map-Reply
lookup process. If these EID-to-RLOC mappings, carried through Map- lookup process. If these EID-to-RLOC mappings, carried through Map-
skipping to change at page 12, line 18 skipping to change at page 12, line 18
In response to an encapsulated Map-Request that has the S-bit set, an In response to an encapsulated Map-Request that has the S-bit set, an
ITR MUST receive a Map-Reply with the S-bit set, that includes an ITR MUST receive a Map-Reply with the S-bit set, that includes an
EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the
ITR MUST discard it. In response to an encapsulated Map-Request with ITR MUST discard it. In response to an encapsulated Map-Request with
S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
the ITR SHOULD discard the Map-Reply if the S-bit is set. the ITR SHOULD discard the Map-Reply if the S-bit is set.
Upon receiving a Map-Reply, the ITR must verify the integrity of both Upon receiving a Map-Reply, the ITR must verify the integrity of both
the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of
the integrity checks fails. the integrity checks fails. After processing the Map-Reply, the ITR
must discard the <nonce,ITK-OTK> pair associated to the Map-Reply
The integrity of the EID-AD is verified using the locally stored ITR- The integrity of the EID-AD is verified using the locally stored ITR-
OTK to re-compute the HMAC of the EID-AD using the algorithm OTK to re-compute the HMAC of the EID-AD using the algorithm
specified in the EID HMAC ID field. If the EID HMAC ID field does specified in the EID HMAC ID field. If the EID HMAC ID field does
not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply
and send, at the first opportunity it needs to, a new Map-Request and send, at the first opportunity it needs to, a new Map-Request
with a different Requested HMAC ID field, according to ITR's local with a different Requested HMAC ID field, according to ITR's local
policy. The scope of the HMAC operation covers the entire EID-AD, policy. The scope of the HMAC operation covers the entire EID-AD,
from the EID-AD Length field to the EID HMAC field, which must be set from the EID-AD Length field to the EID HMAC field, which must be set
to 0 before the computation of the HMAC. to 0 before the computation of the HMAC.
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
Provisioning of the shared keys between the ITR and the Map-Resolver
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
draft. It is recommended that both shared keys are refreshed at
periodical intervals to address key aging or attackers gaining
unauthorized access to the shared keys. Shared keys should be
unpredictable random values.
6.6. Reply Attacks
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
<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>
that matches the incoming Map-Reply and will be discarded.
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
valid LISP-SEC computation and an attacker does not obtain any
benefit.
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 20, line 43 skipping to change at page 21, line 29
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,
<http://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-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, <http://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,
<http://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-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", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-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,
<http://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-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,
<http://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-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,
<http://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-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,
<http://www.rfc-editor.org/info/rfc6833>. <https://www.rfc-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, <http://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,
<http://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-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
skipping to change at page 22, line 22 skipping to change at page 23, line 4
Email: fmaino@cisco.com Email: fmaino@cisco.com
Vina Ermagan Vina Ermagan
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: vermagan@cisco.com Email: vermagan@cisco.com
Albert Cabellos Albert Cabellos
Technical University of Catalonia Universitat Politecnica de Catalunya
c/ Jordi Girona s/n c/ Jordi Girona s/n
Barcelona 08034 Barcelona 08034
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Damien Saucez Damien Saucez
INRIA INRIA
2004 route des Lucioles - BP 93 2004 route des Lucioles - BP 93
Sophia Antipolis Sophia Antipolis
 End of changes. 26 change blocks. 
29 lines changed or deleted 54 lines changed or added

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