draft-ietf-lisp-ms-01.txt   draft-ietf-lisp-ms-02.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: November 27, 2009 May 26, 2009 Expires: March 8, 2010 September 4, 2009
LISP Map Server LISP Map Server
draft-ietf-lisp-ms-01.txt draft-ietf-lisp-ms-02.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 November 27, 2009. This Internet-Draft will expire on March 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 . . . . . . . . . . . . . . . . . 8 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 9
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 9 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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 6, line 10 skipping to change at page 6, line 10
For definitions of other terms, notably Map-Request, Map-Reply, For definitions of other terms, notably Map-Request, Map-Reply,
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please
consult the LISP specification [LISP]. consult the LISP specification [LISP].
4. Basic Overview 4. Basic Overview
A Map-Server is a device which publishes EID-prefix information on A Map-Server is a device which publishes EID-prefix information on
behalf of ETRs and connects to the LISP distributed mapping database behalf of ETRs and connects to the LISP distributed mapping database
system to help answer LISP Map-Requests seeking the RLOCs for those system to help answer LISP Map-Requests seeking the RLOCs for those
EID prefixes. To publish its EID-prefixes, an ETR sends Map-Register EID prefixes. To publish its EID-prefixes, an ETR periodically sends
messages to the Map-Server. A Map-Register message contains a list Map-Register messages to the Map-Server. A Map-Register message
of EID-prefixes plus a set of RLOCs that can be used to reach the ETR contains a list of EID-prefixes plus a set of RLOCs that can be used
when a Map-Server needs to forward a Map-Request to it. to reach the ETR when a Map-Server needs to forward a Map-Request to
it.
On the LISP pilot network, which is expected to be a model for On the LISP pilot network, which is expected to be a model for
deployment of LISP on the Internet, a Map-Server connects to LISP+ALT deployment of LISP on the Internet, a Map-Server connects to LISP+ALT
network and acts as a "last-hop" ALT router. Intermediate ALT network and acts as a "last-hop" ALT router. Intermediate ALT
routers forward Map-Requests to the Map-Server that advertises a routers forward Map-Requests to the Map-Server that advertises a
particular EID-prefix and the Map-Server forwards them to the owning particular EID-prefix and the Map-Server forwards them to the owning
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
skipping to change at page 7, line 51 skipping to change at page 7, line 51
another mapping database mechanism. For example, an ITR that runs another mapping database mechanism. For example, an ITR that runs
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 to a Map-Server by sending LISP An ETR publishes its EID prefixes on a Map-Server by sending LISP
Map-Register messages. The Map-Register message is authenticated Map-Register messages. A Map-Register message is authenticated using
using an IPSec Authentication Header (AH) as defined in [RFC2402], an IPSec Authentication Header (AH) as defined in [RFC2402], with
with MD5 as the authentication HMAC. Prior to sending a Map-Register SHA-1 or SHA-256 as the authentication HMAC. Prior to sending a Map-
message, the ETR and Map-Server must be configured with a secret Register message, the ETR and Map-Server must be configured with a
shared-key. In addition, a Map-Server will typically perform secret shared-key. In addition, a Map-Server will typically perform
additional verification checks, such as matching any EID-prefix additional verification checks, such as matching any EID-prefix
listed in a Map-Register message against a list of prefixes for which listed in a Map-Register message against a list of prefixes for which
the ETR is known to be an authoritative source. the ETR is known to be an authoritative source.
Map-Register messages are sent periodically from an ETR to a Map-
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
not received a valid Map-Register message within the past three
minutes. When first contacting a Map-Server after restart or changes
to its EID-to-RLOC database mappings, an ETR may initially send Map-
Register messages at an increased frequency, up to one every 20
seconds. This "quick registration" period is limited to five minutes
in duration.
An ETR which uses a Map-Server to publish its EID-to-RLOC mappings An ETR which uses a Map-Server to publish its EID-to-RLOC mappings
does not need to participate further in the mapping database does not need to participate further in the mapping database
protocol(s). On the pilot network, for example, this means that the protocol(s). On the pilot network, for example, this means that the
ETR does not need to implement GRE or BGP, which greatly simplifies ETR does not need to implement GRE or BGP, which greatly simplifies
its configuration and reduces its cost of operation. its configuration and reduces its cost of operation.
Note that use of a Map-Server does not preclude an ETR from also Note that use of a Map-Server does not preclude an ETR from also
connecting to the mapping database (i.e. it could also connect to the connecting to the mapping database (i.e. it could also connect to the
LISP+ALT network) but doing so doesn't seem particularly useful as LISP+ALT network) but doing so doesn't seem particularly useful as
the whole purpose of using a Map-Server is to avoid the complexity of the whole purpose of using a Map-Server is to avoid the complexity of
skipping to change at page 10, line 12 skipping to change at page 11, line 12
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 Using the 2-way nonce exchange documented in [LISP] can be used to
avoid ITR spoofing attacks. avoid ITR spoofing attacks.
To publish an authoratative EID-to-RLOC mapping, an ETR uses the To publish an authoratative EID-to-RLOC mapping, an ETR uses the
IPsec AH to authenticate itself to a Map-Server. A pair-wise shared IPsec AH to authenticate itself to a Map-Server. A pair-wise shared
key is used with MD5. A key-chaining scheme may also be employed to key is used with SHA-1 or SHA-256. A key-chaining scheme may also be
facilitate re-keying as needed. ESP is not used, since the mapping employed to facilitate re-keying as needed. ESP is not used, since
data is considered to be public and does not need to be encrypted for the mapping data is considered to be public and does not need to be
transport. encrypted for transport.
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.
skipping to change at page 11, line 31 skipping to change at page 12, line 31
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.
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-00.txt (work in progress), May 2009. draft-ietf-lisp-04.txt (work in progress) (work in
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 also like to thank the operational community for
feedback on the previous mapping database mechanisms. feedback on the previous mapping database mechanisms.
 End of changes. 9 change blocks. 
26 lines changed or deleted 38 lines changed or added

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