draft-ietf-idr-as0-06.txt   rfc7607.txt 
idr W. Kumari Internet Engineering Task Force (IETF) W. Kumari
Internet-Draft Google Request for Comments: 7607 Google
Updates: 4271 (if approved) R. Bush Updates: 4271 R. Bush
Intended status: Standards Track Internet Initiative Japan Category: Standards Track Internet Initiative Japan
Expires: February 27, 2013 H. Schiller ISSN: 2070-1721 H. Schiller
Verizon Google
K. Patel K. Patel
Cisco Systems Cisco Systems
August 26, 2012 August 2015
Codification of AS 0 processing. Codification of AS 0 Processing
draft-ietf-idr-as0-06
Abstract Abstract
This document updates RFC 4271 and proscribes the use of Autonomous This document updates RFC 4271 and proscribes the use of Autonomous
System (AS) 0 in the Border Gateway Protocol (BGP) OPEN and AS_PATH / System (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH,
AS4_PATH BGP attribute. AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE
message.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on February 27, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7607.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2
2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 5.2. Informative References . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Autonomous System 0 is listed in the IANA Autonomous System Number Autonomous System 0 was listed in the IANA Autonomous System Number
Registry as "Reserved - May be use to identify non-routed networks" Registry as "Reserved - May be use [sic] to identify non-routed
([IANA.AS_Numbers]). networks" ([IANA.AS_Numbers]).
[RFC6491] specifies that AS number zero in a Route Origin Attestation [RFC6491] specifies that AS 0 in a Route Origin Attestation (ROA) is
(ROA) is used to mark a prefix and all its more specific prefixes as used to mark a prefix and all its more specific prefixes as not to be
not to be used in a routing context. This allows a resource holder used in a routing context. This allows a resource holder to signal
to signal that a prefix (and the more specifics) should not be routed that a prefix (and the more specifics) should not be routed by
by publishing a ROA listing AS0 as the only origin. To respond to publishing a ROA listing AS 0 as the only origin. To respond to this
this signal requres that BGP implementations do not accept or signal requires that BGP implementations not accept or propagate
propagate routes containing AS0. routes containing AS 0.
No clear statement that AS 0 was proscribed could be found in any BGP No clear statement that AS 0 was proscribed could be found in any BGP
specification. This document corrects this omission, most specification. This document corrects this omission, most
importantly in the case of the AS_PATH. This represents an update to importantly in the case of the AS_PATH. This represents an update to
the error handling procedures given in [RFC4271] Sections 6.2 and 6.3 the error handling procedures given in Sections 6.2 and 6.3 of
by specifying the behavior in the presence of AS0. [RFC4271] by specifying the behavior in the presence of AS 0.
At least two implementations discard routes containing AS 0, and this At least two implementations discard routes containing AS 0, and this
document codifies this behavior. document codifies this behavior.
1.1. Requirements notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Behavior 2. Behavior
A BGP speaker MUST NOT originate or propagate a route with an AS A BGP speaker MUST NOT originate or propagate a route with an AS
number of zero in the AS_PATH, AS4_PATH, AGGREGATOR or AS4_AGGREGATOR number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or
attributes. AS4_AGGREGATOR attributes.
An UPDATE message that contains the AS number of zero in the AS_PATH An UPDATE message that contains the AS number of zero in the AS_PATH
or AGGREGATOR attribute MUST be considered as malformed, and be or AGGREGATOR attribute MUST be considered as malformed and be
handled by the procedures specified in [I-D.ietf-idr-error-handling]. handled by the procedures specified in [RFC7606].
An UPDATE message that contains the AS number of zero in the AS4_PATH An UPDATE message that contains the AS number of zero in the AS4_PATH
or AS4_AGGREGATOR attribute MUST be considered as malformed, and be or AS4_AGGREGATOR attribute MUST be considered as malformed and be
handled by the procedures specified in [I-D.ietf-idr-rfc4893bis]. handled by the procedures specified in [RFC6793].
If a BGP speaker receives zero as the peer AS in an OPEN message, it If a BGP speaker receives zero as the peer AS in an OPEN message, it
MUST abort the connection and send a NOTIFICATION with Error Code MUST abort the connection and send a NOTIFICATION with Error Code
"OPEN Message Error" and subcode "Bad Peer AS" (see [RFC4271] Section "OPEN Message Error" and subcode "Bad Peer AS" (see Section 6 of
6.2). A router MUST NOT initiate a connection claiming to be AS [RFC4271]). A router MUST NOT initiate a connection claiming to be
number zero. AS 0.
Authors of future protocol extensions that carry the Autonomous Authors of future protocol extensions that carry the Autonomous
System number are encouraged to keep in mind that AS number zero is System number are encouraged to keep in mind that AS 0 is reserved
reserved and to provide clear direction on how to handle AS number and to provide clear direction on how to handle AS 0.
zero.
3. IANA Considerations 3. IANA Considerations
The IANA is requested to update the Reference for number 0 in the The IANA has updated the registry for "16-bit Autonomous System
"Autonomous System (AS) Numbers" registry to reference this document. Numbers" so that the entry for AS 0 is simply "Reserved".
4. Security Considerations 4. Security Considerations
By allowing a Resource Public Key Infrastructure (RPKI) resource By allowing a Resource Public Key Infrastructure (RPKI) resource
holder to issue a ROA saying that AS 0 is the only valid origin for a holder to issue a ROA saying that AS 0 is the only valid origin for a
route, we allow them to state that a particular address resource is route, we allow them to state that a particular address resource is
not in use. By ensuring that all implementations that see AS 0 in a not in use. By ensuring that all implementations that see AS 0 in a
route ignore that route, we prevent a malicious party from announcing route ignore that route, we prevent a malicious party from announcing
routes containing AS 0 in an attempt to hijack those resources. routes containing AS 0 in an attempt to hijack those resources.
In addition, by standardizing the behavior upon reception of an In addition, by standardizing the behavior upon reception of an
AS_PATH (or AS4_PATH) containing AS 0, this document makes the AS_PATH (or AS4_PATH) containing AS 0, this document makes the
behavior better defined. behavior better defined.
5. Acknowledgements 5. References
The authors wish to thank Elwyn Davies, Enke Chen, Brian Dickson,
Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny McPherson, Chris
Morrow, iLya, John Scudder, Jeff Tantsura, Daniel Ginsburg and Susan
Hares. Apologies to those we may have missed, it was not
intentional.
6. References
6.1. Normative References
[I-D.ietf-idr-error-handling]
Scudder, J., Chen, E., Mohapatra, P., and K. Patel,
"Revised Error Handling for BGP UPDATE Messages",
draft-ietf-idr-error-handling-01 (work in progress),
December 2011.
[I-D.ietf-idr-rfc4893bis] 5.1. Normative References
Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", draft-ietf-idr-rfc4893bis-06 (work in
progress), April 2012.
[IANA.AS_Numbers] [IANA.AS_Numbers]
IANA, "Autonomous System (AS) Numbers", IANA, "Autonomous System (AS) Numbers",
<http://www.iana.org/assignments/as-numbers>. <http://www.iana.org/assignments/as-numbers>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway <http://www.rfc-editor.org/info/rfc2119>.
Protocol 4 (BGP-4)", RFC 4271, January 2006.
6.2. Informative References
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public
Key Infrastructure (RPKI) Objects Issued by IANA",
RFC 6491, February 2012.
Appendix A. Changes / Author Notes.
[RFC Editor: Please remove this section before publication ]
Draft accepted as IDR Doc, notes reset. Please see notes for
draft-wkumari-idr-as0.xml for prior comments.
Changes -00.
o Added AS4_PATH -- Robert Raszuk.
o Change "bgp listener" to "bgp speaker" -- Enke Chen
o Consistent use of AS_PATH (v., AS-PATH and AS PATH) -- Danny
McPherson
o New text for Sec 2 P1 -- Enke / Keyur / Scudder,
http://www.ietf.org/mail-archive/web/idr/current/msg05786.html
o I made a boo boo -- I had the file open in 2 editors, made changes
in one and overwrote them by saving on the "other, then checked
the broken one into SVN. Apologies to all whose comments I may
have missed...
Changes -01
o The WG thread
http://www.ietf.org/mail-archive/web/idr/current/msg05685.html
showed a very strong preference for separating the error
definition and handling -- the chairs also showed a prefernce to
Publish this and point to the error handling that Enke will write.
o The originally suggested text ("An UPDATE message that contains
the AS number of zero in the AS-PATH attribute MUST be...") only
referenced the AS-PATH, readded AS4_PATH, *AGGREGATOR as suggested
by Robert Raszak and Danny.
Changes -02
o Fixed the reference for *AGGREGATOR. This required breaking it [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
out into two sentences / clauses. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
o Added text on other places where an AS can show up (e.g: "4-Octet DOI 10.17487/RFC4271, January 2006,
AS specific Extended Community" [5668]) -- thanks to Keyur. <http://www.rfc-editor.org/info/rfc4271>.
Changes - 03 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
o Removed text on other places where an AS can show up (e.g: Autonomous System (AS) Number Space", RFC 6793,
"4-Octet AS specific Extended Community" [5668]). DOI 10.17487/RFC6793, December 2012,
o Added *very* generic "Authors of future protocol extensions..." <http://www.rfc-editor.org/info/rfc6793>.
text
Changes -04 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, July 2015,
<http://www.rfc-editor.org/info/rfc7606>.
o Looks like the draft needs an 'Updates: RFC 4271' header. Can you 5.2. Informative References
make the change? -- JGS.
o "You have things a bit scrambled in these two paragraphs" -- JGS
(whoops!).
o Editorial: I suggest dropping the parentheses in... JGS.
o Added "This document updates rfc 4271" to keep IDNITs happy...
o Bumped refs: draft-ietf-sidr-iana-objects has been published as
RFC 6491, idr-error is now -01, 4893bis is now -06
Changes - 05 [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public
Key Infrastructure (RPKI) Objects Issued by IANA",
RFC 6491, DOI 10.17487/RFC6491, February 2012,
<http://www.rfc-editor.org/info/rfc6491>.
o Added something to the intro saying what we update and why. This Acknowledgements
was in the abstract, but I didn't have it in the intro. Stupid.
Changes - 06 The authors wish to thank Elwyn Davies, Enke Chen, Brian Dickson,
o Incorporated some comments / clarifications from Gen-ART review Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny McPherson, Chris
(Elwyn Davies) Morrow, iLya, John Scudder, Jeff Tantsura, Daniel Ginsburg, and Susan
o Expaned acronyms. Hares. Apologies to those we may have missed; it was not
o RFC 6491 fix - clarified what it actually said and what intentional.
implications are.
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States
Email: warren@kumari.net Email: warren@kumari.net
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, WA 98110 Bainbridge Island, WA 98110
US United States
Email: randy@psg.com Email: randy@psg.com
Heather Schiller Heather Schiller
Verizon Google
22001 Loudoun County Parkway 1600 Amphitheatre Parkway
Ashburn 20147 Mountain View, CA 94043
US United States
Email: heather.schiller@verizon.com Email: has@google.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA United States
Phone:
Fax:
Email: keyupate@cisco.com Email: keyupate@cisco.com
URI:
 End of changes. 37 change blocks. 
166 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/