Operational Security G. Van de Velde Internet-Draft K. Patel Updates: 792, 4443 (if approved) Cisco Systems Intended status: Standards Track May 24, 2012 Expires: November 25, 2012 BGP Remote-Next-Hop draft-vandevelde-idr-remote-next-hop-00 Abstract The BGP Remote-Next-Hop optional transitive attribute, provides an additional level of recursive route-lookup. The BGP Remote-Next-Hop attribute can be used, both on the public Internet infrastructure and within public or private Autonomous Systems (AS). The usage of BGP Remote-Next-Hop operates as ships-in-the-night and does not require any capability exchange for any BGP Session. BGP Remote-Next-Hop is providing the distribution of one or more Location Identifiers assigned to a particular BGP prefix or an NLRI. To secure the BGP prefix or NLRI entry BGP security mechanisms, either RPKI or other BGP mechanisms can be utilized. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 25, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Van de Velde & Patel Expires November 25, 2012 [Page 1] Internet-Draft BGP Remote-Next-Hop May 2012 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 1.2. Option Format: BGP Remote-Next-Hop . . . . . . . . . . . . 3 1.2.1. BGP Option Type . . . . . . . . . . . . . . . . . . . . 3 1.2.2. Option Format . . . . . . . . . . . . . . . . . . . . . 4 1.2.3. Remote-Next-Hop Attribute Format . . . . . . . . . . . 4 1.3. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . 5 1.3.1. Networks that do NOT support BGP Next-Hop-Attribute . . 5 1.3.2. Multi-homing for IPv6 . . . . . . . . . . . . . . . . . 5 1.3.3. Mapping Technology to compliment LISP . . . . . . . . . 6 1.3.4. Network Overlay Infrastructure . . . . . . . . . . . . 6 1.3.5. Reduction of the Routing Forwarding Information Base . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 3.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Van de Velde & Patel Expires November 25, 2012 [Page 2] Internet-Draft BGP Remote-Next-Hop May 2012 1. Introduction Each IP address (v4 or v6) represents a location and an identity. This is captured and developed by Locator Identity Split Protocol (LISP) and additionally documented by rfc6227 (Design Goals for Scalable Internet Routing) to scale the Internet. The optional transitive BGP Remote-Next-Hop attribute provides a mapping to complement and support mapping technologies (i.e. LISP) by using using BGP to distribute either a single or a set of locators attached to each entry in the BGP table. Based upon this locater information (the BGP Remote-Next-Hop) an overlay tunnel can be utilized and created. This overlay tunnel could be any type of IPv4- in-IPv4, IPv6-in-IPv4, IPv4-in-IPv6 or IPv6-in-IPv6, If a recipient node has no awareness or does not understand the BGP Remote-Next-Hop attribute then traditional BGP routing can be used as fallback mechanism. If the recipient node does understand the BGP Remote-Next-Hop attribute, then an overlay tunnel could be created i.e a LISP or IPoGRE tunnel. In addition, existing BGP security mechanisms can be used to verify the correctness of the BGP update including the validity of the BGP Remote-Next-Hop attribute. This will make sure that recipients of the BGP NLRI update which understand BGP Remote-Next-Hop, are not by accident tunneling to a malicious intermediate hop instead of the rightful BGP end-point. This note is defining the attribute for usage on Inter-AS and Intra-AS environments. Note that the Address Family (AF) of the NLRI exchanged is intended to be independent of the Address Family of the BGP Remote-Next-Hop attribute; hence the BGP Remote-Next-Hop attribute can be used within and between AF environments. 1.1. Requirements Language 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]. 1.2. Option Format: BGP Remote-Next-Hop 1.2.1. BGP Option Type Optional Transitive Van de Velde & Patel Expires November 25, 2012 [Page 3] Internet-Draft BGP Remote-Next-Hop May 2012 1.2.2. Option Format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attr. Flags |Attr. Type Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Remote-Next-Hop Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit 0: Set to 1 (Optional Attribute); Bit 1: Set to 1 (Transitional Attribute); Bit 2: Partial bit of the attribute; Depending on the size and entries within the BGP Remote-Next-Hop the attribute may be complete (set to 0) or partial (set to 1); Bit 3: Extended Length bit; Set to 0 if non-extended; Set to 1 if Extended length; Bit 4 to 7 Set to 0; Bit 8 to 15: Set to BGP Remote-Next-Hop attribute. Value to be defined by IANA; 1.2.3. Remote-Next-Hop Attribute Format The general format of this attribute describes the structure of the BGP Remote-Next-Hop attribute. Each attribute address family MUST be carried in a different Remote-Next-Hop container. (For example IPv4 and IPv6 will each need their own container) Each attribute can cary multiple BGP Remote-Next-Hop addresses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | BGP Remote-Next-Hop | Van de Velde & Patel Expires November 25, 2012 [Page 4] Internet-Draft BGP Remote-Next-Hop May 2012 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The coding mentioned here is Hexadecimals. If Address Family is set to 0 then it are IPv4 addresses. If Address Family is set to 1 then it are IPv6 addresses. Other values are reserved for the future purposes. The length field is encoded in number of Octets. BGP Remote-Next-Hop: the BGP Remote-Next-Hop addresses. 1.3. Usage Guidelines This section provides a short overview of some use-case scenarios for the BGP Remote-Next-Hop attribute. The usage of the BGP Remote-Next- Hop attribute is not limited to the examples discussed in this section. 1.3.1. Networks that do NOT support BGP Next-Hop-Attribute If a device does not support this attribute, then due to the Optional Transitive BGP character of this attribute will result that traditional routing is utilized with all the benefits and drawbacks. 1.3.2. Multi-homing for IPv6 When an IPv6 network is multi-homed towards the Internet, then it may be assigned with more than a single prefix. While the aspiration for these different assignments is to reduce the size of the Global Internet Routing table, it also results in well known resiliency issues discussed in a few IETF Working groups (if attribute idea gets accepted by WG, references will be added). The BGP Remote-Next-Hop attribute is providing a technology to glue these assigned IPv6 prefixes together and avoid some of the well known resiliency issues. So, how does this concept work? Assume you have a Node (=Source-Node) on Network (=Source-Network) and you would like to send something to your peer (Destination-Node) which is a device in Network (Destination-Network). With traditional routing a destination lookup is done, and forwarded each hop between Van de Velde & Patel Expires November 25, 2012 [Page 5] Internet-Draft BGP Remote-Next-Hop May 2012 Source-Node and Destination-node. What the attribute BGP Remote-Next-Hop provides is that when the Source-Node sends a packet to the Destination-Node it can be specially handled by the Source-Network edge-router. This device will look at the destination address of the packet, and check the BGP Remote-Next-Hop attribute (assuming that the edge-node supports that idea). That lookup will allow a device understanding the attribute, to select or create a tunnel towards the destination. Using this will result in having organizations built Internet overlays. 1.3.3. Mapping Technology to compliment LISP LISP, the Locator ID Split protocol, makes usage of a mapping technology to build up the tunnels to accommodate LISP. What this BGP Remote-Next-Hop attribute is providing is that it provides a mechanism to distribute tunnel end-points using existing BGP infrastructure without the need of anybody requiring to enable it. As result it will be ship in the night from both BGP as LISP perspective. 1.3.4. Network Overlay Infrastructure With the BGP Remote-Next-Hop feature it is possible to build and create an overlay tunneled network. By using this attribute, it is possible to have individual (Internet) Networks create sessions between them and make sure that the Internet and serviceability elements are kept correctly. 1.3.5. Reduction of the Routing Forwarding Information Base Right now there are about 50.000 Autonomous Systems distributed, which is way less as the useful entries in the existing FIB. The usage of double recursive reduction has as result that even if the routing table stays equal size, that the FIB (Traditionally ASIC Based Forwarding Table) when everybody is using this technology is reduced. ( We would go from 400K entries to 50k entries in the FIB). 2. IANA Considerations This memo asks the IANA for a new BGP Attribute assignment. Van de Velde & Patel Expires November 25, 2012 [Page 6] Internet-Draft BGP Remote-Next-Hop May 2012 3. Security Considerations This technology could be used as technology as man in the middle attack, however with existing RPKI validation for BGP that risk is reduced. Additional risks are still to be analysed by the working group and feedbacck received on the draft 3.1. Privacy Considerations This proposal could introduce privacy issues, however with BGP security mechanisms in place they are removed. 4. Acknowledgements To be completed 5. Change Log Initial Version: 16 May 2012 6. References 6.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 6.2. Informative References [RFC6227] Li, T., "Design Goals for Scalable Internet Routing", RFC 6227, May 2011. Van de Velde & Patel Expires November 25, 2012 [Page 7] Internet-Draft BGP Remote-Next-Hop May 2012 Authors' Addresses Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium Phone: +32 2704 5473 Email: gvandeve@cisco.com Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95124 95134 USA Phone: +32 2704 5473 Email: keyupate@cisco.com Van de Velde & Patel Expires November 25, 2012 [Page 8]