idnits 2.17.1 draft-ietf-idr-as0-05.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 (May 22, 2012) is 4355 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 213 == 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: November 23, 2012 H. Schiller 7 Verizon 8 K. Patel 9 Cisco Systems 10 May 22, 2012 12 Codification of AS 0 processing. 13 draft-ietf-idr-as0-05 15 Abstract 17 This document updates RFC 4271 and proscribes the use of AS 0 in BGP 18 OPEN and AS_PATH / AS4_PATH BGP attribute. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 23, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 56 2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 62 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 Autonomous System 0 is listed in the IANA Autonomous System Number 69 Registry as "Reserved - May be use to identify non-routed networks" 70 ([IANA.AS_Numbers]). 72 [RFC6491] specifies that AS number zero in a ROA is used to mark an 73 NLRI which is to be marked as Invalid. 75 No clear statement that AS 0 was proscribed could be found in any BGP 76 specification. This document corrects this omission, most 77 importantly in the case of the AS_PATH. This represents an update to 78 the error handling procedures given in [RFC4271]. 80 As at least two implementations discard routes containing AS 0, and 81 to allow approaches such as the above, this document codifies this 82 behavior. 84 1.1. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Behavior 92 A BGP speaker MUST NOT originate or propagate a route with an AS 93 number of zero in the AS_PATH, AS4_PATH, AGGREGATOR or AS4_AGGREGATOR 94 attributes. 96 An UPDATE message that contains the AS number of zero in the AS_PATH 97 or AGGREGATOR attribute MUST be considered as malformed, and be 98 handled by the procedures specified in [I-D.ietf-idr-error-handling]. 100 An UPDATE message that contains the AS number of zero in the AS4_PATH 101 or AS4_AGGREGATOR attribute MUST be considered as malformed, and be 102 handled by the procedures specified in [I-D.ietf-idr-rfc4893bis]. 104 If a BGP speaker receives zero as the peer AS in an OPEN message, it 105 MUST abort the connection and send a NOTIFICATION with Error Code 106 "OPEN Message Error" and subcode "Bad Peer AS" (see [RFC4271] Section 107 6.2). A router MUST NOT initiate a connection claiming to be AS 108 number zero. 110 Authors of future protocol extensions that carry the Autonomous 111 System number are encouraged keep in mind that AS number zero is 112 reserved and to provide clear direction on how to handle AS number 113 zero. 115 3. IANA Considerations 117 The IANA is requested to update the Reference for number 0 in the 118 "Autonomous System (AS) Numbers" registry to reference this document. 120 4. Security Considerations 122 By allowing a RPKI resource holder to issue a ROA saying that AS 0 is 123 the only valid origin for a route, we allow them to state that a 124 particular address resource is not in use. By ensuring that all 125 implementations that see AS 0 in a route ignore that route, we 126 prevent a malicious party from announcing routes containing AS 0 in 127 an attempt to hijack those resources. 129 In addition, by standardizing the behavior upon reception of an 130 AS_PATH (or AS4_PATH) containing AS 0, this document makes the 131 behavior better defined, and security gotchas often lurk in the 132 undefined spaces. 134 5. Acknowledgements 136 The authors wish to thank Enke Chen, Brian Dickson, Bruno Decraene, 137 Robert Raszuk, Jakob Heitz, Danny McPherson, Chris Morrow, iLya, John 138 Scudder, Jeff Tantsura, Daniel Ginsburg and Susan Hares. Apologies 139 to those we may have missed, it was not intentional. 141 6. References 143 6.1. Normative References 145 [I-D.ietf-idr-error-handling] 146 Scudder, J., Chen, E., Mohapatra, P., and K. Patel, 147 "Revised Error Handling for BGP UPDATE Messages", 148 draft-ietf-idr-error-handling-01 (work in progress), 149 December 2011. 151 [I-D.ietf-idr-rfc4893bis] 152 Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 153 Number Space", draft-ietf-idr-rfc4893bis-06 (work in 154 progress), April 2012. 156 [IANA.AS_Numbers] 157 IANA, "Autonomous System (AS) Numbers", 158 . 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 164 Protocol 4 (BGP-4)", RFC 4271, January 2006. 166 6.2. Informative References 168 [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public 169 Key Infrastructure (RPKI) Objects Issued by IANA", 170 RFC 6491, February 2012. 172 Appendix A. Changes / Author Notes. 174 [RFC Editor: Please remove this section before publication ] 176 Draft accepted as IDR Doc, notes reset. Please see notes for 177 draft-wkumari-idr-as0.xml for prior comments. 179 Changes -00. 181 o Added AS4_PATH -- Robert Raszuk. 182 o Change "bgp listener" to "bgp speaker" -- Enke Chen 183 o Consistent use of AS_PATH (v., AS-PATH and AS PATH) -- Danny 184 McPherson 185 o New text for Sec 2 P1 -- Enke / Keyur / Scudder, 186 http://www.ietf.org/mail-archive/web/idr/current/msg05786.html 187 o I made a boo boo -- I had the file open in 2 editors, made changes 188 in one and overwrote them by saving on the "other, then checked 189 the broken one into SVN. Apologies to all whose comments I may 190 have missed... 192 Changes -01 194 o The WG thread 195 http://www.ietf.org/mail-archive/web/idr/current/msg05685.html 196 showed a very strong preference for separating the error 197 definition and handling -- the chairs also showed a prefernce to 198 Publish this and point to the error handling that Enke will write. 199 o The originally suggested text ("An UPDATE message that contains 200 the AS number of zero in the AS-PATH attribute MUST be...") only 201 referenced the AS-PATH, readded AS4_PATH, *AGGREGATOR as suggested 202 by Robert Raszak and Danny. 204 Changes -02 206 o Fixed the reference for *AGGREGATOR. This required breaking it 207 out into two sentences / clauses. 208 o Added text on other places where an AS can show up (e.g: "4-Octet 209 AS specific Extended Community" [5668]) -- thanks to Keyur. 211 Changes - 03 212 o Removed text on other places where an AS can show up (e.g: 213 "4-Octet AS specific Extended Community" [5668]). 214 o Added *very* generic "Authors of future protocol extensions..." 215 text 217 Changes -04 219 o Looks like the draft needs an 'Updates: RFC 4271' header. Can you 220 make the change? -- JGS. 221 o "You have things a bit scrambled in these two paragraphs" -- JGS 222 (whoops!). 223 o Editorial: I suggest dropping the parentheses in... JGS. 224 o Added "This document updates rfc 4271" to keep IDNITs happy... 225 o Bumped refs: draft-ietf-sidr-iana-objects has been published as 226 RFC 6491, idr-error is now -01, 4893bis is now -06 228 Changes - 05 230 o Added something to the intro saying what we update and why. This 231 was in the abstract, but I didn't have it in the intro. Stupid. 233 Authors' Addresses 235 Warren Kumari 236 Google 237 1600 Amphitheatre Parkway 238 Mountain View, CA 94043 239 US 241 Email: warren@kumari.net 242 Randy Bush 243 Internet Initiative Japan 244 5147 Crystal Springs 245 Bainbridge Island, WA 98110 246 US 248 Email: randy@psg.com 250 Heather Schiller 251 Verizon 252 22001 Loudoun County Parkway 253 Ashburn 20147 254 US 256 Email: heather.schiller@verizon.com 258 Keyur Patel 259 Cisco Systems 260 170 W. Tasman Drive 261 San Jose, CA 95134 262 USA 264 Phone: 265 Fax: 266 Email: keyupate@cisco.com 267 URI: