INET Conferences |
|||||||||||||||||||||
|
A Novel Use of Distributed Directory ServiceBill MANNING <bmanning@isi.edu> AbstractThe inability of the existing tools to provide a consistent view of the public Internet to its constituents is beginning to hamper its growth. Currently there is a disconnection between Internet address delegations to service providers and the announcement of address delegations by those service providers to each other. In conjunction with this disconnect is the centralized nature of these registries. In the increasingly distributed Internet, it is harder and harder to reach through the maze and access these services in real time. We think it is desirable to have a migration strategy that will provide a "chain of custody" from delegation to announcement that can be authenticated and will allow local sites to collect and cache the data they need to maintain a "world view" that, while not authoritative, is generally consistent and useful. To build the system, we used DNS security to provide the authentication and chain of custody components and then added RPSL/RIDE syntax statements to the DNS zones so that each site may build a local copy of a routing registry. Since each site has one or more delegations and maintains the zone data locally, they can ensure that the authoritative routing data is also kept and maintained locally. We then describe how this system was implemented and tested in the 6bone with the 6bone participants and we look to ways in which this system might be deployed in the IPv4 world. ContentsProblem statementA significant hurdle in the growth of the Internet is the lack of methods, tools, and techniques needed by operational staff as they attempt to determine the authenticity of information presented by their peers in normal exchange of routing information. There are two aspects of this problem. One, which we will not go into here, is that the current suite of routing protocols has a single trust level for all transactions. There are efforts underway which intend to add authentication tokens as part of the routing exchange. At present (circa January 1998) these approaches presume either the existence of one or more Internet-wide certification authorities that can validate these authentication tokens or one more round of bilateral agreements, where each site maintains its own certification process. The second, which will be the focus of this monograph, is the description of an out-of-band, non-real-time method of providing assurances of authentication of prefix delegation and prefix/as mapping. This method is based on yet another exploitation of the only existent operational Internet-wide distributed directory system, the DNS. Current state of the artThe existing routing registry function is based on a design created by the RIPE NCC. An initial assumption in the creation of the RIPE-81 specification was a single, centralized repository where everyone would report and record not only the delegation information but also the authorized contacts, ASN tagging, and prefix announcements. As the number of users of this tool grew, enhancements were and are being made. Others took on some of the enhancement work and the number of sites that are using the children of the RIPE-81 specification (RIPE-181, RPSL) is growing. One of the significant problems with this scale of deployment is that unlike the RIPE NCC, few if any of these new sites are also recognized as a regional Internet Registry or RIR, and so there was no easy method to authenticate either the ASN tags or prefix announcements that were entered into these new routing registries. There have been attempts to try to develop synchronization techniques to replicate the data stored in these registries so that they would have some semblance of global knowledge. Some of the earliest techniques, which are still in use, involve periodic file transfers of batch data between sites. It has been pointed out that this injects a level of uncertainty in the integrity of the routing registry data, as it may be as much as 36 hours or so out-of-date with data in the live routing system. It is also true that when the data is centralized, as the existent model calls for, it can be much harder to reach that centralized registry in the event of network instability. So what we have is a system where, for the most part, the registries that perform prefix and ASN delegations are completely disconnected from the registries that record routing preference. This places each Internet service provider in an environment where they individually must create reasonably elaborate procedures to authenticate the accuracy of the routing data provided by and through each of their peers. As the Internet grows, the complexity of these procedures increases. The visionWe believe that it is necessary for the creation and deployment of methods and processes that will provide the following attributes: 1) a "chain of custody" path that will exist between the delegation hierarchy and the announcement hierarchy; and 2) better techniques and tools to support distribution of responsibility for delegations and their corresponding announcements. To meet these goals, we have explored the idea of using the existing structure of the DNS, adding one new zone for recording infrastructure components and then leveraging existing work from the IETF RPS and DNS-SEC working groups. Evidence from this experiment indicates that it is a reasonable approach but it does have one serious drawback, which is the need for cooperation across the Internet between all participants and the acceptance by participants of the responsibility to train their downstream clients and users on the use of these techniques. Using these techniques allows for incremental rollout, without the need for large-scale, top-down investment or flag-day operations. Entities that participate in the responsible use of the Internet's numbering plans are now genuinely authoritative for the delegation contact data and are also authoritative for any routing announcement information. If there is a need, sites may also collect data from other sites to create scoped global views from other participants in the global Internet. These collected views are nonauthoritative. Each site is responsible for maintaining the authoritative master for its delegation of responsibility. ArchitectureThe design exploits the address to name tree in the Domain Name System. For IPv4 this is represented in the in-addr.arpa domain. For IPv6 this is represented in the ip6.int domain. These domains can be viewed as the root of the delegation hierarchy for IP addresses. It is possible to start at the root of the DNS and identify all the authoritative delegations. We note in passing that not all authoritative delegations are active or announced; however, we do have access to a mapping of the delegation hierarchy. There have been a number of claims that these trees are unused and are mostly superfluous and few applications make use of the data present. It is not clear how useful applications such as FTP or HTTP are or how broadly they are used, but they are the principal applications which use these zones as a sanity check by mapping the results of the forward lookup with the results of the inverse lookup to see if the forward domain names match. In a series of zone audits over the last year, the accuracy of the data within the in-addr.arpa domain has been checked with numbers showing more than 57% of the delegations being managed accurately, and the percentage is increasing. It is true that not all delegation points are managed by those to whom the delegations have been made and that this might become an issue if this idea gets broad-scale support. However, given all the caveats on the weaknesses with these zones, they do form the delegation hierarchy of prefixes within the Internet and this hierarchy is distributed and is architecturally structured so that the site receiving a delegation becomes authoritative for the data within that delegation. It is nearly ideal as a starting point but requires the addition of one or two other features to be useful. One item that is increasingly more important in today's Internet is the ability to authenticate information. With the addition of authentication tokens being added to the DNS, it is now possible to validate a prefix delegation from the root. The difficulty with this general idea is that given the DNS implementations in common use, there is lead time needed to propagate code that recognizes these new record types or tokens. In one online discussion, this response seemed to illuminate the problem of waiting for new RR support:
The problem here is that it is hard to tell when to move your code base to support new features, but that topic is outside the purview of this paper. With the addition of the hooks provided by the DNS-SEC working group to the inverse trees of the DNS, we now have the ability to authenticate delegations. We have our "chain of custody" that follows the delegation hierarchy. In and of itself, this pushes the DNS into a new realm. With the addition of support for storing and transmitting public keys and the ability to authenticate DNS transactions, the Internet will have available to it a truly public Certification Hierarchy. There will be the temptation to exploit this feature as a Certification Authority but it is unlikely to receive formal assurances as a public Certification Authority since it is decentralized. The temptation will be strong and so care should be given to explore the legal ramifications on the use of keys stored and moved through the DNS. The use of zone signatures for tracking delegations has its own set of concerns. We have had to look again at the periodicity of change over the inverse tree in the DNS. Most people will recognize, if they think about it, that the changes that occur near the leaves of a DNS tree have a much higher frequency than changes that occur near the root. This fact has ramifications for authentication of zone contents by use of zone signatures. We expect that it is tractable to use zone level authentication at and near the root, while the closer we get to the leaves, the harder it will be to have verifiable signatures. To do so would require features within the DNS that we touched on in the paragraph above as well as other components that are outside the scope of this paper. For our purposes, we will only use the zone authentication features, leaving the topic of the DNS as a public certification authority to other venues. The next step is to add routing policy information. This data applies to both prefixes, which are already mapped into the DNS, and to Autonomous System Numbers, which are tags used to identify administrative span of control. We'll look first at ASNs. Current routing protocols use them to define and apply routing policies. The DNS design did not comprehend ASNs. At the time, ASN usage was a crude method of "tagging" prefixes to be announced to your peers via the EGP (RFC 827). There were few enough peers and simple enough policies that there was no perceived need to track ASN usage within something like the DNS. In recent years, it was recognized that it would be useful to have a way to track aspects of routing domain identifiers and so the zone rdi int was created, initially to record routing domain identifiers for the IDRP routing protocol. It is in this zone that we record the mapping of ASN to administrative contact. At this point we have the address or prefix delegation hierarchy in place, a zone to track ASN usage, and the methods for authentication at each step. For a functional system, we need to add descriptions of routing policy. The method we have experimented with is to utilize the record structure as defined in the routing policy specification language (RPSL) and encapsulate them inside DNS TXT records. The format is opaque, since we have built a specific structure inside the TXT RR so that a better and more robust approach can be taken if this proves viable. We selected the encapsulated TXT method since virtually all existent DNS code understands TXT records. We would prefer to have defined a new RR type, RPS, but will pursue that activity on a different timetable since new RR type support tends to track the deployment of new DNS code and that takes significant time to gain critical penetration rates. With this opaque structure we have shown that it is possible to express policies on both an ASN and on a per prefix basis. With this component in place it becomes possible to discriminate between authoritative and proxy delegations and announcements. There then exists a "chain of custody" between delegation and routing policy that can be independently verified by ISPs. And each delegation point maintains the authoritative data for its delegations and preferred routing policy locally. Implementation reviewThe implementation occurs in two parts. The simplest part is the integration of routing information within the DNS so we look at that aspect first. The more complex part is the activation of DNS Security features as authentication tokens and we'll cover that last. To test our theory, we began creating the needed components for adding routing services. To begin, we had delegated the RDI.INT zone to real servers and began populating the zone with test data. An example, shown below, is the first attempt to build out the data in this zone into something that could be meaningful: Script started on Mon Jan 26 10:23:10 1998 26% dig @dot.ep.net 4555.rdi.int. axfr ; <<>> DiG 2.0 <<>> @dot.ep.net 4555.rdi.int. axfr 4555.rdi.int. 129600 SOA dot.ep.net. hostmaster.ep.net. ( 1925630 ;serial 10800 ;refresh 900 ;retry 604800 ;expire 129600 ) ;minim 4555.rdi.int. 129600 NS dot.ep.net. 4555.rdi.int. 129600 NS ns.isi.edu. 4555.rdi.int. 129600 TXT RPS 0000 person:Bill Manning 4555.rdi.int. 129600 TXT RPS 0001 descr: LosAngelesPeering exchange 4555.rdi.int. 129600 TXT RPS 0002 aut-num: AS4555 4555.rdi.int. 129600 TXT RPS 0003 as-in: from AS226 100 AS226 4555.rdi.int. 129600 TXT RPS 0004 as-in: from AS226 110 AS4554 4555.rdi.int. 129600 TXT RPS 0005 interas-in: fron AS226 10.10.1.1/32 (pref=3) AS4554 4555.rdi.int. 129600 TXT RPS 0007 admin-c: WM110-NSI 4555.rdi.int. 129600 TXT RPS 0008 tech-c: WM110-NSI 4555.rdi.int. 129600 TXT RPS 0009 remarks: The first live example of this technique 4555.rdi.int. 129600 TXT RPS 0010 remarks: Check the SOA for mnt-by, changed data 4555.rdi.int. 129600 TXT RPS 0011 source: DNS 4555.rdi.int. 129600 TXT RPS 0012 route: 198.32.2.0/24 4555.rdi.int. 129600 TXT RPS 0013 route: 3ffe:08/24 ; Matching SOA found ;; FROM: zed.isi.edu to SERVER: dot.ep.net 198.32.2.10 ;; WHEN: Mon Jan 26 10:23:33 1998 27% Most of the historical ASN delegations may be found within the RDI.INT zone now as we populated it with the existing data from the Network Solutions database. Longer term there would need to be means negotiated with the existing regional IRs to ensure that their ASN delegations are properly encoded in this zone. This takes care of one side of the ASN to prefix mapping. The other side of the mapping occurs in the inverse tree of the DNS. An example is listed below: 26% dig @dot.ep.net 2.32.198.in-addr.arpa axfr ; <<>> DiG 2.0 <<>> @dot.ep.net 2.32.198.in-addr.arpa axfr 2.32.198.in-addr.arpa. 86400 SOA dot.ep.net. hostmaster.ep.net. ( 1928529 ;serial 10800 ;refresh 900 ;retry 604800 ;expire 86400 ) ;minim 2.32.198.in-addr.arpa. 86400 NS dot.ep.net. 2.32.198.in-addr.arpa. 86400 NS NS.ISI.EDU. 2.32.198.in-addr.arpa. 86400 TXT RPS 0000 descr: Application Testbed network 2.32.198.in-addr.arpa. 86400 TXT RPS 0001 origin: 4555 2.32.198.in-addr.arpa. 86400 TXT RPS 0002 notify: bmanning@karoshi.com 2.32.198.in-addr.arpa. 86400 TXT RPS 0003 address: PO 12317, MDR, CA. 90295 2.32.198.in-addr.arpa. 86400 TXT RPS 0004 nic-hdl: WM110-NSI 10.2.32.198.in-addr.arpa. 86400 PTR dot.ep.net. 11.2.32.198.in-addr.arpa. 86400 PTR dash.ep.net. 1.2.32.198.in-addr.arpa. 86400 PTR bah2.ep.net. ; Matching SOA found ;; FROM: zed.isi.edu to SERVER: dot.ep.net 198.32.2.10 ;; WHEN: Mon Jan 26 10:31:31 1998 27% or, more appropriately, for our testing, an IPv6 prefix: 79% dig @ns.isi.edu 8.0.e.f.f.3.ip6.int. axfr ; <<>> DiG 8.1 <<>> @ns.isi.edu 8.0.e.f.f.3.ip6.int. axfr ; (1 server found) $ORIGIN 8.0.e.f.f.3.ip6.int. @ 1d12h IN SOA ns.isi.edu. bmanning.isi.edu. ( 1925873 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1d12h ) ; minimum 1d12h IN NS ns.isi.edu. 1d12h IN NS dot.ep.net. 1d12h IN TXT "RPS 0000 descr: Application Testbed network" 1d12h IN TXT "RPS 0001 origin: 4555" 1d12h IN TXT "RPS 0002 notify: bmanning@karoshi.com" 1d12h IN TXT "RPS 0003 address: PO 12317, MDR, CA. 90295" 1d12h IN TXT "RPS 0004 nic-hdl: WM110-NSI" 10 1d12h IN NS ns.isi.edu. 1d12h IN NS dot.ep.net. 0.0 1d12h IN NS NS.ISI.EDU. 1d12h IN NS orb.isi.edu. 1.0 1d12h IN NS ns.isi.edu. @ 1d12h IN SOA ns.isi.edu. bmanning.isi.edu. ( 1925873 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1d12h ) ; minimum ;; Received 14 answers (14 records). ;; FROM: darkstar.isi.edu to SERVER: 128.9.128.127 ;; WHEN: Mon Jan 26 14:46:52 1998 These zones now have coded in them the basic data used by the RA projects routing policy toolset to build router configurations. It is fairly easy to extract the zone data, as has been done above using the DNS tool DiG, if your servers do not already carry the zone as a caching server or a real master or slave. If one or more of the machines are acting in the capacity of master or slave, then you already have access to the data. The process that we took was the following:
This process is functionally identical to the same steps used by the Routing Arbiter project except that the input data is not stored in a remote repository but is collected from authoritative sources and processed locally. This second part of the vision is easily deployable and may be done by any of those who are delegated address prefixes and/or ASNs. The more difficult task is developing the "chain of custody" and the deployment of the features in DNS-Security to provide the authentication tokens needed to instantiate the "chain of custody." Our experiments were hampered by the same issues noted earlier in that there are new DNS resource records required for DNS Security deployment -- to wit, the KEY, NXT, and SIG types are all used. Testing was also hampered by the lack of supported code and stable specifications. During the course of testing, the specifications for how authentication and validation were to be done changed three times from inception to the time of this writing. It is expected that further changes may occur as we gain more experience. It is also true that the initial code base was the proof of concept code released by Trusted Information Systems as initially announced at the Munich IETF. We continue to work with this code because although the Internet Software Consortium has announced that they will have a supported release with DNS Security features available, no such code has been forthcoming as of this writing. And so, given the fluid nature of the specifications and the code, it is very difficult to persuade other operators to run servers with our modifications, except on an experimental basis. Until there is better support for these new RR types within a broader code base, our ability to create authentication chains is very limited. Nonetheless, we were able to demonstrate proof of concept within a restricted scope. To utilize DNS Security features, we need to understand how the various tokens are used and how they interact. Given the fluid nature of the NXT and SIG records, we will only examine how to use the KEY resource record. The KEY record is used to "sign" or stamp a zone with a "signature" that is created with cryptographic techniques that attempt to ensure that the contents of the zone are known to be authentic by the person who generates the signature over the zone contents. As this is exactly what we are looking for, that is all we need to proceed. Since many people are unable to do cryptographic computations in their heads, TIS has created a wonderful tool that provides some level of automation in the creation of KEY records on a per-zone basis. They call this tool zone_sign, and as of this writing, it is available from the TIS ftp site. Here is their description of what zone_sign does:
What this means in practice is that we need to modify the zone file to add the following new directive, the $SIGNER directive. The zone file starts out like this: % more ip6.int-nosec $ORIGIN int. $SIGNER ip6.int. 19769 ip6 IN SOA ns.isi.edu. hostmaster.ep.net. ( 1925623 10800 900 604800 129600 ) IN NS munnari.oz.au. IN NS imag.imag.fr. IN NS ns.isi.edu. $ORIGIN 5.ip6.int. f IN NS NS.ISI.EDU. IN NS munnari.oz.au. IN NS zesbot.ipv6.surfnet.nl. $ORIGIN f.f.3.ip6.int. e IN NS ns.isi.edu. IN NS imag.imag.fr. % What we will not discuss here in detail is the format of $SIGNER directive even though it is pretty simple. The format is the name of the zone and a "footprint" or cryptographic key that is associated with the zone and the person signing it. Generation of the "footprint" may be done with another program from TIS or may be done via other means. In any case we take the zone, modified with the $SIGNER directive, and then we then run through zone_sign, which generates a signature for the zone. %zone_sign -f ip6.int -z ip6.int Starting at Mon, 02/02/98 01:01:47 PM zone_sign -f ip6.int -z ip6.int Warning: appending a '.' to zone 'ip6.int' Warning: Assuming a default signer ip6.int. for zone Running zone_sign with following settings: Initial input file : ip6.int Initial zone suffix : ip6.int. Initial signer : ip6.int. Resulting files in : . Sorting mechanism : In memory tree Tracing directives : none Interim results file: ./ip6.int.unsort. (will be removed by this process before ending) All RR's are to be resigned (all SIG RR's discarded). All new signatures will expire Mon, 03/02/1998 01:01:47 PM. All names (wildcard covered and not) are in NXT chain The following files are created ONLY if necessary. Unsigned record file: ./ip6.int.dontsign. Signed record file : ./ip6.int.signed Note: Records signed by other signers (whose keys are not available) will be placed in files $INCLUDEd in the signed records file. Input lines breakdown: 15 in file(s), 1 continuation, 4 directive, 0 invalid or discarded, 0 blank or comment Total records accepted for sorting: 10 Input lines unaccounted: 0 (should be 0) Beginning to sort ip6.int. at Mon, 02/02/98 01:01:47 PM Key decryption Password: Found key for ip6.int., footprint 19769 dst_read_public_key(): Public Key not found Kip6.int.00000.public Could not find key for ip6.int., footprint 0 Beginning to sign ip6.int. at Mon, 02/02/98 01:20:25 PM Finished signing ip6.int. at Mon, 02/02/98 01:20:29 PM Total records processed: 10 Total signatures generated: 7 in 4 seconds Average 1.75 signatures per second Total signatures verified: 0 successful: 0 Average 0.00 verifications per second Output lines breakdown: 25 in file(s), 15 generated, 0 recalculated, 0 duplicates found Missing lines 0 (should be 0) Ending at Mon, 02/02/98 01:20:29 PM % And the output of the run looks like this. % more ip6.int.signed $SIGNER ip6.int. 19769 ip6.int. SOA ns.isi.edu. hostmaster.ep.net. 886453307 10800 900 604800 129600 ip6.int. SIG SOA 1 129600 19980302210147 19980202212025 19769 ip6.int. Uv70yA0c9c9eGbBSTAktCBh94xE20ZKBmOIfhsQi1dqKyS5mTfcaQYUrMKwoKXLfEMm/xr5qt9hVxVELLVwsVQ ip6.int. NS ns.isi.edu. ip6.int. NS imag.imag.fr. ip6.int. NS munnari.oz.au. ip6.int. SIG NS 1 129600 19980302210147 19980202212025 19769 ip6.int. OqT2wMmnUdnccVtNb3ml58GHoasnCi9KDURfHgJJc2VixUtXUSfCSVWS7gzKa69KCKN9e3ISvyH/BN3rKuJDlA ip6.int. NXT e.f.f.3.ip6.int. NS SOA SIG KEY NXT ip6.int. SIG NXT 1 129600 19980302210147 19980202212025 19769 ip6.int. gqgjVACuGJBpvsraMZmzITaOK4B6a7TYZvbesRG2EDTA+1mJ7oRQsmBSR4YWJdYY9KTl0btcKyD9VV8paBkKQw e.f.f.3.ip6.int. NS ns.isi.edu. e.f.f.3.ip6.int. NS imag.imag.fr. e.f.f.3.ip6.int. SIG NS 1 129600 19980302210147 19980202212025 19769 ip6.int. fac9MHeWkMpJRywGHpkYVkXxTpIg/jumgPD4mXeoD1fs/Ohr5D8u1uxsX2M8Y41pZmzRLVau49O7sIhqyJe08w e.f.f.3.ip6.int. NXT f.5.ip6.int. NS SIG NXT e.f.f.3.ip6.int. SIG NXT 1 129600 19980302210147 19980202212025 19769 ip6.int. gP/wq/qIpBEq4Wm9XsRP9lsyVFgEkn5FwkU5DCf3U0Le399vbPOz3//v8mv4nJtMZSIbFxrOfDO8wgfYRz3BXA f.5.ip6.int. NS NS.ISI.EDU. f.5.ip6.int. NS zesbot.ipv6.surfnet.nl. f.5.ip6.int. NS munnari.oz.au. f.5.ip6.int. SIG NS 1 129600 19980302210147 19980202212025 19769 ip6.int. cUt9dX+VJGDtSz6DIWQZi6bAwM1RwHaQVP3U+rrGnJmc9cZTeh06ST0O12BlRYsmYCRjVrkP8++WHoupiKtT1A== f.5.ip6.int. NXT ip6.int. NS SIG NXT f.5.ip6.int. SIG NXT 1 129600 19980302210147 19980202212025 19769 ip6.int. YgDU1C4X4cfXH4U72fs2+Hod+7wpA9VP9N1Yo982BftIBjQ+BSFrvNisDgytnv9rqumLims0Y8oi49O2tRxkOw $INCLUDE ./ip6.int.dontsign. % %more ip6.int.dontsign. ; $SIGNER ; Zone minimum TTL is 129600 ; Expiration date is 19980302210147 ip6.int. KEY 257 255 1 AQOsEDhLAnKsPiz3Q5y091btFVchctNfs16XFULO02qNyKafPWErCitd62WNEKSxL7BSPzX2kkiMOZ92HR1dTTmz % Here we have the nascent ability to have authentication at each delegation point. Adding this feature to the processes described above, it will be possible to utilize these infrastructure zones to track not only authoritative delegations but also desired routing capabilities as well. There are still areas that need a lot of work. Other areas of weakness:
SummaryThe tools and facilities are available or will shortly be available to allow everyone who receives a delegation of IP space to authoritatively publish their desired routing policy as part of their DNS zones. No longer will there need to be a requirement for registering in one or more centralized routing registries. To ensure the integrity of the data, it is becoming possible to generate cryptographic signatures on zone files, allowing independent authentication of the accuracy of a zone's contents, including authentication tokens and routing hints. Continued work on the remaining problem areas will lead to tools and techniques that will foster the continued explosive growth in the Internet by encouraging local control and administration of certain infrastructure components. We hope that our experiments may lead to a more productive and stable Internet. |