draft-ietf-lisp-ms-03.txt   draft-ietf-lisp-ms-04.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: April 2, 2010 September 29, 2009 Expires: April 8, 2010 October 5, 2009
LISP Map Server LISP Map Server
draft-ietf-lisp-ms-03.txt draft-ietf-lisp-ms-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2, 2010. This Internet-Draft will expire on April 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Interactions With Other LISP Components . . . . . . . . . . . 7 5. Interactions With Other LISP Components . . . . . . . . . . . 7
5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7
5.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 5.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7
5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8
5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 9 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 8
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
LISP [LISP] specifies an architecture and mechanism for replacing the LISP [LISP] specifies an architecture and mechanism for replacing the
skipping to change at page 5, line 28 skipping to change at page 5, line 28
appropriate EID-to-RLOC mapping by consulting the distributed appropriate EID-to-RLOC mapping by consulting the distributed
mapping database system. mapping database system.
Encapsulated Map-Request: a LISP Map-Request with an additional Encapsulated Map-Request: a LISP Map-Request with an additional
LISP header prepended. Sent to UDP destination port 4342. The LISP header prepended. Sent to UDP destination port 4342. The
"outer" addresses are globally-routeable IP addresses, also known "outer" addresses are globally-routeable IP addresses, also known
as RLOCs. Used by an ITR when sending to a Map-Resolver and by a as RLOCs. Used by an ITR when sending to a Map-Resolver and by a
Map-Server when sending to an ETR. Map-Server when sending to an ETR.
Negative Map-Reply: a LISP Map-Reply that contains an empty Negative Map-Reply: a LISP Map-Reply that contains an empty
locator-set. Returned in response to a Map-Request of the locator-set. Returned in response to a Map-Request if the
destination EID does not exist in the mapping database. destination EID does not exist in the mapping database.
Typically, this means that the "EID" being requested is an IP Typically, this means that the "EID" being requested is an IP
address connected to a non-LISP site. address connected to a non-LISP site.
Map-Register message: a LISP message sent by an ETR to a Map-Server Map-Register message: a LISP message sent by an ETR to a Map-Server
to register its associated EID prefixes. In addition to the set to register its associated EID prefixes. In addition to the set
of EID prefixes to register, the message includes one or more of EID prefixes to register, the message includes one or more
RLOCs to be be used by the Map-Server when forwarding Map-Requests RLOCs to be be used by the Map-Server when forwarding Map-Requests
(re-formatted as Encapsulated Map-Requests) received through the (re-formatted as Encapsulated Map-Requests) received through the
database mapping system. database mapping system.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
ETR, which responds with Map-Reply messages. ETR, which responds with Map-Reply messages.
The LISP Map-Server design also includes the operation of a Map- The LISP Map-Server design also includes the operation of a Map-
Resolver, which receives Encapsulated Map-Requests from its client Resolver, which receives Encapsulated Map-Requests from its client
ITRs and uses the distributed mapping database system to find the ITRs and uses the distributed mapping database system to find the
appropriate ETR to answer those requests. On the pilot network, a appropriate ETR to answer those requests. On the pilot network, a
Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels
configured to other ALT routers and uses BGP to learn paths to ETRs configured to other ALT routers and uses BGP to learn paths to ETRs
for different prefixes in the LISP+ALT database. The Map-Resolver for different prefixes in the LISP+ALT database. The Map-Resolver
uses this path information to forward Map-Requests over the ALT to uses this path information to forward Map-Requests over the ALT to
the correct ETRs. A Map-Resolver may operate in either a non-caching the correct ETRs. A Map-Resolver may operate in a non-caching mode,
mode, where it simply de-capsulates and forwards the Encapsulated where it simply de-capsulates and forwards the Encapsulated Map-
Map-Requests that it receives from ITRs, or in caching mode, where it Requests that it receives from ITRs. Alternatively, it may operate
saves information about those Map-Reqeusts, originates new Map- in a caching mode, where it saves information about oustanding Map-
Requests to the correct ETR, accepts and caches the Map-Replies, and Reqeusts, originates new Map-Requests to the correct ETR(s), accepts
finally forwards the Map-Replies to the original ITRs. and caches the Map-Replies, and finally forwards the Map-Replies to
the original ITRs.
Note that a single device can implement the functions of both a Map- Note that a single device can implement the functions of both a Map-
Server and a Map-Resolver. As is the case with the DNS, however, Server and a Map-Resolver. As is the case with the DNS, however,
operational simplicity argues for keeping those functions separate. operational simplicity argues for keeping those functions separate.
5. Interactions With Other LISP Components 5. Interactions With Other LISP Components
5.1. ITR EID-to-RLOC Mapping Resolution 5.1. ITR EID-to-RLOC Mapping Resolution
An ITR is configured with the address of a Map-Resolver. This An ITR is configured with the address of a Map-Resolver. This
skipping to change at page 7, line 52 skipping to change at page 7, line 52
LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver.
When doing this, an ITR should prefer querying an ETR learned through When doing this, an ITR should prefer querying an ETR learned through
the ALT network as LISP+ALT provides better information about the set the ALT network as LISP+ALT provides better information about the set
of define EID prefixes. Such a configuration is expected to be very of define EID prefixes. Such a configuration is expected to be very
rare, since there is little benefit to using a Map-Resolver if an ITR rare, since there is little benefit to using a Map-Resolver if an ITR
is already using a mapping database system. is already using a mapping database system.
5.2. ETR/Map-Server EID Prefix Registration 5.2. ETR/Map-Server EID Prefix Registration
An ETR publishes its EID prefixes on a Map-Server by sending LISP An ETR publishes its EID prefixes on a Map-Server by sending LISP
Map-Register messages. A Map-Register message is authenticated using Map-Register messages. A Map-Register message includes
an IPSec Authentication Header (AH) as defined in [RFC2402], with authentication data, so prior to sending a Map-Register message, the
SHA-1 or SHA-256 as the authentication HMAC. Prior to sending a Map- ETR and Map-Server must be configured with a secret shared-key. In
Register message, the ETR and Map-Server must be configured with a addition, a Map-Server will typically perform additional verification
secret shared-key. In addition, a Map-Server will typically perform checks, such as matching any EID-prefix listed in a Map-Register
additional verification checks, such as matching any EID-prefix message against a list of prefixes for which the ETR is known to be
listed in a Map-Register message against a list of prefixes for which an authoritative source.
the ETR is known to be an authoritative source.
Map-Register messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an ETR to a Map-
Server with a suggested interval between messages of one minute. A Server with a suggested interval between messages of one minute. A
Map-Server should time-out and remove an ETR's registration if it has Map-Server should time-out and remove an ETR's registration if it has
not received a valid Map-Register message within the past three not received a valid Map-Register message within the past three
minutes. When first contacting a Map-Server after restart or changes minutes. When first contacting a Map-Server after restart or changes
to its EID-to-RLOC database mappings, an ETR may initially send Map- to its EID-to-RLOC database mappings, an ETR may initially send Map-
Register messages at an increased frequency, up to one every 20 Register messages at an increased frequency, up to one every 20
seconds. This "quick registration" period is limited to five minutes seconds. This "quick registration" period is limited to five minutes
in duration. in duration.
skipping to change at page 11, line 7 skipping to change at page 10, line 7
A Map-Resolver can be set up to use "anycast", where where the same A Map-Resolver can be set up to use "anycast", where where the same
address is assigned to multiple Map-Resolvers and is propagated address is assigned to multiple Map-Resolvers and is propagated
through IGP routing, to facilitate the use of a topologically-close through IGP routing, to facilitate the use of a topologically-close
Map-Resolver each ITR. Note that Map-Server associations with ETRs Map-Resolver each ITR. Note that Map-Server associations with ETRs
should NOT use anycast addresses as doing so could cause should NOT use anycast addresses as doing so could cause
unpredictable forwarding of Map-Requests to the ETRs. unpredictable forwarding of Map-Requests to the ETRs.
6. Security Considerations 6. Security Considerations
Using the 2-way nonce exchange documented in [LISP] can be used to The 2-way nonce exchange documented in [LISP] can be used to avoid
avoid ITR spoofing attacks. ITR spoofing attacks.
To publish an authoratative EID-to-RLOC mapping, an ETR uses the To publish an authoratative EID-to-RLOC mapping with a Map-Server, an
IPsec AH to authenticate itself to a Map-Server. A pair-wise shared ETR includes authentication data that is a hash of the message using
key is used with SHA-1 or SHA-256. A key-chaining scheme may also be pair-wise shared key. An implementation MUST support use of HMAC-
employed to facilitate re-keying as needed. ESP is not used, since SHA-1-96 [RFC2404] and SHOULD support use of HMAC-SHA-128-256
the mapping data is considered to be public and does not need to be [RFC4634]. A key-chaining scheme may also be employed to facilitate
encrypted for transport. re-keying as needed.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
7.2. Informative References 7.2. Informative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-01.txt (work in progress), March 2009. draft-ietf-lisp-alt-01.txt (work in progress), March 2009.
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-03.txt (work in progress), draft-meyer-lisp-cons-03.txt (work in progress),
November 2007. November 2007.
skipping to change at page 13, line 7 skipping to change at page 12, line 7
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-05.txt (work in progress) (work in draft-ietf-lisp-05.txt (work in progress) (work in
progress), September 2009. progress), September 2009.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-04.txt (work in progress), draft-lear-lisp-nerd-04.txt (work in progress),
January 2008. January 2008.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would also like to thank the operational community for The authors would like to thank Greg Schudel, Darrel Lewis, John
feedback on the previous mapping database mechanisms. Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
and members of the lisp@ietf.org mailing list for their feedback and
helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work on Special thanks are due to Noel Chiappa for his extensive work on
caching with LISP-CONS, some of which will be used by Map-Resolvers. caching with LISP-CONS, some of which will be used by Map-Resolvers.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
 End of changes. 11 change blocks. 
36 lines changed or deleted 44 lines changed or added

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