Internet DRAFT - draft-brim-lisp-analysis
draft-brim-lisp-analysis
Network Working Group LISP Authors
Internet-Draft cisco
Intended status: Experimental March 10, 2008
Expires: September 11, 2008
LISP Analysis
draft-brim-lisp-analysis-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 11, 2008.
LISP Authors Expires September 11, 2008 [Page 1]
Internet-Draft LISP Analysis March 2008
Abstract
This draft answers questions raised in the IRTF Routing Reseach Group
Design Goals. A future version may also address issues raised in the
IETF Routing Area Problem Statement.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Authorship . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Routing Research Group Design Goals . . . . . . . . . . . . . 6
4.1. Improved Routing Scalability . . . . . . . . . . . . . . . 6
4.2. Scalable Support for Traffic Engineering . . . . . . . . . 6
4.3. Scalable Support for Multihoming . . . . . . . . . . . . . 7
4.4. Scalable Support for Mobility . . . . . . . . . . . . . . 8
4.5. Simplified Renumbering . . . . . . . . . . . . . . . . . . 9
4.6. Decoupling Location and Identification . . . . . . . . . . 9
4.7. First-Class Elements . . . . . . . . . . . . . . . . . . . 9
4.8. Routing Quality . . . . . . . . . . . . . . . . . . . . . 10
4.9. Routing Security . . . . . . . . . . . . . . . . . . . . . 11
4.10. Deployability . . . . . . . . . . . . . . . . . . . . . . 12
5. Routing Research Group Design Goals . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
LISP Authors Expires September 11, 2008 [Page 2]
Internet-Draft LISP Analysis March 2008
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
LISP Authors Expires September 11, 2008 [Page 3]
Internet-Draft LISP Analysis March 2008
2. Authorship
The authors of this specification are Scott Brim, Dino Farinacci,
Vince Fuller, Eliot Lear, Darrel Lewis, David Meyer, and David Oran.
LISP Authors Expires September 11, 2008 [Page 4]
Internet-Draft LISP Analysis March 2008
3. Introduction
This document discusses LISP (Locator/Identifier Separation Protocol)
[lisp], and how the LISP protocol answers issues raised in the IRTF
Routing Research Group design goals [rrg]. A future version may
address issues raised in the IETF Routing Area problem statement
[radir].
In general "map-and-encapsulate" approaches to routing and addressing
architecture allow one to decouple the two aspects of mapping and
encapsulating. In the case of LISP there is one base encapsulation
protocol, and a number of possible mapping mechanisms. Because of
the looseness of this coupling it is difficult to analyze "LISP".
Some potentially interesting mapping mechanisms have been proposed
but are still very incomplete. Therefore this document primarily
discusses the base LISP protocol, and then discusses possibilities
with some of the mapping mechanisms but does not try to be a complete
survey.
LISP Authors Expires September 11, 2008 [Page 5]
Internet-Draft LISP Analysis March 2008
4. Routing Research Group Design Goals
If the text from the design goals draft is not too long, it is
included at the start of each section for context.
4.1. Improved Routing Scalability
"Long experience with inter-domain routing has shown us that the
global BGP routing table is continuing to grow rapidly
[BGPGrowth]. Carrying this large amount of state in the control
plane is expensive and places undue cost burdens on network
participants that do not necessarily get value from the
increases in the routing table size.
Thus, the first required goal is to provide significant
improvement to the scalability of the control plane. It is
strongly desired to make the control plane scale independently
from the growth of the Internet user population."
There are three aspects to routing scalability:
o The amount of state in a router's routing databases.
o The rate of change of a routing database.
o Convergence time.
Principally the scalability problem is in the core of the Internet
(the "default-free zone"), not in the periphery.
A map-and-encapsulate approach such as LISP removes routing
information from the core of the Internet by removing announcements
of prefixes at the edge. Edge site routing and core routing are
decoupled. Also, edge sites are the source of most routing
volatility. When edge prefix announcements are removed, routing has
significantly less churn. LISP reaches these non-globally-routed
EIDs by encapsulating packets to them in an outer IP header and a
LISP header at an ITR (ingress tunnel router) and decapsulating them
at an ETR (egress tunnel router). No extra processing is required
within edge sites or at core routers. They perceive no difference in
their protocols.
4.2. Scalable Support for Traffic Engineering
"Traffic engineering is the capability of directing traffic
along paths other than those that would be computed by normal
IGP/EGP routing. Inter-domain traffic engineering today is
frequently accomplished by injecting more-specific prefixes into
LISP Authors Expires September 11, 2008 [Page 6]
Internet-Draft LISP Analysis March 2008
the global routing table, which results in a negative impact on
routing scalability. A scalable solution for inter-domain
traffic engineering is strongly desired."
There are several kinds of traffic engineering. The focus of this
item is on the desire to have particular prefixes in a domain reached
via particular edge routers.
With LISP, BGP is used as it is today for the core of the Internet,
and the current mechanisms can be used. For the edge of the
Internet, where EIDs are no longer globally routed, LISP supports TE
by communicating priorities for ETRs. The details depend on the
mapping mechanism used, but generally a mapping also includes
priorities as to which ETR the ITR should use for a particular
prefix. Thus this design goal is met directly, not by using a
routing protocol to implement policy indirectly as is done now.
These priorities can be updated dynamically, on a per-flow basis by
using ETR reachability in LISP packet headers as well as by LISP
mapping control messages. No handling is required except at the
xTRs.
In addition, with LISP a site has more policy-based control of how
traffic reaches it than it does now with BGP, where a site's wishes
can be overridden unexpectedly by intermediate routers.
4.3. Scalable Support for Multihoming
"Multi-homing is the capability of an organization to be
connected to the Internet via more than one other organization.
The current mechanism for supporting multi-homing is to let the
organization advertise one or multiple prefixes into the global
routing system, again resulting in a negative impact on routing
scalability. More scalable solutions for multi-homing are
strongly desired."
LISP solves this problem, supporting multihoming scalably and with
lower operating expense, by mapping and encapsulating. Map-and-
encapsulate removes routing state from the core of the Internet while
allowing fine-grain control of how a prefix is reached. Also, LISP
allows a site to get multihoming without requiring it to run BGP in
its edge routers. Not only that, but with mapping systems such as
LISP-ALT [alt], the policy controlling multihoming can be dynamic.
Since the decision about how to tell a remote site to reach a
particular prefix is made by the destination site's ETR, the decision
can be made on the fly. It does not need to be pre-configured.
LISP Authors Expires September 11, 2008 [Page 7]
Internet-Draft LISP Analysis March 2008
4.4. Scalable Support for Mobility
"Mobility is the capability of a host, network, or organization
to change its topological connectivity with respect to the
remainder of the Internet, while continuing to receive packets
from the Internet. Existing mechanisms to provide mobility
support include (1) renumbering the mobile entity as it changes
its topological attachment point(s) to the Internet; (2)
renumbering and creating a tunnel from the entity's new
topological location back to its original location; and (3)
letting the mobile entity announce its prefixes from its new
attachment point(s). The first approach alone is considered
unsatisfactory as the change of IP address may break existing
transport or higher level connections for those protocols using
IP addresses as identifiers. The second requires the deployment
of a 'home agent' to keep track of the mobile entity's current
location and adds overhead to the routers involved, as well as
adding stretch to the path of inbound packet. Neither of the
first two approaches impacts the routing scalability. The third
approach, however, injects dynamic updates into the global
routing system as the mobile entity moves. Mechanisms that help
to provide more efficient and scalable mobility support are
desired, especially when they can be coupled with security and
support topological changes at a high-rate."
Since the next section is on ease of renumbering, only "fast"
mobility will be discussed in this section.
With regard to a single entity moving rapidly and wishing to maintain
its IP address, LISP does not intend, and does not believe it is
important, for global routing to maintain what is essentially a
network attachment identifier as a node changes its network
attachment. Solutions to disruption of sessions due to changing IP
address (the first approach mentioned above) should not be sought in
IP routing. Mobility is important, and routing and addressing
architecture must support mobility as a major way of using the
Internet, but that does not mean that direct support mechanisms must
be built into routing.
Routing and addressing are fundamental, and the Internet community
has learned through experience that it is important to architect for
generality and flexibility, and not for support of specific things
running on that architecture. Therefore there is no need for the
third approach mentioned above for individual devices. It can be
used, but it does not need to be used. If it is used, LISP and LISP
mapping approaches can support it. It can be supported directly
using LISP-ALT for mapping, through gleaning mapping information from
data packet LISP headers, and through expedited remapping. It can
LISP Authors Expires September 11, 2008 [Page 8]
Internet-Draft LISP Analysis March 2008
also be supported in conjunction with Mobile IP (the second approach
above). The constraints on its use come in the size of the mapping
cache in ITRs and thrashing of the mapping system if it needs to be
updated, but not in core routing. This approach can be used for
whole networks moving as well.
As for the second approach (MIP), a node will always need a "home"
where it can be found by others establishing new sessions with it.
Even updates to DNS will have some latency. Therefore we need at
least the first part of MIP, the home agent and initial tunneling of
packets, no matter what else we do. Since there is hardly any
deployment of MIPv6 and only partial deployment of MIPv4, we need not
be constrained by the details of those particular approaches.
4.5. Simplified Renumbering
The goal is to make it easier to change upstream providers without
renumbering.
Renumbering is "slow mobility". Under LISP, a site can change
upstream providers with or without changing its prefix. If it keeps
its prefix, information fed to the mapping system needs to be
changed. This can be done -- limitations are not technical. If it
changes its prefix, nothing in routing needs to change.
4.6. Decoupling Location and Identification
The goal is to avoid the problems of coupling endpoint attachment
point information and identification information.
The principal goal of LISP is to save core routing by reducing the
amount of "rate*state" it experiences. It can also be used to
support network layer routing by any network layer names. LISP only
assumes that an EID is globally unique and can be used to deliver
packets within the site in which the EID can be found. Sites are
able to use anything they want as EIDs as long as the site has peer
sites with which its users can communicate using those EIDs. LISP
documentation assumes that EIDs will be continuations of current IP
addresses because this is the most likely deployment path.
4.7. First-Class Elements
"If a solution makes use of a mechanism, it is strongly desired
that the mechanism be a first-class element in the architecture
[FirstClass]. More specifically, if a tunneling mechanism is
used to provide network layering, connectivity virtualization,
or a connection-oriented mode, then it is strongly desired that
the tunneling mechanism be a first-class element in the
LISP Authors Expires September 11, 2008 [Page 9]
Internet-Draft LISP Analysis March 2008
architecture."
This seems to be true for LISP. Further analysis requires further
discussion of the goal.
4.8. Routing Quality
The goal is to have a routing system that produces routes that are at
least as good as today's routes in terms of convergence, stability
and stretch.
The LISP mapping mechanism is for RLOC discovery. Paths for actual
forwarding of LISP-encapsulated packets across the core are
controlled by BGP, running as now, or whatever replaces it.
Therefore, to start with the quality of paths selected using LISP is
at least as good as those currently produced by BGP. However,
routing quality is improved in several ways.
Because both state and rate will be reduced in the core by removal of
the most volatile and error-prone routing information (that from the
edge), stability and convergence time will improve. Because there is
a better possibility of traffic engineering and policy-based routing
with LISP, destination sites can control their ingress points better
and quality of paths may be better from their point of view. They
are not subject to route damping or unexpected policies in the middle
of the network. Finally, with easier and more ubiquitous use of
active-active multi-homing, traffic will be more evenly spread across
the core, and the experienced quality of paths will improve.
Currently when a CE goes down, it takes some time for BGP to converge
so that packets from a remote site can reestablish a good route.
With LISP, when an xTR goes down all packets from within the site
will start flowing through a different xTR (assuming there is one),
and they will arrive at the remote xTR with the locator reachability
bits set to indicate that the first xTR is no longer useable. The
remote site will be able to change its routing for all prefixes to
use the new xTR immediately, without waiting for BGP convergence.
This benefit can be characterized in further research.
There has been concern about delay in some proposed mapping
mechanisms. Initial experiments suggest that when delay occurs, it
is not highly significant. This issue is being pursued and cannot be
resolved until more information is collected.
LISP can support multicast. A draft is being prepared.
Stability in the mapping system depends on which mapping mechanism is
used. All of the ones currently being considered are inherently
LISP Authors Expires September 11, 2008 [Page 10]
Internet-Draft LISP Analysis March 2008
stable because only one source is recognized as authoritative for a
particular EID prefix to RLOC mapping. LISP-ALT is inherently stable
because information is only distributed from the destination site's
ETRs or their representatives. In ALT, new prefix mappings can be
added to the system without affecting stability because their
announcement is quickly absorbed by aggregation. NERD [nerd] is
stable because the flow of information is administrative and there is
no reason for thrashing unless the sources are thrashing.
4.9. Routing Security
"Currently, the routing subsystem is secured through a number of
protocol specific mechanisms of varying strength and
applicability. Any new architecture is required to provide at
least the same level of security as is deployed as of when the
new architecture is deployed."
The current system of routers, and BGP, will continue to be used for
routing of LISP-encapsulated packets. Therefore for routing and
forwarding across the Internet core, the same security issues and
practices apply as are used now.
As in any Locator/identifier split approach, a critical operation is
the creation of Locator to ID binding state that devices will use
over time. In the case of LISP, the critical operation is the
creation of EID prefix to RLOC mappings in the ITR and the ETR.
These mappings can be obtained in three ways:
o By using information obtained from a LISP data packet.
o By using information contained in a Map-Reply message.
o By using an EID prefix to RLOC mapping system.
LISP mitigates attacks on the first two techniques by including a
nonce in the LISP header. The nonce is a 32-bit randomly generated
number (generated by the source ITR), and is used to test route
returnability. More specifically, an ETR will echo the nonce back to
the ITR in a Map-Reply message. The nonce, combined with the ITR
accepting only solicited Map-Replies provides a base level of
authentication for Map-Replies. Note that these techniques do not
protect against Man-In-The-Middle attacks.
The LISP design assumes that mapping systems will all employ the
security mechanisms of the technologies they are built on. If a
mapping system is used (the third technique above) the particular
mapping system chosen will inherit the security characteristics of
its technologies.
LISP Authors Expires September 11, 2008 [Page 11]
Internet-Draft LISP Analysis March 2008
As a mapping system, LISP-ALT shares many of the security
characteristics of BGP. Its security mechanisms are comprised of
existing technologies in wide operational use today. Securing LISP-
ALT is much simpler than securing BGP. Compared to BGP, LISP-ALT
routers are not topologically bound, allowing them to be put in
locations away from the vulnerable AS border (unlike eBGP speakers).
4.10. Deployability
"Since solutions that are not deployable are simply academic
exercises, solutions are required to be deployable from a
technical perspective. Furthermore, given the extensive
deployed base of today's Internet, a solution is required to be
incrementally."
Deployability includes many things, from operational burden to
ability to coexist with current and future deployments of other
approaches.
IPv4 will be with us for years. For IPv4, because of utilization and
address size we have no choice but to use a map-and-encapsulate
strategy. Address rewriting strategies are only viable for IPv6, and
adopting them requires some kind of encapsulation or translation for
IPv4. LISP has a strategy that works for both IPv4 and IPv6.
LISP does not require changes within sites or in the Internet core.
Changes are only required at xTRs and in the LISP mapping system.
Network operators who have been polled have said they prefer changes
at site edges more than changes in user systems.
LISP can be incrementally deployed, and when doing SNAT according to
the LISP interworking draft [interwk], prefixes can be withdrawn from
the main BGP routing system right away during the early stages of
LISP deployment. This can give core routing an immediate lessening
of load while increasing capability -- one of the critical goals of
this effort.
LISP does not require new silicon to be deployed. xTR functionality
can be deployed in software-based routers, and updated quickly. As
needs are discovered they can be met right away.
By using a map-and-encapsulate approach instead of header rewriting,
you have complete visibility of EIDs as well as RLOCs. A rewrite
scheme loses information that may be needed by ACLs in firewalls and
other security processes.
Compared to management of BGP, management of LISP is trivial. This
has been experienced in actual deployments.
LISP Authors Expires September 11, 2008 [Page 12]
Internet-Draft LISP Analysis March 2008
LISP is the only approach whose documentation you can implement from,
and thus truly test its viability.
LISP Authors Expires September 11, 2008 [Page 13]
Internet-Draft LISP Analysis March 2008
5. Routing Research Group Design Goals
TBD
LISP Authors Expires September 11, 2008 [Page 14]
Internet-Draft LISP Analysis March 2008
6. Security Considerations
See Section 4.9.
LISP Authors Expires September 11, 2008 [Page 15]
Internet-Draft LISP Analysis March 2008
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[alt] Fuller, V., "LISP Alternative Topology (LISP-ALT)",
draft-fuller-lisp-alt-01.txt (work in progress),
November 2007.
[interwk] Lewis, D., "Interworking LISP with IPv4 and IPv6",
draft-lewis-lisp-interworking-00.txt (work in progress),
December 2007.
[lisp] Farinacci, D., "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp--06.txt (work in progress),
February 2008.
[nerd] Lear, E., "A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-03.txt (work in progress),
January 2008.
[rrg] Li, T., "Design Goals for Scalable Internet Routing",
draft-irtf-rrg-design-goals-01.txt (work in progress),
July 2007.
7.2. Informative References
[radir] Narten, T., "Routing and Addressing Problem Statement",
draft-narten-radir-problem-statement-00.txt (work in
progress), July 2007.
LISP Authors Expires September 11, 2008 [Page 16]
Internet-Draft LISP Analysis March 2008
Author's Address
LISP Authors
cisco
Tasman Drive
San Jose, CA 95134
USA
Email: lisp-beta@external.cisco.com
LISP Authors Expires September 11, 2008 [Page 17]
Internet-Draft LISP Analysis March 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
LISP Authors Expires September 11, 2008 [Page 18]
