Internet Draft L. Donnerhacke Category: Proposed Standard IKS GmbH Expires: September 2008 March 11, 2008 DNSSEC protected routing announcements for BGP draft-donnerhacke-sidr-bgp-verification-dnssec-01 Status of this Memo Distribution of this memo is unlimited. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an infrastructure for real time verification of routes reveived via BGP4. Some DNS query types are introduced to check the origin of a prefix and validity of the AS path. The crypto part can be offloaded from the routing engine by sending a DNS query and checking the AD bit in the DNS response. The proposal depends on the DNS scalability and caching mechanisms as well as PKI introduced by DNSSEC. Donnerhacke Expires September 2008 [Page 1] Internet Draft DNSSEC protected BGP March 11, 2008 Table of Contents 1. Introduction .................................................. 3 2. DNS Mapping ................................................... 3 2.1. Prefix origin ............................................ 4 2.2. AS Peering ............................................... 5 2.3. Delegation hierarchy ..................................... 6 3. Verification .................................................. 6 3.1. Offloading crypto ........................................ 8 3.2. Zone slaving ............................................. 8 4. Related work .................................................. 8 5. Test environment .............................................. 9 6. Security Considerations ....................................... 10 7. IANA Considerations ........................................... 10 8. References .................................................... 10 8.1. Normative References ..................................... 10 8.2. Informal References ...................................... 11 9. Changes history ............................................... 12 10. Acknowledgements ............................................. 12 Nomenclature The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The process of checking an DNS record set to match the DNSSEC key hierarchy is called "validation" in this document. The process of checking an BGP route for origin and path consistency is called "verification" in this document. Donnerhacke Expires September 2008 [Page 2] Internet Draft DNSSEC protected BGP March 11, 2008 1. Introduction BGP hijacking is a serious problem in the current internet. In an ideal world those cases can't happen at all, because honest operators apply filters on their BGP4 [RFC4271] peerings in order to catch fat- fingered misconfigurations. The filters can automatically derived from existing, well maintained routing databases. A look to actual routing tables suffice for a reality check. This document aims to real time verification of received BGP announcements on the routers: An efficient, automatic, and external filter. The described infrastructure does allow to filter bogus announcements even after some steps of transit. All the routing ressource meta information is simplified and mapped into a DNS hierarchy. The allocation and assignment chains for AS and IP numbers from the IANA via RIR and LIRs to the routing enities are reflected by the approbriate DNS delegation chain [iananum]. At the routing entity level (i.e. the ISP or customer) the delegated prefix is mapped to the AS(-Set), which inject the route into the DFZ. Futhermore the peering state is modeled as a two way announce- ment at this level. Due to DNSSEC [RFC4033] all those delegations and announcements can be validated. When querying the router can do the DNSSEC validation itself or delegate it to the next validating resolver. A validated response contains a special bit (Authenticated Data) assuming the trustworthness of the link between the resolver and the router. So the router can work with validated data without performing expensive cryptographic operations and difficult lookup algorithms. Some special issues arise from the interaction of bulding the routing table while requiring a working interconnection for verification, and from verification and other operational errors. 2. DNS Mapping The mapping is designed to ease the route verification process. All verification steps should be performed in a building a simple DNS query and looking for a single value in the validated DNS response set. Futhermore the whole process should be easy to debug. A new zone BGP.ARPA is introduced to hold the routing ressouces. For AS number mapping, the zone AS.BGP.ARPA is used. IPv4 prefixes are mapped into IPV4.BGP.ARPA and IPv6 prefixes are mapped into IPV6.BGP.ARPA. Donnerhacke Expires September 2008 [Page 3] Internet Draft DNSSEC protected BGP March 11, 2008 2.1. Prefix origin To query the origin AS from a prefix, the prefix is transformed simi- lar to reverse lookups and the DNS is queried for IN/TXT records. The DNS response contains a (possibly empty) set of answer records. Each answer record holds the human readable number of a origin AS in asdot format [as4byte]. IPv4 prefixes are queried as a classless IN-ADDR.ARPA reverse delega- tion [RFC2317], but in the zone IPV4.BGP.ARPA instead of IN- ADDR.ARPA. IPv6 prefixes are queried as a IP6.ARPA reverse delegation [RFC3596], but in the zone IPV6.BGP.ARPA instead of IP6.ARPA. If prefix miss the nibble boundary, the same technique MUST be used as for IPv4. This is necessary, because the LIR needs contol over the whole prefix to announce it. For reserved ranges, the special keyword "reserved" is used as the origin. Prefixes with origin "reserved" SHOULD NOT be accepted or announced. Reserved ranges SHOULD use wildcards to mark all more specific routes as "reserved", too. Prefixes which MUST NOT appear in routing tables, so not get an entry in the delegation hierarchy. DNSSEC provide authenticated denial of existence. I.e. IPV6.BGP.ARPA should not contain an entry for F. During rollout of this proposal, a transition period is necessary to allow the AS operators to set up the necessary zones and get the del- egations. During the transition, the RIRs MAY derive the AS data from the [irdb] or insert the special keyword "transition" for the allocated prefixes. Please note, that for multicast routing the destination adresses are not distributed via BGP4, but only the source addresses. That's why the multicast group addresses from 224.0.0.0/3 or FF00::/8 are never looked up and will not be delegated in BGP.ARPA. Example: $ORIGIN 192/20.17.217.IPV4.BGP.ARPA. @ IN TXT "15725" $ORIGIN 8.D.B.4.1.0.0.2.IPV6.BGP.ARPA. @ IN TXT "15725" $ORIGIN 10.IPV4.BGP.ARPA. * IN TXT "reserved" Donnerhacke Expires September 2008 [Page 4] Internet Draft DNSSEC protected BGP March 11, 2008 2.2. AS Peering Peering between two AS is fourfold: Sending and accepting on each site. Futhermore peering policies depend on the address family of the prefix [RFC2622]. To query the peering policy of AS A in regard to AS B, the both AS numbers are put together and the DNS is queried for IN/TXT records. The DNS response contains a (possibly empty) set of answer records. Each answer record data consists of the peering direction, the address family, and a space seperated (nonempty) set of AS numbers in asdot format or the special term ANY. The data section is case insensitive. During rollout of this proposal, a transition period is necessary to allow the AS operators to set up the necessary zones and get the del- egations. During the transition, the RIRs MAY derive the AS data from the [irdb] or insert the special keyword "transition" for the assigned AS. asrdata = direction SPACE family as-set direction = "import" / "export" family = familyversion "." familycast familyversion = "ipv4" / "ipv6" familycast = "unicast" / "multicast" as-set = SPACE "any" / 1*as as = SPACE [1*DIGIT "."] 1*DIGIT To ease the delegation of AS numbers ranges to a RIR and in order to keep the zone size small for efficent DNSSEC operation, the combining of the two AS numbers is done in the following way: The 32-bit AS number of A is written as ., then reversed, and AS.BGP.ARPA appended. The asdot format of the AS B number is used as a terminal in this zone. Example: $ORIGIN 5.2.7.5.1.0.AS.BGP.ARPA. 3.3 IN TXT "export ipv4.multicast 15725" IN TXT "import ipv4.multicast ANY" 15725 IN TXT "export ipv4.multicast 15725" IN TXT "import ipv4.multicast ANY" $ORIGIN 3.0.0.0.0.3.AS.BGP.ARPA. 15725 IN TXT "export ipv4.multicast 3.3" IN TXT "import ipv4.multicast 15725" 3.3 IN TXT "export ipv4.multicast ANY" IN TXT "import ipv4.multicast ANY" Donnerhacke Expires September 2008 [Page 5] Internet Draft DNSSEC protected BGP March 11, 2008 2.3. Delegation hierarchy IPv4 addresses are allocated to the RIRs as /8. The delegation at IPV4.BGP.ARPA follows this and delegate the zones to the RIRs name servers. This mimics the delegation vom IANA to the RIRs in IN- ADDR.ARPA. IPv4 addresses are allocated to the LIRs in various sizes. Delega- tion of the allocate is done by the RIR in classless manner. Futher- more the classful subdelegations has to be delegated to the LIR, too. The use of DNAME to a subzone of the already delegated classless pre- fix is RECOMMENDED. Example: $ORIGIN 17.217.IPV4.BGP.ARPA. 192/20 IN NS avalon.iks-jena.de. $GENERATE 192-207 $ DNAME $.192/20 If the LIR announce the allocate itself, it can add the TXT record set at the delegated zone apex. If the LIR deaggregate the allocate and/or permit assignments to be seperatly announced, it adds further TXT record sets or delegations to the zone. IPv6 addresses delegation mimics the delegation in IP6.ARPA. Please note the similarity to IPv4 if an allocate or assignment miss the nibble boundary. Example: $ORIGIN 0.0.2.0.1.0.0.2.IPV6.BGP.ARPA. C/35 IN NS ns.jp.example. C DNAME C.C/35 D DNAME D.C/35 E DNAME E.C/35 F DNAME F.C/35 AS number allocation from IANA to the RIRs is done in large blocks. IANA has to delegate every zone for with the RIR might be responsi- ble, but not more. Additional zones MAY introduced to delegate sin- gle AS numbers via RIRs, if the RIR can't maintain the end customer data directly in the IANA zone. RIRs assign single AS numbers to the LIRs and delegate the approbri- ate zone. 3. Verification A router receives routes in a given address family consisting of a prefix and a AS path via BGP4. The router has to verify, if the Donnerhacke Expires September 2008 [Page 6] Internet Draft DNSSEC protected BGP March 11, 2008 incoming route is allowed or not. The router has to check the following criteria: - is the originating AS allowed to inject the route? - does all the AS in the path peer as claimed? - does the recorded path fullfill the peering policies? To check the origin, the router queries for the prefix as described in 2.1. If the last AS in the path is in the answer set, the origin is verified. If the lookup for the prefix results in "reserved", routers SHOULD accept the route only, if local configuration permits the prefix. If the prefix can't be found, the route MUST be dropped and MUST NOT advertised to other peers. To check the peering policies, for each pair of sequenced AS in the path a query as described in 2.2. is performed. The policy of the sending AS MUST contain all AS numbers of the path tail including the sending AS number or ANY for the address family and for the direction "export". The policy of the receiving AS MUST contain all AS numbers of the path tail including the sending AS number or ANY for the address family and for the direction "import". AS path checks are also performed for "reserved" prefixes. If an AS can't be found, the check fails. The router SHOULD NOT check the recursive peering policy for dupli- cate AS numbers, which are the result of prepending. AS operators SHOULD add a self peering entry, if they use prepending. If all checks succeed, the route is accepted. If the check fails, the processing for this route MUST be delayed and retried. This is necessary, because BGP4 does announce a route only once during a peering session. If the temporary (may be remote con- figuration) problem with the DNS disappears, the route will not be reannounced in the BGP4 session, but MUST be accepted now. Routers SHOULD postphone all the checkings but accept all the routes as long as the routing table stays below to a configurable value. This behaviour allows a cold start after disasterous problems. The verification is postphoned until DNS becomes useable. Routers MAY record the TTL of the responses and assign the route the minimum of all TTLs to regularly reverify the route. Routers MUST NOT drop the route soley because the TTL times out. If an AS or a prefix lookup return the special keyword "transition", the verification step is assumed to be correct. Donnerhacke Expires September 2008 [Page 7] Internet Draft DNSSEC protected BGP March 11, 2008 3.1. Offloading crypto Routers are not designed for DNS processing and should not do it. DNSSEC offers a validating resolver and a Authenticated Data bit in the response header. Routers SHOULD ask a validating resolver and rely on the AD bit [RFC4033]. This way, the PKI processing, caching, and debugging is hand over to specialized software and admins. 3.2. Zone slaving Normally name servers of new AS can't be reached, because the new route to the prefix of the AS can't be verified until the route to the nameserver is active. Thats why all zones in BGP.ARPA MUST have secondaries in other AS. The RIRs are urged to provide public secondaries for their LIRs and their routing customers. To avoid a net split after a hypothetical major outage, running sec- ondaries of other zones, especially of those of the peering AS, is RECOMMENDED. Name server operators in BGP.ARPA SHOULD allow zone transfers to everyone [RFC1034]. 4. Related work The idea is not new. Directly after the specification of DNSSEC, the provided infrastructure was applied for verifying BGP announcements. Prefix originating verification was proposed by [bates] and discussed by [liauth]. AS mapping to DNS was proposed by [eastlake]. [bates] prefered to define the new record type AS in order to keep the current semantics of TXT. This proposal prefers TXT. The restrictions in TXT syntax are limited to the BGP.ARPA zone. In IPV4.BGP.ARPA and IPV6.BGP.ARPA the TXT records only contain a space seperated list of asdot formatted AS numbers. In AS.BGP.ARPA the requried syntax is given in 2.2. So there is the tradeoff beween defining two new record types and deploy them to existing name server and resolver software, and modi- fying the semantics of TXT records in special area. This proposal prefers to break the pure semantics of TXT records without explicitly updating [RFC1034]. [eastlake] define the AS mapping to DNS using the asplain notation combined with a length indicator of the significat digits. With the Donnerhacke Expires September 2008 [Page 8] Internet Draft DNSSEC protected BGP March 11, 2008 introduction of four-byte AS numbers [RFC4893], IANA chooses to allo- cate a whole to the a single RIR only. Futhermore fixed sized formats are easier to handle in embedded formats. That's why this proposal chooses to expand the to five decimal digits and and append the whole as a single dec- imal number. This decision does only scale, as long as the number of allocated keeps small. The alternate approach of coding the AS number in hex as in IP6.ARPA offers the possibility to follow the IANA allocation policy more closely (allocation step is 0x100). Tests show, that currently 3455 delegations based on decimal number vom IANA to RIRs are necessary, but only 3440 based on hexadecimal numbers. Only if lookup would be done on binary numbers, the number of delegations would drop to 70. In order to ease debugging, this proposal chooses to stick on decimal numbers. The actual work of the SIDR WG focuses on automatic generation and validation of filters [sidrwg]. AS Path checks are not yet devel- oped. There are other proposals, i.e. a redesign of the BGP4 protocol to include cryptographic authentication of the path and origin [bar- tels]. 5. Test environment A testbed was build to test implementations and verify assumptions based on this recommendation. The data in the testbed is derived on snapshots of the Internet Routing Registy [irdb]. The primary NS for the testbed of BGP.ARPA is IANA.BGP.IKS-JENA.DE. If you run secondaries, I'm happy to add them as name servers for the test zones. If you like to get an delegation to maintain your own part in the testbed, please contact me. IANA and RIRs are especially encouraged to maintain their own area of responsibility. This way the testbed would be more accurate and the communication channels between the participating parties could be covered. To gain experience with DNSSEC signed domains up to the root, I run a signed root [iksroot], which is expanded to cover the BGP.ARPA testbed. You MUST NOT consider this environment as a permanent ressource. It will vanish as soon as the root gets signed [rootsign]. Donnerhacke Expires September 2008 [Page 9] Internet Draft DNSSEC protected BGP March 11, 2008 6. Security Considerations All zones in BGP.ARPA MUST be signed. Local infrastructure between the routers and the validating recursive resolvers SHOULD be secured against data modification or spoofing attacks. Operational errors in DNSSEC or DNS handling will cause routing prob- lems. Operational errors at RIR or IANA will cause larger shutdowns of global routing. 7. IANA Considerations IANA should gracefully add the BGP.ARPA zone and maintain the delega- tions to the RIRs. IANA should sign the all the zones from the RIR delegation point down to the root. IANA should maintain the resigning and key rollover procedures for those zones. IANA should set up a Delegate Signer (manual) update protocol for the delegation points to allow the RIRs to change their keys. 8. References 8.1. Normative References [RFC1034] Mockapetris, P, "Domain Names - Concepts and Facilities", RfC 1034, November 1987 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC2119, March 1997 [RFC2317] Eidnes, H. and de Groot, G. and Vixie, P., "Classless IN- ADDR.ARPA delegation", RFC2317, March 1998 [RFC2622] Alaettinoglu, C. and Villamizar, C. and Gerich, E. and Kessens, D. and Meyer, D. and Bates, T. and Karrenberg, D. and Terpstra, M., "Routing Policy Specification Lan- guage", RFC2622, June 1999 [RFC3596] Thomson, S. and Huitema, C. and Ksinant, V. and Souissi, M., "DNS Extensions to support IP version 6", RFC 3596, October 2003 [RFC4033] Arends, R. and Austein, R. and Larson, M. and Massey, D. and Rose, S., "DNS Security Introduction and Require- ments", RFC4033, March 2005 Donnerhacke Expires September 2008 [Page 10] Internet Draft DNSSEC protected BGP March 11, 2008 [RFC4271] Rekhter, Y. and Li, T. and Hares, S., "A Border Gateway Protocol 4", RFC 4271, January 2006 [RFC4893] Vohra, Q. and Chen, E., "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007 [as4byte] Michaelson, G. and Hustone, G., "Canonical Text Represen- tation of Four-octet AS Numbers", Work in Progress: draft- michaelson-4byte-as-representation-05, December 2007 8.2. Informal References [bates] Bates, T. and Bush, R. and Li, T. and Rekhter, Y., "DNS- based NLRI origin AS verification in BGP", Expired work in progress: draft-bates-bgp4-nlri-orig-verif-00, December 1997 [eastlake] Eastlake, D., "Mapping Autonomous Systems Number into the Domain Name System", Expired work in progress: draft-ietf- dnssec-as-map-05, July 1997 [liauth] Li, T., "Origin Authentication in BGP", Expired work in progress: http://www.academ.com/nanog/feb1998/origin.html, February 1998 [irdb] "The Internet Routing Registry: History and Purpose", http://www.ripe.net/db/irr.html [iananum] "Number Resources", http://www.iana.org/numbers/ [sidrwg] "Secure Inter-Domain Routing", http://tools.ietf.org/wg/sidr/ [rootsign] "IANA (DEMO) DNSSEC Status", https://ns.iana.org/dnssec/status.html [youtube] RIPE NCC, "YouTube Hijacking: A RIPE NCC RIS case study", http://www.ripe.net/news/study-youtube-hijacking.html, February 2008 [bartels] Bartels, O., "Requirements for a new routing protocol", Work in Progress: news:6msps3tgjug- mvlkk1hcr26jpo8nrfhbmj0@4ax.com, March 2008 [iksroot] Donnerhacke, L., "Instructions for a signed root", https://www.iks-jena.de/leistungen/keys.txt, December 2007 Donnerhacke Expires September 2008 [Page 11] Internet Draft DNSSEC protected BGP March 11, 2008 9. Changes history This section will not appear in the final document. It does provide some convenience hints what changed between the document version. It is not complete nor normative. Important differences from 00 to 01: - Added handling of reserved address space using wildcards. - Added handling of non routable address space using denial of exis- tence. - Added classification of multicast address space as non routable space. - Added transition phase where information is copied from [irdb] or verification is explicitly turned off. - Added recommendation to explicitly announce prepending as self peering. - Raised recheck of delayed verifications from SHOULD to MUST. - Added a section about related work and reasons for design deci- sions. 10. Acknowledgements The proposal was developed with the help of Gert Doering and Oliver Bartels in a USENET News discussion about the YouTube hijacking in February 2008 [youtube]. Many thanks go to Tony Li for pointing out several historic docu- ments, and his invaluable comments on the transition phase, reserved areas, and readvertisement of received prefixes. Authors' Addresses Lutz Donnerhacke IKS GmbH Leutragraben 1 07743 Jena Germany Tel: +49-3641-573561 (1.6.5.3.7.5.1.4.6.3.9.4.e164.arpa. NAPTR) EMail: lutz@iks-jena.de Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Donnerhacke Expires September 2008 [Page 12] Internet Draft DNSSEC protected BGP March 11, 2008 Disclamer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Donnerhacke Expires September 2008 [Page 13]