--- 1/draft-ietf-grow-ix-bgp-route-server-operations-00.txt 2013-08-28 11:14:23.220289560 -0700 +++ 2/draft-ietf-grow-ix-bgp-route-server-operations-01.txt 2013-08-28 11:14:23.248290272 -0700 @@ -1,23 +1,23 @@ GROW Working Group N. Hilliard Internet-Draft INEX Intended status: Informational E. Jasinska -Expires: February 23, 2014 Microsoft Corporation +Expires: March 01, 2014 Microsoft Corporation R. Raszuk NTT I3 N. Bakker AMS-IX B.V. - August 22, 2013 + August 28, 2013 Internet Exchange Route Server Operations - draft-ietf-grow-ix-bgp-route-server-operations-00 + draft-ietf-grow-ix-bgp-route-server-operations-01 Abstract The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. @@ -37,21 +37,21 @@ 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 February 23, 2014. + This Internet-Draft will expire on March 01, 2014. Copyright Notice Copyright (c) 2013 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 publication of this document. Please review these documents @@ -64,41 +64,41 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 4. Operational Considerations for Route Server Installations . . 5 4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6 - 4.2.1.1. View Merging and Decomposition . . . . . . . . . 6 + 4.2.1.1. View Merging and Decomposition . . . . . . . . . 7 4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7 4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8 4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9 4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9 4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9 4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10 4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 8.2. Informative References . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction - Internet exchange points (IXPs) provide IP data interconnection facilities for their participants, typically using shared Layer-2 networking media such as Ethernet. The Border Gateway Protocol (BGP) [RFC4271] is normally used to facilitate exchange of network reachability information over these media. As bilateral interconnection between IXP participants requires operational and administrative overhead, BGP route servers [I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP operators to provide a simple and convenient means of interconnecting @@ -456,35 +458,99 @@ routing control path between the two hosts is usually (but not always, due to IXP inter-switch connectivity load balancing algorithms) the same as the data path between them. Problems of this form can be dealt with using [RFC5881] bidirectional forwarding detection. However, as this is a bilateral protocol configured between routers, and as there is currently no means for automatic configuration of BFD between route server clients, BFD does not currently provide an optimal means of handling the problem. -5. Security Considerations +4.8. BGP NEXT_HOP Hijacking + + Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the + NEXT_HOP address of an NLRI update to be a different internet address + on the same subnet. This is the mechanism which allows route servers + to operate on a shared layer 2 IXP network. However, the mechanism + can be abused by route server clients to redirect traffic for their + prefixes to other IXP participant routers. + ____ + / \ + + | AS99 | + \____/ + / \ + / \ + __/ \__ + / \ / \ + ..| AS1 |..| AS2 |.. + : \___/ \___/ : + : \ / : + : \ / : + : \__/ : + : IXP / \ : + : | RS | : + : \____/ : + : : + .................... + + Figure 3: BGP NEXT_HOP Hijacking using a Route Server + + For example in Figure 3, if AS1 and AS2 both announce prefixes for + AS99 to the route server, AS1 could set the NEXT_HOP address for + AS99's prefixes to be the address of AS2's router, thereby diverting + traffic for AS99 via AS2. This may override the routing policies of + AS99 and AS2. + + Worse still, if the route server operator does not use inbound prefix + filtering, AS1 could announce any arbitrary prefix to the route + server with a NEXT_HOP address of any other IXP participant. This + could be used as a denial of service mechanism against either the + users of the address space being announced by illicitly diverting + their traffic, or the other IXP participant by overloading their + network with traffic which would not normally be sent there. + + This problem is not specific to route servers and it can also be + implemented using bilateral peering sessions. However, the potential + damage is amplified by route servers because a single BGP session can + be used to affect many networks simultaneously. + + Route server operators SHOULD check that the BGP NEXT_HOP attribute + for NLRIs received from a route server client matches the interface + address of the client. If the route server receives an NLRI where + these addresses are different and where the announcing route server + client is in a different autonomous system to the route server client + which uses the next hop address, the NLRI SHOULD be dropped. + +5. Security Considerations On route server installations which do not employ path hiding mitigation techniques, the path hiding problem outlined in section Section 4.1 can be used in certain circumstances to proactively block third party prefix announcements from other route server clients. + If the route server operator does not implement prefix leakage + mitigation as described in section Section 4.3, it is trivial for + route server clients to implement denial of service attacks against + arbitrary Internet networks using a route server. + + Route server installations SHOULD be secured against BGP NEXT_HOP + hijacking, as described in section Section 4.8. + 6. IANA Considerations There are no IANA considerations. 7. Acknowledgments - The authors would like to thank Chris Hall, Ryan Bickhart and Steven - Bakker for their valuable input. + The authors would like to thank Chris Hall, Ryan Bickhart, Steven + Bakker and Eduardo Ascenco Reis for their valuable input. In addition, the authors would like to acknowledge the developers of BIRD, OpenBGPD and Quagga, whose open source BGP implementations include route server capabilities which are compliant with this document. 8. References 8.1. Normative References