Network Working Group                                          J. Gersch
Internet-Draft                                          Secure64 SW Corp
Intended status: Standards Track                               D. Massey
Expires: March 2, 2013                                 Maka'ala Networks
                                                         C. Olschanowsky
                                               Colorado State University
                                                                L. Zhang
                                                                    UCLA
                                                         August 29, 2012


               DNS Resource Records for BGP Routing Data
                    draft-gersch-grow-revdns-bgp-01

Abstract

   This draft discusses the use of two DNS record types for storing BGP
   routing information in the reverse DNS.  The RLOCK record allows
   prefix owners to indicate whether the DNS is being used to publish
   routing data.  The SRO record allows operators to indicate whether an
   IPv4 or IPv6 prefix ought to appear in global routing tables and
   identifies authorized origin Autonomous System Number(s) for that
   prefix.  The resulting published data can be used in a variety of
   contexts from routing security to address ownership.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   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
   and may be updated, replaced, or obsoleted by other documents 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 March 2, 2013.

Copyright Notice

   Copyright (c) 2012 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



Gersch, et al.            Expires March 2, 2013                 [Page 1]


Internet-Draft            BGP Resource Records               August 2012


   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
     1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  5
   3.  Overview of Route Publishing . . . . . . . . . . . . . . . . .  6
   4.  Overview of Route Verification . . . . . . . . . . . . . . . .  7
   5.  The RLOCK Resource Record  . . . . . . . . . . . . . . . . . .  9
     5.1.  RLOCK RDATA Wire Format  . . . . . . . . . . . . . . . . . 10
     5.2.  RLOCK Presentation Format  . . . . . . . . . . . . . . . . 10
     5.3.  RLOCK RR Examples  . . . . . . . . . . . . . . . . . . . . 10
   6.  The SRO Resource Record  . . . . . . . . . . . . . . . . . . . 11
     6.1.  SRO RDATA Wire Format  . . . . . . . . . . . . . . . . . . 11
     6.2.  SRO RRDATA Presentation Format . . . . . . . . . . . . . . 12
     6.3.  SRO RR Examples  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Discussion and Related Work  . . . . . . . . . . . . . . . . . 13
     7.1.  Prior Work on CIDR names for Routing . . . . . . . . . . . 13
     7.2.  RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     12.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 21
     A.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . . . . 21
     A.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24











Gersch, et al.            Expires March 2, 2013                 [Page 2]


Internet-Draft            BGP Resource Records               August 2012


1.  Introduction

1.1.  Overview

   This draft describes a method in which a prefix owner can exploit the
   existing reverse DNS tree structure, along with the authentication
   provided by DNSSEC [RFC4033], to publish information about whether a
   prefix can be announced and identify the origin Autonomous System(s)
   that may originate a route to that prefix.  This data is
   complementary to a variety of other data sources ranging from
   existing databases to new directions.

   Publishing route information in the Reverse DNS takes advantage of
   infrastructure that already exists and has been globally deployed.
   No new infrastructure deployment is required, in contrast with
   approaches that use purpose-built resource certification.

   Other key advantages to using the Reverse DNS are that it 1) has been
   in successful operation for many years, 2) has an existing
   operational model where prefix owners currently manage their IP
   address space (through various models from local operation to hosting
   companies), 3) has an existing operational model where both
   registries and providers delegate authority to entities receiving
   address space, 4) the resulting reverse DNS data can be authenticated
   using DNSSEC [RFC4033], and 5) the data can be easily checked using
   simple tools ranging from DNS query tools such as DIG to more
   elaborate systems.

   A prefix owner must OPT-IN to the approach.  Prefix owners who do not
   take any action are not impacted, but also do not gain any
   advantages.  Prefix owners that do choose to participate would
   thereby enable a number of tools to make use of the published data.
   The objective of this draft is to standardize the format for
   indicating participation and publishing data.  A variety of potential
   uses for the data are discussed later in the document, but are
   provided only to illustrate the usefulness of the data and should not
   be taken as a comprehensive list of all possible applications.

1.2.  Scope

   We limit the scope of this internet draft to associating origin and
   optionally a transit provider last hop with a prefix.  Armed with
   this information, one can address origin hijacks, sub-prefix hijacks,
   and some forms of path integrity -- a capability that can be
   implemented and deployed in a reasonable time frame.  Future
   expansion is readily made possible: the SRO record is kept simple for
   now, but may be expanded to incorporate additional fields.  New RR
   types can also be added later for additional capabilities.



Gersch, et al.            Expires March 2, 2013                 [Page 3]


Internet-Draft            BGP Resource Records               August 2012


   The proposed naming structure and record types recommend that a
   unique entry be published for each prefix, not ranges as with RPKI.
   This can make routing security policy explicit and help minimize
   route table bloat.















































Gersch, et al.            Expires March 2, 2013                 [Page 4]


Internet-Draft            BGP Resource Records               August 2012


2.  Conventions Used In This Document

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














































Gersch, et al.            Expires March 2, 2013                 [Page 5]


Internet-Draft            BGP Resource Records               August 2012


3.  Overview of Route Publishing

   This document defines two new DNS resource records types (RRTypes)
   and describes how two existing record types can be associated with
   prefixes.

   1.  The RLOCK RRType (Route Lock)

       *  Purpose: Indicates that the Reverse DNS zone has enabled BGP
          route publishing.

       *  The presence of the RLOCK Record at the apex of a Reverse DNS
          zone indicates that a prefix owner has OPTED-IN to BGP Route
          Publishing.  All route announcements that map to this zone
          will be denied as INVALID unless an SRO record exists that
          specifically authorizes the announcement.

   2.  The SRO RRType (Secure Route Origin)

       *  Purpose: Declare an authorized route origin ASN and optionally
          a last hop that specifies a transit provider (not a peer or
          customer) for comparison against BGP route announcements.

       *  Placed in the Reverse DNS at the domain name corresponding to
          the associated CIDR address block.

   Organizations that have been assigned and/or allocated CIDR address
   blocks also have Reverse-DNS delegations assigned to them from either
   the Regional Internet Registries (RIPE, ARIN, APNIC, etc.) or from a
   sub-delegation.

   Address-block owners may use these new record types to declare
   authoritative data for route origins associated with that address
   block.  This data may be declared statically, with a long TTL (Time
   To Live) if the routing data changes infrequently.  Alternatively,
   dynamic DNS and short TTLs can be used to rapidly publish and
   disseminate the authoritative information on a world-wide basis in
   near real-time.

   The RLOCK and SRO records are to be stored in the reverse-DNS in
   zones with domain names that correspond to the associated CIDR
   address block.  These domain names are to be constructed per the
   naming specification described in [I-D.gersch-dnsop-revDNS-CIDR].

   The RLOCK and SRO records MUST be signed with DNSSEC and have a valid
   DNSSEC chain-of-trust.





Gersch, et al.            Expires March 2, 2013                 [Page 6]


Internet-Draft            BGP Resource Records               August 2012


4.  Overview of Route Verification

   Various applications could be written to use BGP records published in
   the Reverse DNS.  One example is an application to perform near-real-
   time route origin verification that alerts operators of hijacks or
   directly interacts with a router to prevent the hijack.  Another
   application could perform a nightly analysis that generates router
   prefix filters.  A third application could cross-check data in the
   Internet Routing Registries (IRR) against the data in the reverse
   DNS.  This list is not intended to be comprehensive, but instead aims
   to illustrate the potential uses of the published data.

   These applications analyze BGP announcements by performing DNS
   queries to classify route route announcements into one of the
   following three categories:

   1.  "VALID": a DNSSEC-validated SRO RRSET was received and one of the
       route origins in the RRSET matches the origin contained in the
       BGP route announcement.

   2.  "INVALID": a route hijack was detected.

       A.  The DNSSEC-validated SRO responses received did NOT match the
           origin of the route announcement.  This is indicative of an
           origin hijack.

       B.  There was no SRO record at the domain name corresponding to
           this address block, but the authoritative zone did contain an
           RLOCK statement.  This is indicative of a sub-prefix hijacks.

   3.  "NOTFOUND": there was no SRO record for this prefix and no RLOCK
       record to protect the zone, or the data did not properly validate
       with DNSSEC.  In this case, the algorithm cannot authoritatively
       state that the prefix is valid or invalid, so it is simply marked
       as not found.  Most routes today are in this category, as it
       takes a specific action to OPT-IN to this methodology.

   This verification algorithm MUST "fail-safe".  If a query for a DNS
   record fails, or if DNSSEC fails to validate the record, the
   algorithm MUST behave as if no DNS records were present in the first
   place.  This results in marking a BGP announcement as "NOTFOUND".
   One could completely unplug a router verification application at any
   time and internet routing would continue to work just as it does
   today.  The default state is always "not found".

   Note that this implies the verification algorithm MUST use DNSSEC-
   enabled queries (set the DO bit) and MUST check for a validated
   response (the AD bit).  A successful DNSSEC-downgrade attack would



Gersch, et al.            Expires March 2, 2013                 [Page 7]


Internet-Draft            BGP Resource Records               August 2012


   result in classifying records as "NOTFOUND".  However the redundancy
   in DNS would allow checking of multiple slave DNS servers should
   DNSSEC fail to validate.

   The core of the verification algorithm can be summarized as follows:

   1.  Given a BGP announcement from a router feed, offline database,
       prefix filter, or other source, perform a DNSSEC-validated query
       for the SRO records at the domain name corresponding to the CIDR
       prefix in the BGP announcement.

   2.  Case 1: If no records exist (NXDOMAIN or NOERROR with number of
       answers=0), use the AUTHORITY section of the answer to determine
       the covering zone.  Perform a query to that domain name (the zone
       apex) for an RLOCK record.  There are two possible responses to
       the RLOCK query:

       A.  NOERROR, answer=0: the RLOCK does not exist; the zone owner
           has not opted in.  Mark the announcement as "NOTFOUND".

       B.  RLOCK exists: the zone owner has OPTED-IN.  Mark the
           announcement as "INVALID" since no SRO record exists to vouch
           for the announcement.  This may be an example of a sub-prefix
           hijack.

   3.  Case 2: One or more SRO records were returned from the query.
       Loop through each SRO in the RRSET to compare the origin with the
       data in the route announcement.  If a record with a matching set
       of data is found, mark the announcement as "VALID".  If no match
       is found, mark the announcement as "INVALID".





















Gersch, et al.            Expires March 2, 2013                 [Page 8]


Internet-Draft            BGP Resource Records               August 2012


5.  The RLOCK Resource Record

   The RLOCK resource record indicates "Route Lock".  This record is
   placed at the apex of a reverse-DNS zone to indicate that the zone is
   being used to publish routing information.  If this record is
   present, all route announcements for the CIDR address block covered
   by this zone MUST be marked as "INVALID" unless they are specifically
   authorized by a SRO record.

   The main purpose of the RLOCK statement is to indicate participation
   (OPT-IN) and as a side-effect prevent sub-prefix route hijacks.
   Applications that query for an SRO record may get an NXDOMAIN or
   NOERROR with 0 answers.  In this case, the application queries the
   domain name specified in the AUTHORITY section for an RLOCK record
   (this will be at the zone apex).  If the RLOCK is present, the route
   announcement MUST be marked as "INVALID".  Otherwise there is no SRO
   and no RLOCK, so the route announcement MUST be marked as "NOTFOUND".

   The effective span of control for an RLOCK is dependent on the
   structure of the Reverse DNS zone.  To be more specific, a Reverse
   DNS zone that has no delegations will have a span of control that
   covers all prefixes at or below the CIDR prefix specified by the
   domain name at the zone apex.  Any zone delegation (also known as a
   "cut point") starts a new zone authority.  Those prefixes in the
   delegated zone will not be covered by the parent zone's RLOCK.  As an
   example, consider the zone at 129.82.0.0/16 and assume that it has
   only one delegation at 129.82.138.0/24.  The /16 RLOCK covers all
   prefixes within the /16 to /32 range with the exception of prefixes
   within the 129.82.138.0/24 through /32 range.  The child zone would
   need to have its own RLOCK.

   The RLOCK record MUST be signed with DNSSEC and have an associated
   RRSIG record.  If a resolving DNS server cannot validate the DNSSEC
   signature, the SRO record should be ignored as if it were not even
   present in the zone.

   The Type value for the RLOCK RR type is currently unassigned.  We are
   temporarily using private RRTYPE TYPE65400 until a formal number is
   assigned by IANA.

   The RLOCK RR is class independent.

   The RLOCK RR has no special TTL requirements.

   Example use of RLOCK records, taken directly from the current
   testbed, are included in the appendix.





Gersch, et al.            Expires March 2, 2013                 [Page 9]


Internet-Draft            BGP Resource Records               August 2012


5.1.  RLOCK RDATA Wire Format

   The RLOCK record contains no RRData (RDLength field = 0).

5.2.  RLOCK Presentation Format

   Since there is no RRDATA, the presentation format of the RDATA
   portion is simply the RLOCK keyword with no extra fields.

5.3.  RLOCK RR Examples

   The following example shows an RLOCK RR enabling routing security for
   the zone covering 129.82.0.0/16.

     82.129.in-addr.arpa.  86400  IN    RLOCK




































Gersch, et al.            Expires March 2, 2013                [Page 10]


Internet-Draft            BGP Resource Records               August 2012


6.  The SRO Resource Record

   Zones that participate in this approach use "Secure Route Origin"
   (SRO) resource records to indicate that a prefix may be announced.
   This record contains a mandatory ORIGIN ASN field.  It can also
   contain an optional transit provider that can be used as a last hop.
   Both 2 and 4 bytes AS numbers are accommodated.

   The ORIGIN AS indicates an AS number that is authorized to originate
   a route announcement for the CIDR address block associated with the
   SRO record's Reverse DNS domain name.

   The optional LAST HOP indicates an AS number that is authorized to
   provide transit to the origin for the CIDR address block associated
   with the SRO record's Reverse DNS domain name.  If the LAST HOP is
   not included the record has a length of 4.  If the last hop is
   present, the record length is 8.

   The SRO record MUST be signed with DNSSEC [RFC4033] and have an
   associated RRSIG record.  If a resolving DNS server cannot validate
   the DNSSEC signature, the SRO record should be ignored and an attempt
   should be made to query an alternate DNS server.  If all servers
   fail, the route prefix should be classified as "NOTFOUND".

   The Type value for the SRO RR type is currently unassigned.  We are
   temporarily using TYPE65401 until a formal number is assigned by
   IANA.

   The SRO RR is class independent.

   The SRO RR has no special TTL requirements.

6.1.  SRO RDATA Wire Format

   The SRO RDATA wire format MUST contain either 4 octets which specify
   the ORIGIN AS number or 8 octets which specify the ORIGIN AS and the
   LAST HOP. 2-octet AS Numbers MUST be encoded with leading zeroes to
   construct a complete 4-octet field.

   The SRO record type is intended to evolve over time; in the future
   there may be optional extensions to indicate a version numbers and
   other fields such as last hop, system capacity, IRR information, etc.
   The value of the RDLength provides the flexibility to determine
   whether additional fields are present or not.  Applications MUST
   always interpret the first 4 octets as the ORIGIN AS number.






Gersch, et al.            Expires March 2, 2013                [Page 11]


Internet-Draft            BGP Resource Records               August 2012


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         ORIGIN AS Number                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Optional Last Hop Transit AS Number              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.2.  SRO RRDATA Presentation Format

   The presentation format of the RDATA portion is as follows:

   AS Numbers are represented in asdot notation which is a combination
   of asplain and asdot+ notation.  That is, any ASN in the 2-octet
   range is represented in asplain (simple decimal representation of the
   ASN).  Any ASN above the 2-octet range is represented in asdot+
   notation which breaks an ASN into two 16-bit values separated by a
   dot.  For example, AS65535 will be represented by the decimal number
   "65535" while AS65536 will be represented as "1.0".

   The ORIGIN AS field MUST be present.

   The LAST HOP field is optional.

6.3.  SRO RR Examples

   The following example shows an SRO RR authorizing AS14041 as the
   origin for CIDR address block 129.82.0.0/16 in the reverse DNS.

        82.129.in-addr.arpa.  86400  IN   SRO 12145

   The next example shows two separate origins to be authorized for a
   prefix.  This example also illustrates the use of the asdot notation.

        82.129.in-addr.arpa.  86400  IN   SRO 12145
                              86400  IN   SRO 3.1858

   The third example shows two one origin that has two transit
   providers.

        82.129.in-addr.arpa.  86400  IN   SRO 12145 14041
                              86400  IN   SRO 12145 209









Gersch, et al.            Expires March 2, 2013                [Page 12]


Internet-Draft            BGP Resource Records               August 2012


7.  Discussion and Related Work

   This work is not the first to propose entering routing data in the
   Reverse DNS and there are also many other proposed approaches for
   publishing routing data.  We first review some of the past work and
   then discusses the differences presented in this approach.

7.1.  Prior Work on CIDR names for Routing

   Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use
   the reverse DNS to verify the origin AS associated with a prefix.
   This requires both a naming convention for converting the name into a
   prefix and additional resource record types for storing origin
   information, along with recommendations on their use.  More recently
   [I-D.donnerhacke-sidr-bgp-verification-dnssec] including links to IRR
   data and also includes the notion of policy in adjacency, but this
   approach also introduces a new reverse DNS tree under "BGP.ARPA."
   CNAME and DNAME records must be used in publishing the data.

   Our approach differs in several respects.  We rely on the existing
   reverse DNS tree without creating a new hierarchy such as
   "BGP.ARPA.".  We exploit the naming convention in
   [I-D.gersch-dnsop-revDNS-CIDR] so one does not need to introduce
   CNAME or DNAME records (though an operator could choose to do so if
   so desired).  We assume optional participation and introduce the
   concept of an RLOCK resource record to indicate participation.  We
   currently limit our approach to detecting false sub-prefix and false
   origin route announcements.  Extensions to include links to other
   databases such as IRR can be achieved in combination with or in lieu
   of an SRO record and further path validation can be included, but the
   scope of this document is intentionally limited, both for clarity and
   to match actual implementation.  Finally, we separate the publishing
   technique which is specified in this document from the variety of
   ways in which one may make use of the data, recognizing that
   different operators will make different choices on how to make use of
   the data.

7.2.  RPKI

   A great deal of work has been done in the sidr working group on
   Resource Public Key Infrastructure
   [RFC6480][RFC6481][RFC6482][RFC6483].

   RPKI, also known as Resource Certification, is a specialized public
   key infrastructure (PKI) framework designed to secure Border Gateway
   Protocol (BGP).  RPKI provides a way to connect Internet number
   resource information (such as Autonomous System numbers and IP
   Addresses) to a trust anchor.  The certificate structure mirrors the



Gersch, et al.            Expires March 2, 2013                [Page 13]


Internet-Draft            BGP Resource Records               August 2012


   way in which Internet number resources are distributed.  That is,
   resources are initially distributed by the IANA to the Regional
   Internet Registries (RIRs), who in turn distribute them to Local
   Internet Registries (LIRs), who then distribute the resources to
   their customers.  RPKI can be used by the legitimate holders of the
   resources to control the operation of Internet routing protocols to
   prevent route hijacking and other attacks. [cited from Wikipedia].

   The publication of BGP route origin information in the reverse-DNS is
   a complementary technique to RPKI.  While there is some overlap in
   the techniques, there are also different goals for the reverse-DNS.

   The Reverse-DNS publication method uses DNSSEC as its base trust
   model, not a chain of certificates.  If an organization has a DNSSEC-
   signed delegation for a reverse-DNS address block, that organization
   is the legitimate owner and may place SRO and RLOCK statements in
   their zone without the interaction of any other organization.  If an
   address block is sold or transferred, either the RIR (Regional
   Internet Registry) will change its signed delegation records to
   reflect the change, or the organization itself may independently
   implement a signed sub-delegation.






























Gersch, et al.            Expires March 2, 2013                [Page 14]


Internet-Draft            BGP Resource Records               August 2012


8.  Security Considerations

   Applications that query the DNS for SRO and RLOCK records MUST
   request them from DNSSEC-enabled servers and have the DO bit set.
   Responses that are returned MUST be checked to verify that the D bit
   is set indicating that the responses have been validated.  Otherwise
   the response should be ignored.

   The absence of DNSSEC or the inability to contact any nameservers
   MUST indicate the route is vialbe (NOTFOUND).









































Gersch, et al.            Expires March 2, 2013                [Page 15]


Internet-Draft            BGP Resource Records               August 2012


9.  IANA Considerations

   RRType numbers need to be assigned for the SRO and RLOCK records.
   The current testbed temporarily substitutes TYPE65400 for the RLOCK
   record and TYPE65401 for the SRO record.














































Gersch, et al.            Expires March 2, 2013                [Page 16]


Internet-Draft            BGP Resource Records               August 2012


10.  Acknowledgments

   We would like to thank Danny McPherson for his comments and
   suggestions.  In addition, this document was aided via numerous
   discussions at NANOG, IETF and private meetings with ISPs, telecomm
   carriers, and research organizations too numerous to mention by name.
   Thanks to all for your comments and advice.












































Gersch, et al.            Expires March 2, 2013                [Page 17]


Internet-Draft            BGP Resource Records               August 2012


11.  Change History

   Changes from version 00 to 01

      Removed all discussion of an "alternate naming scheme".  A related
      draft on prefix naming had proposed both a standard naming scheme
      and an alternate naming scheme, but the alternate naming scheme
      was removed.  Since the alternate naming scheme no longer exists,
      it was no longer necessary to discuss how this draft would deal
      with the alternate alternate naming scheme.

      An optional transit provider field was added the SRO record.

      Examples were updated based on the SRO change and operational
      experience.

      Added Cathie Olschanowsky as a co-author


































Gersch, et al.            Expires March 2, 2013                [Page 18]


Internet-Draft            BGP Resource Records               August 2012


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [I-D.bates-bgp4-nlri-orig-verif]
              Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based
              NLRI origin AS verification in BGP",
              draft-bates-bgp4-nlri-orig-verif-00 (work in progress),
              January 1998.

   [I-D.donnerhacke-sidr-bgp-verification-dnssec]
              Donnerhacke, L. and W. Wijngaards, "DNSSEC protected
              routing announcements for BGP",
              draft-donnerhacke-sidr-bgp-verification-dnssec-04 (work in
              progress), May 2008.

   [I-D.gersch-dnsop-revDNS-CIDR]
              Gersch, J. and D. Massey, "Reverse DNS Naming Convention
              for CIDR Address Blocks",
              draft-gersch-dnsop-revDNS-CIDR-02 (work in progress),
              May 2012.

   [RFC1876]  Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
              Means for Expressing Location Information in the Domain
              Name System", RFC 1876, January 1996.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, February 2012.

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              February 2012.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482, February 2012.

   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations



Gersch, et al.            Expires March 2, 2013                [Page 19]


Internet-Draft            BGP Resource Records               August 2012


              (ROAs)", RFC 6483, February 2012.


















































Gersch, et al.            Expires March 2, 2013                [Page 20]


Internet-Draft            BGP Resource Records               August 2012


Appendix A.  Examples

A.1.  Example 1

   This example shows data entered for the prefix 129.82.0.0/16.  The
   prefix owner has authorized the announcement of 129.82.0.0/16 and the
   four /18's at 129.82.0.0/18, 129.82.64.0/18, 129.82.128.0/18, and
   129.82.192.0/18.  All the prefixes originate from AS12145 and have a
   transit provider of AS14041.

   Finally, the example shows a record for a 129.82.177/24 so that the
   parent zone can manage this for the child zone at 177.82.129.in-
   addr.arpa.  Any entry in the child zone would override the data
   stored at the parent.

   Note: this data is directly cut and paste from actual deployment.
   TYPE 65400 is being used for RLOCK and TYPE 65401 for SRO records.
   This draft requests IANA to assign numbers for RLOCK and SRO, the
   values here are purely for illustrative purposes.
































Gersch, et al.            Expires March 2, 2013                [Page 21]


Internet-Draft            BGP Resource Records               August 2012


     $TTL 3600
     $ORIGIN 82.129.in-addr.arpa.

     @    IN    SOA     rush.colostate.edu.  dnsadmin.colostate.edu. (
                             2012082800      ; serial number
                             900             ; refresh, 15 minutes
                             600             ; update retry, 10 minutes
                             86400           ; expiry, 1 day
                             3600            ; minimum, 1 hour
                            )

          IN    NS      dns1.colostate.edu.
          IN    NS      dns2.colostate.edu.

     @                  IN   TYPE65400 \# 0
     ;                  RLOCK    OPT-IN; deny all route announcements
     ;                           except those authorized

     @                  IN   TYPE65401 \# 4 00002f71
     ; 129.82.0.0/16         SRO  12145 14041

     0.0.m              IN   TYPE65401 \# 4 00002f71
     ; 129.82.0.0/18         SRO 12145 14041

     1.0.m              IN   TYPE65401 \# 4 00002f71
     ; 129.82.64.0/18        SRO 12145  14041

     0.1.m              IN   TYPE65401 \# 4 00002f71
     ; 129.82.128.0/18       SRO 12145 14041

     1.1.m              IN   TYPE65401 \# 4 00002f71
     ; 129.82.192.0/18       SRO 12145 14041

     1.0.0.0.1.1.0.1.m  IN   TYPE65401 \# 4 00004070
     ; 129.82.177.0/24       SRO 16496

     ;  delegations required for 256 /24 zones which contain PTR records

     1   IN  NS  dns1.colostate.edu.
         IN  NS  dns2.colostate.edu.
     2   IN  NS  dns1.colostate.edu.
         IN  NS  dns2.colostate.edu.

     ;  continuation to 255 is left out for the sake of brevity







Gersch, et al.            Expires March 2, 2013                [Page 22]


Internet-Draft            BGP Resource Records               August 2012


A.2.  Example 2

   This example shows data entered for the prefix 216.17.128.0/17.  The
   prefix owner has authorized the announcement of 216.17.128.0/17.  The
   prefix originates from AS6582.

           1.m.17.216.in-addr.arpa  NS   ns.frii.net

   This delegation refers to the new /17 zone and the domain name is not
   in conflict with any of the pre-existing /24 zones at IN-ADDR.ARPA.
   This delegation is to be placed at the IN-ADDR.ARPA zone.

    $TTL 3600
    $ORIGIN 1.m.17.216.in-addr.arpa.

    @    IN   SOA     ns1.frii.net.  hostmaster.frii.net. (
                            2012021300      ; serial number
                            14400           ; refresh, 4 hours
                            3600            ; update retry, 1 hour
                            604800          ; expiry, 7 days
                            600             ; minimum, 10 minutes
                           )

         IN   NS      ns1.frii.net.
         IN   NS      ns2.frii.net.

    $ORIGIN 17.216.in-addr.arpa.

    1.m               IN   TYPE65400 \# 0
    ;                      RLOCK    OPT-IN; deny all route announcements
    ;                               except those authorized

    1.m               IN   TYPE65401 \# 4 000019b6
    ; 216.17.128.0/17      SRO 6582

    ; no other delegations or PTR records are needed in this zone file
    ; since the /24 delegations are at ARIN at xxx.17.216.IN-ADDR.ARPA














Gersch, et al.            Expires March 2, 2013                [Page 23]


Internet-Draft            BGP Resource Records               August 2012


Authors' Addresses

   Joe Gersch
   Secure64 SW Corp
   Fort Collins, CO
   US

   Email: joe.gersch@secure64.com


   Dan Massey
   Maka'ala Networks
   Fort Collins, CO
   US

   Email: dan@makaalanetworks.com


   Cathie Olschanowsky
   Colorado State University
   Fort Collins, CO
   US

   Email: cathie@cs.colostate.edu


   Lixia Zhang
   UCLA
   Los Angeles, CA
   US

   Email: lixia@cs.ucla.edu



















Gersch, et al.            Expires March 2, 2013                [Page 24]