[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/