idnits 2.17.1 draft-bates-bgp4-nlri-orig-verif-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 336: '... A BGP speaker MAY use and advertise...' RFC 2119 keyword, line 339: '... MAY give preference to routes marke...' RFC 2119 keyword, line 341: '... A BGP speaker MUST NOT use and/or a...' RFC 2119 keyword, line 347: '...ailed". In this case the speaker MUST...' RFC 2119 keyword, line 350: '...er a BGP speaker MAY "preload" as much...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2050' is mentioned on line 49, but not defined ** Obsolete undefined reference: RFC 2050 (Obsoleted by RFC 7020) == Unused Reference: 'BGP-4' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'DNSSEC' is defined on line 395, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSSEC' Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tony Bates 3 Internet Draft cisco Systems 4 Expiration Date: July 1998 Randy Bush 5 RGnet 6 Tony Li 7 Juniper Networks 8 Yakov Rekhter 9 cisco Systems 11 DNS-based NLRI origin AS verification in BGP 13 draft-bates-bgp4-nlri-orig-verif-00.txt 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 2. Abstract 35 This document describes how a BGP speaker may verify that the Network 36 Layer Reachability Information (NLRI) of a prefix received from a 37 peer is consistent with the allocation of IP address space as 38 determined by the Internet Registry system. These verification 39 procedures rely on the DNS to provide a repository of information 40 about address space allocation provided by the Internet Registry 41 system. 43 Note that this is not a repository of announceable prefixes, but 44 rather of allocation of delegated address space. 46 3. Motivations 48 IP address space is allocated by the Internet Registry system 49 [RFC2050]. To provide Internet-wide IP connectivity it is imperative 50 that the information provided by the Internet routing system be 51 consistent with IP address allocation. Specifically, the consistency 52 requirement implies that an organization should inject a route for a 53 particular IP address prefix into inter-domain routing only if the 54 address space covered by the prefix was allocated to the organization 55 via the Internet Address Registry system. To provide adequate fault 56 isolation and robust Internet-wide routing in the presence of either 57 misconfiguration or malicious attacks on routing, 58 procedures/mechanisms which allow operators to enforce this 59 consistency requirement are essential. 61 This document describes procedures and mechanisms that will allow 62 operators to determine the correct origin AS of a prefix advertised 63 into interdomain routing. While other procedures and mechanisms are 64 also necessary to provide reasonably secure routing, such procedures 65 and mechanisms are beyond the scope of this document. 67 This document does not address the related, but orthogonal, issue of 68 determining the authenticated identity of the routing domain 69 advertising a given prefix. 71 4. Overview of Operations 73 We propose that information about IP address space allocation 74 provided by the Internet Registry system be maintained within the DNS 75 [DNS] under the bgp.in-addr.arpa domain. This domain is to be 76 further subdivided into additional sub-domains to reflect the 77 allocation structure associated with IP address space. Within this 78 domain, and all of its subdomains, each node in the DNS tree (i.e., 79 each fully qualified domain name (FQDN)) represents one or more IP 80 address prefixes allocated by the Internet Registry system. 82 This document uses Autonomous System numbers (ASs) to identify 83 entities to which address space has been allocated. 85 For each address prefix, the DNS may contain either (a) the AS to 86 which the address space described by the prefix has been allocated, 87 or (b) NS delegation to name servers authoritative for the zone 88 identified by the address prefix, or (c) no information about the 89 prefix. 91 When a BGP speaker receives a route from an external neighbor, the 92 speaker uses the information provided by the DNS to verify that the 93 prefix was legitimately allocated to the AS/organization that 94 injected the route into the inter-domain routing system. If the 95 speaker determines that the NLRI of the route wasn't legitimately 96 allocated to the organization, the speaker rejects the route. 98 5. Extensions to the DNS 100 The mechanism described in this document requires one new Resource 101 Record (RR): 103 Autonomous System RR (AS): 105 This RR consists of two fields, 'AS' and 'Prefix Length'. The 106 AS field contains an AS number, encoded as a two octet unsigned 107 integer (0 through 65535), with 0 and 65535 having special 108 meanings. The Prefix Length field contains an octet encoding 109 the length of the address prefix associated with the node named 110 by the RR (0 through 32). 112 6. Procedures for populating the DNS with the Address Allocation 113 information 115 A node under the bgp.in-addr.arpa domain may contain either (a) a set 116 of NS RRs that specify name servers authoritative for the zone 117 covered by the address prefix associated with the node, or (b) a 118 CNAME RR, or (c) a set of one or more AS RRs, where each AS RR 119 specifies the AS to which the address prefix has been allocated via 120 the Internet Registry procedures and the length of the allocated 121 address prefix. 123 Discussion: An alternative to constructing this information under the 124 in-addr.arpa domain would be to pick up some other domain 125 (e.g.,ipv4.nlri.ietf.org). Comments and suggestions are welcome. 127 CNAME RRs are used for allocations which occur on non-octet 128 boundaries as described in draft-ietf-dnsind-classless-inaddr-04.txt. 130 The AS field of an AS RR may contain the special value zero (0). 131 This value indicates that the DNS may not contain all the information 132 about allocations out of the address prefix as defined by a 133 combination of the node and the Prefix Length field of the AS RR. In 134 other words, the allocation status of this space is not known. This 135 is distinct from the case where the space is not allocated or it is 136 known to be allocated to some particular AS. 138 The AS field of the AS RR may also contain the special value 65535. 139 This value indicates that the address prefix associated with the 140 address space has not been allocated by the Internet Registries. An 141 AS RR with an AS value of 65535 can also be used to prevent 142 authentication of certain prefixes. 144 While 0/0 is not allocated address space per se, as some routing 145 domains use default announcement, default should be allowed in 146 practice. Hence we propose 0/0 be considered unauthenticated (AS of 147 zero) and all truely unallocated space be specifically so marked (AS 148 65535). 150 7. Conventions for encoding address allocations in DNS names 152 Syntactically, a DNS name is a series of text 'labels', separated by 153 the '.' character. Within the bgp.in-addr.arpa domain, a label that 154 is a decimal number is used to represent an octet within a prefix. 155 To indicate partial octets, we use the notation / 156 where the contains the value of the last significant octet in 157 the prefix and the is the prefix length. Thus, the prefix 158 10.1.128/20 may be encoded in a DNS name as 128/20.1.10.bgp.in- 159 addr.arpa. 161 In addition, for this proposal to work, the hierarchy of address 162 allocations must be explicitly encoded in the name through the 163 addition of one or more labels. This also implies that no labels may 164 be removed as part of the allocation of portions of a prefix. 166 If a prefix is allocated on a non-octet boundary, then the allocating 167 domain constructs the name by first adding the labels for the 168 additional full octets, if any, in reversed order to the leftmost 169 position in the name. Then, the label for the partial octet is added 170 as the leftmost position in the name. This name is given an NS RR. 171 As always, normal DNS syntax applies and the resulting name need not 172 be fully qualified. 174 For non-octet allocations, the NS record is necessary but not 175 sufficient. In addition, a number of CNAME RRs must be added. 176 Recall that the partial octet specifies a number of significant bits 177 in the least significant octet in the prefix. One CNAME RR must be 178 created for each possible value of the remaining bits. The name that 179 the CNAME RR points to (i.e., the name on the right hand side) is 180 constructed by using the value of the least significant octet 181 concatenated with the fully qualified name used for the NS RR. These 182 RRs allow lookups for longer prefixes to redirect through the correct 183 allocation. 185 A prefix can be extracted from a DNS name constructed using the above 186 conventions by using the labels that represent full octets and the 187 leftmost label (if any) that represents a partial octet. These 188 labels are then reversed in the normal in-addr.arpa manner. 190 This particular naming scheme is a suggested convention, and 191 alternate semantically equivalent conventions are also perfectly 192 acceptable. 194 8. An Example 196 The following example illustrates how the DNS might be populated with 197 address allocation information. 199 ; the root 200 $ORIGIN bgp.in-addr.arpa. ;well-known root zone 201 @ SOA (...) ;presume ns etc. for zone 202 0 AS 0 0 ;default not allocated but Ok 203 1 NS ns0.bbn.com. ;allocate 1/8 to bbn 204 205 NS ns0.arin.net. ;allocate 205/8 to arin 206 ; ns0.bbn.com - bbn's server 207 $ORIGIN 1.bgp.in-addr.arpa. 208 @ SOA (...) ;presume ns etc. for zone 209 AS 1 8 ;claim allocation for 1/8 211 ; ns0.arin.net - arin's server 212 $ORIGIN 205.bgp.in-addr.arpa. 213 @ SOA (...) ;presume ns etc. for zone 214 AS 65535 8 ;205/8 is delegated in parts 215 0 NS ns0.digex.net. ;delegating 205.0/16 216 1 NS ns0.verio.net. ;delegating 205.1/16 218 ; ns0.digex.net - digex's server 219 $ORIGIN 0.205.bgp.in-addr.arpa. 220 @ SOA (...) ;presume ns etc. for zone 221 AS 2548 16 ;claim allocation for 205.0/16 223 ; ns0.verio.net - verio's server 224 $ORIGIN 1.205.bgp.in-addr.arpa. 225 @ SOA (...) ;presume ns etc. for zone 226 AS 2914 16 ;205.1/16 is allocated to AS 2914 227 0 AS 777 24 ;205.1.0/24 is allocated to AS 777 228 1 AS 2914 24 ;205.1.1/24 is allocated to AS 2914 229 ; delegate 205.1.2/23 using the classless in-addr hack 230 2 CNAME 2.2/23.1.205.bgp.in-addr.arpa. 231 3 CNAME 3.2/23.1.205.bgp.in-addr.arpa. 233 2/23 NS ns.cust.com. ;delegate 205.1.2/23, or 234 ;205.1.2/24 and 205.1.3/24 235 ;to customer server 236 4 AS 42 22 ;205.1.4/22 is allocated to AS 42 237 AS 0 22 ;also allocated elsewhere 238 8 AS 666 21 ;205.1.8/21 is allocated to AS 666 239 ; delegate 205.1.16/22 using the classless in-addr hack 240 16 CNAME 16.16/22.1.205.bgp.in-addr.arpa. 241 17 CNAME 17.16/22.1.205.bgp.in-addr.arpa. 242 18 CNAME 18.16/22.1.205.bgp.in-addr.arpa. 243 19 CNAME 19.16/22.1.205.bgp.in-addr.arpa. 244 16/22 NS ns.cust.net. ;delegate 205.1.16/22 and longer 245 ;to customer 247 ; ns.cust.com - 2/23 server 248 $ORIGIN 2/23.1.205.bgp.in-addr.arpa. 249 @ SOA (...) ;presume ns etc. for zone 250 AS 4242 23 ;AS 4242 claims 205.1.2/23 252 ; ns.cust.net - 16/22 server 253 $ORIGIN 16/22.1.205.bgp.in-addr.arpa. 254 @ SOA (...) ;presume ns etc. for zone 255 16 AS 222 23 ;AS 222 claims 205.1.16/23 256 18 NS ns.c1.cust.net. ;delegate 205.1.18/24 257 ;to a customer's campus 259 9. Procedures for verifying BGP routing information 261 Given a prefix, a lookup in the bgp.in-addr.arpa domain is done by 262 padding the least significant side of the prefix with zeros to an 263 octet boundary and then reversing the octets, as is normally done 264 within the bgp.in-addr.arpa domain. A normal DNS lookup on the 265 resulting name may involve multiple CNAME records, eventually 266 resulting in a FQDN. 268 We define that a DNS node, authenticated by DNSSEC and under the 269 bgp.in-addr.arpa domain, 'matches' a particular prefix if (a) the 270 result of a lookup on the prefix is the node, and (b) the node 271 contains an AS RR with the value of the Prefix Length field less than 272 or equal to the length of the prefix. We refer to any such AS RR as 273 a "matching" AS RR. 275 If a BGP speaker performs a lookup on a prefix and cannot find a 276 match, it first clears the least significant set bit in the least 277 significant octet in the prefix and performs another lookup. If 278 there is no set bit in the least significant octet, it then discards 279 the least significant octet from the prefix and performs another 280 lookup. The AS RRs that result from this lookup are compared to the 281 original, unmodified prefix to determine if there is a match. 283 Using the example from the previous section, an address prefix 284 205.1.4/22 matches the node 4.1.205.bgp.in-addr.arpa. The matching 285 AS RR is "AS 42 22". An address prefix 205.1/16 matches the node 286 1.205.bgp.in-addr.arpa with a matching AS RR of (AS 2914 16). 288 Further, an address prefix 205.1.0/18 matches the node 1.205.bgp.in- 289 addr.arpa, with the matching AS RR as (AS 2914 16). Note that in 290 this case, the first lookup fails and requires a second lookup. 291 Similarly, the prefix 205.1.5/24 matches the node 4.1.205.bgp.in- 292 addr.arpa with the matching AS RR as (AS 42 22). 294 The following assumes that a BGP speaker has sufficient routing 295 information to have access into the DNS system. 297 A route may be marked "Authenticated", "Unauthenticated", or 298 "Authentication Failed". 300 When a BGP speaker receives a route from an external peer, the 301 speaker marks the route as "Unauthenticated", and then performs the 302 following: 304 - the speaker checks the DNS for the presence of a node that 305 "matches" the NLRI of the route. 307 - if there is a matching node with an AS RR where the value of the 308 AS field is equal to the origin AS of the BGP AS_PATH attribute of 309 the received prefix, the route is marked as "Authenticated." 311 - if there is a matching node with an AS RR where the value of the 312 AS field is 65535, the route is marked as "Authentication Failed." 314 - if there is a matching node with an AS RR where the value of the 315 AS field is is zero (0), the route is left as as 316 "Unauthenticated." 318 - if there is a matching node with an AS RR where the value of the 319 AS field is neither 0, 65535, nor the origin AS of the received 320 prefix, the route is marked as "Authentication Failed." 322 - in all other cases the marking of the route is not modified, 323 i.e. it remains "Unauthenticated." 325 The authentication status of a route has a time limit, maintained in 326 the authentication status timer. If the origin of a route is 327 Authenticated, then the timer is set to the Time To Live (TTL) of the 328 matching AS RR. The timer for a route marked as "Unauthenticated" is 329 set to RouteAuthenticationRetryTimer value (by default 24 hours). 330 Note that the authentication status timer is not propagated in BGP 331 Update messages. 333 When the timer expires, the route is marked as "Unauthenticated", and 334 the BGP speaker performs the above procedures. 336 A BGP speaker MAY use and advertise to other BGP speakers a route 337 that is marked as either Unauthenticated or Authenticated. As a 338 matter of local policy the BGP speaker in its route selection policy 339 MAY give preference to routes marked as Authenticated. 341 A BGP speaker MUST NOT use and/or advertise to other BGP speakers a 342 route that is marked as "Authentication Failed". 344 Since a BGP speaker may perform the above procedures asynchronously 345 with route installation and advertisement, a speaker may advertise a 346 route marked as "Unauthenticated", but then might later mark the 347 route as "Authentication Failed". In this case the speaker MUST 348 withdraw the route, and stop using it. 350 As a local matter a BGP speaker MAY "preload" as much of the DNS 351 information as it wants. Doing this would allow the speaker to 352 accelerate the marking of a newly received routes. 354 A BGP speaker, MAY (under control of its local configuration) exempt 355 certain routes from the above verification procedures. 357 In addition to address allocations, the bgp.in-addr.arpa domain can 358 be used to encode aggregated prefixes. As with other prefixes, the 359 AS RR is used to indicate the origin of the aggregate. Insertion of 360 information about the aggregate requires the cooperation of the 361 entity controlling the appropriate point in the namespace. 363 10. Use of TXT RRs 365 Instead of introducing a new RR type, the AS RR, the scheme described 366 in this document might use a TXT RR, where the information encoded in 367 the TXT RR would be the same as in the AS RR (although the encoding 368 will be different). One of the problems with using the TXT RRs is 369 that it redefines the semantics of the TXT RR, which at least will be 370 somewhat confusing. Further, if a TXT RR is used for initial 371 deployment, there is a likelihood that no transition would ever be 372 made to the AS RR. 374 11. Security Considerations 376 This entire document is about security considerations. 378 DNSSEC should be used in conjunction with the procedures described in 379 this document to provide authentication for the DNS information. 381 12. Acknowledgments 383 The authors would like to acknowledge the contributions of the DNSSEC 384 working group and the authors of draft-ietf-dnsind-classless-inaddr- 385 04.txt for their contributions without which, this work would have 386 been impossible. Additionally, the authors would like to thank Jerry 387 Scharf for commenting on the work as it progressed. 389 13. References 391 [BGP-4] 393 [DNS] 395 [DNSSEC] 396 14. Author Information 398 Tony Bates 399 cisco Systems, Inc. 400 170 W. Tasman Dr. 401 San Jose, CA 95134 402 Email: tbates@cisco.com 404 Randy Bush 405 RGnet, Inc. 406 5147 Crystal Springs 407 Bainbridge Island, WA 98110 408 E-mail: randy@psg.com 410 Tony Li 411 Juniper Networks, Inc. 412 385 Ravendale Dr. 413 Mountain View, CA 94043 414 E-mail: tli@juniper.com 416 Yakov Rekhter 417 cisco Systems, Inc. 418 170 W. Tasman Dr. 419 San Jose, CA 95134 420 Email: yakov@cisco.com