idr
Internet Engineering Task Force (IETF)                         W. Kumari
Internet-Draft
Request for Comments: 7607                                        Google
Updates: 4271 (if approved)                                                    R. Bush
Intended status:
Category: Standards Track                      Internet Initiative Japan
Expires: February 27, 2013
ISSN: 2070-1721                                              H. Schiller
                                                                 Verizon
                                                                  Google
                                                                K. Patel
                                                           Cisco Systems
                                                             August 26, 2012 2015

                    Codification of AS 0 processing.
                         draft-ietf-idr-as0-06 Processing

Abstract

   This document updates RFC 4271 and proscribes the use of Autonomous
   System (AS) 0 in the Border Gateway Protocol (BGP) OPEN OPEN, AS_PATH,
   AS4_PATH, AGGREGATOR, and AS_PATH /
   AS4_PATH AS4_AGGREGATOR attributes in the BGP attribute. UPDATE
   message.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 27, 2013.
   http://www.rfc-editor.org/info/rfc7607.

Copyright Notice

   Copyright (c) 2012 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3   2
     1.1.  Requirements notation . Notation . . . . . . . . . . . . . . . . . . 3   2
   2.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4   3
   5.  Acknowledgements  . . . . . .  References  . . . . . . . . . . . . . . . . . 4
   6.  References . . . . . . . .   4
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . .
   Acknowledgements  . . . . . . . . . . 5
   Appendix A.  Changes / Author Notes. . . . . . . . . . . . . . . . 5   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6   5

1.  Introduction

   Autonomous System 0 is was listed in the IANA Autonomous System Number
   Registry as "Reserved - May be use [sic] to identify non-routed
   networks" ([IANA.AS_Numbers]).

   [RFC6491] specifies that AS number zero 0 in a Route Origin Attestation (ROA) is
   used to mark a prefix and all its more specific prefixes as not to be
   used in a routing context.  This allows a resource holder to signal
   that a prefix (and the more specifics) should not be routed by
   publishing a ROA listing AS0 AS 0 as the only origin.  To respond to this
   signal requres requires that BGP implementations do not accept or propagate
   routes containing AS0. AS 0.

   No clear statement that AS 0 was proscribed could be found in any BGP
   specification.  This document corrects this omission, most
   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 of
   [RFC4271] by specifying the behavior in the presence of AS0. AS 0.

   At least two implementations discard routes containing AS 0, and this
   document codifies this behavior.

1.1.  Requirements notation Notation

   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.  Behavior

   A BGP speaker MUST NOT originate or propagate a route with an AS
   number of zero in the AS_PATH, AS4_PATH, AGGREGATOR AGGREGATOR, or
   AS4_AGGREGATOR attributes.

   An UPDATE message that contains the AS number of zero in the AS_PATH
   or AGGREGATOR attribute MUST be considered as malformed, malformed and be
   handled by the procedures specified in [I-D.ietf-idr-error-handling]. [RFC7606].

   An UPDATE message that contains the AS number of zero in the AS4_PATH
   or AS4_AGGREGATOR attribute MUST be considered as malformed, malformed and be
   handled by the procedures specified in [I-D.ietf-idr-rfc4893bis]. [RFC6793].

   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
   "OPEN Message Error" and subcode "Bad Peer AS" (see [RFC4271] Section
   6.2). 6 of
   [RFC4271]).  A router MUST NOT initiate a connection claiming to be
   AS
   number zero. 0.

   Authors of future protocol extensions that carry the Autonomous
   System number are encouraged to keep in mind that AS number zero 0 is reserved
   and to provide clear direction on how to handle AS number
   zero. 0.

3.  IANA Considerations

   The IANA is requested to update has updated the Reference registry for number 0 in the
   "Autonomous "16-bit Autonomous System (AS)
   Numbers" registry to reference this document. so that the entry for AS 0 is simply "Reserved".

4.  Security Considerations

   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
   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
   route ignore that route, we prevent a malicious party from announcing
   routes containing AS 0 in an attempt to hijack those resources.

   In addition, by standardizing the behavior upon reception of an
   AS_PATH (or AS4_PATH) containing AS 0, this document makes the
   behavior better defined.

5.  Acknowledgements

   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.

5.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]
              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, "Autonomous System (AS) Numbers",
              <http://www.iana.org/assignments/as-numbers>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI
              10.17487/RFC4271, January 2006.

6.2. 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793, DOI
              10.17487/RFC6793, December 2012,
              <http://www.rfc-editor.org/info/rfc6793>.

   [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>.

5.2.  Informative References

   [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.

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" -- 2012,
              <http://www.rfc-editor.org/info/rfc6491>.

Acknowledgements

   The authors wish to thank Elwyn Davies, Enke Chen
   o  Consistent use of AS_PATH (v., AS-PATH and AS PATH) -- Chen, Brian Dickson,
   Bruno Decraene, Robert Raszuk, Jakob Heitz, Danny
      McPherson
   o  New text for Sec 2 P1 -- Enke / Keyur / McPherson, Chris
   Morrow, iLya, John 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 Jeff Tantsura, Daniel Ginsburg, and overwrote them by saving on the "other, then checked
      the broken one into SVN. Susan
   Hares.  Apologies to all whose comments I those we 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 missed; it
      out into two sentences / clauses.
   o  Added text on other places where an AS can show up (e.g: "4-Octet
      AS specific Extended Community" [5668]) -- thanks to Keyur.

   Changes - 03
   o  Removed text on other places where an AS can show up (e.g:
      "4-Octet AS specific Extended Community" [5668]).
   o  Added *very* generic "Authors of future protocol extensions..."
      text

   Changes -04

   o  Looks like the draft needs an 'Updates: RFC 4271' header.  Can you
      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

   o  Added something to the intro saying what we update and why.  This was in the abstract, but I didn't have it in the intro.  Stupid.

   Changes - 06
   o  Incorporated some comments / clarifications from Gen-ART review
      (Elwyn Davies)
   o  Expaned acronyms.
   o  RFC 6491 fix - clarified what it actually said and what
      implications are. not
   intentional.

Authors' Addresses

   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US
   United States

   Email: warren@kumari.net

   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, WA  98110
   US
   United States

   Email: randy@psg.com

   Heather Schiller
   Verizon
   22001 Loudoun County
   Google
   1600 Amphitheatre Parkway
   Ashburn  20147
   US
   Mountain View, CA  94043
   United States

   Email: heather.schiller@verizon.com has@google.com

   Keyur Patel
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   United States

   Email: keyupate@cisco.com
   URI: