idnits 2.17.1 draft-pmohapat-idr-acceptown-community-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2008) is 5848 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3765' is defined on line 218, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1966 (Obsoleted by RFC 4456) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James Uttaro 3 Internet Draft AT&T 4 Expiration Date: October 2008 5 Pradosh Mohapatra 6 David J. Smith 7 Cisco Systems, Inc. 9 Robert Raszuk 10 John Scudder 11 Juniper Networks, Inc. 13 April 2008 15 BGP ACCEPT_OWN Well-known Community Attribute 17 draft-pmohapat-idr-acceptown-community-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 It may be useful for a BGP speaker in an autonomous system to receive 45 and accept its own advertised route from a route reflector with more 46 fine-grained route control. For example, the route reflector can 47 change certain attributes of a route as desired, and then re- 48 advertise it back to the originator. Though it is possible to perform 49 such policy control directly at the originator, it may be 50 operationally cumbersome in a network with a large number of border 51 routers having complex BGP policies. 53 This draft defines a new and well-known BGP community value, 54 ACCEPT_OWN, that signals a BGP speaker to continue processing of an 55 UPDATE message and the associated routes even when the ORIGINATOR_ID 56 or the NEXT_HOP value matches that of the receiving speaker. 58 Table of Contents 60 1 Specification of Requirements ...................... 2 61 2 Introduction ....................................... 2 62 3 ACCEPT_OWN Community ............................... 3 63 4 Security Considerations ............................ 4 64 5 IANA Considerations ................................ 4 65 6 Appendix A - Extranet application (non-normative) .. 4 66 7 Acknowledgements ................................... 5 67 8 Normative References ............................... 5 68 9 Informative References ............................. 6 69 10 Authors' Addresses ................................. 6 70 11 Full Copyright Statement ........................... 7 71 12 Intellectual Property .............................. 7 73 1. Specification of Requirements 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 In certain scenarios, a BGP speaker may maintain multiple contexts, 82 in which case the speaker originates and receives routes within a 83 particular context (an example of such a context could be a VRF used 84 by BGP/MPLS VPNs [RFC4364]). In such scenarios, the ability of a BGP 85 speaker to accept a route with its own ORIGINATOR_ID or its own 86 NEXT_HOP provides a way to modify and then redistribute routing 87 information among the contexts maintained by the speaker through some 88 other (external) speakers. For example, a route reflector can change 89 certain path attributes of a route as desired, and then re-advertise 90 it back to the originator. Though it is possible to perform such 91 policy control directly on the originator, it may be operationally 92 cumbersome in a network with a large number of border routers having 93 complex BGP policies. 95 As per the BGP protocol [RFC4271], a BGP speaker rejects prefix 96 advertisements received that were originated by itself. In an 97 autonomous system with route reflectors, the route reflector attaches 98 the ORIGINATOR_ID attribute to the UPDATE messages so that if such 99 prefix advertisements reach the originator, the originator can reject 100 them by simply checking the ORIGINATOR_ID attribute. The BGP 101 specification also mandates that a route should not be advertised to 102 a peer nor accepted from a peer when the NEXT_HOP attribute matches 103 the receiver's own "IP address". These integrity checks help to 104 detect and prevent routing information loops. 106 The draft proposes a modification to this behavior by defining a new 107 well-known community [RFC1997] value. If this community value, 108 ACCEPT_OWN, is attached to an UPDATE message, the originator will not 109 reject the UPDATE message and the associated routes even when the 110 ORIGINATOR_ID or the NEXT_HOP value matches that of the receiving 111 speaker, thus enabling more fine-grained route control via a route 112 reflector. 114 To prevent routing information loops, a BGP speaker SHOULD accept a 115 route with its own ORIGINATOR_ID or NEXT_HOP value only if the 116 ACCEPT_OWN community value is present and the context in which the 117 speaker originated the route is different than the context in which 118 the speaker accepts the route. 120 3. ACCEPT_OWN Community 122 This memo defines the use of a new well-known BGP non-transitive 123 community, ACCEPT_OWN, with value 0xFFFFFF05. The ACCEPT_OWN 124 community has global significance. However, it SHOULD NOT be 125 advertised between external BGP peers. The ACCEPT_OWN community 126 SHOULD only be advertised between internal BGP peers. 128 Use of this well-known community value signals that the associated 129 route prefix should not be rejected by its originator irrespective of 130 the ORIGINATOR_ID and NEXT_HOP values. The ACCEPT_OWN community 131 effectively disables the ORIGINATOR_ID and NEXT_HOP integrity checks, 132 however, only for those route prefixes having the ACCEPT_OWN 133 community value. 135 Some route reflectors may be designed such that they never send 136 routing information back to the router specified in ORIGINATOR_ID as 137 mandated by [RFC1966]. Such route reflectors MUST disable this 138 suppression functionality for routes which carry the ACCEPT_OWN 139 community. 141 4. Security Considerations 143 ACCEPT_OWN as described above permits a router's own route prefix to 144 be advertised to a different "context" on that router. In this 145 respect, such a route is similar to any other BGP route and shares 146 the same set of security vulnerabilities and concerns. No new 147 fundamental security issues are introduced by ACCEPT_OWN. 149 5. IANA Considerations 151 This document defines a new well-known community, called ACCEPT_OWN. 152 It is to be assigned value 0xFFFFFF05. 154 6. Appendix A - Extranet application (non-normative) 156 One of the applications for this behavior is auto-configuration of 157 extranets within MPLS VPN networks. Consider the following topology: 159 CE1 --------+ 160 | 161 (VRF 1, RD 1, RT 1) 162 PE1 ................... RR 163 (VRF 2, RD 2, RT 2) 164 | 165 CE2 --------+ 167 Within the above topology, PE1 receives a prefix X from CE1. Prefix X 168 is installed in VRF 1 and is advertised to the route reflector with 169 route distinguisher (RD) 1 and route target (RT) 1 as configured on 170 PE1. The requirement is to import prefix X into VRF 2 and advertise 171 it to CE2 in support of extranet VPN connectivity between CE1/VRF1 172 and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require 173 changing the import RT value and/or import policy for VRF 2 on PE1. 174 This is operationally cumbersome in a network with a large number of 175 border routers having complex BGP policies. 177 Alternatively, using the new ACCEPT_OWN community value, the route 178 reflector can simply re-advertise prefix X back to PE1 with RT 2 179 appended. In this way, PE1 will accept prefix X despite its 180 ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2, and will 181 determine the correct adjacency rewrite within VRF 1 based on the RD 182 value (1) and the prefix. The same operation needs also to happen in 183 the reverse direction (VRF 1 learning a route from VRF 2) to achieve 184 establishment of an extranet VPN strictly via the route reflector 185 without changing the BGP policy of PE1 in any way. 187 A router performing such an extranet application can accept a route 188 with its own ORIGINATOR_ID or NEXT_HOP value only if the "context" in 189 which the router originated the route is different than the "context" 190 in which the router accepts the re-advertised route (VRF is an 191 example of a "context"). 193 7. Acknowledgements 195 The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence 196 Filsfils, and John Mullooly for their valuable comments and 197 suggestions. 199 8. Normative References 201 [RFC4271] Rekhter, Y., Li T., and Hares S.(editors), "A Border 202 Gateway Protocol 4 (BGP-4)," RFC 4271, January 2006. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels," March 1997. 207 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 208 Attribute", RFC 1997, August 1996. 210 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 211 Networks (VPNs)", RFC 4364, February 2006. 213 [RFC1966] Bates, T. and Chandra, R, "BGP Route Reflection: An 214 Alternative to full mesh IBGP," June 1996. 216 9. Informative References 218 [RFC3765] G. Huston, "NOPEER community for BGP route scope control", 219 RFC 3765, April 2004. 221 Schudel, G. and D. Smith, "Router Security Strategies: Securing IP 222 Network Traffic Planes.", Cisco Press, January 2008. 224 10. Authors' Addresses 226 James Uttaro 227 AT&T 228 200 S. Laurel Avenue 229 Middletown, NJ 07748 230 Email: uttaro@att.com 232 Pradosh Mohapatra 233 Cisco Systems, Inc. 234 170 Tasman Drive 235 San Jose, CA 95134 236 Email: pmohapat@cisco.com 238 David J. Smith 239 Cisco Systems, Inc. 240 499 Thornall Street 241 Edison, NJ 08837 242 E-mail: dasmith@cisco.com 244 Robert Raszuk 245 Juniper Networks 246 1194 North Mathilda Avenue 247 Sunnyvale, California 94089 248 USA 249 Email: raszuk@juniper.net 250 John Scudder 251 Juniper Networks 252 1194 North Mathilda Avenue 253 Sunnyvale, California 94089 254 USA 255 Email: jgs@juniper.net 257 11. Full Copyright Statement 259 Copyright (C) The IETF Trust (2008). 261 This document is subject to the rights, licenses and restrictions 262 contained in BCP 78, and except as set forth therein, the authors 263 retain all their rights. 265 This document and the information contained herein are provided on an 266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 268 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 269 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 270 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 273 12. Intellectual Property 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at ietf- 295 ipr@ietf.org.