RFC 6830
The Locator/ID Separation Protocol (LISP)
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
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.
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,
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.
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 Packets14.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.
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).
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.
[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.
[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.
[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.
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.
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