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/