[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group Tony Bates
Internet Draft cisco Systems
Expiration Date: July 1998 Randy Bush
RGnet
Tony Li
Juniper Networks
Yakov Rekhter
cisco Systems
DNS-based NLRI origin AS verification in BGP
draft-bates-bgp4-nlri-orig-verif-00.txt
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
This document describes how a BGP speaker may verify that the Network
Layer Reachability Information (NLRI) of a prefix received from a
peer is consistent with the allocation of IP address space as
determined by the Internet Registry system. These verification
procedures rely on the DNS to provide a repository of information
about address space allocation provided by the Internet Registry
system.
Note that this is not a repository of announceable prefixes, but
rather of allocation of delegated address space.
[Page 1]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
3. Motivations
IP address space is allocated by the Internet Registry system
[RFC2050]. To provide Internet-wide IP connectivity it is imperative
that the information provided by the Internet routing system be
consistent with IP address allocation. Specifically, the consistency
requirement implies that an organization should inject a route for a
particular IP address prefix into inter-domain routing only if the
address space covered by the prefix was allocated to the organization
via the Internet Address Registry system. To provide adequate fault
isolation and robust Internet-wide routing in the presence of either
misconfiguration or malicious attacks on routing,
procedures/mechanisms which allow operators to enforce this
consistency requirement are essential.
This document describes procedures and mechanisms that will allow
operators to determine the correct origin AS of a prefix advertised
into interdomain routing. While other procedures and mechanisms are
also necessary to provide reasonably secure routing, such procedures
and mechanisms are beyond the scope of this document.
This document does not address the related, but orthogonal, issue of
determining the authenticated identity of the routing domain
advertising a given prefix.
4. Overview of Operations
We propose that information about IP address space allocation
provided by the Internet Registry system be maintained within the DNS
[DNS] under the bgp.in-addr.arpa domain. This domain is to be
further subdivided into additional sub-domains to reflect the
allocation structure associated with IP address space. Within this
domain, and all of its subdomains, each node in the DNS tree (i.e.,
each fully qualified domain name (FQDN)) represents one or more IP
address prefixes allocated by the Internet Registry system.
This document uses Autonomous System numbers (ASs) to identify
entities to which address space has been allocated.
For each address prefix, the DNS may contain either (a) the AS to
which the address space described by the prefix has been allocated,
or (b) NS delegation to name servers authoritative for the zone
identified by the address prefix, or (c) no information about the
prefix.
When a BGP speaker receives a route from an external neighbor, the
speaker uses the information provided by the DNS to verify that the
[Page 2]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
prefix was legitimately allocated to the AS/organization that
injected the route into the inter-domain routing system. If the
speaker determines that the NLRI of the route wasn't legitimately
allocated to the organization, the speaker rejects the route.
5. Extensions to the DNS
The mechanism described in this document requires one new Resource
Record (RR):
Autonomous System RR (AS):
This RR consists of two fields, 'AS' and 'Prefix Length'. The
AS field contains an AS number, encoded as a two octet unsigned
integer (0 through 65535), with 0 and 65535 having special
meanings. The Prefix Length field contains an octet encoding
the length of the address prefix associated with the node named
by the RR (0 through 32).
6. Procedures for populating the DNS with the Address Allocation
information
A node under the bgp.in-addr.arpa domain may contain either (a) a set
of NS RRs that specify name servers authoritative for the zone
covered by the address prefix associated with the node, or (b) a
CNAME RR, or (c) a set of one or more AS RRs, where each AS RR
specifies the AS to which the address prefix has been allocated via
the Internet Registry procedures and the length of the allocated
address prefix.
Discussion: An alternative to constructing this information under the
in-addr.arpa domain would be to pick up some other domain
(e.g.,ipv4.nlri.ietf.org). Comments and suggestions are welcome.
CNAME RRs are used for allocations which occur on non-octet
boundaries as described in draft-ietf-dnsind-classless-inaddr-04.txt.
The AS field of an AS RR may contain the special value zero (0).
This value indicates that the DNS may not contain all the information
about allocations out of the address prefix as defined by a
combination of the node and the Prefix Length field of the AS RR. In
other words, the allocation status of this space is not known. This
is distinct from the case where the space is not allocated or it is
known to be allocated to some particular AS.
[Page 3]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
The AS field of the AS RR may also contain the special value 65535.
This value indicates that the address prefix associated with the
address space has not been allocated by the Internet Registries. An
AS RR with an AS value of 65535 can also be used to prevent
authentication of certain prefixes.
While 0/0 is not allocated address space per se, as some routing
domains use default announcement, default should be allowed in
practice. Hence we propose 0/0 be considered unauthenticated (AS of
zero) and all truely unallocated space be specifically so marked (AS
65535).
7. Conventions for encoding address allocations in DNS names
Syntactically, a DNS name is a series of text 'labels', separated by
the '.' character. Within the bgp.in-addr.arpa domain, a label that
is a decimal number is used to represent an octet within a prefix.
To indicate partial octets, we use the notation <value>/<length>
where the <value> contains the value of the last significant octet in
the prefix and the <length> is the prefix length. Thus, the prefix
10.1.128/20 may be encoded in a DNS name as 128/20.1.10.bgp.in-
addr.arpa.
In addition, for this proposal to work, the hierarchy of address
allocations must be explicitly encoded in the name through the
addition of one or more labels. This also implies that no labels may
be removed as part of the allocation of portions of a prefix.
If a prefix is allocated on a non-octet boundary, then the allocating
domain constructs the name by first adding the labels for the
additional full octets, if any, in reversed order to the leftmost
position in the name. Then, the label for the partial octet is added
as the leftmost position in the name. This name is given an NS RR.
As always, normal DNS syntax applies and the resulting name need not
be fully qualified.
For non-octet allocations, the NS record is necessary but not
sufficient. In addition, a number of CNAME RRs must be added.
Recall that the partial octet specifies a number of significant bits
in the least significant octet in the prefix. One CNAME RR must be
created for each possible value of the remaining bits. The name that
the CNAME RR points to (i.e., the name on the right hand side) is
constructed by using the value of the least significant octet
concatenated with the fully qualified name used for the NS RR. These
RRs allow lookups for longer prefixes to redirect through the correct
allocation.
[Page 4]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
A prefix can be extracted from a DNS name constructed using the above
conventions by using the labels that represent full octets and the
leftmost label (if any) that represents a partial octet. These
labels are then reversed in the normal in-addr.arpa manner.
This particular naming scheme is a suggested convention, and
alternate semantically equivalent conventions are also perfectly
acceptable.
8. An Example
The following example illustrates how the DNS might be populated with
address allocation information.
; the root
$ORIGIN bgp.in-addr.arpa. ;well-known root zone
@ SOA (...) ;presume ns etc. for zone
0 AS 0 0 ;default not allocated but Ok
1 NS ns0.bbn.com. ;allocate 1/8 to bbn
205 NS ns0.arin.net. ;allocate 205/8 to arin
; ns0.bbn.com - bbn's server
$ORIGIN 1.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
AS 1 8 ;claim allocation for 1/8
; ns0.arin.net - arin's server
$ORIGIN 205.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
AS 65535 8 ;205/8 is delegated in parts
0 NS ns0.digex.net. ;delegating 205.0/16
1 NS ns0.verio.net. ;delegating 205.1/16
; ns0.digex.net - digex's server
$ORIGIN 0.205.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
AS 2548 16 ;claim allocation for 205.0/16
; ns0.verio.net - verio's server
$ORIGIN 1.205.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
AS 2914 16 ;205.1/16 is allocated to AS 2914
0 AS 777 24 ;205.1.0/24 is allocated to AS 777
1 AS 2914 24 ;205.1.1/24 is allocated to AS 2914
; delegate 205.1.2/23 using the classless in-addr hack
2 CNAME 2.2/23.1.205.bgp.in-addr.arpa.
3 CNAME 3.2/23.1.205.bgp.in-addr.arpa.
[Page 5]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
2/23 NS ns.cust.com. ;delegate 205.1.2/23, or
;205.1.2/24 and 205.1.3/24
;to customer server
4 AS 42 22 ;205.1.4/22 is allocated to AS 42
AS 0 22 ;also allocated elsewhere
8 AS 666 21 ;205.1.8/21 is allocated to AS 666
; delegate 205.1.16/22 using the classless in-addr hack
16 CNAME 16.16/22.1.205.bgp.in-addr.arpa.
17 CNAME 17.16/22.1.205.bgp.in-addr.arpa.
18 CNAME 18.16/22.1.205.bgp.in-addr.arpa.
19 CNAME 19.16/22.1.205.bgp.in-addr.arpa.
16/22 NS ns.cust.net. ;delegate 205.1.16/22 and longer
;to customer
; ns.cust.com - 2/23 server
$ORIGIN 2/23.1.205.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
AS 4242 23 ;AS 4242 claims 205.1.2/23
; ns.cust.net - 16/22 server
$ORIGIN 16/22.1.205.bgp.in-addr.arpa.
@ SOA (...) ;presume ns etc. for zone
16 AS 222 23 ;AS 222 claims 205.1.16/23
18 NS ns.c1.cust.net. ;delegate 205.1.18/24
;to a customer's campus
9. Procedures for verifying BGP routing information
Given a prefix, a lookup in the bgp.in-addr.arpa domain is done by
padding the least significant side of the prefix with zeros to an
octet boundary and then reversing the octets, as is normally done
within the bgp.in-addr.arpa domain. A normal DNS lookup on the
resulting name may involve multiple CNAME records, eventually
resulting in a FQDN.
We define that a DNS node, authenticated by DNSSEC and under the
bgp.in-addr.arpa domain, 'matches' a particular prefix if (a) the
result of a lookup on the prefix is the node, and (b) the node
contains an AS RR with the value of the Prefix Length field less than
or equal to the length of the prefix. We refer to any such AS RR as
a "matching" AS RR.
If a BGP speaker performs a lookup on a prefix and cannot find a
match, it first clears the least significant set bit in the least
significant octet in the prefix and performs another lookup. If
there is no set bit in the least significant octet, it then discards
the least significant octet from the prefix and performs another
[Page 6]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
lookup. The AS RRs that result from this lookup are compared to the
original, unmodified prefix to determine if there is a match.
Using the example from the previous section, an address prefix
205.1.4/22 matches the node 4.1.205.bgp.in-addr.arpa. The matching
AS RR is "AS 42 22". An address prefix 205.1/16 matches the node
1.205.bgp.in-addr.arpa with a matching AS RR of (AS 2914 16).
Further, an address prefix 205.1.0/18 matches the node 1.205.bgp.in-
addr.arpa, with the matching AS RR as (AS 2914 16). Note that in
this case, the first lookup fails and requires a second lookup.
Similarly, the prefix 205.1.5/24 matches the node 4.1.205.bgp.in-
addr.arpa with the matching AS RR as (AS 42 22).
The following assumes that a BGP speaker has sufficient routing
information to have access into the DNS system.
A route may be marked "Authenticated", "Unauthenticated", or
"Authentication Failed".
When a BGP speaker receives a route from an external peer, the
speaker marks the route as "Unauthenticated", and then performs the
following:
- the speaker checks the DNS for the presence of a node that
"matches" the NLRI of the route.
- if there is a matching node with an AS RR where the value of the
AS field is equal to the origin AS of the BGP AS_PATH attribute of
the received prefix, the route is marked as "Authenticated."
- if there is a matching node with an AS RR where the value of the
AS field is 65535, the route is marked as "Authentication Failed."
- if there is a matching node with an AS RR where the value of the
AS field is is zero (0), the route is left as as
"Unauthenticated."
- if there is a matching node with an AS RR where the value of the
AS field is neither 0, 65535, nor the origin AS of the received
prefix, the route is marked as "Authentication Failed."
- in all other cases the marking of the route is not modified,
i.e. it remains "Unauthenticated."
The authentication status of a route has a time limit, maintained in
the authentication status timer. If the origin of a route is
[Page 7]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
Authenticated, then the timer is set to the Time To Live (TTL) of the
matching AS RR. The timer for a route marked as "Unauthenticated" is
set to RouteAuthenticationRetryTimer value (by default 24 hours).
Note that the authentication status timer is not propagated in BGP
Update messages.
When the timer expires, the route is marked as "Unauthenticated", and
the BGP speaker performs the above procedures.
A BGP speaker MAY use and advertise to other BGP speakers a route
that is marked as either Unauthenticated or Authenticated. As a
matter of local policy the BGP speaker in its route selection policy
MAY give preference to routes marked as Authenticated.
A BGP speaker MUST NOT use and/or advertise to other BGP speakers a
route that is marked as "Authentication Failed".
Since a BGP speaker may perform the above procedures asynchronously
with route installation and advertisement, a speaker may advertise a
route marked as "Unauthenticated", but then might later mark the
route as "Authentication Failed". In this case the speaker MUST
withdraw the route, and stop using it.
As a local matter a BGP speaker MAY "preload" as much of the DNS
information as it wants. Doing this would allow the speaker to
accelerate the marking of a newly received routes.
A BGP speaker, MAY (under control of its local configuration) exempt
certain routes from the above verification procedures.
In addition to address allocations, the bgp.in-addr.arpa domain can
be used to encode aggregated prefixes. As with other prefixes, the
AS RR is used to indicate the origin of the aggregate. Insertion of
information about the aggregate requires the cooperation of the
entity controlling the appropriate point in the namespace.
[Page 8]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
10. Use of TXT RRs
Instead of introducing a new RR type, the AS RR, the scheme described
in this document might use a TXT RR, where the information encoded in
the TXT RR would be the same as in the AS RR (although the encoding
will be different). One of the problems with using the TXT RRs is
that it redefines the semantics of the TXT RR, which at least will be
somewhat confusing. Further, if a TXT RR is used for initial
deployment, there is a likelihood that no transition would ever be
made to the AS RR.
11. Security Considerations
This entire document is about security considerations.
DNSSEC should be used in conjunction with the procedures described in
this document to provide authentication for the DNS information.
12. Acknowledgments
The authors would like to acknowledge the contributions of the DNSSEC
working group and the authors of draft-ietf-dnsind-classless-inaddr-
04.txt for their contributions without which, this work would have
been impossible. Additionally, the authors would like to thank Jerry
Scharf for commenting on the work as it progressed.
13. References
[BGP-4]
[DNS]
[DNSSEC]
[Page 9]
Internet Draft draft-bates-bgp4-nlri-orig-verif-00.txt January 1998
14. Author Information
Tony Bates
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: tbates@cisco.com
Randy Bush
RGnet, Inc.
5147 Crystal Springs
Bainbridge Island, WA 98110
E-mail: randy@psg.com
Tony Li
Juniper Networks, Inc.
385 Ravendale Dr.
Mountain View, CA 94043
E-mail: tli@juniper.com
Yakov Rekhter
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
Email: yakov@cisco.com
[Page 10]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/