Network Working Group James Uttaro
Internet Draft AT&T
Expiration Date: October 2008
Pradosh Mohapatra
David J. Smith
Cisco Systems, Inc.
Robert Raszuk
John Scudder
Juniper Networks, Inc.
April 2008
BGP ACCEPT_OWN Well-known Community Attribute
draft-pmohapat-idr-acceptown-community-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
It may be useful for a BGP speaker in an autonomous system to receive
and accept its own advertised route from a route reflector with more
fine-grained route control. For example, the route reflector can
change certain attributes of a route as desired, and then re-
Uttaro, et al. [Page 1]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
advertise it back to the originator. Though it is possible to perform
such policy control directly at the originator, it may be
operationally cumbersome in a network with a large number of border
routers having complex BGP policies.
This draft defines a new and well-known BGP community value,
ACCEPT_OWN, that signals a BGP speaker to continue processing of an
UPDATE message and the associated routes even when the ORIGINATOR_ID
or the NEXT_HOP value matches that of the receiving speaker.
Table of Contents
1 Specification of Requirements ...................... 2
2 Introduction ....................................... 2
3 ACCEPT_OWN Community ............................... 3
4 Security Considerations ............................ 4
5 IANA Considerations ................................ 4
6 Appendix A - Extranet application (non-normative) .. 4
7 Acknowledgements ................................... 5
8 Normative References ............................... 5
9 Informative References ............................. 6
10 Authors' Addresses ................................. 6
11 Full Copyright Statement ........................... 7
12 Intellectual Property .............................. 7
1. Specification of 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].
2. Introduction
In certain scenarios, a BGP speaker may maintain multiple contexts,
in which case the speaker originates and receives routes within a
particular context (an example of such a context could be a VRF used
by BGP/MPLS VPNs [RFC4364]). In such scenarios, the ability of a BGP
speaker to accept a route with its own ORIGINATOR_ID or its own
NEXT_HOP provides a way to modify and then redistribute routing
information among the contexts maintained by the speaker through some
Uttaro, et al. [Page 2]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
other (external) speakers. For example, a route reflector can change
certain path attributes of a route as desired, and then re-advertise
it back to the originator. Though it is possible to perform such
policy control directly on the originator, it may be operationally
cumbersome in a network with a large number of border routers having
complex BGP policies.
As per the BGP protocol [RFC4271], a BGP speaker rejects prefix
advertisements received that were originated by itself. In an
autonomous system with route reflectors, the route reflector attaches
the ORIGINATOR_ID attribute to the UPDATE messages so that if such
prefix advertisements reach the originator, the originator can reject
them by simply checking the ORIGINATOR_ID attribute. The BGP
specification also mandates that a route should not be advertised to
a peer nor accepted from a peer when the NEXT_HOP attribute matches
the receiver's own "IP address". These integrity checks help to
detect and prevent routing information loops.
The draft proposes a modification to this behavior by defining a new
well-known community [RFC1997] value. If this community value,
ACCEPT_OWN, is attached to an UPDATE message, the originator will not
reject the UPDATE message and the associated routes even when the
ORIGINATOR_ID or the NEXT_HOP value matches that of the receiving
speaker, thus enabling more fine-grained route control via a route
reflector.
To prevent routing information loops, a BGP speaker SHOULD accept a
route with its own ORIGINATOR_ID or NEXT_HOP value only if the
ACCEPT_OWN community value is present and the context in which the
speaker originated the route is different than the context in which
the speaker accepts the route.
3. ACCEPT_OWN Community
This memo defines the use of a new well-known BGP non-transitive
community, ACCEPT_OWN, with value 0xFFFFFF05. The ACCEPT_OWN
community has global significance. However, it SHOULD NOT be
advertised between external BGP peers. The ACCEPT_OWN community
SHOULD only be advertised between internal BGP peers.
Use of this well-known community value signals that the associated
route prefix should not be rejected by its originator irrespective of
the ORIGINATOR_ID and NEXT_HOP values. The ACCEPT_OWN community
effectively disables the ORIGINATOR_ID and NEXT_HOP integrity checks,
however, only for those route prefixes having the ACCEPT_OWN
community value.
Uttaro, et al. [Page 3]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
Some route reflectors may be designed such that they never send
routing information back to the router specified in ORIGINATOR_ID as
mandated by [RFC1966]. Such route reflectors MUST disable this
suppression functionality for routes which carry the ACCEPT_OWN
community.
4. Security Considerations
ACCEPT_OWN as described above permits a router's own route prefix to
be advertised to a different "context" on that router. In this
respect, such a route is similar to any other BGP route and shares
the same set of security vulnerabilities and concerns. No new
fundamental security issues are introduced by ACCEPT_OWN.
5. IANA Considerations
This document defines a new well-known community, called ACCEPT_OWN.
It is to be assigned value 0xFFFFFF05.
6. Appendix A - Extranet application (non-normative)
One of the applications for this behavior is auto-configuration of
extranets within MPLS VPN networks. Consider the following topology:
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
Within the above topology, PE1 receives a prefix X from CE1. Prefix X
is installed in VRF 1 and is advertised to the route reflector with
route distinguisher (RD) 1 and route target (RT) 1 as configured on
PE1. The requirement is to import prefix X into VRF 2 and advertise
it to CE2 in support of extranet VPN connectivity between CE1/VRF1
and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require
changing the import RT value and/or import policy for VRF 2 on PE1.
This is operationally cumbersome in a network with a large number of
border routers having complex BGP policies.
Alternatively, using the new ACCEPT_OWN community value, the route
Uttaro, et al. [Page 4]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
reflector can simply re-advertise prefix X back to PE1 with RT 2
appended. In this way, PE1 will accept prefix X despite its
ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2, and will
determine the correct adjacency rewrite within VRF 1 based on the RD
value (1) and the prefix. The same operation needs also to happen in
the reverse direction (VRF 1 learning a route from VRF 2) to achieve
establishment of an extranet VPN strictly via the route reflector
without changing the BGP policy of PE1 in any way.
A router performing such an extranet application can accept a route
with its own ORIGINATOR_ID or NEXT_HOP value only if the "context" in
which the router originated the route is different than the "context"
in which the router accepts the re-advertised route (VRF is an
example of a "context").
7. Acknowledgements
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence
Filsfils, and John Mullooly for their valuable comments and
suggestions.
8. Normative References
[RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border
Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," March 1997.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, August 1996.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC1966] Bates, T. and Chandra, R, "BGP Route Reflection: An
Alternative to full mesh IBGP," June 1996.
Uttaro, et al. [Page 5]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
9. Informative References
[RFC3765] G. Huston, "NOPEER community for BGP route scope control",
RFC 3765, April 2004.
Schudel, G. and D. Smith, "Router Security Strategies: Securing IP
Network Traffic Planes.", Cisco Press, January 2008.
10. Authors' Addresses
James Uttaro
AT&T
200 S. Laurel Avenue
Middletown, NJ 07748
Email: uttaro@att.com
Pradosh Mohapatra
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA 95134
Email: pmohapat@cisco.com
David J. Smith
Cisco Systems, Inc.
499 Thornall Street
Edison, NJ 08837
E-mail: dasmith@cisco.com
Robert Raszuk
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: raszuk@juniper.net
Uttaro, et al. [Page 6]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
John Scudder
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
Email: jgs@juniper.net
11. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Uttaro, et al. [Page 7]
Internet Draftdraft-pmohapat-idr-acceptown-community-01.txt April 2008
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Uttaro, et al. [Page 8]