diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-05.txt b/doc/draft/draft-ietf-dnsext-dns-threats-06.txt similarity index 71% rename from doc/draft/draft-ietf-dnsext-dns-threats-05.txt rename to doc/draft/draft-ietf-dnsext-dns-threats-06.txt index 90a40da4e1..6540f0def2 100644 --- a/doc/draft/draft-ietf-dnsext-dns-threats-05.txt +++ b/doc/draft/draft-ietf-dnsext-dns-threats-06.txt @@ -1,16 +1,13 @@ - - - Network Working Group D. Atkins -draft-ietf-dnsext-dns-threats-05.txt IHTFP Consulting +draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting R. Austein - Grunchweather Associates - November 2003 + ISC + February 2004 - Threat Analysis Of The Domain Name System + Threat Analysis of the Domain Name System Status of this document @@ -54,9 +51,9 @@ Abstract -Atkins & Austein Expires 26 May 2004 [Page 1] +Atkins & Austein Expires 21 August 2004 [Page 1] -draft-ietf-dnsext-dns-threats-05.txt November 2003 +draft-ietf-dnsext-dns-threats-06.txt February 2004 1. Introduction @@ -106,25 +103,29 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 This note assumes that the reader is familiar with both the DNS and with DNSSEC, and does not attempt to provide a tutorial on either. + The DNS documents most relevant to the subject of this note are: - -Atkins & Austein Expires 26 May 2004 [Page 2] +Atkins & Austein Expires 21 August 2004 [Page 2] -draft-ietf-dnsext-dns-threats-05.txt November 2003 +draft-ietf-dnsext-dns-threats-06.txt February 2004 + [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], + [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. + For purposes of discussion, this note uses the term "DNSSEC" to refer to the core hierarchical public key and signature mechanism specified in the DNSSEC documents, and refers to TKEY and TSIG as separate - mechanisms, even though TKEY and TSIG are also part of the larger - problem of "securing DNS" and thus are often considered part of the - overall set of "DNS security extensions". This is an arbitrary - distinction that in part reflects the way in which the protocol has - evolved (introduction of a putatively simpler transaction model for - certain operations), and perhaps should be changed in a future - revision of this note. + mechanisms, even though channel security mechanisms such as TKEY and + TSIG are also part of the larger problem of "securing DNS" and thus + are often considered part of the overall set of "DNS security + extensions". This is an arbitrary distinction that in part reflects + the way in which the protocol has evolved (introduction of a + putatively simpler channel security model for certain operations such + as zone transfers and dynamic update requests), and perhaps should be + changed in a future revision of this note. 2. Known Threats @@ -147,33 +148,34 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 To further complicate things, the DNS query the attacker intercepts may just be a means to an end for the attacker: the attacker might - even chose to return the correct result in the answer section of a + even choose to return the correct result in the answer section of a reply message while using other parts of the message to set the stage for something more complicated, for example, a name-based attack (see below). - While it certainly would be possible to sign DNS messages using TSIG - or IPsec, or even to encrypt them using IPsec, this would not be a - very good solution. First, this approach would impose a fairly high - processing cost per DNS message, as well as a very high cost - associated with establishing and maintaining bilateral trust - relationships between all the parties that might be involved in - resolving any particular query. For heavily used name servers (such - as the servers for the root zone), this cost would almost certainly - be prohibitively high. Even more important, however, is that the - underlying trust model in such a design would be wrong, since at best - it would only provide a hop-by-hop integrity check on DNS messages + While it certainly would be possible to sign DNS messages using a + channel security mechanism such as TSIG or IPsec, or even to encrypt + them using IPsec, this would not be a very good solution. First, + this approach would impose a fairly high processing cost per DNS + message, as well as a very high cost associated with establishing and + maintaining bilateral trust relationships between all the parties + that might be involved in resolving any particular query. For -Atkins & Austein Expires 26 May 2004 [Page 3] +Atkins & Austein Expires 21 August 2004 [Page 3] -draft-ietf-dnsext-dns-threats-05.txt November 2003 +draft-ietf-dnsext-dns-threats-06.txt February 2004 - and would not provide any sort of end-to-end integrity check between - the producer of DNS data (the zone administrator) and the consumer of - DNS data (the application that triggered the query). + heavily used name servers (such as the servers for the root zone), + this cost would almost certainly be prohibitively high. Even more + important, however, is that the underlying trust model in such a + design would be wrong, since at best it would only provide a hop-by- + hop integrity check on DNS messages and would not provide any sort of + end-to-end integrity check between the producer of DNS data (the zone + administrator) and the consumer of DNS data (the application that + triggered the query). By contrast, DNSSEC (when used properly) does provide an end-to-end data integrity check, and is thus a much better solution for this @@ -190,7 +192,7 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 - Perform all of the DNSSEC signature checking on its own, - - Use TSIG (or some equivalent mechanism) to insure the integrity of + - Use TSIG (or some equivalent mechanism) to ensure the integrity of its communication with whatever name servers it chooses to trust, or @@ -205,28 +207,28 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 only a 16-bit field and the server UDP port associated with DNS is a well-known value, so there are only 2**32 possible combinations of ID and client UDP port for a given client and server. This is not a - particularly large range, and is not proof against a brute force - search; furthermore, in practice both the client UDP port and the ID - can often be predicted from previous traffic, and it is not uncommon - for the client port to be a known fixed value as well (due to - firewalls or other restrictions), thus frequently reducing the search - space to a range smaller than 2**16. + particularly large range, and is not sufficient to protect against a + brute force search; furthermore, in practice both the client UDP port + and the ID can often be predicted from previous traffic, and it is + not uncommon for the client port to be a known fixed value as well + (due to firewalls or other restrictions), thus frequently reducing + the search space to a range smaller than 2**16. By itself, ID guessing is not enough to allow an attacker to inject bogus data, but combined with knowledge (or guesses) about QNAMEs and + + + +Atkins & Austein Expires 21 August 2004 [Page 4] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + QTYPEs for which a resolver might be querying, this leaves the resolver only weakly defended against injection of bogus responses. Since this attack relies on predicting a resolver's behavior, it's most likely to be successful when the victim is in a known state, - - - -Atkins & Austein Expires 26 May 2004 [Page 4] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - whether because the victim rebooted recently, or because the victim's behavior has been influenced by some other action by the attacker, or because the victim is responding (in a predictable way) to some third @@ -242,7 +244,7 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 interception attack. A resolver that checks DNSSEC signatures will be able to detect the forged response; resolvers that do not themselves perform DNSSEC signature checking should use TSIG or some - equivalent mechanism to insure the integrity of their communication + equivalent mechanism to ensure the integrity of their communication with a recursing name server that does perform DNSSEC signature checking. @@ -271,18 +273,18 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 using this query as a means to inject false information about some other name). + + +Atkins & Austein Expires 21 August 2004 [Page 5] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + - Attacker injects response, whether via packet interception, query guessing, or by being a legitimate name server that's involved at some point in the process of answering the query that the victim issued. - - -Atkins & Austein Expires 26 May 2004 [Page 5] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - - Attacker's response includes one or more RRs with DNS names in their RDATA; depending on which particular form this attack takes, the object may be to inject false data associated with those names @@ -326,19 +328,19 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 injected the data had access to an allegedly secret key whose corresponding public key appears at an expected location in the DNS name space with an expected chain of parental signatures that start + + + +Atkins & Austein Expires 21 August 2004 [Page 6] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + with a public key of which the resolver has prior knowledge). DNSSEC signatures do not cover glue records, so there's still a possibility of a name-based attack involving glue, but with DNSSEC it is possible to detect the attack by temporarily accepting the glue in - - - -Atkins & Austein Expires 26 May 2004 [Page 6] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - order to fetch the signed authoritative version of the same data, then checking the signatures on the authoritative version. @@ -364,17 +366,17 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 installed when adding network drops in every guest room...). While the obvious solution to this problem would be for the client to - chose a more trustworthy server, in practice this may not be an + choose a more trustworthy server, in practice this may not be an option for the client. In many network environments a client machine - has only a limited set of recursive name server from which to chose, - and none of them may be particularly trustworthy. In extreme cases, - port filtering or other forms of packet interception may prevent the - client host from being able to run an iterative resolver even if the - owner of the client machine is willing and able to do so. Thus, - while the initial source of this problem is not a DNS protocol attack - per se, this sort of betrayal is a threat to DNS clients, and simply - switching to a different recursive name server is not an adequate - defense. + has only a limited set of recursive name servers from which to + choose, and none of them may be particularly trustworthy. In extreme + cases, port filtering or other forms of packet interception may + prevent the client host from being able to run an iterative resolver + even if the owner of the client machine is willing and able to do so. + Thus, while the initial source of this problem is not a DNS protocol + attack per se, this sort of betrayal is a threat to DNS clients, and + simply switching to a different recursive name server is not an + adequate defense. Viewed strictly from the DNS protocol standpoint, the only difference between this sort of betrayal and a packet interception attack is @@ -382,27 +384,27 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 attacker. The defense against this is the same as with a packet interception attack: the resolver must either check DNSSEC signatures itself or use TSIG (or equivalent) to authenticate the server that it + + + +Atkins & Austein Expires 21 August 2004 [Page 7] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + has chosen to trust. Note that use of TSIG does not by itself guarantee that a name server is at all trustworthy: all TSIG can do is help a resolver protect its communication with a name server that it has already decided to trust for other reasons. Protecting a resolver's communication with a server that's giving out bogus - - - -Atkins & Austein Expires 26 May 2004 [Page 7] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - answers is not particularly useful. Also note that if the stub resolver does not trust the name server that is doing work on its behalf and wants to check the DNSSEC signatures itself, the resolver really does need to have independent - knowledge of the DNSSEC public key(s) it needs to perform the check - (usually the public key for the root zone, but in some cases - knowledge of additional keys may also be appropriate). + knowledge of the DNSSEC public key(s) it needs in order to perform + the check (usually the public key for the root zone, but in some + cases knowledge of additional keys may also be appropriate). It is difficult to escape the conclusion that a properly paranoid resolver must always perform its own signature checking, and that @@ -438,22 +440,27 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 might be considered a problem. The question remains: how serious is this threat? Clearly the threat does exist; general paranoia says that some day it'll be on the front page of some major newspaper, + + + +Atkins & Austein Expires 21 August 2004 [Page 8] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + even if we cannot conceive of a plausible scenario involving this attack today. This implies that some mitigation of this risk is required. - Note that it's necessary to prove the non-existance of applicable - - - -Atkins & Austein Expires 26 May 2004 [Page 8] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - + Note that it's necessary to prove the non-existence of applicable wildcard RRs as part of the authenticated denial mechanism, and that, in a zone that is more than one label deep, such a proof may require - proving the non-existance of multiple discrete sets of wildcard RRs. + proving the non-existence of multiple discrete sets of wildcard RRs. + + DNSSEC does include mechanisms which make it possible to determine + which authoritative names exist in a zone, and which authoritative + resource record types exist at those names. The DNSSEC protections + do not cover non-authoritative data such as glue records. 2.7. Wildcards @@ -467,26 +474,36 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 heavy use of wildcard RRs, particularly wildcard MX RRs. In order to provide the desired services for wildcard RRs, we need to - prove two things: + do two things: - - We need to prove the existance of the wildcard RR itself (that is, - we need to prove that the synthesis rule exists), and + - We need a way to attest to the existence of the wildcard RR itself + (that is, we need to show that the synthesis rule exists), and - - We need to prove the non-existance of any RRs which, if they - existed, would make the wildcard RR irrelevant according to the - synthesis rules the way in which wildcards are used (that is, we - need to prove that the synthesis rule is applicable). + - We need a way to attest to the non-existence of any RRs which, if + they existed, would make the wildcard RR irrelevant according to + the synthesis rules that govern the way in which wildcard RRs are + used (that is, we need to show that the synthesis rule is + applicable). - Note that this makes the wildcard proof mechanism dependent upon the + Note that this makes the wildcard mechanisms dependent upon the authenticated denial mechanism described in the previous section. - DNSSEC does include mechanisms by which it is possible to furnish - wildcard proofs along the lines described above. + DNSSEC includes mechanisms along the lines described above, which + make it possible for a resolver to verify that a name server applied + the wildcard expansion rules correctly when generating an answer. 3. Weaknesses of DNSSEC DNSSEC has some problems of its own: + + + +Atkins & Austein Expires 21 August 2004 [Page 9] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + - DNSSEC is complex to implement, and includes some nasty edge cases at the zone cuts that require very careful coding. Testbed experience to date suggests that trivial zone configuration errors @@ -499,22 +516,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 effective as denial of service amplifiers. - DNSSEC answer validation increases the resolver's work load, since - - - -Atkins & Austein Expires 26 May 2004 [Page 9] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - a DNSSEC-aware resolver will need to perform signature validation and in some cases will also need to issue further queries. This increased workload will also increase the time it takes to get an - answer back to the original DNS client, which will almost certainly - trigger both timeouts and re-queries. (Arguably, many current DNS - clients are already too impatient even before taking the further - delays that DNSSEC will impose into account, but that's a separate - topic for another document....) + answer back to the original DNS client, which is likely to trigger + both timeouts and re-queries in some cases. (Arguably, many + current DNS clients are already too impatient even before taking + the further delays that DNSSEC will impose into account, but that's + a separate topic for another document....) - Like DNS itself, DNSSEC's trust model is almost totally hierarchical. While DNSSEC does allow resolvers to have special @@ -522,48 +531,58 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 the general case the root key is the one that matters. Thus any compromise in any of the zones between the root and a particular target name can damage DNSSEC's ability to protect the integrity of - data owned by that target name. This is not really a change, since - insecure DNS has essentially the same problem, but it's not good - either. + data owned by that target name. This is not a change, since + insecure DNS has the same model. - Key rollover at the root is really hard. Work to date has not even come close to adequately specifying how the root key rolls over, or even how it's configured in the first place. - DNSSEC creates a requirement of loose time synchronization between - the resolver and the host creating the DNSSEC signatures. Prior to - DNSSEC, all time-related actions in DNS could be performed by a - machine that only knew about "elapsed" or "relative" time. Because - the validity period of a DNSSEC signature is based on "absolute" - time, a resolver must have the same concept of absolute time in - order to determine whether the signature is within its validity - period or has expired. An attacker that can change a resolver's - opinion of the current absolute time can fool the resolver using - expired signatures. An attacker that can change the zone signer's - opinion of the current absolute time can fool the zone signer into + the validating resolver and the entity creating the DNSSEC + signatures. Prior to DNSSEC, all time-related actions in DNS could + be performed by a machine that only knew about "elapsed" or + "relative" time. Because the validity period of a DNSSEC signature + is based on "absolute" time, a validating resolver must have the + same concept of absolute time as the zone signer in order to + determine whether the signature is within its validity period or + has expired. An attacker that can change a resolver's opinion of + the current absolute time can fool the resolver using expired + signatures. An attacker that can change the zone signer's opinion + of the current absolute time can fool the zone signer into generating signatures whose validity period does not match what the signer intended. - - The mechanism for wildcard proofs in DNSSEC is fairly painful. At - various times there have been questions as to whether the proof - mechanism is completely airtight and whether it would be worthwhile - to optimize the wildcard proof mechanism for the common case in - which wildcards do not exist, but the main problem is just the - inherent complexity of the wildcard mechanism itself. This - complexity probably makes the code for generating and checking - wildcard proofs somewhat fragile, but since the alternative of - giving up wildcards entirely is not practical due to widespread - use, we are going to have to live with wildcards, and the question - just becomes one of whether or not the proposed optimizations would - -Atkins & Austein Expires 26 May 2004 [Page 10] +Atkins & Austein Expires 21 August 2004 [Page 10] -draft-ietf-dnsext-dns-threats-05.txt November 2003 +draft-ietf-dnsext-dns-threats-06.txt February 2004 - make DNSSEC's wildcard proof mechanisms more or less fragile. + - The possible existence of wildcard RRs in a zone complicates the + authenticated denial mechanism considerably. For most of the + decade that DNSSEC has been under development these issues were + poorly understood. At various times there have been questions as + to whether the authenticated denial mechanism is completely + airtight and whether it would be worthwhile to optimize the + authenticated denial mechanism for the common case in which + wildcards are not present in a zone, but the main problem is just + the inherent complexity of the wildcard mechanism itself. This + complexity probably makes the code for generating and checking + authenticated denial attestations somewhat fragile, but since the + alternative of giving up wildcards entirely is not practical due to + widespread use, we are going to have to live with wildcards, and + the question just becomes one of whether or not the proposed + optimizations would make DNSSEC's mechanisms more or less fragile. + + - Even with DNSSEC, the class of attacks discussed in section 2.4 is + not easy to defeat. In order for DNSSEC to be effective in this + case, it must be possible to configure the resolver to expect + certain categories of DNS records to be signed, which may require + manual configuration of the resolver, especially during the initial + DNSSEC rollout period when the resolver cannot reasonably expect + the root and TLD zones to be signed. 4. Topics for Future Work @@ -589,6 +608,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 limited or closed environment such as a DHCP server updating a local DNS name server. + + + +Atkins & Austein Expires 21 August 2004 [Page 11] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + Major issues arise when trying to use dynamic update on a secure zone. TSIG can similarly be used in a limited fashion to authenticate the client to the server, but TSIG only protects DNS @@ -611,18 +638,10 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 the above options, but in practice (a) would almost certainly be extremely fragile, so (b) is the only workable mechanism. - - - -Atkins & Austein Expires 26 May 2004 [Page 11] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - There are other threats in terms of describing the policy of who can make what changes to which RRsets in the zone. The current access control scheme in Secure Dynamic Update is fairly limited. There is - no way to give find-grained access to updating DNS zone information + no way to give fine-grained access to updating DNS zone information to multiple entities, each of whom may require different kinds of access. For example, Alice may need to be able to add new nodes to the zone or change existing nodes, but not remove them; Bob may need @@ -636,8 +655,8 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 As discussed in previous sections, DNSSEC per se attempts to provide data integrity and data origin authentication services on top of the - normal DNS query protocol. Using the terminology discussed in [SEC- - CONS], DNSSEC provides "object security" for the normal DNS query + normal DNS query protocol. Using the terminology discussed in + [RFC3552], DNSSEC provides "object security" for the normal DNS query protocol. For purposes of replicating entire DNS zones, however, DNSSEC does not provide object security, because zones include unsigned NS RRs and glue at delegation points. Use of TSIG to @@ -645,6 +664,14 @@ draft-ietf-dnsext-dns-threats-05.txt November 2003 security", but still does not provide object security for complete zones, so the trust relationships involved in zone transfer are still very much a hop-by-hop matter of name server operators trusting other + + + +Atkins & Austein Expires 21 August 2004 [Page 12] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + name server operators, rather than an end-to-end matter of name server operators trusting zone administrators. @@ -668,13 +695,6 @@ Security Considerations The authors believe that deploying DNSSEC will help to address some, but not all, of the known threats to the DNS. - - -Atkins & Austein Expires 26 May 2004 [Page 12] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - IANA Considerations None. @@ -684,56 +704,61 @@ Acknowledgments This note is based both previous published works by others and on a number of discussions both public and private over a period of many years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin, - Dan Bernstein, Randy Bush, Olafur Gudmundsson, Rip Loomis, Allison - Mankin, Paul Mockapetris, Mans Nilsson, Paul Vixie, Xunhua Wang, and - any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working - groups whose names and contributions the authors have forgotten, none - of whom are responsible for what the authors did with their ideas. + Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ + Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten + Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other + members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose + names and contributions the authors have forgotten, none of whom are + responsible for what the authors did with their ideas. + + As with any work of this nature, the authors of this note acknowledge + that we are standing on the toes of those who have gone before us. + Readers interested in this subject may also wish to read + [Bellovin95], [Schuba93], and [Vixie95]. Normative References - [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and - facilities", RFC 1034, November 1987. + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + RFC 1034, November 1987. - [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation - and specification", RFC 1035, November 1987. - [HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet - Hosts - Application and Support", RFC 1123, October 1989. - [DNS-CLARIFY] Elz, R., and R. Bush, "Clarifications to the DNS +Atkins & Austein Expires 21 August 2004 [Page 13] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", RFC 1035, November 1987. + + [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS Specification" RFC 2181, July 1997. - [NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" RFC 2308, March 1998. - [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. - [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845, - May 2000. + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)" RFC 2845, May 2000. - [TKEY] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" RFC - 2930, September 2000. + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" + RFC 2930, September 2000. - [SECURE-UPDATE] Wellington, B., "Secure Domain Name System (DNS) - Dynamic Update" RFC 3007, November 2000. + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update" RFC 3007, November 2000. - [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. - - - -Atkins & Austein Expires 26 May 2004 [Page 13] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - Informative References - [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture + [RFC3552] Rescorla, E., Korver, B., and the Internet Architecture Board, "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003. @@ -751,7 +776,15 @@ Informative References [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of the Fifth Usenix Unix Security Symposium, June 1995. -Author's addresses: + + + +Atkins & Austein Expires 21 August 2004 [Page 14] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + +Authors' addresses: Derek Atkins IHTFP Consulting, Inc. @@ -762,10 +795,12 @@ Author's addresses: Email: derek@ihtfp.com Rob Austein - Grunchweather Associates - - Email: sra@hactrn.net + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + Email: sra@isc.org Intellectual Property Statement The IETF takes no position regarding the validity or scope of any @@ -779,14 +814,6 @@ Intellectual Property Statement claims of rights made available for publication 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 - - - -Atkins & Austein Expires 26 May 2004 [Page 14] - -draft-ietf-dnsext-dns-threats-05.txt November 2003 - - proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. @@ -805,6 +832,14 @@ Full Copyright Statement or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are + + + +Atkins & Austein Expires 21 August 2004 [Page 15] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other @@ -838,5 +873,23 @@ Acknowledgement -Atkins & Austein Expires 26 May 2004 [Page 15] - + + + + + + + + + + + + + + + + + + +Atkins & Austein Expires 21 August 2004 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt similarity index 72% rename from doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt rename to doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt index 41070d556d..8097d63455 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-08.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: June 16, 2004 R. Austein +Expires: August 16, 2004 R. Austein ISC M. Larson VeriSign @@ -10,11 +10,11 @@ Expires: June 16, 2004 R. Austein USC/ISI S. Rose NIST - December 17, 2003 + February 16, 2004 DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-08 + draft-ietf-dnsext-dnssec-intro-09 Status of this Memo @@ -36,15 +36,15 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 16, 2004. + This Internet-Draft will expire on August 16, 2004. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract - The Domain Name System Security Extensions (DNSSEC) adds data origin + The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions, and describes their capabilities and limitations. This document also discusses the @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires June 16, 2004 [Page 1] +Arends, et al. Expires August 16, 2004 [Page 1] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 Last, this document describes the interrelationships between the @@ -75,15 +75,13 @@ Table of Contents 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 - 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 15 - 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 15 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 - Normative References . . . . . . . . . . . . . . . . . . . . . 21 - Informative References . . . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 - Intellectual Property and Copyright Statements . . . . . . . . 25 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . . 20 + Informative References . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 24 @@ -108,9 +106,11 @@ Table of Contents -Arends, et al. Expires June 16, 2004 [Page 2] + + +Arends, et al. Expires August 16, 2004 [Page 2] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 1. Introduction @@ -133,13 +133,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 This document and its two companions update and obsolete RFCs 2535 [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3226 [RFC3226], and 3445 [RFC3445], as well as several works in progress: "Redefinition of the - AD bit" [I-D.ietf-dnsext-ad-is-secure], "Legacy Resolver - Compatibility for Delegation Signer" - [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation Signer - Resource Record" [I-D.ietf-dnsext-delegation-signer]. This document - set also updates, but does not obsolete, RFCs 1034 [RFC1034], 1035 - [RFC1035], 2136 [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 - [RFC3597]. + AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation + Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation + Signer Resource Record" [RFC3658]. This document set also updates, + but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597]. The DNS security extensions provide origin authentication and integrity protection for DNS data, as well as a means of public key @@ -164,9 +162,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 3] + + +Arends, et al. Expires August 16, 2004 [Page 3] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 2. Definitions of Important DNSSEC Terms @@ -178,36 +178,36 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 this section. authentication chain: an alternating sequence of DNSKEY RRsets and DS - RRs forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to check the signature - covering a DS RR and allows the DS RR to be authenticated. The DS - RR contains a hash of another DNSKEY RR and this new DNSKEY RR is - authenticated by matching the hash in the DS RR. This new DNSKEY - RR in turn authenticates another DNSKEY RRset and, in turn, some - DNSKEY RR in this set may be used to authenticate another DS RR - and so forth until the chain finally ends with a DNSKEY RR which - signs the desired DNS data. For example, the root DNSKEY can be - used to authenticated the DS RR for "example." The "example." DS - RR contains a hash that matches some "example." DNSKEY and this - DNSKEY signs the "example." DNSKEY RRset. Private key - counterparts in the "example." DNSKEY RRset sign data records such - as "www.example." as well as DS RRs for delegations such as - "subzone.example." + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash of another DNSKEY RR and + this new DNSKEY RR is authenticated by matching the hash in the DS + RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset + and, in turn, some DNSKEY RR in this set may be used to + authenticate another DS RR and so forth until the chain finally + ends with a DNSKEY RR which signs the desired DNS data. For + example, the root DNSKEY RRset can be used to authenticate the DS + RRset for "example." The "example." DS RRset contains a hash that + matches some "example." DNSKEY and this DNSKEY signs the + "example." DNSKEY RRset. Private key counterparts of the + "example." DNSKEY RRset sign data records such as "www.example." + as well as DS RRs for delegations such as "subzone.example." authentication key: A public key which a security-aware resolver has verified and can therefore use to authenticate data. A security-aware resolver can obtain authentication keys in three ways. First, the resolver is generally preconfigured to know - about at least one public key. This preconfigured data is either - the public key itself, or a hash of the key as found in the DS RR. - Second, the resolver may use an authenticated public key to verify - a DS RR and its associated DNSKEY RR. Third, the resolver may be - able to determine that a new key has been signed by another key - which the resolver has verified. Note that the resolver must - always be guided by local policy when deciding whether to - authenticate a new key, even if the local policy is simply to - authenticate any new key for which the resolver is able verify the - signature. + about at least one public key. This preconfigured data is usually + either the public key itself or a hash of the key as found in the + DS RR. Second, the resolver may use an authenticated public key + to verify a DS RR and its associated DNSKEY RR. Third, the + resolver may be able to determine that a new key has been signed + by another key which the resolver has verified. Note that the + resolver must always be guided by local policy when deciding + whether to authenticate a new key, even if the local policy is + simply to authenticate any new key for which the resolver is able + verify the signature. delegation point: Term used to describe the name at the parental side of a zone cut. That is, the delegation point for "foo.example" @@ -220,32 +220,46 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 4] +Arends, et al. Expires August 16, 2004 [Page 4] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 in its delegating parent zone (see [I-D.ietf-dnsext-dnssec-records]). An island of security is served by a security-aware nameserver and may provide authentication chains to any delegated child zones. Responses from an island of - security or its descendents can only be validated if its zone key - can be obtained by some trusted means out of band from the DNS - protocol. + security or its descendents can only be authenticated if its zone + key can be authenticated by some trusted means out of band from + the DNS protocol. key signing key: An authentication key which is used to sign one or - more other authentication keys. Typically, a key signing key will - sign a zone signing key, which in turn will sign other zone data. - Local policy may require the zone signing key to be changed - frequently, while the key signing key may have a longer validity - period in order to provide a more stable secure entry point into - the zone. Designating an authentication key as a key signing key - is purely an operational issue: DNSSEC validation does not - distinguish between key signing keys and other DNSSEC + more other authentication keys for a given zone. Typically, a key + signing key will sign a zone signing key, which in turn will sign + other zone data. Local policy may require the zone signing key to + be changed frequently, while the key signing key may have a longer + validity period in order to provide a more stable secure entry + point into the zone. Designating an authentication key as a key + signing key is purely an operational issue: DNSSEC validation does + not distinguish between key signing keys and other DNSSEC authentication keys. Key signing keys are discussed in more detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: zone signing key. + non-validating security-aware stub resolver: A security-aware stub + resolver which trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + non-validating stub resolver: A less tedious term for a + non-validating security-aware stub resolver. + security-aware name server: An entity acting in the role of a name server (defined in section 2.4 of [RFC1034]) which understands the DNS security extensions defined in this document set. In @@ -260,6 +274,13 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 A more cumbersome equivalent phrase would be "a security-aware name server which offers recursive service". + + +Arends, et al. Expires August 16, 2004 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + security-aware resolver: An entity acting in the role of a resolver (defined in section 2.4 of [RFC1034]) which understands the DNS security extensions defined in this document set. In particular, @@ -269,72 +290,51 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 types and message header bits defined in this document set to provide DNSSEC services. - security-aware stub resolver: An entity acting in the role of a - resolver (defined in section 2.4 of [RFC1034]) which has at least - a minimal understanding the DNS security extensions defined in - this document set, but which trusts one or more security-aware + security-aware stub resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) which has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating" depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also: validating stub resolver, non-validating stub resolver. - - -Arends, et al. Expires June 16, 2004 [Page 5] - -Internet-Draft DNSSEC Introduction and Requirements December 2003 - - - recursive name servers to perform most of the tasks discussed in - this document set on its behalf. In particular, a security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. Note that the distinction between security-aware - resolvers and security-aware stub resolvers is different from the - distinction between iterative-mode and recursive-mode resolvers in - the base DNS specification: a particular security-aware resolver - may operate exclusively in recursive mode, but still perform its - own DNSSEC signature validity checks, while a security-aware stub - resolver does not, by definition. - - security-oblivious (server or resolver): The opposite of + security-oblivious : An which is not "security-aware". signed zone: A zone whose RRsets are signed and which contains properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS records. - unsigned zone: The opposite of a "signed zone". + unsigned zone: A zone which is not signed. + + validating security-aware stub resolver: A security-aware resolver + which operates sends queries in recursive mode but which performs + signature validation on its own rather than just blindly trusting + a friendly security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + validating stub resolver: A less tedious term for a validating + security-aware stub resolver. zone signing key: An authentication key which is used to sign a zone. See key signing key, above. Typically a zone signing key will be part of the same DNSKEY RRset as the key signing key which signs it, but is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. + Designating an authentication key as a zone signing key is purely + an operational issue: DNSSEC validation does not distinguish + between zone signing keys and other DNSSEC authentication keys. See also: key signing key. - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 16, 2004 [Page 6] +Arends, et al. Expires August 16, 2004 [Page 6] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 3. Services Provided by DNS Security @@ -381,16 +381,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 offline when practical to do so. To discover a public key reliably via DNS resolution, the target key itself needs to be signed by either a preconfigured authentication key or another key that has - been authenticated previously. Security-aware resolvers authenticate + been authenticated previously. Security-aware resolvers authenticate zone information by forming an authentication chain from a newly learned public key back to a previously known authentication public key, which in turn either must have been preconfigured into the -Arends, et al. Expires June 16, 2004 [Page 7] +Arends, et al. Expires August 16, 2004 [Page 7] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 resolver or must have been learned and verified previously. @@ -412,9 +412,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 point in a parent zone and indicates the key or keys used by the delegated child zone to self-sign the DNSKEY RRset at the child zone's apex. The child zone, in turn, uses one or more of the keys - in this DNSKEY RRset to sign its zone data. The authentication chain - is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or - more DS->DNSKEY subchains. + in this DNSKEY RRset to sign its zone data. The typical + authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where + "*" denotes zero or more DS->DNSKEY subchains. DNSSEC permits more + complex authentication chains, such as additional layers of DNSKEY + RRs signing other DNSKEY RRs within a zone. A security-aware resolver normally constructs this authentication chain from the root of the DNS hierarchy down to the leaf zones based @@ -439,16 +441,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 record. The NSEC record allows a security-aware resolver to authenticate a negative reply for either name or type non-existence via the same mechanisms used to authenticate other DNS replies. Use - of NSEC records require a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe -Arends, et al. Expires June 16, 2004 [Page 8] +Arends, et al. Expires August 16, 2004 [Page 8] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe the gaps, or "empty space", between domain names in a zone, as well as listing the types of RRsets present at existing names. Each NSEC record is signed and authenticated using the mechanisms described in @@ -498,11 +500,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 - - -Arends, et al. Expires June 16, 2004 [Page 9] +Arends, et al. Expires August 16, 2004 [Page 9] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 4. Services Not Provided by DNS Security @@ -520,10 +520,11 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 on cryptographic operations. Please see Section 11 for details. The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above extend no protection to - operations such as zone transfers and dynamic update [RFC3007]. - Message authentication schemes described in [RFC2845] and [RFC2931] - address security operations that pertain to these transactions. + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. @@ -555,17 +556,16 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 - -Arends, et al. Expires June 16, 2004 [Page 10] +Arends, et al. Expires August 16, 2004 [Page 10] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 5. Resolver Considerations A security-aware resolver needs to be able to perform cryptographic functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithms. Security-aware resolvers must + mandatory-to-implement algorithm(s). Security-aware resolvers must also be capable of forming an authentication chain from a newly learned zone back to an authentication key, as described above. This process might require additional queries to intermediate DNS zones to @@ -578,7 +578,7 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 authoritative name servers by a recursive name server or by any sort of device which acts as a proxy for DNS, and if the recursive name server or proxy is not security-aware, the security-aware resolver - may not be able to operate in a secure mode. For example, if a + may not be capable of operating in a secure mode. For example, if a security-aware resolver's packets are routed through a network address translation device that includes a DNS proxy which is not security-aware, the security-aware resolver may find it difficult or @@ -612,9 +612,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 11] +Arends, et al. Expires August 16, 2004 [Page 11] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 6. Stub Resolver Considerations @@ -657,10 +657,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 if, for whatever reason, it is not able to establish a useful trust relationship with the recursive name servers which it uses: it can perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. Upon taking this step, the - resolver is no longer really a stub resolver at all anymore (in the - terminology used in this document set, anyway), and is now a - security-aware resolver with somewhat limited functionality. + Disabled (CD) bit in its query messages. A validating stub resolver + is thus able to treat the DNSSEC signatures as a trust relationship + between the zone administrator and the stub resolver itself. @@ -668,9 +667,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 12] + +Arends, et al. Expires August 16, 2004 [Page 12] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 7. Zone Considerations @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 13] +Arends, et al. Expires August 16, 2004 [Page 13] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 8. Name Server Considerations @@ -735,10 +735,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from resolvers which have signaled their willingness to receive such records via use of the DO bit in the EDNS header, subject to message - size limitations. For this reason a security-aware name server must - support the EDNS mechanism size extension, since otherwise inclusion - of DNSSEC RRs could easily cause UDP message truncation and fallback - to TCP. + size limitations. Since inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. If possible, the private half of each DNSSEC key pair should be kept offline, but this will not be possible for a zone for which DNS @@ -752,10 +752,10 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 DNSSEC, by itself, is not enough to protect the integrity of an entire zone during zone transfer operations, since even a signed zone - contains some unsigned data if the zone has any children, so zone - maintenance operations will require some additional mechanisms (most - likely some form of channel security, such as TSIG, SIG(0), or - IPsec). + contains some unsigned, nonauthoritative data if the zone has any + children, so zone maintenance operations will require some additional + mechanisms (most likely some form of channel security, such as TSIG, + SIG(0), or IPsec). @@ -780,44 +780,15 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 14] +Arends, et al. Expires August 16, 2004 [Page 14] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 9. DNS Security Document Family - The DNSSEC set of documents can be partitioned into five main groups - as depicted in Figure 1. All of these documents are in turn under - the larger umbrella of the DNS base protocol documents. - -9.1 DNS Security Document Roadmap - - +----------------------------------+ - | Base DNS Protocol Documents | - | [RFC1035, RFC2181, et sequentia] | - +----------------------------------+ - | - | - +-----------+ +----------+ - | DNSSEC | | New | - | Protocol |--------->| Security | - | Documents | | Uses | - +-----------+ +----------+ - | - | - +---------------- - - - - - - -+ - | . - | . - +------------------+ . - | Digital | +------------------+ - | Signature | | Transaction | - | Algorithm | | Authentication | - | Implementations | | Implementations | - +------------------+ +------------------+ - - -9.2 Categories of DNS Security Documents + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. The "DNSSEC protocol document set" refers to the three documents which form the core of the DNS security extensions: @@ -830,22 +801,14 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 3. Protocol Modifications for the DNS Security Extensions [I-D.ietf-dnsext-dnssec-protocol] - The "Digital Signature Algorithm Implementations" document set refers + The "Digital Signature Algorithm Specification" document set refers to the group of documents that describe how specific digital signature algorithms should be implemented to fit the DNSSEC resource - - - -Arends, et al. Expires June 16, 2004 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements December 2003 - - record format. Each of these documents deals with a specific digital signature algorithm. - The "Transaction Authentication Implementations" document set refers - to the group of documents that deal with DNS message authentication, + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, including secret key establishment and verification. While not strictly part of the DNSSEC specification as defined in this set of documents, this group is noted to show its relationship to DNSSEC. @@ -873,28 +836,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 16, 2004 [Page 16] +Arends, et al. Expires August 16, 2004 [Page 15] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 10. IANA Considerations @@ -948,9 +892,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 17] +Arends, et al. Expires August 16, 2004 [Page 16] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 11. Security Considerations @@ -963,33 +907,34 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 resource record sets. In order for a security-aware resolver to validate a DNS response, - all of the intermediate zones must be signed, and all of the - intermediate name servers must be security-aware, as defined in this - document set. A security-aware resolver cannot verify responses - originating from an unsigned zone, from a zone not served by a - security-aware name server, or for any DNS data which the resolver is - only able to obtain through a recursive name server which is not - security-aware. If there is a break in the authentication chain such - that a security-aware resolver cannot obtain and validate the - authentication keys it needs, then the security-aware resolver cannot - validate the affected DNS data. + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data which the resolver is only able to obtain through a + recursive name server which is not security-aware. If there is a + break in the authentication chain such that a security-aware resolver + cannot obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. This document briefly discusses other methods of adding security to a DNS query, such as using a channel secured by IPsec or using a DNS transaction authentication mechanism, but transaction security is not part of DNSSEC per se. - A security-aware stub resolver, by definition, does not perform - DNSSEC signature validation on its own, and thus is vulnerable both - to attacks on (and by) the security-aware recursive name servers - which perform these checks on its behalf and also to attacks on its - communication with those security-aware recursive name servers. - Security-aware stub resolvers should use some form of channel - security to defend against the latter threat. The only known defense - against the former threat would be for the security-aware stub - resolver to perform its own signature validation, at which point, - again by definition, it would no longer be a security-aware stub - resolver. + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own, and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers which perform these checks on its behalf and also to + attacks on its communication with those security-aware recursive name + servers. Non-validating security-aware stub resolvers should use some + form of channel security to defend against the latter threat. The + only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. DNSSEC does not protect against denial of service attacks. DNSSEC makes DNS vulnerable to a new class of denial of service attacks @@ -1000,15 +945,15 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 resources in a security-aware resolver's signature validation code by tampering with RRSIG RRs in response messages or by constructing needlessly complex signature chains. An attacker may also be able to - consume resources in a security-aware name server which supports DNS -Arends, et al. Expires June 16, 2004 [Page 18] +Arends, et al. Expires August 16, 2004 [Page 17] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 + consume resources in a security-aware name server which supports DNS dynamic update, by sending a stream of update messages that force the security-aware name server to re-sign some RRsets in the zone more frequently than would otherwise be necessary. @@ -1021,20 +966,24 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 obtain all the names in a zone. While not an attack on the DNS itself, this could allow an attacker to map network hosts or other resources by enumerating the contents of a zone. There are non-DNS - protocol means of limiting this attack such as limiting the number of - NSEC queries from a single host, use of intrusion detection tools, - etc. + protocol means of detecting and limiting this attack beyond the scope + of this document set. DNSSEC introduces significant additional complexity to the DNS, and thus introduces many new opportunities for implementation bugs and - misconfigured zones. + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. DNSSEC does not provide confidentiality, due to a deliberate design choice. DNSSEC does not protect against tampering with unsigned zone data. Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. Thus, while DNSSEC can provide data origin + zone) are not signed. This does not pose a problem when validating + the authentication chain, but does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin authentication and data integrity for RRsets, it cannot do so for zones, and other mechanisms must be used to protect zone transfer operations. @@ -1055,14 +1004,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 - - - - - -Arends, et al. Expires June 16, 2004 [Page 19] +Arends, et al. Expires August 16, 2004 [Page 18] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 12. Acknowledgements @@ -1116,9 +1060,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 20] +Arends, et al. Expires August 16, 2004 [Page 19] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 Normative References @@ -1147,14 +1091,14 @@ Normative References [I-D.ietf-dnsext-dnssec-records] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-05 (work in progress), - October 2003. + draft-ietf-dnsext-dnssec-records-07 (work in progress), + February 2004. [I-D.ietf-dnsext-dnssec-protocol] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-03 (work in - progress), October 2003. + Extensions", draft-ietf-dnsext-dnssec-protocol-05 (work in + progress), February 2004. @@ -1172,9 +1116,9 @@ Normative References -Arends, et al. Expires June 16, 2004 [Page 21] +Arends, et al. Expires August 16, 2004 [Page 20] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 Informative References @@ -1211,38 +1155,35 @@ Informative References [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + [I-D.ietf-dnsext-dns-threats] Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-04 (work in - progress), October 2003. - - [I-D.ietf-dnsext-ad-is-secure] - Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD - bit", draft-ietf-dnsext-ad-is-secure-06 (work in - progress), June 2002. - - [I-D.ietf-dnsext-delegation-signer] - Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), - June 2003. - - - -Arends, et al. Expires June 16, 2004 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements December 2003 - + Name System", draft-ietf-dnsext-dns-threats-05 (work in + progress), November 2003. [I-D.ietf-dnsext-dnssec-2535typecode-change] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 - (work in progress), October 2003. + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 + + + +Arends, et al. Expires August 16, 2004 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + (work in progress), December 2003. [I-D.ietf-dnsext-keyrr-key-signing-flag] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure Entry Point Flag", - draft-ietf-dnsext-keyrr-key-signing-flag-11 (work in - progress), October 2003. + draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in + progress), December 2003. Authors' Addresses @@ -1257,9 +1198,9 @@ Authors' Addresses Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 USA EMail: sra@isc.org @@ -1284,9 +1225,12 @@ Authors' Addresses -Arends, et al. Expires June 16, 2004 [Page 23] + + + +Arends, et al. Expires August 16, 2004 [Page 22] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 Scott Rose @@ -1340,9 +1284,9 @@ Internet-Draft DNSSEC Introduction and Requirements December 2003 -Arends, et al. Expires June 16, 2004 [Page 24] +Arends, et al. Expires August 16, 2004 [Page 23] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 Intellectual Property Statement @@ -1370,7 +1314,7 @@ Intellectual Property Statement Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it @@ -1396,9 +1340,9 @@ Full Copyright Statement -Arends, et al. Expires June 16, 2004 [Page 25] +Arends, et al. Expires August 16, 2004 [Page 24] -Internet-Draft DNSSEC Introduction and Requirements December 2003 +Internet-Draft DNSSEC Introduction and Requirements February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -1452,6 +1396,6 @@ Acknowledgement -Arends, et al. Expires June 16, 2004 [Page 26] +Arends, et al. Expires August 16, 2004 [Page 25] diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt new file mode 100644 index 0000000000..2d5c87eb3c --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +IPv6 Working Group John Loughney (ed) +Internet-Draft Nokia + January 14, 2004 + +Expires: July 14, 2004 + + + + IPv6 Node Requirements + draft-ietf-ipv6-node-requirements-08.txt + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + + + + + +Loughney (editor) February 16, 2004 [Page 1] + + + + + +Internet-Draft + + +Table of Contents + + 1. Introduction + 1.1 Requirement Language + 1.2 Scope of this Document + 1.3 Description of IPv6 Nodes + 2. Abbreviations Used in This Document + 3. Sub-IP Layer + 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + 3.2 IP version 6 over PPP - RFC2472 + 3.3 IPv6 over ATM Networks - RFC2492 + 4. IP Layer + 4.1 Internet Protocol Version 6 - RFC2460 + 4.2 Neighbor Discovery for IPv6 - RFC2461 + 4.3 Path MTU Discovery & Packet Size + 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + 4.5 Addressing + 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + 5. Transport and DNS + 5.1 Transport Layer + 5.2 DNS + 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + 6. IPv4 Support and Transition + 6.1 Transition Mechanisms + 7. Mobility + 8. Security + 8.1 Basic Architecture + 8.2 Security Protocols + 8.3 Transforms and Algorithms + 8.4 Key Management Methods + 9. Router Functionality + 9.1 General + 10. Network Management + 10.1 MIBs + 11. Security Considerations + 12. References + 12.1 Normative + 12.2 Non-Normative + 13. Authors and Acknowledgements + 14. Editor's Address + Notices + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 2] + + + + + +Internet-Draft + + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but all IPv6 nodes can be + expected to implement the mandatory requirements listed in this + document. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. In case of any conflicting text, + this document takes less precedence than the normative RFCs, unless + additional clarifying text is included in this document. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + +1.1 Requirement Language + + 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 RFC 2119 [RFC-2119]. + +1.2 Scope of this Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes, in order + to ensure interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3 Description of IPv6 Nodes + + From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we + have the following definitions: + + Description of an IPv6 Node + + + + +Loughney (editor) February 16, 2004 [Page 3] + + + + + +Internet-Draft + + + - a device that implements IPv6 + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed to + itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + + +Loughney (editor) February 16, 2004 [Page 4] + + + + + +Internet-Draft + + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2 IP version 6 over PPP - RFC2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- + 2472]. + +3.3 IPv6 over ATM Networks - RFC2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1 Internet Protocol Version 6 - RFC2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receving IPv6 packets; forwarding functionality MAY be + supported + + RFC 2460 specifies extension headers and the processing for these + headers. + + + +Loughney (editor) February 16, 2004 [Page 5] + + + + + +Internet-Draft + + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload. [RFC-2460] + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] caused by them. + +4.2 Neighbor Discovery for IPv6 - RFC2461 + + Neighbor Discovery SHOULD be supported. RFC 2461 states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e. send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + + + +Loughney (editor) February 16, 2004 [Page 6] + + + + + +Internet-Draft + + + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are required + for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3 Path MTU Discovery & Packet Size + +4.3.1 Path MTU Discovery - RFC1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2 IPv6 Jumbograms - RFC2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + +4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5 Addressing + +4.5.1 IP Version 6 Addressing Architecture - RFC3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported. + +4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + + + +Loughney (editor) February 16, 2004 [Page 7] + + + + + +Internet-Draft + + + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4 Default Address Selection for IPv6 - RFC3484 + + The rules specified in the Default Address Selection for IPv6 [RFC- + 3484] document MUST be implemented. It is expected that IPv6 nodes + will need to deal with multiple addresses. + +4.5.5 Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- + 3315] is the standard stateful address configuration protocol; see + section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses aside from link-local addresses + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and which contains no prefixes advertised + for Stateless Address Autoconfiguration (see section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information such as the addresses of DNS servers when it is connected + to a link over which the node receives a router advertisement in + which the 'O' flag ("Other stateful configuration") is set. + +4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [MLDv2]. However, if the node has applications, which only need + support for Any- Source Multicast [RFC3569], the node MAY implement + MLDv1 [MLDv1] instead. If the node has applications, which need + support for Source- Specific Multicast [RFC3569, SSMARCH], the node + MUST support MLDv2 [MLDv2]. + + + + +Loughney (editor) February 16, 2004 [Page 8] + + + + + +Internet-Draft + + + When MLD is used, the rules in "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. Transport Layer and DNS + +5.1 Transport Layer + +5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 + + This specification MUST be supported if jumbograms are implemented + [RFC- 2675]. + +5.2 DNS + + DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] + and [RFC-3596] MAY be supported. Not all nodes will need to resolve + names. All nodes that need to resolve names SHOULD implement stub- + resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with + support for: + + - AAAA type Resource Records [RFC-3596]; + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extentions + [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 + + RFC 2732 MUST be supported if applications on the node use URL's. + +5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 + +5.3.1 Managed Address Configuration + + Those IPv6 Nodes that use DHCP for address assignment initiate DHCP + to obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set, as described + in section 5.5.3 of RFC 2462. In addition, in the absence of a + router, those IPv6 Nodes that use DHCP for address assignment MUST + initiate DHCP to obtain IPv6 addresses and other configuration + information, as described in section 5.5.2 of RFC 2462. Those IPv6 + nodes that do not use DHCP for address assignment can ignore the 'M' + + + +Loughney (editor) February 16, 2004 [Page 9] + + + + + +Internet-Draft + + + flag in Router Advertisements. + +5.3.2 Other Configuration Information + + Those IPv6 Nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to + obtain other configuration information. + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1 Transition Mechanisms + +6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 + + If an IPv6 node implements dual stack and tunneling, then RFC2893 + MUST be supported. + + RFC 2893 is currently being updated. + +7. Mobile IP + + The Mobile IPv6 [MIPv6] specification defines requirements for the + following types of nodes: + + - mobile nodes + - correspondent nodes with support for route optimization + - home agents + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [MIPv6], including support of generic packet tunneling [RFC-2473] + and secure home agent communications [MIPv6-HASEC]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [MIPv6]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY + support the home agent functionality described in Section 8.4 of + [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. + + + +Loughney (editor) February 16, 2004 [Page 10] + + + + + +Internet-Draft + + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1 Basic Architecture + + Security Architecture for the Internet Protocol [RFC-2401] MUST be + supported. RFC-2401 is being updated by the IPsec Working Group. + +8.2 Security Protocols + + ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. + RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. + + +8.3 Transforms and Algorithms + + Current IPsec RFCs specify the support of certain transforms and + algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. + The requirements for these are discussed first, and then additional + algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. + + NULL encryption algorithm [RFC-2410] MUST be supported for providing + integrity service and also for debugging use. + + The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD + NOT be supported. Security issues related to the use of DES are + discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as + required by the existing IPsec RFCs, but as it is currently viewed as + an inherently weak algorithm, and no longer fulfills its intended + role. + + The NULL authentication algorithm [RFC-2406] MUST be supported within + ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- + 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, + described in [RFC-2403] MUST be supported. An implementer MUST refer + to Keyed- Hashing for Message Authentication [RFC-2104]. + + 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC + and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- + CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected + to be a widely available, secure algorithm that is required for + interoperability. It is not required by the current IPsec RFCs, but + is expected to become required in the future. + + In addition to the above requirements, "Cryptographic Algorithm + Implementation Requirements For ESP And AH" [CRYPTREQ] contains the + current set of mandatory to implement algorithms for ESP and AH as + + + +Loughney (editor) February 16, 2004 [Page 11] + + + + + +Internet-Draft + + + well as specifying algorithms that should be implemented because they + may be promoted to mandatory at some future time. It is RECOMMENDED + that IPv6 nodes conform to the requirements in this document. + +8.4 Key Management Methods + + Manual keying MUST be supported. + + IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast + traffic. Where key refresh, anti-replay features of AH and ESP, or + on- demand creation of Security Associations (SAs) is required, + automated keying MUST be supported. Note that the IPsec WG is working + on the successor to IKE [IKE2]. Key management methods for multicast + traffic are also being worked on by the MSEC WG. + + "Cryptographic Algorithms for use in the Internet Key Exchange + Version 2" [IKEv2ALGO] defines the current set of mandatory to + implement algorithms for use of IKEv2 as well as specifying + algorithms that should be implemented because they made be promoted + to mandatory at some future time. It is RECOMMENDED that IPv6 nodes + implementing IKEv2 conform to the requirements in this + document. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1 General + +9.1.1 IPv6 Router Alert Option - RFC2711 + + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2 Neighbor Discovery for IPv6 - RFC2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + + + +Loughney (editor) February 16, 2004 [Page 12] + + + + + +Internet-Draft + + + nodes that are embedded devices, network management may be the only + possibility to control these nodes. + +10.1 Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + +10.1.1 IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes + that support an SNMP agent. + +10.1.2 Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an + SNMP agent. + +11. Security Considerations + + This draft does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC2460 describe the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + +12. References + +12.1 Normative + + [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- + tion Requirements For ESP And AH", draft-ietf-ipsec- + esp-ah-algorithms-01.txt, January 2004. + + [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the + Internet Key Exchange Version 2", draft-ietf-ipsec- + ikev2-algorithms-04.txt, Work in Progress. + + [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 + Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, + Work in Progress. + + [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support + in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 13] + + + + + +Internet-Draft + + + progress. + + [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec + to Protect Mobile IPv6 Signaling between Mobile Nodes + and Home Agents", draft-ietf- mobileip-mipv6-ha- + ipsec-06.txt, Work in Progress. + + [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version + 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in + Progress. + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table + MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in + Progress. + + [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the + Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- + update-07.txt, Work in progress. + + [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication + Header", RFC 2402, November 1998. + + [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within + ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 + within ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security + + + +Loughney (editor) February 16, 2004 [Page 14] + + + + + +Internet-Draft + + + Protocol (ESP)", RFC 2406, November 1998. + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, + J., "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- + sion 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address + Autoconfiguration", RFC 2462. + + [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- + tocol Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. Xxx + add + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert + Option", RFC 2711, October 1999. + + + + +Loughney (editor) February 16, 2004 [Page 15] + + + + + +Internet-Draft + + + [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August + 2001. + + [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- + sion 6 (IPv6) Addresses in the Domain Name System + (DNS)", RFC 3363, August 2002. + + [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC + 3484, February 2003. + + [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the Multi- + cast Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP + version 6", RFC 3596, October 2003. + + [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. + +12.2 Non-Normative + + [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", + draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in + Progress. + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, Jan + 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- + vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 16] + + + + + +Internet-Draft + + + Progress. + + [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "DNS Security Introduction and Requirements" draft- + ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. + + [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- + gress. + + [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Protocol Modifications for the DNS Security Exten- + sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work + in Progress. + + [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- + col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", draft-savola-ipv6-rh-ha-security- + 03.txt, Work in Progress, March 2002. + + [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- + rity Threats and Counter-Measures; In Proceedings "Sympo- + sium on Network and Distributed System Security", Febru- + ary 1995, pp.2-16. + + [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, + August 1980. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- + ties", RFC 1034, November 1987. + + [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, + May 1997. + + [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and + S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC + 2205, September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2462, December 1998. + + [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over + ATM Networks", RFC 2492, January 1999. + + [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 + + + +Loughney (editor) February 16, 2004 [Page 17] + + + + + +Internet-Draft + + + Jumbograms", RFC 2675, August 1999. + + [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal + IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, + "Textual Conventions for Internet Network Addresses", RFC + 2851, June 2000. + + [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", + draft-ietf- ssm-arch-03.txt, Work in Progress. + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + + +Loughney (editor) February 16, 2004 [Page 18] + + + + + +Internet-Draft + + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- + penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, + Juha Ollila and Pekka Savola for their comments. + +14. Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + Email: John.Loughney@Nokia.com + +Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain 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; neither does it represent that it has made + any effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and standards- + related documentation can be found in BCP-11. Copies of claims of + rights made available for publication 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 implementors or users of this specification can be obtained from + the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + + + +Loughney (editor) February 16, 2004 [Page 19] + + + + + +Internet-Draft + + + rights, which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 20] + +