[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04                                                
Internet Draft                                            L. Donnerhacke
Category: Proposed Standard                                     IKS GmbH
Expires: September 2008                                   March 10, 2008

             DNSSEC protected routing announcements for BGP

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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 10, 2008

Table of Contents

   1. Introduction ..................................................  2
   2. DNS Mapping ...................................................  3
      2.1. Prefix origin ............................................  3
      2.2. AS Peering ...............................................  4
      2.3. Delegation hierarchy .....................................  5
   3. Verification ..................................................  6
      3.1. Offloading crypto ........................................  7
      3.2. Zone slaving .............................................  7
   4. Test environment ..............................................  7
   5. Security Considerations .......................................  8
   6. IANA Considerations ...........................................  8
   7. References ....................................................  8
      7.1. Normative References .....................................  8
      7.2. Informal References ......................................  9


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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.

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.

   The actual work of the SIDR WG focuses on automatic generation and
   validation of filters [sidrwg].  There are other proposals, i.e. a
   redesign of the BGP4 protocol to include cryptographic authentication
   of the path and origin [bartels].

   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.

Donnerhacke              Expires September 2008                 [Page 2]

Internet Draft            DNSSEC protected BGP            March 10, 2008

   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

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-

   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

Donnerhacke              Expires September 2008                 [Page 3]

Internet Draft            DNSSEC protected BGP            March 10, 2008

   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.

      $ORIGIN 192/20.17.217.IPV4.BGP.ARPA.
      @ IN TXT "15725"

      $ORIGIN 8.D.B.
      @ IN TXT "15725"

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

      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 <high order 16-bit value in decimal>.<low
   order 16-bit value in decimal as five dot seperated digits>, then
   reversed, and AS.BGP.ARPA appended.  The asdot format of the AS B
   number is used as a terminal in this zone.

Donnerhacke              Expires September 2008                 [Page 4]

Internet Draft            DNSSEC protected BGP            March 10, 2008

      3.3   IN TXT "export ipv4.multicast 15725"
            IN TXT "import ipv4.multicast ANY"

      15725 IN TXT "export ipv4.multicast 3.3 1273"
            IN TXT "import ipv4.multicast 15725"

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-

   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.

      $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.

      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

Donnerhacke              Expires September 2008                 [Page 5]

Internet Draft            DNSSEC protected BGP            March 10, 2008

   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
   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.

   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".

   The router SHOULD NOT check the recursive peering policy for dupli-
   cate AS numbers, which are the result of 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 SHOULD 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
   checking is postphoned until DNS becomes workable.

   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.

Donnerhacke              Expires September 2008                 [Page 6]

Internet Draft            DNSSEC protected BGP            March 10, 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. 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

   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

   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 7]

Internet Draft            DNSSEC protected BGP            March 10, 2008

5. Security Considerations

   All zones in BGP.ARPA MUST be signed.  Local infrastructure between
   the routers and the validating recursive resolvers SHOULD be secured
   for 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.

6. 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.

7. References

7.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 8]

Internet Draft            DNSSEC protected BGP            March 10, 2008

   [RFC4271]  Rekhter, Y. and Li, T. and Hares, S., "A Border Gateway
              Protocol 4", RFC 4271,  January 2006

   [as4byte]  Michaelson, G. and Hustone, G., "Canonical Text Represen-
              tation of Four-octet AS Numbers", Work in Progress

7.2. Informal References

   [irdb]     "The Internet Routing Registry: History and Purpose",

   [iananum]  "Number Resources", http://www.iana.org/numbers/

   [sidrwg]   "Secure Inter-Domain Routing",

   [rootsign] "IANA (DEMO) DNSSEC Status",

   [youtube]  RIPE NCC, "YouTube Hijacking: A RIPE NCC RIS case study",
              February 2008

   [bartels]  Bartels, O., "Requirements for a new routing protocol",
              news:6msps3tgjugmvlkk1hcr26jpo8nrfhbmj0@4ax.com, Work in
              Progress, March 2008

   [iksroot]  Donnerhacke, L., "Instructions for a signed root",
              https://www.iks-jena.de/leistungen/keys.txt, December 2007


   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].

Authors' Addresses

   Lutz Donnerhacke
   IKS GmbH
   Leutragraben 1
   07743 Jena
   Tel: +49-3641-573561 ( NAPTR)
   EMail: lutz@iks-jena.de

Donnerhacke              Expires September 2008                 [Page 9]

Internet Draft            DNSSEC protected BGP            March 10, 2008

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.


   This document and the information contained herein are provided on

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 10]