sidr B. Dickson
Internet-Draft Brian Dickson
Expires: September 7, 2012 March 6, 2012
Route Leaks -- Proposed Solutions
draft-dickson-sidr-route-leak-solns-01
Abstract
The Border Gateway Protocol, version 4, (BGP4) provides the means to
advertise reachability for IP prefixes. This reachability
information is propagated in a peer-to-peer topology. Sometimes
routes are announced to peers for which the local peering policy does
not permit. And sometimes routes are propagated indiscriminantly,
once they have been accepted.
This document considers the situations that can lead to routes being
leaked, and tries to find acceptable definitions for describing these
scenarios.
The purpose of these definitions is to facilitate discussion on what
a route leak is, and what the scope of the problem space for route
leaks is. This, in turn, is intended to inform a requirements
document for detection of (and prevention of) route leaks. And
finally, the definitions and requirements are intended to allow
proposed solutions which meet these criteria, and to facilitate
evaluation of proposed solutions.
The fundamental objective is to "solve the route leaks problem".
Author's Note
Intended Status: Standards track.
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
Dickson Expires September 7, 2012 [Page 1]
Internet-Draft Route Leaks - Proposed Solutions March 2012
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 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
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.
Dickson Expires September 7, 2012 [Page 2]
Internet-Draft Route Leaks - Proposed Solutions March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Prefix Attribute Possibilities . . . . . . . . . . . . . . . . 4
3. Encoding Color via Choice of Algorithm . . . . . . . . . . . . 5
4. Encoding Color via a Second Signature Block . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Dickson Expires September 7, 2012 [Page 3]
Internet-Draft Route Leaks - Proposed Solutions March 2012
1. Introduction
1.1. Rationale
This document describes two different schemes for implementing a
solution for route leaks.
They represent different trade-offs between simplicity of
implementation, versus embedding information. The information
embedded can be inferred currently from a variety of sources, so the
risk/cost of doing so is marginal.
Either solution would be adequate to solve the route leak problem.
Due to the requirement for mandatory establishment of peering link
types, and cryptographic protection, the ideal time and place to
implement this would be coincident with BGPSEC.
Including route leak protection with BGPSEC may be beneficial to the
latter. It is more compelling to deploy a solution to both sets of
problems, than to deploy a solution to one or the other alone.
1.2. Requirements
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.3. Terminology
The reader is assumed to be familiar with the IETF.
2. Prefix Attribute Possibilities
If we presume that there are two possible colors for a prefix, then
we have three ways to express those colors:
1. A single bit, with two possible values, always attached to a
prefix.
2. An attribute whose presence signals one of the colors, and whose
absence signals the other color.
3. The same as 2, but with the other color being signaled.
For sake of clarity, we will use a fairly universally understood pair
of colors, "green" (meaning "proceed"), and "yellow" (meaning
Dickson Expires September 7, 2012 [Page 4]
Internet-Draft Route Leaks - Proposed Solutions March 2012
"caution").
So, the three ways of marking the colors are:
Use a green/yellow bit (green if 1, yellow if 0)
Use a "green" attribute (green if present, yellow otherwise)
Use a "yellow" attribute (yellow if present, green otherwise).
Since information is leaked for both the "green/yellow bit" and
"yellow attribute", there is no reason to discuss the "yellow
attribute" option. It is inferior to both other methods.
3. Encoding Color via Choice of Algorithm
Here, we are presuming that BGPSEC is in use on prefixes, and that
BGPSEC includes an explicit algorithm identifier. Currently, the
identifier only specifies which algorithm to use to validate the
signature in the signature block.
This would be augmented so that for any given algorithm, two
identifiers would be assigned. One would be the identifier
signifying "Green", and the other would signify "Yellow". When
sending a "green" route, the current "green" algorithm would be used.
When sending a "yellow" route, the current "yellow" algorithm would
be used. Validation would work as usual, with the additional ability
to validate the color rules for preventing route leaks.
No additional changes to the structure of the BGPSEC protocol or wire
format are needed.
However, there is the leak of information about transit
relationships, which is unavoidable with this design.
Routes which violate the path coloring rules but otherwise validate,
would be blocked. (They should not occur, but should be checked
regardless.) Routes which do not validate under BGPSEC would be
blocked regardless, also preventing a potential source of route
leaks.
4. Encoding Color via a Second Signature Block
A signature block analogous to the AS-PATH signature block, would be
included on any announcement that is "green". The local sender would
add her signature to the signature block on these "green"
Dickson Expires September 7, 2012 [Page 5]
Internet-Draft Route Leaks - Proposed Solutions March 2012
announcements. In addition, the new signature block would be sent
across the "green/yellow" boundary to any Peer. However, when
sending across the "green/yellow" boundary, would not add her
signature to the block.
The recipient would be able to validate all the "green" signatures up
to the sender, and if present, the sender's signature as well. If
the "green" signature does not include the sender, no more signatures
can be attached. When sending to a "yellow" peer, the "green
attribute" block is stripped (if present). The absence of a "green
block" means the prefix is considered "yellow". This mechanism is
not "free" in that more crypto calculations are needed, the structure
of the BGPSEC attributes change, and more data is needed on each
announcement within the "green" zone.
However, no information concerning relationships is leaked, beyond
what the recipient can already infer. A transit provider already
knows his/her customers, and their customers, etc.
From a scaling perspective, it should be noted that only customers'
prefixes require additional signatures, so the number of prefixes
with those signatures is proportionally smaller. Signature
validation is only done on the "green block" upon receiving a
customer's routes or a peer's routes. This also minimizes the
incremental cost.
Since it is physically impossible to promote a "yellow" route to a
"green" route, because the originators "green" block is absent, this
is a very strong mechanism for stopping route leaks. Validating link
type versus color, after validation of any "green block" present, is
sufficient to stop route leaks.
5. Security Considerations
None per se.
6. IANA Considerations
This document contains no IANA-specific material.
7. Acknowledgements
To be added later.
Dickson Expires September 7, 2012 [Page 6]
Internet-Draft Route Leaks - Proposed Solutions March 2012
8. References
8.1. Normative References
[RFC1773] Traina, P., "Experience with the BGP-4 protocol",
RFC 1773, March 1995.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Brian Dickson
Brian Dickson
703 Palmer Drive,
Herndon, VA 20170
USA
Email: brian.peter.dickson@gmail.com
Dickson Expires September 7, 2012 [Page 7]