draft-ietf-lisp-sec-10.txt | draft-ietf-lisp-sec-11.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: October 15, 2016 A. Cabellos | Expires: April 6, 2017 A. Cabellos | |||
Technical University of Catalonia | Technical University of Catalonia | |||
D. Saucez | D. Saucez | |||
INRIA | INRIA | |||
April 13, 2016 | October 3, 2016 | |||
LISP-Security (LISP-SEC) | LISP-Security (LISP-SEC) | |||
draft-ietf-lisp-sec-10 | draft-ietf-lisp-sec-11 | |||
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 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
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 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 October 15, 2016. | This Internet-Draft will expire on April 6, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 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 | (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 | |||
skipping to change at page 3, line 18 ¶ | skipping to change at page 3, line 18 ¶ | |||
functions for routers to exchange information used to map from non- | functions for routers to exchange information used to map from non- | |||
routable Endpoint Identifiers (EIDs) to routable Routing Locators | routable Endpoint Identifiers (EIDs) to routable Routing Locators | |||
(RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply | (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply | |||
messages, are transmitted without integrity protection, an adversary | messages, are transmitted without integrity protection, an adversary | |||
can manipulate them and hijack the communication, impersonate the | can manipulate them and hijack the communication, impersonate the | |||
requested EID, or mount Denial of Service or Distributed Denial of | requested EID, or mount Denial of Service or Distributed Denial of | |||
Service attacks. Also, if the Map-Reply message is transported | Service attacks. Also, if the Map-Reply message is transported | |||
unauthenticated, an adversarial LISP entity can overclaim an EID- | unauthenticated, an adversarial LISP entity can overclaim an EID- | |||
prefix and maliciously redirect traffic directed to a large number of | prefix and maliciously redirect traffic directed to a large number of | |||
hosts. A detailed description of "overclaiming" attack is provided | hosts. A detailed description of "overclaiming" attack is provided | |||
in [I-D.ietf-lisp-threats]. | in [RFC7835]. | |||
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, ensuring that the sender of a | prefix claims in Map-Reply messages, ensuring that the sender of a | |||
Map-Reply that provides the location for a given EID-prefix is | Map-Reply that provides the location for a given EID-prefix is | |||
entitled to do so according to the EID prefix registered in the | entitled to do so according to the EID prefix registered in the | |||
associated Map-Server. Map-Register security, including the right | associated Map-Server. Map-Register security, including the right | |||
for a LISP entity to register an EID-prefix or to claim presence at | for a LISP entity to register an EID-prefix or to claim presence at | |||
skipping to change at page 4, line 21 ¶ | skipping to change at page 4, line 21 ¶ | |||
PKT-AD: The portion of Map-Reply Authentication Data used to | PKT-AD: The portion of Map-Reply Authentication Data used to | |||
protect the integrity of the Map-Reply message. | protect the integrity of the Map-Reply 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 | LISP-SEC addresses the control plane threats, described in [RFC7835], | |||
[I-D.ietf-lisp-threats], that target EID-to-RLOC mappings, including | that target EID-to-RLOC mappings, including manipulations of Map- | |||
manipulations of Map-Request and Map-Reply messages, and malicious | Request and Map-Reply messages, and malicious ETR EID prefix | |||
ETR EID prefix overclaiming. LISP-SEC makes two main assumptions: | overclaiming. LISP-SEC makes two main assumptions: (1) the LISP | |||
(1) the LISP mapping system is expected to deliver a Map-Request | mapping system is expected to deliver a Map-Request message to their | |||
message to their intended destination ETR as identified by the EID, | intended destination ETR as identified by the EID, and (2) no man-in- | |||
and (2) no man-in-the-middle (MITM) attack can be mounted within the | the-middle (MITM) attack can be mounted within the LISP Mapping | |||
LISP Mapping System. Furthermore, while LISP-SEC enables detection | System. Furthermore, while LISP-SEC enables detection of EID prefix | |||
of EID prefix overclaiming attacks, it assumes that Map-Servers can | overclaiming attacks, it assumes that Map-Servers can verify the EID | |||
verify the EID prefix authorization at time of registration. | prefix authorization at time of registration. | |||
According to the threat model described in [I-D.ietf-lisp-threats] | According to the threat model described in [RFC7835] LISP-SEC assumes | |||
LISP-SEC assumes that any kind of attack, including MITM attacks, can | that any kind of attack, including MITM attacks, can be mounted in | |||
be mounted in the access network, outside of the boundaries of the | the access network, outside of the boundaries of the LISP mapping | |||
LISP mapping system. An on-path attacker, outside of the LISP | system. An on-path attacker, outside of the LISP mapping system can, | |||
mapping system can, for example, hijack Map-Request and Map-Reply | for example, hijack Map-Request and Map-Reply messages, spoofing the | |||
messages, spoofing the identity of a LISP node. Another example of | identity of a LISP node. Another example of on-path attack, called | |||
on-path attack, called overclaiming attack, can be mounted by a | overclaiming attack, can be mounted by a malicious Egress Tunnel | |||
malicious Egress Tunnel Router (ETR), by overclaiming the EID- | Router (ETR), by overclaiming the EID-prefixes for which it is | |||
prefixes for which it is authoritative. In this way the ETR can | authoritative. In this way the ETR can maliciously redirect traffic | |||
maliciously redirect traffic directed to a large number of hosts. | directed to a large number of hosts. | |||
4. Protocol Operations | 4. Protocol Operations | |||
The goal of the security mechanisms defined in [RFC6830] is to | The goal of the security mechanisms defined in [RFC6830] is to | |||
prevent unauthorized insertion of mapping data by providing origin | prevent unauthorized insertion of mapping data by providing origin | |||
authentication and integrity protection for the Map-Registration, and | authentication and integrity protection for the Map-Registration, and | |||
by using the nonce to detect unsolicited Map-Reply sent by off-path | by using the nonce to detect unsolicited Map-Reply sent by off-path | |||
attackers. | attackers. | |||
LISP-SEC builds on top of the security mechanisms defined in | LISP-SEC builds on top of the security mechanisms defined in | |||
skipping to change at page 18, line 14 ¶ | skipping to change at page 18, line 14 ¶ | |||
8. Acknowledgements | 8. Acknowledgements | |||
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 | |||
[I-D.ietf-lisp-threats] | ||||
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats | ||||
Analysis", draft-ietf-lisp-threats-15 (work in progress), | ||||
January 2016. | ||||
[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>. | <http://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>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 19, line 10 ¶ | skipping to change at page 19, line 5 ¶ | |||
[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>. | <http://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>. | <http://www.rfc-editor.org/info/rfc6833>. | |||
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID | ||||
Separation Protocol (LISP) Threat Analysis", RFC 7835, | ||||
DOI 10.17487/RFC7835, April 2016, | ||||
<http://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 | |||
End of changes. 9 change blocks. | ||||
30 lines changed or deleted | 30 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/ |