idnits 2.17.1 draft-gersch-grow-revdns-bgp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4075 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1876' is defined on line 745, but no explicit reference was found in the text -- No information found for draft-gersch-dnsop-revDNS-CIDR - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gersch 3 Internet-Draft Secure64 SW Corp 4 Intended status: Standards Track D. Massey 5 Expires: August 29, 2013 C. Olschanowsky 6 Colorado State University 7 L. Zhang 8 UCLA 9 February 25, 2013 11 DNS Resource Records for Authorized Routing Information 12 draft-gersch-grow-revdns-bgp-02 14 Abstract 16 This draft discusses the use of two DNS record types for storing BGP 17 routing information in the reverse DNS. The RLOCK record allows 18 prefix owners to indicate whether the DNS is being used to publish 19 routing data. The SRO record allows operators to indicate whether an 20 IPv4 or IPv6 prefix ought to appear in global routing tables and 21 identifies authorized origin Autonomous System Number(s) for that 22 prefix. The resulting published data can be used in a variety of 23 contexts from routing security to address ownership. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 29, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used In This Document . . . . . . . . . . . . . . 4 63 3. Overview of Route Publishing . . . . . . . . . . . . . . . . . 5 64 4. Overview of Route Verification . . . . . . . . . . . . . . . . 6 65 5. The RLOCK Resource Record . . . . . . . . . . . . . . . . . . 8 66 5.1. RLOCK RDATA Wire Format . . . . . . . . . . . . . . . . . 9 67 5.1.1. The Activation Time field . . . . . . . . . . . . . . 9 68 5.2. RLOCK Presentation Format . . . . . . . . . . . . . . . . 10 69 5.3. RLOCK RR Examples . . . . . . . . . . . . . . . . . . . . 10 70 6. The SRO Resource Record . . . . . . . . . . . . . . . . . . . 11 71 6.1. SRO RDATA Wire Format . . . . . . . . . . . . . . . . . . 11 72 6.1.1. The Origin AS Number field . . . . . . . . . . . . . . 12 73 6.1.2. The Flags field . . . . . . . . . . . . . . . . . . . 12 74 6.1.3. The Prefix Limit field . . . . . . . . . . . . . . . . 12 75 6.1.4. The Activation Time field . . . . . . . . . . . . . . 12 76 6.2. SRO RRDATA Presentation Format . . . . . . . . . . . . . . 13 77 6.3. SRO RR Examples . . . . . . . . . . . . . . . . . . . . . 14 78 7. Discussion and Related Work . . . . . . . . . . . . . . . . . 15 79 7.1. Prior Work on CIDR names for Routing . . . . . . . . . . . 15 80 7.2. RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 84 11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 20 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 87 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Appendix A. Discussion of Prefix Limits use in conjunction 89 with DNS wildcards . . . . . . . . . . . . . . . . . 23 90 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 25 91 B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 25 92 B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 27 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 95 1. Introduction 97 1.1. Overview 99 This draft describes a method in which a prefix owner can exploit the 100 existing reverse DNS tree structure, along with the authentication 101 provided by DNSSEC [RFC4033], to publish information about whether a 102 prefix can be announced and identify the origin Autonomous System(s) 103 that may originate a route to that prefix. This data is 104 complementary to a variety of other data sources ranging from 105 existing databases to new directions. 107 Publishing route information in the Reverse DNS takes advantage of 108 infrastructure that already exists and has been globally deployed. 109 No new infrastructure deployment is required, in contrast with 110 approaches that use purpose-built resource certification. 112 Other key advantages to using the Reverse DNS are that it 1) has been 113 in successful operation for many years, 2) has an existing 114 operational model where prefix owners currently manage their IP 115 address space (through various models from local operation to hosting 116 companies), 3) has an existing operational model where both 117 registries and providers delegate authority to entities receiving 118 address space, 4) the resulting reverse DNS data can be authenticated 119 using DNSSEC [RFC4033], and 5) the data can be easily checked using 120 simple tools ranging from DNS query tools such as DIG to more 121 elaborate systems. 123 A prefix owner must OPT-IN to the approach. Prefix owners who do not 124 take any action are not impacted, but also do not gain any 125 advantages. Prefix owners that do choose to participate would 126 thereby enable a number of tools to make use of the published data. 127 The objective of this draft is to standardize the format for 128 indicating participation and publishing data. A variety of potential 129 uses for the data are discussed later in the document, but are 130 provided only to illustrate the usefulness of the data and should not 131 be taken as a comprehensive list of all possible applications. 133 1.2. Scope 135 We limit the scope of this internet draft to associating an origin AS 136 number with a prefix. Armed with this information, one can address 137 both origin hijacks and sub-prefix hijacks in a manner that can be 138 deployed in a reasonable time frame. Future expansion is readily 139 made possible: the SRO record is kept simple for now, but is designed 140 to reference additional future records that enable additional 141 capabilities. 143 2. Conventions Used In This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Overview of Route Publishing 151 This document defines two new DNS resource records types (RRTypes) 152 and describes how these record types can be associated with prefixes. 154 1. The RLOCK RRType (Route Lock) 156 * Purpose: Indicates that the Reverse DNS zone has enabled BGP 157 route publishing. 159 * The presence of the RLOCK Record at the apex of a Reverse DNS 160 zone indicates that a prefix owner has OPTED-IN to BGP Route 161 Publishing. All route announcements that map to this zone 162 will be denied as INVALID unless an SRO record exists that 163 specifically authorizes the announcement. 165 2. The SRO RRType (Secure Route Origin) 167 * Purpose: Declare an authorized route origin ASN for comparison 168 against BGP route announcements. 170 * Placed in the Reverse DNS at the domain name corresponding to 171 the associated CIDR address block. 173 Organizations that have been assigned and/or allocated CIDR address 174 blocks also have Reverse-DNS delegations assigned to them from either 175 the Regional Internet Registries (RIPE, ARIN, APNIC, etc.) or from a 176 sub-delegation. 178 Address-block owners may use these record types to declare 179 authoritative data for route origins associated with that address 180 block. This data may be declared statically, with a long TTL (Time 181 To Live) if the routing data changes infrequently. Alternatively, 182 dynamic DNS and short TTLs can be used to rapidly publish and 183 disseminate the authoritative information on a world-wide basis in 184 near real-time. 186 The RLOCK and SRO records are to be stored in the reverse-DNS in 187 zones with domain names that correspond to the associated CIDR 188 address block. These domain names are to be constructed per the 189 naming specification described in [I-D.gersch-dnsop-revDNS-CIDR]. 191 The RLOCK and SRO records MUST be signed with DNSSEC and have a valid 192 DNSSEC chain-of-trust. 194 4. Overview of Route Verification 196 Various applications could be written to use BGP records published in 197 the Reverse DNS. One example is an application to perform near-real- 198 time route origin verification that alerts operators of hijacks or 199 directly interacts with a router to prevent the hijack. Another 200 application could perform a nightly analysis that generates router 201 prefix filters. A third application could cross-check data in the 202 Internet Routing Registries (IRR) against the data in the reverse 203 DNS. This list is not intended to be comprehensive, but instead aims 204 to illustrate the potential uses of the published data. 206 These applications analyze BGP announcements by performing DNS 207 queries to classify route route announcements into one of the 208 following three categories: 210 1. "VALID": a DNSSEC-validated SRO RRSET was received and one of the 211 route origins in the RRSET matches the origin contained in the 212 BGP route announcement. 214 2. "INVALID": a route hijack was detected. 216 A. The DNSSEC-validated SRO responses received did NOT match the 217 origin of the route announcement. This is indicative of an 218 origin hijack. 220 B. There was no SRO record at the domain name corresponding to 221 this address block, but the authoritative zone did contain an 222 RLOCK statement. This is indicative of a sub-prefix hijacks. 224 3. "NOTFOUND": there was no SRO record for this prefix and no RLOCK 225 record to protect the zone, or the data did not properly validate 226 with DNSSEC. In this case, the algorithm cannot authoritatively 227 state that the prefix is valid or invalid, so it is simply marked 228 as not found. Most routes today are in this category, as it 229 takes a specific action to OPT-IN to this methodology. 231 This verification algorithm MUST "fail-safe". If a query for a DNS 232 record fails, or if DNSSEC fails to validate the record, the 233 algorithm MUST behave as if no DNS records were present in the first 234 place. This results in marking a BGP announcement as "NOTFOUND". 235 One could completely unplug a router verification application at any 236 time and internet routing would continue to work just as it does 237 today. The default state is always "not found". 239 Note that this implies the verification algorithm MUST use DNSSEC- 240 enabled queries (set the DO bit) and MUST check for a validated 241 response (the AD bit). A successful DNSSEC-downgrade attack would 242 result in classifying records as "NOTFOUND". However the redundancy 243 in DNS would allow checking of multiple slave DNS servers should 244 DNSSEC fail to validate. 246 The core of the verification algorithm can be summarized as follows: 248 1. Given a BGP announcement from a router feed, offline database, 249 prefix filter, or other source, perform a DNSSEC-validated query 250 for the SRO records at the domain name corresponding to the CIDR 251 prefix in the BGP announcement. 253 2. Case 1: If no records exist (NXDOMAIN or NOERROR with number of 254 answers=0), use the AUTHORITY section of the answer to determine 255 the covering zone. Perform a query to that domain name (the zone 256 apex) for an RLOCK record. There are two possible responses to 257 the RLOCK query: 259 A. NOERROR, answer=0: the RLOCK does not exist; the zone owner 260 has not opted in. Mark the announcement as "NOTFOUND". 262 B. RLOCK exists: the zone owner has OPTED-IN. Mark the 263 announcement as "INVALID" since no SRO record exists to vouch 264 for the announcement. This may be an example of a sub-prefix 265 hijack. 267 3. Case 2: One or more SRO records were returned from the query. 268 Loop through each SRO in the RRSET to compare the origin with the 269 data in the route announcement. If a record with a matching set 270 of data is found, mark the announcement as "VALID". If no match 271 is found, mark the announcement as "INVALID". 273 5. The RLOCK Resource Record 275 The RLOCK resource record indicates "Route Lock". This record is 276 placed at the apex of a reverse-DNS zone to indicate that the zone is 277 being used to publish routing information. If this record is 278 present, all route announcements for the CIDR address block covered 279 by this zone MUST be marked as "INVALID" unless they are specifically 280 authorized by a SRO record. 282 The main purpose of the RLOCK statement is to indicate participation 283 (OPT-IN) and as a side-effect prevent sub-prefix route hijacks. 284 Applications that query for an SRO record may get an NXDOMAIN or 285 NOERROR with 0 answers. In this case, the application queries the 286 domain name specified in the AUTHORITY section for an RLOCK record 287 (this will be at the zone apex). If the RLOCK is present, the route 288 announcement MUST be marked as "INVALID". Otherwise there is no SRO 289 and no RLOCK, so the route announcement MUST be marked as "NOTFOUND". 291 The effective span of control for an RLOCK is dependent on the 292 structure of the Reverse DNS zone. To be more specific, a Reverse 293 DNS zone that has no delegations will have a span of control that 294 covers all prefixes at or below the CIDR prefix specified by the 295 domain name at the zone apex. Any zone delegation (also known as a 296 "cut point") starts a new zone authority. Those prefixes in the 297 delegated zone will not be covered by the parent zone's RLOCK. As an 298 example, consider the zone at 129.82.0.0/16 and assume that it has 299 only one delegation at 129.82.138.0/24. The /16 RLOCK covers all 300 prefixes within the /16 to /32 range with the exception of prefixes 301 within the 129.82.138.0/24 through /32 range. The child zone would 302 need to have its own RLOCK. 304 The RLOCK record MUST be signed with DNSSEC and have an associated 305 RRSIG record. If a resolving DNS server cannot validate the DNSSEC 306 signature, the SRO record should be ignored as if it were not even 307 present in the zone. 309 The Type value for the RLOCK RR type is currently unassigned. We are 310 temporarily using private RRTYPE TYPE65400 until a formal number is 311 assigned by IANA. 313 The RLOCK RR is class independent. 315 The RLOCK RR has no special TTL requirements. 317 Example use of RLOCK records, taken directly from the current 318 testbed, are included in the appendix. 320 5.1. RLOCK RDATA Wire Format 322 The SRO RDATA wire format consists of one optional field, a 4 octet 323 Activation Time field. If the Activation Time field is not present, 324 the RDATA length is 0 octets. If the Activation Time field is 325 present, the RDATA Length is 4 octets. 327 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Activation Time | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 5.1.1. The Activation Time field 335 The optional Activation Time field specifies a starting date and time 336 from which the RLOCK record is considered to be active and may be 337 used for route origin validation. The RLOCK record MUST NOT be used 338 for validation prior to this activation time. 340 The Activation Time field value specifies a date and time in the form 341 of a 32-bit unsigned number of seconds elapsed since 1 January 1970 342 00:00:00 UTC, ignoring leap seconds, in network byte order. The 343 longest interval that can be expressed by this format without 344 wrapping is approximately 136 years. 346 If the Activation Time field is not present, or if it contains a 347 value of 0, immediate activation for the RLOCK record is in effect. 349 The purpose of the Activation Time field is to permit publication of 350 RLOCK records in the reverse DNS prior to its use in formal route 351 validation. This enables two key capabilities: first,it allows for 352 the testing of RLOCK records in a safe manner by informing an 353 application to "don't validate, but tell me what you would have 354 done". Second, it allows an ISP to publish an RLOCK and SRO record 355 that defines a large covering prefix to give advance warning to that 356 ISP's customers. Customers that have their own AS number and a 357 delegated address block within the ISP's larger block may want to 358 publish their own SRO record if they share a zone with the ISP, or 359 they will risk having their announcements being marked INVALID 360 because the ISP has claimed a larger covering prefix. Alternatively, 361 the customer may be independent from the ISP's zone and manage their 362 own reverse-DNS zone that has been delegated to them. In this case 363 they may choose to publish an SRO record or to do nothing. The cut 364 point of the zone delegation stops the ISP's covering prefix from 365 extending into the new zone. 367 5.2. RLOCK Presentation Format 369 The presentation format of the RDATA portion is as follows: 371 [ ACTIVATION_TIME ] 373 where the ACTIVATION TIME is an optional field. 375 The optional Activation Time field value, if present, MUST be 376 represented either as an unsigned decimal integer indicating seconds 377 since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in 378 UTC, where: 380 YYYY is the year (0001-9999); 381 MM is the month number (01-12); 382 DD is the day of the month (01-31); 383 HH is the hour, in 24 hour notation (00-23); 384 mm is the minute (00-59); and 385 SS is the second (00-59). 387 Note that it is always possible to distinguish between these two 388 formats because the YYYYMMDDHHmmSS format will always be exactly 14 389 digits, while the decimal representation of a 32-bit unsigned integer 390 can never be longer than 10 digits. 392 5.3. RLOCK RR Examples 394 The following examples shows an RLOCK resource record that enables 395 routing security for the zone covering 129.82.0.0/16. The first 396 example specifies immediate activation. The second specifies 397 activation starting on July 4, 2013 at 9:30 UTC. 399 82.129.in-addr.arpa. 86400 IN RLOCK 401 120.15.in-addr.arpa. 86400 IN RLOCK 20130704093000 403 6. The SRO Resource Record 405 Zones that participate in this approach to BGP route security use 406 "Secure Route Origin" (SRO) resource records to identify authorized 407 origin Autonomous System Number(s) for a prefix. 409 The SRO record contains one mandatory field, the ORIGIN ASN field. 410 The SRO record MAY contain also contain one to three optional fields 411 in the following order: a FLAGS field, a PREFIX LIMIT field, and an 412 ACTIVATION TIME field. These fields MUST be appended to the RDATA in 413 that specific order. 415 The SRO record MUST be signed with DNSSEC [RFC4033] and have an 416 associated RRSIG record. If a resolving DNS server cannot validate 417 the DNSSEC signature, the SRO record should be ignored and an attempt 418 should be made to query an alternate DNS server. If all servers 419 fail, the route prefix should be classified as "NOTFOUND". 421 The Type value for the SRO RR type is currently unassigned. We are 422 temporarily using TYPE65401 until a formal number is assigned by 423 IANA. 425 The SRO RR is class independent. 427 The SRO RR has no special TTL requirements. 429 6.1. SRO RDATA Wire Format 431 The SRO RDATA wire format consists of four fields: a 4 octet ORIGIN 432 AS NUMBER field, a 1 octet FLAGS field, a 1 octet PREFIX LIMIT field, 433 and a 4 octet SRO ACTIVATION TIME field. The RDATA Length is a 434 constant 10 octets. Missing fields in the presentation format are 435 filled with 0's in the wire data format. 437 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | ORIGIN AS Number | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | flags | prefix limit | Activation Time / 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 / Activation Time, continued | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 6.1.1. The Origin AS Number field 449 The Origin AS Number field is used to specify an AS Number that is 450 authorized to originate a route announcement for the CIDR address 451 block corresponding to the SRO record's reverse DNS domain name. If 452 a CIDR address block can be announced from multiple AS numbers, then 453 multiple SRO records should be defined at the domain name 454 corresponding to that CIDR address block. 456 The Origin AS Number field accommodates both 2 octet and 4 octet AS 457 Numbers. 2 octet AS numbers MUST be encoded with leading zeroes to 458 construct a complete 4 octet field. 460 6.1.2. The Flags field 462 The Flags field is reserved for future expansion; currently there are 463 no flags defined and the Flags field, if present, MUST be set to 0. 464 In the future various bits of the field will be used to define 465 extensions and additional records related to the SRO record. 467 6.1.3. The Prefix Limit field 469 The Prefix Limit field specifies the maximum length of a prefix that 470 the SRO statement is authorizing. If the field contains a value of 0 471 then the origin AS is only authorized for the exact prefix 472 corresponding to that domain name. 474 Any other integer value from 1 to 32 for IPv4 and 1 to 128 for IPv6 475 specifies the length of the most specific IP prefix that the SRO is 476 authorizing. For example, if an IP address prefix is 10.0/16 and the 477 prefix limit is 22, the AS is authorized to advertise any prefix 478 under 10.0/16, as long as it is no more specific than /22. In this 479 example, the AS would be authorized to advertise 10.0/16, 10.0.128/20 480 or 10.0.255/22, but not 10.0.255.0/24. An SRO statement must be 481 present at each domain name corresponding to these prefixes (see 482 Appendix A for a discussion on how to create multiple SRO records 483 using wildcard DNS names). The Prefix Limit field is used to inform 484 a route validation algorithm that if an SRO response is returned for 485 a domain name past the prefix limit, the SRO statement MUST be 486 ignored as if it were not present. 488 6.1.4. The Activation Time field 490 The Activation Time field specifies a starting date and time from 491 which the RLOCK record is considered to be active and may be used for 492 route origin validation. The RLOCK record MUST NOT be used for 493 validation prior to this activation time. 495 The Activation Time field value specifies a date and time in the form 496 of a 32-bit unsigned number of seconds elapsed since 1 January 1970 497 00:00:00 UTC, ignoring leap seconds, in network byte order. The 498 longest interval that can be expressed by this format without 499 wrapping is approximately 136 years. 501 If the Activation Time field contains a value of 0, immediate 502 activation for the RLOCK record is in effect. 504 The purpose of the Activation Time field is to permit publication of 505 SRO records in the reverse DNS prior to its use in formal route 506 validation. This enables two key capabilities: first,it allows for 507 the testing of RLOCK records in a safe manner by informing an 508 application to "don't validate, but tell me what you would have 509 done". Second, it allows an ISP to publish an RLOCK and SRO record 510 that defines a large covering prefix to give advance warning to that 511 ISP's customers. Customers that have their own AS number and a 512 delegated address block within the ISP's larger block may want to 513 publish their own SRO record if they share a zone with the ISP, or 514 they will risk having their announcements being marked INVALID 515 because the ISP has claimed a larger covering prefix. Alternatively, 516 the customer may be independent from the ISP's zone and manage their 517 own reverse-DNS zone that has been delegated to them. In this case 518 they may choose to publish an SRO record or to do nothing. The cut 519 point of the zone delegation stops the ISP's covering prefix from 520 extending into the new zone. 522 6.2. SRO RRDATA Presentation Format 524 The presentation format of the RDATA portion is as follows: 526 ORIGIN_ASN [ FLAGS [ PREFIX_LIMIT [ [ ACTIVATION_TIME ] ] ] 528 where ORIGIN_ASN is the mandatory Origin AS Number field, and the 529 remaining fields are optional. If not present, the wire data format 530 will be filled with zeroes. 532 The Flags field is represented by an unsigned integer. The current 533 accepted value MUST be 0. 535 The Prefix Limit field is represented by an unsigned integer in the 536 range 0 to 128. 538 The ORIGIN AS NUMBER field is represented in asdot notation which is 539 a combination of asplain and asdot+ notation. That is, any ASN in 540 the 2-octet range is represented in asplain (simple decimal 541 representation of the ASN). Any ASN above the 2-octet range is 542 represented in asdot+ notation which breaks an ASN into two 16-bit 543 values separated by a dot. For example, AS65535 will be represented 544 by the decimal number "65535" while AS65536 will be represented as 545 "1.0". 547 The Activation Time field values MUST be represented either as an 548 unsigned decimal integer indicating seconds since 1 January 1970 00: 549 00:00 UTC, or in the form YYYYMMDDHHmmSS in UTC, where: 551 YYYY is the year (0001-9999); 552 MM is the month number (01-12); 553 DD is the day of the month (01-31); 554 HH is the hour, in 24 hour notation (00-23); 555 mm is the minute (00-59); and 556 SS is the second (00-59). 558 Note that it is always possible to distinguish between these two 559 formats because the YYYYMMDDHHmmSS format will always be exactly 14 560 digits, while the decimal representation of a 32-bit unsigned integer 561 can never be longer than 10 digits. 563 6.3. SRO RR Examples 565 The following example shows an SRO RR authorizing AS12145 as the 566 origin for CIDR address block 129.82.0.0/16 and only for that prefix. 567 Its activation time is immediate. 569 m.82.129.in-addr.arpa. 86400 IN SRO 12145 571 The second example shows the use of a prefix limit field to authorize 572 AS 12145 to cover the range from 129.82/16 through and including 573 announcements to the /24 limit. Its activation is set to June 1, 574 2013 at 00:00 UTC. 576 m.82.129.in-addr.arpa. 86400 IN SRO 12145 0 24 20130601000000 578 The third example shows two separate origins to be authorized for a 579 prefix. This example also illustrates the use of the asdot notation. 580 Two different prefix limits are used. Activation is immediate for 581 the first SRO; the second is to be used after July 15, 2013 at noon 582 UTC. 584 m.82.129.in-addr.arpa. 86400 IN SRO 12145 0 24 585 86400 IN SRO 3.421 0 18 20130715120000 587 7. Discussion and Related Work 589 This work is not the first to propose entering routing data in the 590 Reverse DNS and there are also many other proposed approaches for 591 publishing routing data. We first review some of the past work and 592 then discusses the differences presented in this approach. 594 7.1. Prior Work on CIDR names for Routing 596 Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use 597 the reverse DNS to verify the origin AS associated with a prefix. 598 This requires both a naming convention for converting the name into a 599 prefix and additional resource record types for storing origin 600 information, along with recommendations on their use. More recently 601 [I-D.donnerhacke-sidr-bgp-verification-dnssec] including links to IRR 602 data and also includes the notion of policy in adjacency, but this 603 approach also introduces a new reverse DNS tree under "BGP.ARPA." 604 CNAME and DNAME records must be used in publishing the data. 606 Our approach differs in several respects. We rely on the existing 607 reverse DNS tree without creating a new hierarchy such as 608 "BGP.ARPA.". We exploit the naming convention in 609 [I-D.gersch-dnsop-revDNS-CIDR] so one does not need to introduce 610 CNAME or DNAME records (though an operator could choose to do so if 611 so desired). We assume optional participation and introduce the 612 concept of an RLOCK resource record to indicate participation. We 613 currently limit our approach to detecting false sub-prefix and false 614 origin route announcements. Extensions to include links to other 615 databases such as IRR can be achieved in combination with or in lieu 616 of an SRO record and further path validation can be included, but the 617 scope of this document is intentionally limited, both for clarity and 618 to match actual implementation. Finally, we separate the publishing 619 technique which is specified in this document from the variety of 620 ways in which one may make use of the data, recognizing that 621 different operators will make different choices on how to make use of 622 the data. 624 7.2. RPKI 626 A great deal of work has been done in the sidr working group on 627 Resource Public Key Infrastructure 628 [RFC6480][RFC6481][RFC6482][RFC6483]. 630 RPKI, also known as Resource Certification, is a specialized public 631 key infrastructure (PKI) framework designed to secure Border Gateway 632 Protocol (BGP). RPKI provides a way to connect Internet number 633 resource information (such as Autonomous System numbers and IP 634 Addresses) to a trust anchor. The certificate structure mirrors the 635 way in which Internet number resources are distributed. That is, 636 resources are initially distributed by the IANA to the Regional 637 Internet Registries (RIRs), who in turn distribute them to Local 638 Internet Registries (LIRs), who then distribute the resources to 639 their customers. RPKI can be used by the legitimate holders of the 640 resources to control the operation of Internet routing protocols to 641 prevent route hijacking and other attacks. [cited from Wikipedia]. 643 The publication of BGP route origin information in the reverse-DNS is 644 a complementary technique to RPKI. While there is some overlap in 645 the techniques, there are also different goals for the reverse-DNS. 647 The Reverse-DNS publication method uses DNSSEC as its base trust 648 model, not a chain of certificates. If an organization has a DNSSEC- 649 signed delegation for a reverse-DNS address block, that organization 650 is the legitimate owner and may place SRO and RLOCK statements in 651 their zone without the interaction of any other organization. If an 652 address block is sold or transferred, either the RIR (Regional 653 Internet Registry) will change its signed delegation records to 654 reflect the change, or the organization itself may independently 655 implement a signed sub-delegation. 657 8. Security Considerations 659 Applications that query the DNS for SRO and RLOCK records MUST 660 request them from DNSSEC-enabled servers and have the DO bit set. 661 Responses that are returned MUST be checked to verify that the D bit 662 is set indicating that the responses have been validated. Otherwise 663 the response should be ignored. 665 The absence of DNSSEC or the inability to contact any nameservers 666 MUST indicate the route is viable (NOTFOUND). 668 9. IANA Considerations 670 RRType numbers need to be assigned for the SRO and RLOCK records. 671 The current testbed temporarily substitutes TYPE65400 for the RLOCK 672 record and TYPE65401 for the SRO record. 674 10. Acknowledgments 676 We would like to thank Danny McPherson for his comments and 677 suggestions. In addition, this document was aided via numerous 678 discussions at NANOG, IETF and private meetings with ISPs, telecomm 679 carriers, and research organizations too numerous to mention by name. 680 Thanks to all for your comments and advice. 682 11. Change History 684 Changes from version 01 to 02 686 Removed the last_hop field from the SRO record 688 Changed the structure of the RLOCK to accommodate an activation 689 date. 691 Changed the structure of the SRO record to accommodate activation 692 date, prefix limit and flag fields. These changes were suggested 693 from a year's practical experience in running a reverse-DNS 694 testbed. 696 Added appendix A discussing the use of DNS wildcards with SRO 697 prefix limits. 699 Modified the examples in Appendix B to reflect changes to the SRO 700 and RLOCK records. 702 Changes from version 00 to 01 704 Removed all discussion of an "alternate naming scheme". A related 705 draft on prefix naming had proposed both a standard naming scheme 706 and an alternate naming scheme, but the alternate naming scheme 707 was removed. Since the alternate naming scheme no longer exists, 708 it was no longer necessary to discuss how this draft would deal 709 with the alternate alternate naming scheme. 711 An optional transit provider field was added the SRO record. 713 Examples were updated based on the SRO change and operational 714 experience. 716 Added Cathie Olschanowsky as a co-author 718 12. References 720 12.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 12.2. Informative References 727 [I-D.bates-bgp4-nlri-orig-verif] 728 Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based 729 NLRI origin AS verification in BGP", 730 draft-bates-bgp4-nlri-orig-verif-00 (work in progress), 731 January 1998. 733 [I-D.donnerhacke-sidr-bgp-verification-dnssec] 734 Donnerhacke, L. and W. Wijngaards, "DNSSEC protected 735 routing announcements for BGP", 736 draft-donnerhacke-sidr-bgp-verification-dnssec-04 (work in 737 progress), May 2008. 739 [I-D.gersch-dnsop-revDNS-CIDR] 740 Gersch, J. and D. Massey, "Reverse DNS Naming Convention 741 for CIDR Address Blocks", 742 draft-gersch-dnsop-revDNS-CIDR-04 (work in progress), 743 May 2012. 745 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 746 Means for Expressing Location Information in the Domain 747 Name System", RFC 1876, January 1996. 749 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 750 Rose, "DNS Security Introduction and Requirements", 751 RFC 4033, March 2005. 753 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 754 Secure Internet Routing", RFC 6480, February 2012. 756 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 757 Resource Certificate Repository Structure", RFC 6481, 758 February 2012. 760 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 761 Origin Authorizations (ROAs)", RFC 6482, February 2012. 763 [RFC6483] Huston, G. and G. Michaelson, "Validation of Route 764 Origination Using the Resource Certificate Public Key 765 Infrastructure (PKI) and Route Origin Authorizations 766 (ROAs)", RFC 6483, February 2012. 768 Appendix A. Discussion of Prefix Limits use in conjunction with DNS 769 wildcards 771 The combination of RLOCK and SRO records may be used to detect and/or 772 prevent sub-prefix hijacks. For example, the zone file shown in 773 appendix B has one SRO record for the /16 and four SRO records for 774 the /18's. If a BGP announcement is made at any other prefix, say a 775 /19, no SRO record will be found. In this case the verification 776 algorithm must query for the RLOCK record. If present, a sub-prefix 777 hijack is indicated. 779 This behavior is desirable in most situations. On the other hand, 780 some organizations may want the ability to advertise an announcement 781 at any arbitrary sub-prefix (e.g. traffic control). The semantics of 782 the SRO statement dictates that if an organization intends to 783 advertise any prefix, an SRO statement must be present to authorize 784 it. This can be done by statically creating multiple SRO statements 785 in a zone for each prefix that could be announced, or by using 786 dynamic DNS to add and remove SRO statements on demand. 788 There are two ways to create a range of SRO statements within a zone 789 file. The first method is to simply create all of the individual SRO 790 statements required and put them in the zone. To cover the full 791 octet from /16 to /23, for example, the administrator would need one 792 SRO for the /16, two for the /17's, four for the /18's, eight for the 793 /19's, and so on. This would be a total of 255 SRO records. One can 794 see that this becomes impractical for IPv6 address ranges; the number 795 of SRO records to authorize a /32 through /64 is enormous. 797 To manage this situation, administrators may use the Prefix Limit 798 field in combination with a DNS wildcard domain name. Assume that 799 the administrator of address block 2002:1488::/32 wants to pre- 800 authorize any announcement from the /32 up to and including /64. 801 Assume also that the zone apex is at the /32. In this case a single 802 SRO record in the zone will suffice: 804 *.8.8.4.1.2.0.0.2.ip6.arpa. IN SRO 12345 0 64 0 806 A query for an SRO record for any prefix, (e.g. /32, or /36 or /48 or 807 even a /96) covered by this zone (i.e., up to any zone cut) will 808 return this SRO record and the announcement can be verified. The 809 prefix limit tells the verification algorithm when to stop using the 810 SRO statement. If an announcement is made for a /96, for example, 811 the SRO record will be returned. Since the prefix limit is 64, the 812 validation algorithm MUST ignore this SRO record as if it did not 813 exist, and perform a query for the RLOCK record. Furthermore, any 814 zone cut also stops the extent of the SRO statement. Any new zone 815 declared below the /32 can declare (or not declare) its own SRO and 816 RLOCK statements. 818 This method allows the creation of zone files for a sparsely 819 populated IPv6 delegation. Individual zones can be created that 820 manage their own sub-prefixes, and the top level zone can handle all 821 the covering prefixes. 823 Appendix B. Examples 825 B.1. Example 1 827 This example shows data entered for the prefix 129.82.0.0/16. The 828 prefix owner has authorized the announcement of 129.82.0.0/16 and the 829 four /18's at 129.82.0.0/18, 129.82.64.0/18, 129.82.128.0/18, and 830 129.82.192.0/18. All the prefixes originate from AS12145. 832 Note: this data is directly cut and paste from actual deployment. 833 TYPE 65400 is being used for RLOCK and TYPE 65401 for SRO records. 834 This draft requests IANA to assign numbers for RLOCK and SRO, the 835 values here are purely for illustrative purposes. 837 $TTL 3600 838 $ORIGIN 82.129.in-addr.arpa. 840 @ IN SOA rush.colostate.edu. dnsadmin.colostate.edu. ( 841 2012082800 ; serial number 842 900 ; refresh, 15 minutes 843 600 ; update retry, 10 minutes 844 86400 ; expiry, 1 day 845 3600 ; minimum, 1 hour 846 ) 848 IN NS dns1.colostate.edu. 849 IN NS dns2.colostate.edu. 851 @ IN TYPE65400 \#0 852 ; RLOCK 853 ; OPT-IN; deny all route announcements 854 ; except those authorized 855 ; effective date = immediate 857 m IN TYPE65401 \# 10 00002f71000000000000 858 ; 129.82.0.0/16 SRO 12145 860 0.0.m IN TYPE65401 \# 10 00002f71000000000000 861 ; 129.82.0.0/18 SRO 12145 863 1.0.m IN TYPE65401 \# 10 00002f71000000000000 864 ; 129.82.64.0/18 SRO 12145 866 0.1.m IN TYPE65401 \# 10 00002f71000000000000 867 ; 129.82.128.0/18 SRO 12145 869 1.1.m IN TYPE65401 \# 10 00002f71000000000000 870 ; 129.82.192.0/18 SRO 12145 872 ; delegations required for 256 /24 zones which contain PTR records 874 1 IN NS dns1.colostate.edu. 875 IN NS dns2.colostate.edu. 876 2 IN NS dns1.colostate.edu. 877 IN NS dns2.colostate.edu. 879 ; continuation to 255 is left out for the sake of brevity 881 B.2. Example 2 883 This example shows data entered for the prefix 216.17.128.0/17. The 884 prefix owner has authorized the announcement of 216.17.128.0/17. The 885 prefix originates from AS6582. 887 1.m.17.216.in-addr.arpa NS ns.frii.net 889 This delegation refers to the new /17 zone and the domain name is not 890 in conflict with any of the pre-existing /24 zones at IN-ADDR.ARPA. 891 This delegation is to be placed at the IN-ADDR.ARPA zone. 893 $TTL 3600 894 $ORIGIN 1.m.17.216.in-addr.arpa. 896 @ IN SOA ns1.frii.net. hostmaster.frii.net. ( 897 2012021300 ; serial number 898 14400 ; refresh, 4 hours 899 3600 ; update retry, 1 hour 900 604800 ; expiry, 7 days 901 600 ; minimum, 10 minutes 902 ) 904 IN NS ns1.frii.net. 905 IN NS ns2.frii.net. 907 $ORIGIN 17.216.in-addr.arpa. 909 1.m IN TYPE65400 \# 0 910 ; RLOCK 911 ; OPT-IN; deny all route announcements 912 ; except those authorized 913 ; activation date = immediate 915 1.m IN TYPE65401 \# 10 000019b6000000000000 916 ; 216.17.128.0/17 SRO 6582 918 ; no other delegations or PTR records are needed in this zone file 919 ; since the /24 delegations are at ARIN at xxx.17.216.IN-ADDR.ARPA 921 Authors' Addresses 923 Joe Gersch 924 Secure64 SW Corp 925 Fort Collins, CO 926 US 928 Email: joe.gersch@secure64.com 930 Dan Massey 931 Colorado State University 932 Fort Collins, CO 933 US 935 Email: massey@cs.colostate.edu 937 Cathie Olschanowsky 938 Colorado State University 939 Fort Collins, CO 940 US 942 Email: cathie@cs.colostate.edu 944 Lixia Zhang 945 UCLA 946 Los Angeles, CA 947 US 949 Email: lixia@cs.ucla.edu