idnits 2.17.1 draft-donnerhacke-sidr-bgp-verification-dnssec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. 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 9 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (March 10, 2008) is 5863 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L. Donnerhacke 2 Category: Proposed Standard IKS GmbH 3 Expires: September 2008 March 10, 2008 5 DNSSEC protected routing announcements for BGP 6 draft-donnerhacke-sidr-bgp-verification-dnssec-00.txt 8 Status of this Memo 10 Distribution of this memo is unlimited. 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes an infrastructure for real time verification 36 of routes reveived via BGP4. Some DNS query types are introduced to 37 check the origin of a prefix and validity of the AS path. The crypto 38 part can be offloaded from the routing engine by sending a DNS query 39 and checking the AD bit in the DNS response. The proposal depends on 40 the DNS scalability and caching mechanisms as well as PKI introduced 41 by DNSSEC. 43 Table of Contents 45 1. Introduction .................................................. 2 46 2. DNS Mapping ................................................... 3 47 2.1. Prefix origin ............................................ 3 48 2.2. AS Peering ............................................... 4 49 2.3. Delegation hierarchy ..................................... 5 50 3. Verification .................................................. 6 51 3.1. Offloading crypto ........................................ 7 52 3.2. Zone slaving ............................................. 7 53 4. Test environment .............................................. 7 54 5. Security Considerations ....................................... 8 55 6. IANA Considerations ........................................... 8 56 7. References .................................................... 8 57 7.1. Normative References ..................................... 8 58 7.2. Informal References ...................................... 9 60 Nomenclature 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 The process of checking an DNS record set to match the DNSSEC key 67 hierarchy is called "validation" in this document. 69 The process of checking an BGP route for origin and path consistency 70 is called "verification" in this document. 72 1. Introduction 74 BGP hijacking is a serious problem in the current internet. In an 75 ideal world those cases can't happen at all, because honest operators 76 apply filters on their BGP4 [RFC4271] peerings in order to catch fat- 77 fingered misconfigurations. The filters can automatically derived 78 from existing, well maintained routing databases. A look to actual 79 routing tables suffice for a reality check. 81 The actual work of the SIDR WG focuses on automatic generation and 82 validation of filters [sidrwg]. There are other proposals, i.e. a 83 redesign of the BGP4 protocol to include cryptographic authentication 84 of the path and origin [bartels]. 86 This document aims to real time verification of received BGP 87 announcements on the routers: An efficient, automatic, and external 88 filter. The described infrastructure does allow to filter bogus 89 announcements even after some steps of transit. 91 All the routing ressource meta information is simplified and mapped 92 into a DNS hierarchy. The allocation and assignment chains for AS 93 and IP numbers from the IANA via RIR and LIRs to the routing enities 94 are reflected by the approbriate DNS delegation chain [iananum]. 96 At the routing entity level (i.e. the ISP or customer) the delegated 97 prefix is mapped to the AS(-Set), which inject the route into the 98 DFZ. Futhermore the peering state is modeled as a two way announce- 99 ment at this level. 101 Due to DNSSEC [RFC4033] all those delegations and announcements can 102 be validated. When querying the router can do the DNSSEC validation 103 itself or delegate it to the next validating resolver. A validated 104 response contains a special bit (Authenticated Data) assuming the 105 trustworthness of the link between the resolver and the router. So 106 the router can work with validated data without performing expensive 107 cryptographic operations and difficult lookup algorithms. 109 Some special issues arise from the interaction of bulding the routing 110 table while requiring a working interconnection for verification, and 111 from verification and other operational errors. 113 2. DNS Mapping 115 The mapping is designed to ease the route verification process. All 116 verification steps should be performed in a building a simple DNS 117 query and looking for a single value in the validated DNS response 118 set. Futhermore the whole process should be easy to debug. 120 A new zone BGP.ARPA is introduced to hold the routing ressouces. For 121 AS number mapping, the zone AS.BGP.ARPA is used. IPv4 prefixes are 122 mapped into IPV4.BGP.ARPA and IPv6 prefixes are mapped into 123 IPV6.BGP.ARPA. 125 2.1. Prefix origin 127 To query the origin AS from a prefix, the prefix is transformed simi- 128 lar to reverse lookups and the DNS is queried for IN/TXT records. 129 The DNS response contains a (possibly empty) set of answer records. 130 Each answer record holds the human readable number of a origin AS in 131 asdot format [as4byte]. 133 IPv4 prefixes are queried as a classless IN-ADDR.ARPA reverse delega- 134 tion [RFC2317], but in the zone IPV4.BGP.ARPA instead of IN- 135 ADDR.ARPA. 137 IPv6 prefixes are queried as a IP6.ARPA reverse delegation [RFC3596], 138 but in the zone IPV6.BGP.ARPA instead of IP6.ARPA. If prefix miss 139 the nibble boundary, the same technique MUST be used as for IPv4. 140 This is necessary, because the LIR needs contol over the whole prefix 141 to announce it. 143 Example: 144 $ORIGIN 192/20.17.217.IPV4.BGP.ARPA. 145 @ IN TXT "15725" 147 $ORIGIN 8.D.B.4.1.0.0.2.IPV6.BGP.ARPA. 148 @ IN TXT "15725" 150 2.2. AS Peering 152 Peering between two AS is fourfold: Sending and accepting on each 153 site. Futhermore peering policies depend on the address family of 154 the prefix [RFC2622]. 156 To query the peering policy of AS A in regard to AS B, the both AS 157 numbers are put together and the DNS is queried for IN/TXT records. 158 The DNS response contains a (possibly empty) set of answer records. 159 Each answer record data consists of the peering direction, the 160 address family, and a space seperated (nonempty) set of AS numbers in 161 asdot format or the special term ANY. The data section is case 162 insensitive. 164 asrdata = direction SPACE family as-set 165 direction = "import" / "export" 166 family = familyversion "." familycast 167 familyversion = "ipv4" / "ipv6" 168 familycast = "unicast" / "multicast" 169 as-set = SPACE "any" / 1*as 170 as = SPACE [1*DIGIT "."] 1*DIGIT 172 To ease the delegation of AS numbers ranges to a RIR and in order to 173 keep the zone size small for efficent DNSSEC operation, the combining 174 of the two AS numbers is done in the following way: The 32-bit AS 175 number of A is written as ., then 177 reversed, and AS.BGP.ARPA appended. The asdot format of the AS B 178 number is used as a terminal in this zone. 180 Example: 181 $ORIGIN 5.2.7.5.1.0.AS.BGP.ARPA. 182 3.3 IN TXT "export ipv4.multicast 15725" 183 IN TXT "import ipv4.multicast ANY" 185 $ORIGIN 3.0.0.0.0.3.AS.BGP.ARPA. 186 15725 IN TXT "export ipv4.multicast 3.3 1273" 187 IN TXT "import ipv4.multicast 15725" 189 2.3. Delegation hierarchy 191 IPv4 addresses are allocated to the RIRs as /8. The delegation at 192 IPV4.BGP.ARPA follows this and delegate the zones to the RIRs name 193 servers. This mimics the delegation vom IANA to the RIRs in IN- 194 ADDR.ARPA. 196 IPv4 addresses are allocated to the LIRs in various sizes. Delega- 197 tion of the allocate is done by the RIR in classless manner. Futher- 198 more the classful subdelegations has to be delegated to the LIR, too. 199 The use of DNAME to a subzone of the already delegated classless pre- 200 fix is RECOMMENDED. 202 Example: 203 $ORIGIN 17.217.IPV4.BGP.ARPA. 204 192/20 IN NS avalon.iks-jena.de. 205 $GENERATE 192-207 $ DNAME $.192/20 207 If the LIR announce the allocate itself, it can add the TXT record 208 set at the delegated zone apex. If the LIR deaggregate the allocate 209 and/or permit assignments to be seperatly announced, it adds further 210 TXT record sets or delegations to the zone. 212 IPv6 addresses delegation mimics the delegation in IP6.ARPA. Please 213 note the similarity to IPv4 if an allocate or assignment miss the 214 nibble boundary. 216 Example: 217 $ORIGIN 0.0.2.0.1.0.0.2.IPV6.BGP.ARPA. 218 C/35 IN NS ns.jp.example. 219 C DNAME C.C/35 220 D DNAME D.C/35 221 E DNAME E.C/35 222 F DNAME F.C/35 224 AS number allocation from IANA to the RIRs is done in large blocks. 225 IANA has to delegate every zone for with the RIR might be responsi- 226 ble, but not more. Additional zones MAY introduced to delegate sin- 227 gle AS numbers via RIRs, if the RIR can't maintain the end customer 228 data directly in the IANA zone. 230 RIRs assign single AS numbers to the LIRs and delegate the approbri- 231 ate zone. 233 3. Verification 235 A router receives routes in a given address family consisting of a 236 prefix and a AS path via BGP4. The router has to verify, if the 237 incoming route is allowed or not. 239 The router has to check the following criteria: 240 - is the originating AS allowed to inject the route? 241 - does all the AS in the path peer as claimed? 242 - does the recorded path fullfill the peering policies? 244 To check the origin, the router queries for the prefix as described 245 in 2.1. If the last AS in the path is in the answer set, the origin 246 is verified. 248 To check the peering policies, for each pair of sequenced AS in the 249 path a query as described in 2.2. is performed. The policy of the 250 sending AS MUST contain all AS numbers of the path tail including the 251 sending AS number or ANY for the address family and for the direction 252 "export". The policy of the receiving AS MUST contain all AS numbers 253 of the path tail including the sending AS number or ANY for the 254 address family and for the direction "import". 256 The router SHOULD NOT check the recursive peering policy for dupli- 257 cate AS numbers, which are the result of prepending. 259 If all checks succeed, the route is accepted. 261 If the check fails, the processing for this route MUST be delayed and 262 retried. This is necessary, because BGP4 does announce a route only 263 once during a peering session. If the temporary (may be remote con- 264 figuration) problem with the DNS disappears, the route will not be 265 reannounced in the BGP4 session, but SHOULD be accepted now. 267 Routers SHOULD postphone all the checkings but accept all the routes 268 as long as the routing table stays below to a configurable value. 269 This behaviour allows a cold start after disasterous problems. The 270 checking is postphoned until DNS becomes workable. 272 Routers MAY record the TTL of the responses and assign the route the 273 minimum of all TTLs to regularly reverify the route. Routers MUST 274 NOT drop the route soley because the TTL times out. 276 3.1. Offloading crypto 278 Routers are not designed for DNS processing and should not do it. 279 DNSSEC offers a validating resolver and a Authenticated Data bit in 280 the response header. Routers SHOULD ask a validating resolver and 281 rely on the AD bit [RFC4033]. 283 This way, the PKI processing, caching, and debugging is hand over to 284 specialized software and admins. 286 3.2. Zone slaving 288 Normally name servers of new AS can't be reached, because the new 289 route to the prefix of the AS can't be verified until the route to 290 the nameserver is active. 292 Thats why all zones in BGP.ARPA MUST have secondaries in other AS. 293 The RIRs are urged to provide public secondaries for their LIRs and 294 their routing customers. 296 To avoid a net split after a hypothetical major outage, running sec- 297 ondaries of other zones, especially of those of the peering AS, is 298 RECOMMENDED. Name server operators in BGP.ARPA SHOULD allow zone 299 transfers to everyone [RFC1034]. 301 4. Test environment 303 A testbed was build to test implementations and verify assumptions 304 based on this recommendation. The data in the testbed is derived on 305 snapshots of the Internet Routing Registy [irdb]. 307 The primary NS for the testbed of BGP.ARPA is IANA.BGP.IKS-JENA.DE. 308 If you run secondaries, I'm happy to add them as name servers for the 309 test zones. If you like to get an delegation to maintain your own 310 part in the testbed, please contact me. 312 IANA and RIRs are especially encouraged to maintain their own area of 313 responsibility. This way the testbed would be more accurate and the 314 communication channels between the participating parties could be 315 covered. 317 To gain experience with DNSSEC signed domains up to the root, I run a 318 signed root [iksroot], which is expanded to cover the BGP.ARPA 319 testbed. 321 You MUST NOT consider this environment as a permanent ressource. It 322 will vanish as soon as the root gets signed [rootsign]. 324 5. Security Considerations 326 All zones in BGP.ARPA MUST be signed. Local infrastructure between 327 the routers and the validating recursive resolvers SHOULD be secured 328 for data modification or spoofing attacks. 330 Operational errors in DNSSEC or DNS handling will cause routing prob- 331 lems. Operational errors at RIR or IANA will cause larger shutdowns 332 of global routing. 334 6. IANA Considerations 336 IANA should gracefully add the BGP.ARPA zone and maintain the delega- 337 tions to the RIRs. 339 IANA should sign the all the zones from the RIR delegation point down 340 to the root. IANA should maintain the resigning and key rollover 341 procedures for those zones. 343 IANA should set up a Delegate Signer (manual) update protocol for the 344 delegation points to allow the RIRs to change their keys. 346 7. References 348 7.1. Normative References 350 [RFC1034] Mockapetris, P, "Domain Names - Concepts and Facilities", 351 RfC 1034, November 1987 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", RFC2119, March 1997 356 [RFC2317] Eidnes, H. and de Groot, G. and Vixie, P., "Classless IN- 357 ADDR.ARPA delegation", RFC2317, March 1998 359 [RFC2622] Alaettinoglu, C. and Villamizar, C. and Gerich, E. and 360 Kessens, D. and Meyer, D. and Bates, T. and Karrenberg, 361 D. and Terpstra, M., "Routing Policy Specification Lan- 362 guage", RFC2622, June 1999 364 [RFC3596] Thomson, S. and Huitema, C. and Ksinant, V. and Souissi, 365 M., "DNS Extensions to support IP version 6", RFC 3596, 366 October 2003 368 [RFC4033] Arends, R. and Austein, R. and Larson, M. and Massey, D. 369 and Rose, S., "DNS Security Introduction and Require- 370 ments", RFC4033, March 2005 372 [RFC4271] Rekhter, Y. and Li, T. and Hares, S., "A Border Gateway 373 Protocol 4", RFC 4271, January 2006 375 [as4byte] Michaelson, G. and Hustone, G., "Canonical Text Represen- 376 tation of Four-octet AS Numbers", Work in Progress 378 7.2. Informal References 380 [irdb] "The Internet Routing Registry: History and Purpose", 381 http://www.ripe.net/db/irr.html 383 [iananum] "Number Resources", http://www.iana.org/numbers/ 385 [sidrwg] "Secure Inter-Domain Routing", 386 http://tools.ietf.org/wg/sidr/ 388 [rootsign] "IANA (DEMO) DNSSEC Status", 389 https://ns.iana.org/dnssec/status.html 391 [youtube] RIPE NCC, "YouTube Hijacking: A RIPE NCC RIS case study", 392 http://www.ripe.net/news/study-youtube-hijacking.html, 393 February 2008 395 [bartels] Bartels, O., "Requirements for a new routing protocol", 396 news:6msps3tgjugmvlkk1hcr26jpo8nrfhbmj0@4ax.com, Work in 397 Progress, March 2008 399 [iksroot] Donnerhacke, L., "Instructions for a signed root", 400 https://www.iks-jena.de/leistungen/keys.txt, December 2007 402 Acknowledgement 404 The proposal was developed with the help of Gert Doering and Oliver 405 Bartels in a USENET News discussion about the YouTube hijacking in 406 February 2008 [youtube]. 408 Authors' Addresses 410 Lutz Donnerhacke 411 IKS GmbH 412 Leutragraben 1 413 07743 Jena 414 Germany 415 Tel: +49-3641-573561 (1.6.5.3.7.5.1.4.6.3.9.4.e164.arpa. NAPTR) 416 EMail: lutz@iks-jena.de 418 Full Copyright Statement 420 Copyright (C) The IETF Trust (2008). 422 This document is subject to the rights, licenses and restrictions 423 contained in BCP 78, and except as set forth therein, the authors 424 retain all their rights. 426 Disclamer 428 This document and the information contained herein are provided on 429 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 430 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 431 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 432 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 433 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 434 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 435 PARTICULAR PURPOSE. 437 Intellectual Property 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed 441 to pertain to the implementation or use of the technology 442 described in this document or the extent to which any license 443 under such rights might or might not be available; nor does it 444 represent that it has made any independent effort to identify any 445 such rights. Information on the procedures with respect to rights 446 in RFC documents can be found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use 451 of such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository 453 at http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention 456 any copyrights, patents or patent applications, or other 457 proprietary rights that may cover technology that may be required 458 to implement this standard. Please address the information to the 459 IETF at ietf-ipr@ietf.org.