draft-ietf-lisp-ms-13.txt   draft-ietf-lisp-ms-14.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: June 8, 2012 December 6, 2011 Expires: June 18, 2012 December 16, 2011
LISP Map Server Interface LISP Map Server Interface
draft-ietf-lisp-ms-13.txt draft-ietf-lisp-ms-14.txt
Abstract Abstract
This draft describes the Maping Service for the Locator Identifier This draft describes the Maping Service for the Locator Identifier
Separation Protocol (LISP), implemented by two new types of LISP- Separation Protocol (LISP), implemented by two new types of LISP-
speaking devices, the LISP Map Resolver and LISP Map Server, that speaking devices, the LISP Map Resolver and LISP Map Server, that
provides a simplified "front end" to for one or more Endpoint ID to provides a simplified "front end" to for one or more Endpoint ID to
Routing Locator mapping databases. Routing Locator mapping databases.
By using this service interface and communicating with Map Resolvers By using this service interface and communicating with Map Resolvers
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 June 8, 2012. This Internet-Draft will expire on June 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 2, line 20 skipping to change at page 2, line 20
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
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Interactions With Other LISP Components . . . . . . . . . . . 7 4. Interactions With Other LISP Components . . . . . . . . . . . 6
4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 4.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 6
4.2. EID Prefix Configuration and ETR Registration . . . . . . 8 4.2. EID Prefix Configuration and ETR Registration . . . . . . 7
4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 9 4.3. Map Server Processing . . . . . . . . . . . . . . . . . . 8
4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 10 4.4. Map Resolver Processing . . . . . . . . . . . . . . . . . 9
4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 12 4.4.1. Anycast Map Resolver Operation . . . . . . . . . . . . 10
5. Open Issues and Considerations . . . . . . . . . . . . . . . . 13 5. Open Issues and Considerations . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
[LISP], the Locator Identifier Separation Protocol, specifies an [LISP], the Locator Identifier Separation Protocol, specifies an
architecture and mechanism for replacing the addresses currently used architecture and mechanism for replacing the addresses currently used
by IP with two separate name spaces: Endpoint IDs (EIDs), used within by IP with two separate name spaces: Endpoint IDs (EIDs), used within
sites, and Routing Locators (RLOCs), used on the transit networks sites, and Routing Locators (RLOCs), used on the transit networks
that make up the Internet infrastructure. To achieve this that make up the Internet infrastructure. To achieve this
separation, LISP defines protocol mechanisms for mapping from EIDs to separation, LISP defines protocol mechanisms for mapping from EIDs to
RLOCs. In addition, LISP assumes the existence of a database to RLOCs. In addition, LISP assumes the existence of a database to
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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.
A Map Resolver receives Encapsulated Map-Requests from its client A Map Resolver receives Encapsulated Map-Requests from its client
ITRs and uses a mapping database system to find the appropriate ETR ITRs and uses a mapping database system to find the appropriate ETR
to answer those requests. On a LISP+ALT network, a Map Resolver acts to answer those requests. On a LISP+ALT network, a Map Resolver acts
as a "first-hop" ALT router. It has GRE tunnels configured to other as a "first-hop" ALT router. It has GRE tunnels configured to other
ALT routers and uses BGP to learn paths to ETRs for different ALT routers and uses BGP to learn paths to ETRs for different
prefixes in the LISP+ALT database. The Map Resolver uses this path prefixes in the LISP+ALT database. The Map Resolver uses this path
information to forward Map-Requests over the ALT to the correct ETRs. information to forward Map-Requests over the ALT to the correct ETRs.
During initial deployment, a Map Resolver will operate only in a non-
caching mode, where it simply de-capsulates and forwards the
Encapsulated Map-Requests that it receives from ITRs.
In future deployments, a Map Resolver may operate in a caching mode, Note that while it is conceivable that a Map Resolver could cache
where it saves information about outstanding Map-Requests, originates responses to improve performance, issues surrounding cache management
new Map-Requests to the correct ETR(s), accepts and caches the Map- will need to be resolved for doing so to be reliable and practical.
Replies, and finally forwards the Map-Replies to the original ITRs. As initially deployed, Map Resolvers will operate only in a non-
One significant issue with use of caching in a Map Resolver is that caching mode, de-decapsulating and forwarding Encapsulated Map
it hides the original ITR source of a Map-Request, which prevents an Requests received from ITRs. Any specification of caching
ETR from tailoring its responses to that source; this reduces the functionality is left for future work.
inbound traffic- engineering capability for the site owning the ETR.
In addition, caching in a Map Resolver exacerbates problems
associated with old mappings being cached; an outdated, cached
mapping in an ITR affects only that ITR and traffic originated by its
site while an outdated, cached mapping in a Map Resolver could cause
a problem with a wider scope. More experience with caching Map
Resolvers on the LISP pilot network will be needed to determine
whether their use can be recommended.
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 and, in many cases, the functions will be Server and a Map Resolver and, in many cases, the functions will be
co-located in that way. co-located in that way.
Detailed descriptions of the LISP packet types referenced by this Detailed descriptions of the LISP packet types referenced by this
document may be found in [LISP]. document may be found in [LISP].
4. Interactions With Other LISP Components 4. Interactions With Other LISP Components
skipping to change at page 10, line 34 skipping to change at page 9, line 34
If none of the ETRs have requested proxy reply service, then the Map If none of the ETRs have requested proxy reply service, then the Map
Server re-encapsulates and forwards the resulting Encapsulated Map- Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not otherwise alter
the Map-Request so any Map-Reply sent by the ETR is returned to the the Map-Request so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map Server. Unless also acting RLOC in the Map-Request, not to the Map Server. Unless also acting
as a Map Resolver, a Map Server should never receive Map-Replies; any as a Map Resolver, a Map Server should never receive Map-Replies; any
such messages should be discarded without response, perhaps such messages should be discarded without response, perhaps
accompanied by logging of a diagnostic message if the rate of Map- accompanied by logging of a diagnostic message if the rate of Map-
Replies is suggestive of malicious traffic. Replies is suggestive of malicious traffic.
A Map Server may also receive a Map-Request that is contained inside
of an Encapsulated Control Message (an Encapsulated Map-Request) with
the "Security" bit ("S-bit") set. It processes the security
parameters as described in [LISP-SEC] then handles the Map-Request as
as described above.
Note that a Map Server that is sending a Map-Reply on behalf of an
ETR (performing proxy reply service) must perform security processing
for that ETR as well; see [LISP-SEC] for details.
4.4. Map Resolver Processing 4.4. Map Resolver Processing
Upon receipt of an Encapsulated Map-Request, a Map Resolver de- Upon receipt of an Encapsulated Map-Request, a Map Resolver de-
capsulates the enclosed message then searches for the requested EID capsulates the enclosed message then searches for the requested EID
in its local database of mapping entries (statically configured, in its local database of mapping entries (statically configured or
cached, or learned from associated ETRs when the Map Resolver is also learned from associated ETRs if the Map Resolver is also a Map Server
acting as a Map Server). If it finds a matching entry, it returns a offering proxy reply service). If it finds a matching entry, it
non-authoritative LISP Map-Reply with the known mapping. returns a LISP Map-Reply with the known mapping.
If the Map Resolver does not have the mapping entry and if it can If the Map Resolver does not have the mapping entry and if it can
determine that the EID is not in the mapping database (for example, determine that the EID is not in the mapping database (for example,
if LISP+ALT is used, the Map Resolver will have an ALT forwarding if LISP+ALT is used, the Map Resolver will have an ALT forwarding
table that covers the full EID space) it immediately returns a table that covers the full EID space) it immediately returns a
negative LISP Map-Reply, with action code "forward-native" and a 15- negative LISP Map-Reply, with action code "forward-native" and a 15-
minute TTL. To minimize the number of negative cache entries needed minute TTL. To minimize the number of negative cache entries needed
by an ITR, the Map Resolver should return the least-specific prefix by an ITR, the Map Resolver should return the least-specific prefix
which both matches the original query and does not match any EID- which both matches the original query and does not match any EID-
prefix known to exist in the LISP-capable infrastructure. prefix known to exist in the LISP-capable infrastructure.
If the Map Resolver does not have sufficient information to know If the Map Resolver does not have sufficient information to know
whether the EID exists, it needs to forward the Map-Request to whether the EID exists, it needs to forward the Map-Request to
another device which has more information about the EID being another device which has more information about the EID being
requested. This is done in one of two ways: requested. To do this, it forwards the unencapsulated Map-Request,
with the original ITR RLOC as the source, to the mapping database
1. A non-caching Map Resolver simply forwards the unencapsulated system. Using LISP+ALT, the Map Resolver is connected to the ALT
Map-Request, with the original ITR RLOC as the source, to the network and sends the Map-Request to the next ALT hop learned from
mapping database system. Using LISP+ALT, the Map Resolver is its ALT BGP neighbors. The Map Resolver does not send any response
connected to the ALT network and sends the Map-Request to the to the ITR; since the source RLOC is that of the ITR, the ETR or Map
next ALT hop learned from its ALT BGP neighbors. The Map Server which receives the Map-Request over the ALT and responds will
Resolver does not send any response to the ITR; since the source do so directly to the ITR.
RLOC is that of the ITR, the ETR or Map Server which receives the
Map-Request over the ALT and responds will do so directly to the
ITR.
2. A caching Map Resolver queues information from the Encapsulated
Map-Request, including the ITR RLOC and the original Map-Request
message nonce. It then modifies the Map-Request to use its own
RLOC, generates a "local nonce" (which is also saved in the
request queue entry), and forwards the Map-Request as above.
When the Map Resolver receives a Map-Reply, it looks in its
request queue to match the reply nonce to a "local nonce" entry
then de-queues the entry and uses the saved original nonce and
ITR RLOC to re-write those fields in the Map-Reply before sending
to the ITR. The request queue entry is also deleted and the
mapping entries from the Map-Reply are saved in the Map
Resolver's cache.
If a Map Resolver receives a Map-Request contained in an Encapsulated
Control Message (an Encapsulated Map-Request) with the "security"
option ("S-Bit") set, additional processing is required. It extracts
the enclosed Map-Request and uses the attached security paramaters to
generate a new Encapsulated Control Message containing the original
Map-Request and additional signature information used to protect both
the Map-Request and the Map-Reply that will be generated by the
destination ETR or Map Server. The outgoing message will have the
"S-bit" set, will use the requested EID as its outer header
destination IP address plus Map Resolver RLOC as source IP address,
and will include security parameters added by the Map Resolver. See
[LISP-SEC] for details of the checks that are performed and the
security information that is added during the de-encapsulation and
re-encapsulation process.
4.4.1. Anycast Map Resolver Operation 4.4.1. Anycast Map Resolver Operation
A Map Resolver can be set up to use "anycast", where the same address A Map Resolver can be set up to use "anycast", where the same address
is assigned to multiple Map Resolvers and is propagated through IGP is assigned to multiple Map Resolvers and is propagated through IGP
routing, to facilitate the use of a topologically-close Map Resolver routing, to facilitate the use of a topologically-close Map Resolver
each ITR. each ITR.
Note that Map Server associations with ETRs should not use anycast Note that Map Server associations with ETRs should not use anycast
addresses as registrations need to be established between an ETR and addresses as registrations need to be established between an ETR and
skipping to change at page 13, line 15 skipping to change at page 11, line 15
5. Open Issues and Considerations 5. Open Issues and Considerations
There are a number of issues with the Map Server and Map Resolver There are a number of issues with the Map Server and Map Resolver
design that are not yet completely understood. Among these are: design that are not yet completely understood. Among these are:
o Constants, such as those used for Map-Register frequency, o Constants, such as those used for Map-Register frequency,
retransmission timeouts, retransmission limits, negative Map-Reply retransmission timeouts, retransmission limits, negative Map-Reply
TTLs, et al are subject to further refinement as more experience TTLs, et al are subject to further refinement as more experience
with prototype deployment is gained. with prototype deployment is gained.
o Feasibility, performance, and complexity trade-offs of
implementing caching in Map Resolvers, as discussed in Section 3,
Paragraph 4.
o Convergence time when an EID-to-RLOC mapping changes and o Convergence time when an EID-to-RLOC mapping changes and
mechanisms for detecting and refreshing or removing stale, cached mechanisms for detecting and refreshing or removing stale, cached
information information
o Deployability and complexity trade-offs of implementing stronger o Deployability and complexity trade-offs of implementing stronger
security measures in both EID-prefix registration and Map-Request/ security measures in both EID-prefix registration and Map-Request/
Map-Reply processing Map-Reply processing
o Requirements for additional state in the registration process o Requirements for additional state in the registration process
between Map Servers and ETRs between Map Servers and ETRs
skipping to change at page 15, line 26 skipping to change at page 13, line 26
During experimental and prototype deployment, all authentication key During experimental and prototype deployment, all authentication key
configuration will be manual. Should LISP and its components be configuration will be manual. Should LISP and its components be
considered for IETF standardization, further work will be required to considered for IETF standardization, further work will be required to
follow the BCP 107 [RFC4107] recommendations on automated key follow the BCP 107 [RFC4107] recommendations on automated key
management. management.
As noted in Section 4.2, a Map Server should verify that all EID- As noted in Section 4.2, a Map Server should verify that all EID-
prefixes registered by an ETR match configuration stored on the Map prefixes registered by an ETR match configuration stored on the Map
Server. Server.
[LISP-SEC] defines a mechanism for providing origin authentication, [LISP-SEC] defines a proposed mechanism for providing origin
integrity, anti-reply protection, and prevention of man-in-the-middle authentication, integrity, anti-reply protection, and prevention of
and "overclaiming" attacks on the Map-Request/Map-Reply exchange. man-in-the-middle and "overclaiming" attacks on the Map-Request/
Map-Reply exchange. Work is ongoing on this and other proposals for
resolving these open security issues
While beyond the scope of securing an individual Map Server or Map While beyond the scope of securing an individual Map Server or Map
Resolver, it should be noted that a BGP-based LISP+ALT network (if Resolver, it should be noted that a BGP-based LISP+ALT network (if
ALT is used as the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) can take
advantage of technology being developed by the IETF SIDR working advantage standards work on adding security to BGP.
group or either S-BGP [I-D.murphy-bgp-secr] or soBGP
[I-D.white-sobgparchitecture] should they be developed and widely
deployed.
8. References 8. References
8.1. Normative References 8.1. Normative 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-10.txt (work in progress), draft-ietf-lisp-alt-10.txt (work in progress),
October 2011. October 2011.
[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-15.txt (work in progress), July 2011. draft-ietf-lisp-15.txt (work in progress), July 2011.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
(work in progress), July 2011.
[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.
[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,
February 1997. February 1997.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
8.2. Informative References 8.2. Informative References
[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-04.txt (work in progress), draft-meyer-lisp-cons-04.txt (work in progress),
April 2008. April 2008.
[I-D.murphy-bgp-secr]
Murphy, S., "BGP Security Analysis",
draft-murphy-bgp-secr-04 (work in progress),
November 2001.
[I-D.white-sobgparchitecture]
White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)",
draft-white-sobgparchitecture-00 (work in progress),
May 2004.
[LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [LISP-MN] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Mobile Node Architecture", draft-meyer-lisp-mn-05.txt Mobile Node Architecture", draft-meyer-lisp-mn-05.txt
(work in progress), May 2011. (work in progress), May 2011.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O.
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-00.txt
(work in progress), July 2011.
[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-08.txt (work in progress), draft-lear-lisp-nerd-08.txt (work in progress),
March 2010. March 2010.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Greg Schudel, Darrel Lewis, John
 End of changes. 15 change blocks. 
115 lines changed or deleted 47 lines changed or added

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