draft-ietf-grow-ix-bgp-route-server-operations-00.txt | draft-ietf-grow-ix-bgp-route-server-operations-01.txt | |||
---|---|---|---|---|
GROW Working Group N. Hilliard | GROW Working Group N. Hilliard | |||
Internet-Draft INEX | Internet-Draft INEX | |||
Intended status: Informational E. Jasinska | Intended status: Informational E. Jasinska | |||
Expires: February 23, 2014 Microsoft Corporation | Expires: March 01, 2014 Microsoft Corporation | |||
R. Raszuk | R. Raszuk | |||
NTT I3 | NTT I3 | |||
N. Bakker | N. Bakker | |||
AMS-IX B.V. | AMS-IX B.V. | |||
August 22, 2013 | August 28, 2013 | |||
Internet Exchange Route Server Operations | Internet Exchange Route Server Operations | |||
draft-ietf-grow-ix-bgp-route-server-operations-00 | draft-ietf-grow-ix-bgp-route-server-operations-01 | |||
Abstract | Abstract | |||
The popularity of Internet exchange points (IXPs) brings new | The popularity of Internet exchange points (IXPs) brings new | |||
challenges to interconnecting networks. While bilateral eBGP | challenges to interconnecting networks. While bilateral eBGP | |||
sessions between exchange participants were historically the most | sessions between exchange participants were historically the most | |||
common means of exchanging reachability information over an IXP, the | common means of exchanging reachability information over an IXP, the | |||
overhead associated with this interconnection method causes serious | overhead associated with this interconnection method causes serious | |||
operational and administrative scaling problems for IXP participants. | operational and administrative scaling problems for IXP participants. | |||
skipping to change at page 1, line 48 | skipping to change at page 1, line 48 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | 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 Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 30 | skipping to change at page 2, line 30 | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 | 2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 | |||
3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 | 3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 | |||
4. Operational Considerations for Route Server Installations . . 5 | 4. Operational Considerations for Route Server Installations . . 5 | |||
4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 | 4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 | |||
4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 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.2. Destination Splitting . . . . . . . . . . . . . . 7 | |||
4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 | 4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 | |||
4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 | 4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 | |||
4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8 | 4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8 | |||
4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 | 4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 | |||
4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9 | 4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9 | |||
4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9 | 4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9 | |||
4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9 | 4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9 | |||
4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10 | 4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10 | |||
4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10 | 4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 11 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | 8.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
Internet exchange points (IXPs) provide IP data interconnection | Internet exchange points (IXPs) provide IP data interconnection | |||
facilities for their participants, typically using shared Layer-2 | facilities for their participants, typically using shared Layer-2 | |||
networking media such as Ethernet. The Border Gateway Protocol (BGP) | networking media such as Ethernet. The Border Gateway Protocol (BGP) | |||
[RFC4271] is normally used to facilitate exchange of network | [RFC4271] is normally used to facilitate exchange of network | |||
reachability information over these media. | reachability information over these media. | |||
As bilateral interconnection between IXP participants requires | As bilateral interconnection between IXP participants requires | |||
operational and administrative overhead, BGP route servers | operational and administrative overhead, BGP route servers | |||
[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP | [I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP | |||
operators to provide a simple and convenient means of interconnecting | operators to provide a simple and convenient means of interconnecting | |||
skipping to change at page 10, line 41 | skipping to change at page 10, line 41 | |||
routing control path between the two hosts is usually (but not | routing control path between the two hosts is usually (but not | |||
always, due to IXP inter-switch connectivity load balancing | always, due to IXP inter-switch connectivity load balancing | |||
algorithms) the same as the data path between them. | algorithms) the same as the data path between them. | |||
Problems of this form can be dealt with using [RFC5881] bidirectional | Problems of this form can be dealt with using [RFC5881] bidirectional | |||
forwarding detection. However, as this is a bilateral protocol | forwarding detection. However, as this is a bilateral protocol | |||
configured between routers, and as there is currently no means for | configured between routers, and as there is currently no means for | |||
automatic configuration of BFD between route server clients, BFD does | automatic configuration of BFD between route server clients, BFD does | |||
not currently provide an optimal means of handling the problem. | 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 | On route server installations which do not employ path hiding | |||
mitigation techniques, the path hiding problem outlined in section | mitigation techniques, the path hiding problem outlined in section | |||
Section 4.1 can be used in certain circumstances to proactively block | Section 4.1 can be used in certain circumstances to proactively block | |||
third party prefix announcements from other route server clients. | 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 | 6. IANA Considerations | |||
There are no IANA considerations. | There are no IANA considerations. | |||
7. Acknowledgments | 7. Acknowledgments | |||
The authors would like to thank Chris Hall, Ryan Bickhart and Steven | The authors would like to thank Chris Hall, Ryan Bickhart, Steven | |||
Bakker for their valuable input. | Bakker and Eduardo Ascenco Reis for their valuable input. | |||
In addition, the authors would like to acknowledge the developers of | In addition, the authors would like to acknowledge the developers of | |||
BIRD, OpenBGPD and Quagga, whose open source BGP implementations | BIRD, OpenBGPD and Quagga, whose open source BGP implementations | |||
include route server capabilities which are compliant with this | include route server capabilities which are compliant with this | |||
document. | document. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
End of changes. 11 change blocks. | ||||
16 lines changed or deleted | 80 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |