Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6830

The Locator/ID Separation Protocol (LISP)

Pages: 75
Experimental
Updated by:  8113
Part 4 of 4 – Pages 64 to 75
First   Prev   None

Top   ToC   RFC6830 - Page 64   prevText

11. Multicast Considerations

A multicast group address, as defined in the original Internet architecture, is an identifier of a grouping of topologically independent receiver host locations. The address encoding itself does not determine the location of the receiver(s). The multicast routing protocol, and the network-based state the protocol creates, determine where the receivers are located. In the context of LISP, a multicast group address is both an EID and a Routing Locator. Therefore, no specific semantic or action needs to be taken for a destination address, as it would appear in an IP header. Therefore, a group address that appears in an inner IP header built by a source host will be used as the destination EID. The outer IP header (the destination Routing Locator address), prepended by a LISP router, will use the same group address as the destination Routing Locator. Having said that, only the source EID and source Routing Locator need to be dealt with. Therefore, an ITR merely needs to put its own IP address in the source 'Routing Locator' field when prepending the outer IP header. This source Routing Locator address, like any other Routing Locator address, MUST be globally routable. Therefore, an EID-to-RLOC mapping does not need to be performed by an ITR when a received data packet is a multicast data packet or when processing a source-specific Join (either by IGMPv3 or PIM). But the source Routing Locator is decided by the multicast routing protocol in a receiver site. That is, an EID-to-RLOC translation is done at control time. Another approach is to have the ITR not encapsulate a multicast packet and allow the packet built by the host to flow into the core even if the source address is allocated out of the EID namespace. If the RPF-Vector TLV [RFC5496] is used by PIM in the core, then core
Top   ToC   RFC6830 - Page 65
   routers can RPF to the ITR (the locator address, which is injected
   into core routing) rather than the host source address (the EID
   address, which is not injected into core routing).

   To avoid any EID-based multicast state in the network core, the first
   approach is chosen for LISP-Multicast.  Details for LISP-Multicast
   and interworking with non-LISP sites are described in [RFC6831] and
   [RFC6832].

12. Security Considerations

It is believed that most of the security mechanisms will be part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. For data-plane-triggered mappings, as described in this specification, protection is provided against ETR spoofing by using route-returnability (see Section 3) mechanisms evidenced by the use of a 24-bit 'Nonce' field in the LISP encapsulation header and a 64-bit 'Nonce' field in the LISP control message. The nonce, coupled with the ITR accepting only solicited Map-Replies, provides a basic level of security, in many ways similar to the security experienced in the current Internet routing system. It is hard for off-path attackers to launch attacks against these LISP mechanisms, as they do not have the nonce values. Sending a large number of packets to accidentally find the right nonce value is possible but would already by itself be a denial-of-service (DoS) attack. On-path attackers can perform far more serious attacks, but on-path attackers can launch serious attacks in the current Internet as well, including eavesdropping, blocking, or redirecting traffic. See more discussion on this topic in Section 6.1.5.1. LISP does not rely on a PKI or a more heavyweight authentication system. These systems challenge one of the primary design goals of LISP -- scalability. DoS attack prevention will depend on implementations rate-limiting Map-Requests and Map-Replies to the control plane as well as rate-limiting the number of data-triggered Map-Replies. An incorrectly implemented or malicious ITR might choose to ignore the Priority and Weights provided by the ETR in its Map-Reply. This traffic-steering would be limited to the traffic that is sent by this ITR's site and no more severe than if the site initiated a bandwidth DoS attack on (one of) the ETR's ingress links. The ITR's site would typically gain no benefit from not respecting the Weights and would likely receive better service by abiding by them.
Top   ToC   RFC6830 - Page 66
   To deal with map-cache exhaustion attempts in an ITR/PITR, the
   implementation should consider putting a maximum cap on the number of
   entries stored with a reserve list for special or frequently accessed
   sites.  This should be a configuration policy control set by the
   network administrator who manages ITRs and PITRs.  When overlapping
   EID-Prefixes occur across multiple Map-Cache entries, the integrity
   of the set must be wholly maintained.  So, if a more-specific entry
   cannot be added due to reaching the maximum cap, then none of the
   less-specific entries should be stored in the map-cache.

   Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings,
   cache sizing and maintenance are issues to be kept in mind during
   implementation.  It is a good idea to have instrumentation in place
   to detect thrashing of the cache.  Implementation experimentation
   will be used to determine which cache management strategies work
   best.  In general, it is difficult to defend against cache-thrashing
   attacks.  It should be noted that an undersized cache in an ITR/PITR
   not only causes adverse effects on the site or region it supports but
   may also cause increased Map-Request loads on the mapping system.

   "Piggybacked" mapping data as discussed in Section 6.1.3 specifies
   how to handle such mappings and includes the possibility for an ETR
   to temporarily accept such a mapping before verification when running
   in "trusted" environments.  In such cases, there is a potential
   threat that a fake mapping could be inserted (even if only for a
   short period) into a map-cache.  As noted in Section 6.1.3, an ETR
   MUST be specifically configured to run in such a mode and might
   usefully only consider some specific ITRs as also running in that
   same trusted environment.

   There is a security risk implicit in the fact that ETRs generate the
   EID-Prefix to which they are responding.  An ETR can claim a shorter
   prefix than it is actually responsible for.  Various mechanisms to
   ameliorate or resolve this issue will be examined in the future
   [LISP-SEC].

   Spoofing of inner-header addresses of LISP-encapsulated packets is
   possible, as with any tunneling mechanism.  ITRs MUST verify the
   source address of a packet to be an EID that belongs to the site's
   EID-Prefix range prior to encapsulation.  An ETR must only
   decapsulate and forward datagrams with an inner-header destination
   that matches one of its EID-Prefix ranges.  If, upon receipt and
   decapsulation, the destination EID of a datagram does not match one
   of the ETR's configured EID-Prefixes, the ETR MUST drop the datagram.
   If a LISP-encapsulated packet arrives at an ETR, it SHOULD compare
   the inner-header source EID address and the outer-header source RLOC
   address with the mapping that exists in the mapping database.  Then,
Top   ToC   RFC6830 - Page 67
   when spoofing attacks occur, the outer-header source RLOC address can
   be used to trace back the attack to the source site, using existing
   operational tools.

   This experimental specification does not address automated key
   management (AKM).  BCP 107 [RFC4107] provides guidance in this area.
   In addition, at the time of this writing, substantial work is being
   undertaken to improve security of the routing system [RFC6518]
   [RFC6480] [BGP-SEC] [LISP-SEC].  Future work on LISP should address
   the issues discussed in BCP 107 as well as other open security
   considerations, which may require changes to this specification.

13. Network Management Considerations

Considerations for network management tools exist so the LISP protocol suite can be operationally managed. These mechanisms can be found in [LISP-MIB] and [RFC6835].

14. IANA Considerations

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the LISP specification, in accordance with BCP 26 [RFC5226]. There are four namespaces (listed in the sub-sections below) in LISP that have been registered. o LISP IANA registry allocations should not be made for purposes unrelated to LISP routing or transport protocols. o The following policies are used here with the meanings defined in BCP 26: "Specification Required", "IETF Review", "Experimental Use", and "First Come First Served".

14.1. LISP ACT and Flag Fields

New ACT values (Section 6.1.4) can be allocated through IETF review or IESG approval. Four values have already been allocated by this specification (Section 6.1.4). In addition, LISP has a number of flag fields and reserved fields, such as the LISP header flags field (Section 5.3). New bits for flags in these fields can be implemented after IETF review or IESG approval, but these need not be managed by IANA.
Top   ToC   RFC6830 - Page 68

14.2. LISP Address Type Codes

LISP Address [LCAF] type codes have a range from 0 to 255. New type codes MUST be allocated consecutively, starting at 0. Type Codes 0-127 are to be assigned by IETF review or IESG approval. Type Codes 128-255 are available according to the [RFC5226] First Come First Served policy. This registry, initially empty, is constructed for future use in experimental work related to LISP Canonical Address Format (LCAF) values. See [LCAF] for details of other possible unapproved address encodings. The unapproved LCAF encodings are an area for further study and experimentation.

14.3. LISP UDP Port Numbers

The IANA registry has allocated UDP port numbers 4341 and 4342 for lisp-data and lisp-control operation, respectively. IANA has updated the description for UDP ports 4341 and 4342 as follows: lisp-data 4341 udp LISP Data Packets lisp-control 4342 udp LISP Control Packets

14.4. LISP Key ID Numbers

The following Key ID values are defined by this specification as used in any packet type that references a 'Key ID' field: Name Number Defined in ----------------------------------------------- None 0 n/a HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-256-128 2 [RFC4868] Number values are in the range of 0 to 65535. The allocation of values is on a first come first served basis.

15. Known Open Issues and Areas of Future Work

As an experimental specification, this work is, by definition, incomplete. Specific areas where additional experience and work are needed include the following: o At present, only [RFC6836] is defined for implementing a database of EID-to-RLOC mapping information. Additional research on other mapping database systems is strongly encouraged.
Top   ToC   RFC6830 - Page 69
   o  Failure and recovery of LISP site partitioning (see Section 6.4)
      in the presence of redundant configuration (see Section 8.5) needs
      further research and experimentation.

   o  The characteristics of map-cache management under exceptional
      conditions, such as denial-of-service attacks, are not fully
      understood.  Further experience is needed to determine whether
      current caching methods are practical or in need of further
      development.  In particular, the performance, scaling, and
      security characteristics of the map-cache will be discovered as
      part of this experiment.  Performance metrics to be observed are
      packet reordering associated with the LISP Data-Probe and loss of
      the first packet in a flow associated with map-caching.  The
      impact of these upon TCP will be observed.  See Section 12 for
      additional thoughts and considerations.

   o  Preliminary work has been done to ensure that sites employing LISP
      can interconnect with the rest of the Internet.  This work is
      documented in [RFC6832], but further experimentation and
      experience are needed.

   o  At present, no mechanism for automated key management for message
      authentication is defined.  Addressing automated key management is
      necessary before this specification can be developed into a
      Standards Track RFC.  See Section 12 for further details regarding
      security considerations.

   o  In order to maintain security and stability, Internet protocols
      typically isolate the control and data planes.  Therefore, user
      activity cannot cause control-plane state to be created or
      destroyed.  LISP does not maintain this separation.  The degree to
      which the loss of separation impacts security and stability is a
      topic for experimental observation.

   o  LISP allows for the use of different mapping database systems.
      While only one [RFC6836] is currently well defined, each mapping
      database will likely have some impact on the security of the
      EID-to-RLOC mappings.  How each mapping database system's security
      properties impact LISP overall is for further study.

   o  An examination of the implications of LISP on Internet traffic,
      applications, routers, and security is needed.  This will help
      implementors understand the consequences for network stability,
      routing protocol function, routing scalability, migration and
      backward compatibility, and implementation scalability (as
      influenced by additional protocol components; additional state;
      and additional processing for encapsulation, decapsulation, and
      liveness).
Top   ToC   RFC6830 - Page 70
   o  Experiments need to verify that LISP produces no significant
      change in the behavior of protocols run between end-systems over a
      LISP infrastructure versus being run directly between those same
      end-systems.

   o  Experiments need to verify that the issues raised in the Critique
      section of [RFC6115] are either insignificant or have been
      addressed by updates to LISP.

   Other LISP documents may also include open issues and areas for
   future work.

16. References

16.1. Normative References

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
Top   ToC   RFC6830 - Page 71
   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
              HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
              May 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5496]  Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [RFC6115]  Li, T., "Recommendation for a Routing Architecture",
              RFC 6115, February 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6833]  Farinacci, D. and V. Fuller, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              January 2013.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              January 2013.

   [RFC6836]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol Alternative Logical
              Topology (LISP+ALT)", RFC 6836, January 2013.

16.2. Informative References

[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>. [BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work in Progress, May 2012. [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed Enhancement to the Internet Architecture", 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. [CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", Work in Progress, April 2008.
Top   ToC   RFC6830 - Page 72
   [EMACS]    Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
              Mappings Multicast Across Cooperating Systems for LISP",
              Work in Progress, November 2007.

   [LCAF]     Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
              Address Format (LCAF)", Work in Progress, January 2013.

   [LISA96]   Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
              "Renumbering: Threat or Menace?", Usenix Tenth System
              Administration Conference (LISA 96), October 1996.

   [LISP-DEPLOY]
              Jakab, L., Cabellos-Aparicio, A., Coras, F.,
              Domingo-Pascual, J., and D. Lewis, "LISP Network Element
              Deployment Considerations", Work in Progress,
              October 2012.

   [LISP-MIB] Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work
              in Progress, January 2013.

   [LISP-MN]  Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
              Mobile Node", Work in Progress, October 2012.

   [LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
              Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress,
              October 2012.

   [LOC-ID-ARCH]
              Meyer, D. and D. Lewis, "Architectural Implications of
              Locator/ID Separation", Work in Progress, January 2009.

   [OPENLISP] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
              Implementation Report", Work in Progress, July 2008.

   [RADIR]    Narten, T., "On the Scalability of Internet Routing", Work
              in Progress, February 2010.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.
Top   ToC   RFC6830 - Page 73
   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic
              Key Management", BCP 107, RFC 4107, June 2005.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              September 2005.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              February 2012.

   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
              Locator/ID Separation Protocol (LISP) for Multicast
              Environments", RFC 6831, January 2013.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832, January 2013.

   [RFC6835]  Farinacci, D. and D. Meyer, "The Locator/ID Separation
              Protocol Internet Groper (LIG)", RFC 6835, January 2013.

   [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
              Routing Locator (RLOC) Database", RFC 6837, January 2013.

   [UDP-TUNNELS]
              Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
              UDP Checksums for Tunneled Packets", Work in Progress,
              January 2013.

   [UDP-ZERO] Fairhurst, G. and M. Westerlund, "Applicability Statement
              for the use of IPv6 UDP Datagrams with Zero Checksums",
              Work in Progress, December 2012.
Top   ToC   RFC6830 - Page 74

Appendix A. Acknowledgments

An initial thank you goes to Dave Oran for planting the seeds for the initial ideas for LISP. His consultation continues to provide value to the LISP authors. A special and appreciative thank you goes to Noel Chiappa for providing architectural impetus over the past decades on separation of location and identity, as well as detailed reviews of the LISP architecture and documents, coupled with enthusiasm for making LISP a practical and incremental transition for the Internet. The authors would like to gratefully acknowledge many people who have contributed discussions and ideas to the making of this proposal. They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, and Alia Atlas. This work originated in the Routing Research Group (RRG) of the IRTF. An individual submission was converted into the IETF LISP working group document that became this RFC. The LISP working group would like to give a special thanks to Jari Arkko, the Internet Area AD at the time that the set of LISP documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward experimental RFCs.
Top   ToC   RFC6830 - Page 75

Authors' Addresses

Dino Farinacci Cisco Systems Tasman Drive San Jose, CA 95134 USA EMail: farinacci@gmail.com Vince Fuller EMail: vaf@vaf.net Dave Meyer Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: dmm@1-4-5.net Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA USA EMail: darlewis@cisco.com