idnits 2.17.1 draft-ietf-idr-as0-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- 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 (August 26, 2012) is 4251 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) -- Looks like a reference, but probably isn't: '5668' on line 220 == Outdated reference: A later version (-19) exists of draft-ietf-idr-error-handling-01 == Outdated reference: A later version (-07) exists of draft-ietf-idr-rfc4893bis-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr W. Kumari 3 Internet-Draft Google 4 Updates: 4271 (if approved) R. Bush 5 Intended status: Standards Track Internet Initiative Japan 6 Expires: February 27, 2013 H. Schiller 7 Verizon 8 K. Patel 9 Cisco Systems 10 August 26, 2012 12 Codification of AS 0 processing. 13 draft-ietf-idr-as0-06 15 Abstract 17 This document updates RFC 4271 and proscribes the use of Autonomous 18 System (AS) 0 in the Border Gateway Protocol (BGP) OPEN and AS_PATH / 19 AS4_PATH BGP attribute. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 27, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 57 2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 64 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Autonomous System 0 is listed in the IANA Autonomous System Number 70 Registry as "Reserved - May be use to identify non-routed networks" 71 ([IANA.AS_Numbers]). 73 [RFC6491] specifies that AS number zero in a Route Origin Attestation 74 (ROA) is used to mark a prefix and all its more specific prefixes as 75 not to be used in a routing context. This allows a resource holder 76 to signal that a prefix (and the more specifics) should not be routed 77 by publishing a ROA listing AS0 as the only origin. To respond to 78 this signal requres that BGP implementations do not accept or 79 propagate routes containing AS0. 81 No clear statement that AS 0 was proscribed could be found in any BGP 82 specification. This document corrects this omission, most 83 importantly in the case of the AS_PATH. This represents an update to 84 the error handling procedures given in [RFC4271] Sections 6.2 and 6.3 85 by specifying the behavior in the presence of AS0. 87 At least two implementations discard routes containing AS 0, and this 88 document codifies this behavior. 90 1.1. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 2. Behavior 98 A BGP speaker MUST NOT originate or propagate a route with an AS 99 number of zero in the AS_PATH, AS4_PATH, AGGREGATOR or AS4_AGGREGATOR 100 attributes. 102 An UPDATE message that contains the AS number of zero in the AS_PATH 103 or AGGREGATOR attribute MUST be considered as malformed, and be 104 handled by the procedures specified in [I-D.ietf-idr-error-handling]. 106 An UPDATE message that contains the AS number of zero in the AS4_PATH 107 or AS4_AGGREGATOR attribute MUST be considered as malformed, and be 108 handled by the procedures specified in [I-D.ietf-idr-rfc4893bis]. 110 If a BGP speaker receives zero as the peer AS in an OPEN message, it 111 MUST abort the connection and send a NOTIFICATION with Error Code 112 "OPEN Message Error" and subcode "Bad Peer AS" (see [RFC4271] Section 113 6.2). A router MUST NOT initiate a connection claiming to be AS 114 number zero. 116 Authors of future protocol extensions that carry the Autonomous 117 System number are encouraged to keep in mind that AS number zero is 118 reserved and to provide clear direction on how to handle AS number 119 zero. 121 3. IANA Considerations 123 The IANA is requested to update the Reference for number 0 in the 124 "Autonomous System (AS) Numbers" registry to reference this document. 126 4. Security Considerations 128 By allowing a Resource Public Key Infrastructure (RPKI) resource 129 holder to issue a ROA saying that AS 0 is the only valid origin for a 130 route, we allow them to state that a particular address resource is 131 not in use. By ensuring that all implementations that see AS 0 in a 132 route ignore that route, we prevent a malicious party from announcing 133 routes containing AS 0 in an attempt to hijack those resources. 135 In addition, by standardizing the behavior upon reception of an 136 AS_PATH (or AS4_PATH) containing AS 0, this document makes the 137 behavior better defined. 139 5. Acknowledgements 141 The authors wish to thank Elwyn Davies, Enke Chen, Brian Dickson, 142 Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny McPherson, Chris 143 Morrow, iLya, John Scudder, Jeff Tantsura, Daniel Ginsburg and Susan 144 Hares. Apologies to those we may have missed, it was not 145 intentional. 147 6. References 149 6.1. Normative References 151 [I-D.ietf-idr-error-handling] 152 Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 153 "Revised Error Handling for BGP UPDATE Messages", 154 draft-ietf-idr-error-handling-01 (work in progress), 155 December 2011. 157 [I-D.ietf-idr-rfc4893bis] 158 Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 159 Number Space", draft-ietf-idr-rfc4893bis-06 (work in 160 progress), April 2012. 162 [IANA.AS_Numbers] 163 IANA, "Autonomous System (AS) Numbers", 164 . 166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 167 Requirement Levels", BCP 14, RFC 2119, March 1997. 169 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 170 Protocol 4 (BGP-4)", RFC 4271, January 2006. 172 6.2. Informative References 174 [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public 175 Key Infrastructure (RPKI) Objects Issued by IANA", 176 RFC 6491, February 2012. 178 Appendix A. Changes / Author Notes. 180 [RFC Editor: Please remove this section before publication ] 182 Draft accepted as IDR Doc, notes reset. Please see notes for 183 draft-wkumari-idr-as0.xml for prior comments. 185 Changes -00. 187 o Added AS4_PATH -- Robert Raszuk. 188 o Change "bgp listener" to "bgp speaker" -- Enke Chen 189 o Consistent use of AS_PATH (v., AS-PATH and AS PATH) -- Danny 190 McPherson 191 o New text for Sec 2 P1 -- Enke / Keyur / Scudder, 192 http://www.ietf.org/mail-archive/web/idr/current/msg05786.html 193 o I made a boo boo -- I had the file open in 2 editors, made changes 194 in one and overwrote them by saving on the "other, then checked 195 the broken one into SVN. Apologies to all whose comments I may 196 have missed... 198 Changes -01 200 o The WG thread 201 http://www.ietf.org/mail-archive/web/idr/current/msg05685.html 202 showed a very strong preference for separating the error 203 definition and handling -- the chairs also showed a prefernce to 204 Publish this and point to the error handling that Enke will write. 206 o The originally suggested text ("An UPDATE message that contains 207 the AS number of zero in the AS-PATH attribute MUST be...") only 208 referenced the AS-PATH, readded AS4_PATH, *AGGREGATOR as suggested 209 by Robert Raszak and Danny. 211 Changes -02 213 o Fixed the reference for *AGGREGATOR. This required breaking it 214 out into two sentences / clauses. 215 o Added text on other places where an AS can show up (e.g: "4-Octet 216 AS specific Extended Community" [5668]) -- thanks to Keyur. 218 Changes - 03 219 o Removed text on other places where an AS can show up (e.g: 220 "4-Octet AS specific Extended Community" [5668]). 221 o Added *very* generic "Authors of future protocol extensions..." 222 text 224 Changes -04 226 o Looks like the draft needs an 'Updates: RFC 4271' header. Can you 227 make the change? -- JGS. 228 o "You have things a bit scrambled in these two paragraphs" -- JGS 229 (whoops!). 230 o Editorial: I suggest dropping the parentheses in... JGS. 231 o Added "This document updates rfc 4271" to keep IDNITs happy... 232 o Bumped refs: draft-ietf-sidr-iana-objects has been published as 233 RFC 6491, idr-error is now -01, 4893bis is now -06 235 Changes - 05 237 o Added something to the intro saying what we update and why. This 238 was in the abstract, but I didn't have it in the intro. Stupid. 240 Changes - 06 241 o Incorporated some comments / clarifications from Gen-ART review 242 (Elwyn Davies) 243 o Expaned acronyms. 244 o RFC 6491 fix - clarified what it actually said and what 245 implications are. 247 Authors' Addresses 249 Warren Kumari 250 Google 251 1600 Amphitheatre Parkway 252 Mountain View, CA 94043 253 US 255 Email: warren@kumari.net 257 Randy Bush 258 Internet Initiative Japan 259 5147 Crystal Springs 260 Bainbridge Island, WA 98110 261 US 263 Email: randy@psg.com 265 Heather Schiller 266 Verizon 267 22001 Loudoun County Parkway 268 Ashburn 20147 269 US 271 Email: heather.schiller@verizon.com 273 Keyur Patel 274 Cisco Systems 275 170 W. Tasman Drive 276 San Jose, CA 95134 277 USA 279 Phone: 280 Fax: 281 Email: keyupate@cisco.com 282 URI: