Network Working Group J. Gersch
Internet-Draft Secure64 SW Corp
Intended status: Standards Track D. Massey
Expires: September 1, 2012 Colorado State University
E. Osterweil
Verisign
L. Zhang
UCLA
February 29, 2012
DNS Resource Records for BGP Routing Data
draft-gersch-grow-revdns-bgp-00
Abstract
This draft proposes the creation 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 published data can be used in a variety of contexts and
can be extended to include additional information. This work is part
of an on-going effort and is accessible in an active testbed.
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 September 1, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gersch, et al. Expires September 1, 2012 [Page 1]
Internet-Draft BGP Resource Records February 2012
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
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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Gersch, et al. Expires September 1, 2012 [Page 2]
Internet-Draft BGP Resource Records February 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 to 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.
Examples taken directly from the current testbed are included in the
appendix.
1.2. Scope
The scope of this internet draft is purposely limited to the subject
of BGP route origins. There are many other possible topics that
could be explored: BGP path verification, BGP capacity constraints,
man-in-the-middle attacks, routing policy, address ownership
assignment and provenance, route ingress and egress filtering,
Gersch, et al. Expires September 1, 2012 [Page 3]
Internet-Draft BGP Resource Records February 2012
interface to internet routing registries, and so on. These are all
reasonable extensions.
We limit the scope of this internet draft to the prevention of origin
and sub-prefix hijacks -- 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.
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 September 1, 2012 [Page 4]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 5]
Internet-Draft BGP Resource Records February 2012
3. Overview of Route Publishing
This document defines two new DNS resource records types (RRTypes)
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 BOGUS unless an SRO record exists that
specifically authorizes the announcement.
2. The SRO RRType (Secure Route Origin)
* Purpose: Declare an authorized route origin ASN 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 September 1, 2012 [Page 6]
Internet-Draft BGP Resource Records February 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. "BOGUS": 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. "VIABLE": 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 bogus, so it is simply marked
as viable. 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 "VIABLE". 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 "viable".
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 September 1, 2012 [Page 7]
Internet-Draft BGP Resource Records February 2012
result in classifying records as "viable". 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. Upon receipt of a BGP announcement, 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 "VIABLE".
B. RLOCK exists: the zone owner has OPTED-IN. Mark the
announcement as "BOGUS" 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 "BOGUS".
This algorithm can be extended to handle the case of "overlapping"
domain names at octet boundaries. Consider the example where a /16
zone has 256 zone delegations for each of its /24 children. For ease
of implementation the zone author may wish to place an SRO or RLOCK
statement at the overlapping domain name contained in the parent zone
rather than create data within the 256 child zones.
In this example, the algorithm should check for BGP data in the /24
zone as normal. If data is found, it is considered authoritative and
the algorithm stops. If no SRO or RLOCK is found in this /24 zone,
the algorithm queries the "overlapping name" as defined in
[I-D.gersch-dnsop-revDNS-CIDR] for an SRO record. If no records are
found, it then queries the parent zone (as defined by the AUTHORITY
portion of the DNS answer) for an RLOCK statement.
Gersch, et al. Expires September 1, 2012 [Page 8]
Internet-Draft BGP Resource Records February 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 "bogus" 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 "bogus". Otherwise there is no SRO
and no RLOCK, so the route announcement MUST be marked as "viable"
(with the possible exception outlined next regarding "overlapping"
octet boundaries).
The RLOCK statement may also be present at zone cuts created at octet
or nibble boundaries. The "overlapping domain name" specified in
[I-D.gersch-dnsop-revDNS-CIDR] is used to specify the CIDR address
block. This type of RLOCK allows the zone author to create one
parent zone with 256 delegations to the next octet and add an RLOCK
for each one of the child zones. The alternative is to edit all 256
child zones to place the RLOCK at each zone apex. Applications that
search for an RLOCK should also search the parent zone to see if
there is an RLOCK at the overlapping name.
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, either directly, or with an "overlapping"
domain name.
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.
Gersch, et al. Expires September 1, 2012 [Page 9]
Internet-Draft BGP Resource Records February 2012
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.
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
The following example shows RLOCK at "overlapping /24" address
blocks. The domain name uses the reverse-DNS naming convention for
CIDR address blocks specified in [I-D.gersch-dnsop-revDNS-CIDR].
0.0.0.0.0.0.0.0.m.82.129.in-addr.arpa. 86400 IN RLOCK
0.82.129.in-addr.arpa. 86400 IN NS ns1.org.edu
1.0.0.0.0.0.0.0.m.82.129.in-addr.arpa. 86400 IN RLOCK
1.82.129.in-addr.arpa. 86400 IN NS ns1.org.edu
0.1.0.0.0.0.0.0.m.82.129.in-addr.arpa. 86400 IN RLOCK
2.82.129.in-addr.arpa. 86400 IN NS ns1.org.edu
1.1.0.0.0.0.0.0.m.82.129.in-addr.arpa. 86400 IN RLOCK
3.82.129.in-addr.arpa. 86400 IN NS ns1.org.edu
. . . Continuing to
1.1.1.1.1.1.1.1.m.82.129.in-addr.arpa. 86400 IN RLOCK
255.82.129.in-addr.arpa. 86400 IN NS ns1.org.edu
Gersch, et al. Expires September 1, 2012 [Page 10]
Internet-Draft BGP Resource Records February 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. Both 32 and 64
bit 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 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 "VIABLE".
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 a minimum of 4 octets which
specify the ORIGIN AS number. 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. In this first version
of the SRO record, the the RDLENGTH will be 4. Applications MUST
always interpret the first 4 octets as the ORIGIN AS number.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gersch, et al. Expires September 1, 2012 [Page 11]
Internet-Draft BGP Resource Records February 2012
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.
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
Gersch, et al. Expires September 1, 2012 [Page 12]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 13]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 14]
Internet-Draft BGP Resource Records February 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 viable.
Gersch, et al. Expires September 1, 2012 [Page 15]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 16]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 17]
Internet-Draft BGP Resource Records February 2012
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.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-00 (work in progress),
February 2012.
[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
(ROAs)", RFC 6483, February 2012.
Gersch, et al. Expires September 1, 2012 [Page 18]
Internet-Draft BGP Resource Records February 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.
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 September 1, 2012 [Page 19]
Internet-Draft BGP Resource Records February 2012
$TTL 3600
$ORIGIN 82.129.in-addr.arpa.
@ IN SOA rush.colostate.edu. dnsadmin.colostate.edu. (
2012021300 ; 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
0.0.m IN TYPE65401 \# 4 00002f71
; 129.82.0.0/18 SRO 12145
1.0.m IN TYPE65401 \# 4 00002f71
; 129.82.64.0/18 SRO 12145
0.1.m IN TYPE65401 \# 4 00002f71
; 129.82.128.0/18 SRO 12145
1.1.m IN TYPE65401 \# 4 00002f71
; 129.82.192.0/18 SRO 12145
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 September 1, 2012 [Page 20]
Internet-Draft BGP Resource Records February 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 September 1, 2012 [Page 21]
Internet-Draft BGP Resource Records February 2012
Authors' Addresses
Joe Gersch
Secure64 SW Corp
Fort Collins, CO
US
Email: joe.gersch@secure64.com
Dan Massey
Colorado State University
Fort Collins, CO
US
Email: massey@cs.colostate.edu
Eric Osterweil
Verisign
Reston, VA
US
Email: eosterweil@verisign.com
Lixia Zhang
UCLA
Los Angeles, CA
US
Email: lixia@cs.ucla.edu
Gersch, et al. Expires September 1, 2012 [Page 22]