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-00.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-00.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 accept an UPDATE message and process the associated routes even when the ORIGINATOR_ID or the NEXT_HOP 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 ............................ 3 5 IANA Considerations ................................ 4 6 Appendix A - Extranet application (non-normative) .. 4 7 Acknowledgements ................................... 5 8 Normative References ............................... 5 9 Informative References ............................. 5 10 Authors' Addresses ................................. 5 11 Full Copyright Statement ........................... 6 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 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- 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 Uttaro, et al. [Page 2] Internet Draftdraft-pmohapat-idr-acceptown-community-00.txt April 2008 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 accept the UPDATE message and process the associated routes even when the ORIGINATOR_ID and/or the NEXT_HOP match those of the receiving speaker, thus enabling more fine-grained route control via a route reflector. 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 readvertisement of a route prefix to the originator, and that the originator SHOULD accept and process the associated route prefixes irrespective of the ORIGINATOR_ID and NEXT_HOP value. 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. 4. Security Considerations The ORIGINATOR_ID and NEXT_HOP integrity checks outlined above help to detect and avoid routing information loops. It is possible with the use of the ACCEPT_OWN community value to introduce a routing loop within an autonomous system. However, BGP is already vulnerable to denial of service attacks including but not limited to routing loops based upon the injection of false routing information. The usage of the ACCEPT_OWN community SHOULD, therefore, be limited to internal Uttaro, et al. [Page 3] Internet Draftdraft-pmohapat-idr-acceptown-community-00.txt April 2008 (trusted) peers. 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 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 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 anyway. A router performing such an extranet application can accept a route with its own ORIGINATOR_ID 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 Uttaro, et al. [Page 4] Internet Draftdraft-pmohapat-idr-acceptown-community-00.txt April 2008 "context"). 7. Acknowledgements The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence Filsfil, 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. 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 Uttaro, et al. [Page 5] Internet Draftdraft-pmohapat-idr-acceptown-community-00.txt April 2008 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 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 Uttaro, et al. [Page 6] Internet Draftdraft-pmohapat-idr-acceptown-community-00.txt April 2008 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 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Uttaro, et al. [Page 7]