diff --git a/contrib/queryperf/utils/gen-data-queryperf.py b/contrib/queryperf/utils/gen-data-queryperf.py new file mode 100644 index 0000000000..b164025a06 --- /dev/null +++ b/contrib/queryperf/utils/gen-data-queryperf.py @@ -0,0 +1,100 @@ +#!/usr/bin/python + +# +# $Id: gen-data-queryperf.py,v 1.1 2003/04/10 02:33:40 marka Exp $ +# +# Contributed by Stephane Bortzmeyer +# +# "A small tool which may be useful with contrib/queryperf. This script +# can generate files of queries, both with random names (to test the +# behaviour with NXdomain) and with domains from a real zone file." +# + +import sys +import getopt +import random +import re + +ldh = [] +# Letters +for i in range(97, 122): + ldh.append(chr(i)) +# Digits +for i in range(48, 57): + ldh.append(chr(i)) +# Hyphen +ldh.append('-') + +maxsize=10 +tld='org' +num=4 +percent_random = 0.3 +gen = None +zone_file = None +domains = {} +domain_ns = "^([a-z0-9-]+)(\.([a-z0-9-\.]+|)|)( +IN|) +NS" +domain_ns_re = re.compile(domain_ns, re.IGNORECASE) + +def gen_random_label(): + label = "" + for i in range(gen.randint(1, maxsize)): + label = label + gen.choice(ldh) + return label + +def make_domain(label): + return "www." + label + "." + tld + " A" + +def usage(): + sys.stdout.write("Usage: " + sys.argv[0] + " [-n number] " + \ + "[-p percent-random] [-t TLD]\n") + sys.stdout.write(" [-m MAXSIZE] [-f zone-file]\n") + +try: + optlist, args = getopt.getopt(sys.argv[1:], "hp:f:n:t:m:", + ["help", "percentrandom=", "zonefile=", + "num=", "tld=", + "maxsize="]) + for option, value in optlist: + if option == "--help" or option == "-h": + usage() + sys.exit(0) + elif option == "--number" or option == "-n": + num = int(value) + elif option == "--maxsize" or option == "-m": + maxsize = int(value) + elif option == "--percentrandom" or option == "-p": + percent_random = float(value) + elif option == "--tld" or option == "-t": + tld = str(value) + elif option == "--zonefile" or option == "-f": + zone_file = str(value) + else: + error("Unknown option " + option) +except getopt.error, reason: + sys.stderr.write(sys.argv[0] + ": " + str(reason) + "\n") + usage() + sys.exit(1) + +if len(args) <> 0: + usage() + sys.exit(1) + +gen = random.Random() +if zone_file: + file = open(zone_file) + line = file.readline() + while line: + domain_line = domain_ns_re.match(line) + if domain_line: + domain = domain_line.group(1) + domains[domain] = 1 + line = file.readline() + file.close() +for i in range(num): + if zone_file: + if gen.random() < percent_random: + print make_domain(gen_random_label()) + else: + print make_domain(gen.choice(domains.keys())) + else: + print make_domain(gen_random_label()) diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-00.txt b/doc/draft/draft-baba-dnsext-acl-reqts-00.txt new file mode 100644 index 0000000000..950e34c751 --- /dev/null +++ b/doc/draft/draft-baba-dnsext-acl-reqts-00.txt @@ -0,0 +1,336 @@ + + + + +Internet-Draft T. Baba +Expires: August 4, 2003 NTT Data + February 4, 2003 + + + Requirements for Access Control in Domain Name Systems + draft-baba-dnsext-acl-reqts-00.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Distribution of this memo is unlimited. + + This Internet-Draft will expire on August 4, 2003. + +Abstract + + This document describes the requirements for access control + mechanisms in the Domain Name System (DNS), which authenticate + clients and then allow or deny access to resource records in the + zone according to the access control list (ACL). + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for bi-directional mapping between domain + names and IP addresses, for email routing, and for other information + [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined + to authenticate the data in DNS and provide key distribution services + using SIG, KEY, and NXT resource records (RRs) [RFC2535]. + + + +Baba Expires August 4, 2003 [Page 1] + +Internet-Draft DNS Access Control Requirements February 2003 + + + At the 28th IETF Meeting in Houston in 1993, DNS security design team + started a discussion about DNSSEC and agreed to accept the assumption + that "DNS data is public". Accordingly, confidentiality for queries + or responses is not provided by DNSSEC, nor are any sort of access + control lists or other means to differentiate inquirers. However, + about ten years has passed, access control in DNS has been more + important than before. With DNS access control mechanism, access + from unauthorized clients can be blocked when they perform DNS name + resolution. Thus, for example, Denial of Service (DoS) attacks + against a server used by a closed user group can be prevented using + this mechanism if IP address of the server is not revealed by other + sources. + + This document describes the requirements for access control + mechanisms in DNS. + +2. Terminology + + AC-aware client + This is the client that understands the DNS access control + extensions. This client may be an end host which has a stub + resolver, or a cashing/recursive name server which has a + full-service resolver. + + AC-aware server + This is the authoritative name server that understands the DNS + access control extensions. + + ACE + An Access Control Entry. This is the smallest unit of access + control policy. It grants or denies a given set of access + rights to a set of principals. An ACE is a component of an ACL, + which is associated with a resource. + + ACL + An Access Control List. This contains all of the access control + policies which are directly associated with a particular + resource. These policies are expressed as ACEs. + + Client + A program or host which issues DNS requests and accepts its + responses. A client may be an end host or a cashing/recursive name + server. + + RRset + All resource records (RRs) having the same NAME, CLASS and TYPE + are called a Resource Record Set (RRset). + + + + +Baba Expires August 4, 2003 [Page 2] + +Internet-Draft DNS Access Control Requirements February 2003 + + +3. Requirements + + This section describes the requirements for access control in DNS. + +3.1 Authentication + +3.1.1 Client Identifier / Authentication Mechanism + + The AC-aware server must identify AC-aware clients based on IP + address and/or domain name (user ID or host name), and must + authenticate them using strong authentication mechanism such as + digital signature or message authentication code (MAC). + + SIG(0) RR [RFC2931] contains a domain name associated with sender's + public key in its signer's name field, and TSIG RR [RFC2845] also + contains a domain name associated with shared secret key in its key + name field. Each of these domain names can be a host name or a user + name, and can be used as a sender's identifier for access control. + Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for + message authentication. These mechanisms can be used to authenticate + AC-aware clients. + + Server authentication may be also provided. + +3.1.2 End-to-End Authentication + + In current DNS model, caching/recursive name servers are deployed + between end hosts and authoritative name servers. Although + authoritative servers can authenticate caching/recursive name servers + using SIG(0) or TSIG, they cannot authenticate end hosts behind them. + For end-to-end authentication, the mechanism for an end host to + discover the target authoritative name server and directly access to + it bypassing caching/recursive name servers is needed. For example, + an end host can get the IP addresses of the authoritative name + servers by retrieving NS RRs for the zone via local caching/recursive + name server. + +3.1.3 Authentication Key Retrieval + + Keys which are used to authenticate clients should be able to be + automatically retrieved. The KEY RR is used to store a public key + for a zone or a host that is associated with a domain name. SIG(0) + RR uses a public key in KEY RR for verifying the signature. If + DNSSEC is available, the KEY RR would be protected by the SIG RR. + KEY RR or newly defined RR can be used to automatic key retrieval. + + + + + + +Baba Expires August 4, 2003 [Page 3] + +Internet-Draft DNS Access Control Requirements February 2003 + + +3.2 Confidentiality + +3.2.1 Data Encryption + + To avoid disclosure to eavesdroppers, the response containing the + RRsets which are restricted to access from particular users should be + encrypted. Although IPsec can be used to encrypt DNS packets, it + authenticates a peer based on IP address. Currently, no encryption + mechanism is specified in DNS. Therefore, new RRs must be defined + for DNS message encryption. In case encryption is applied, entire + DNS message including DNS header must be encrypted to hide + information including error code. + + Query encryption may be also provided. + +3.2.2 Key Exchange + + If DNS message encryption is provided, automatic key exchange + mechanism must be also provided. [RFC2930] specifies a TKEY RR that + can be used to establish and delete shared secret keys used by TSIG + between a client and a server. With minor extensions, TKEY can be + used to establish shared secret keys used for message encryption. + +3.2.3 Caching + + The RRset that is restricted to access from particular users must not + be cached. To avoid caching, the TTL of the RR that is restricted to + access should be set to zero during transit. + +3.3 Access Control + +3.3.1 Granularity of Access Control + + Control of access on a per-user/per-host granularity must be + supported. Control of access to individual RRset (not just the + entire zone) must be also supported. However, SOA, NS, SIG, NXT, + KEY, and DS RRs must be publicly accessible to avoid unexpected + results. + + + + + + + + + + + + + +Baba Expires August 4, 2003 [Page 4] + +Internet-Draft DNS Access Control Requirements February 2003 + + +3.3.2 ACL Representation + + Access Control List (ACL) format must be standardized so that both + the primary and secondary AC-aware servers can recognize the same + ACL. Although ACL may appear in or out of zone data, it must be + transferred to the secondary AC-aware server with associated zone + data. It is a good idea to contain ACL in zone data, because ACL can + be transferred with zone data using existing zone transfer mechanisms + automatically. However, ACL must not be published except for + authorized secondary master servers. + + In zone data master files, ACL should be specified using TXT RRs or + newly defined RRs. In each access control entry (ACE), authorized + entities (host or user) must be described using domain name (host + name, user name, or IP address in in-addr.arpa/ip6.arpa format). + There may be other access control attributes such as access time. + + It must be possible to create publicly readable entries, which may be + read even by unauthenticated clients. + +3.3.3 Zone/ACL Transfer + + As mentioned above, ACL should be transferred from a primary AC-aware + server to a secondary AC-aware server with associated zone data. + When an AC-aware server receives a zone/ACL transfer request, the + server must authenticate the client, and should encrypt the zone + data and associated ACL during transfer. + +3.4 Backward/co-existence Compatibility + + Any new protocols to be defined for access control in DNS must be + backward compatible with existing DNS protocol. AC-aware servers + must be able to process normal DNS query without authentication, and + must respond if retrieving RRset is publicly accessible. + + Modifications to root/gTLD/ccTLD name servers are not allowed. + +4. Security Considerations + + This document discusses the requirements for access control + mechanisms in DNS. + +5. Acknowledgements + + This work is funded by the Telecommunications Advancement + Organization of Japan (TAO). + + The author would like to thank the members of the NTT DATA network + security team for their important contribution to this work. + + +Baba Expires August 4, 2003 [Page 5] + +Internet-Draft DNS Access Control Requirements February 2003 + + +6. References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + +Author's Address + + Tatsuya Baba + NTT Data Corporation + Research and Development Headquarters + Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku, + Tokyo 104-0033, Japan + + Tel: +81 3 3523 8081 + Fax: +81 3 3523 8090 + Email: babatt@nttdata.co.jp + + + + + + + + + + + + + + + + + + +Baba Expires August 4, 2003 [Page 6] diff --git a/doc/draft/draft-dnsext-opcode-discover-01.txt b/doc/draft/draft-dnsext-opcode-discover-01.txt new file mode 100644 index 0000000000..b4af79091c --- /dev/null +++ b/doc/draft/draft-dnsext-opcode-discover-01.txt @@ -0,0 +1,246 @@ + +IETF DNSEXT WG Bill Manning +draft-dnsext-opcode-discover-01.txt ISI + Paul Vixie + ISC + Erik Guttman + SUN + 21 Dec 2002 + + + The DISCOVER opcode + +This document is an Internet-Draft and is subject to all provisions of +Section 10 of RFC2026. + +Comments may be submitted to the group mailing list at "mdns@zocalo.net" +or the authors. + +Distribution of this memo is unlimited. + +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. + +The capitalized keywords "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 + +0. Abstract: + + The QUERY opcode in the DNS is designed for unicast. With the + development of multicast capabilities in the DNS, it is desireable + to have a more robust opcode for server interactions since a single + request may result in replies from multiple responders. So DISCOVER + is defined to deal with replies from multiple responders. + + As such, this document extend the core DNS specifications to allow + clients to have a method for coping with replies from multiple + responders. Use of this new opcode may facilitate DNS operations in + modern networking topologies. A prototype of the DISCOVER opcode + was developed as part of the TBDS project, funded under DARPA grant + F30602-99-1-0523. + +1. Introduction: + + This document describes an experimental extension to the DNS to receive + multiple responses which is the likely result when using DNS that has + enabled multicast queries. This approach was developed as part of the + TBDS research project, funded under DARPA grant F30602-99-1-0523. The + full processing rules used by TBDS are documented here for possible + incorporation in a future revision of the DNS specification." + +2. Method: + + DISCOVER works like QUERY except: + + 1. it can be sent to a broadcast or multicast destination QUERY + isn't defined for non-unicast, and arguably shouldn't be. + + 2. the Question section, if present, has + tuples. Our testing tried to augment this structure as follows: + . While this worked for our purposes in + TBDS, it is cleaner to place the SRV question in a separate pass. + + 3. if QDCOUNT==0 then only servers willing to do recursion should + answer. Other servers must silently discard the DISCOVER request. + + 4. if QDCOUNT!=0 then only servers who are authoritative for the + zones named by some QNAME should answer. + + 5. responses may echo the request's Question section or leave it blank, + just like QUERY. + + 6. responses have "normal" Answer, Authority, and Additional sections. + e.g. the response is the same as that to a QUERY. It is desireable + that zero content answers not be sent to avoid badly formed or + unfulfilled requests. Responses should be sent to the unicast + address of the requester and the source address should reflect + the unicast address of the responder. + + Example usage for gethostby{name,addr}-style requestors: + + Compute the zone name of the enclosing in-addr.arpa, ip6.int, or + ip6.arpa domain. + + DISCOVER whether anyone in-scope is authoritative for this zone. + + If so, query these authoritative servers for local + in-addr/ip6 names. + + If not, DISCOVER whether there are recursive servers available. + + If so, query these recursive servers for local + in-addr/ip6 names. + + So, a node will issue a multicast request with the DISCOVER opcode at + some particular multicast scope. Then determine, from the replies, + whether there are any DNS servers which are authoritative (or support + recursion) for the zone. Replies to DISCOVER requests MUST set the + Recursion Available (RA) flag in the DNS message header. + + It is important to recognize that a requester must be prepared to + receive multiple replies from multiple responders. + + Once one learns a host's FQDN by the above means, repeat the process + for discovering the closest enclosing authoritative server of such + local name. + + Cache all NS and A data learned in this process, respecting TTL's. + + TBDS usage for SRV requestors: + + Do the gethostbyaddr() and gethostbyname() on one's own link-local + address, using the above process. + + Assume that the closest enclosing zone for which an authority server + answers an in-scope DISCOVER packet is "this host's parent domain". + + Compute the SRV name as _service._transport.*.parentdomain. + + This is a change to the definition as defined in RFC 1034. + A wildcard label ("*") in the QNAME used in a DNS message with + opcode DISCOVER SHOULD be evaluated with special rules. The + wildcard matches any label for which the DNS server data is + authoritative. For example 'x.*.example.com.' would match + 'x.y.example.com.' and 'x.yy.example.com.' provided that the + server was authoritative for 'example.com.' In this particular + case, we suggest the follwing considerations be made: + + getservbyname() can be satisfied by issuing a request with + this computed SRV name. The servent structure can be + populated by values returned from a request as follows: + + s_name The name of the service, "_service" without the + preceding underscore. + s_aliases The names returned in the SRV RRs in replies + to the query. + s_port The port number in the SRV RRs replies to the + query. If these port numbers disagree - one + of the port numbers is chosen, and only those + names which correspond are returned. + s_proto The transport protocol from named by the + "_transport" label, without the preceding + underscore. + + Send SRV query for this name to discovered local authority servers. + + Usage for disconnected networks with no authority servers: + + Hosts should run a "stub server" which acts as though its FQDN is a + zone name. Computed SOA gives the host's FQDN as MNAME, "." as the + ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE + and the other timers. Computed NS gives the host's FQDN. Computed + glue gives the host's link-local address. Or Hosts may run a + "DNS stub server" which acts as though its FQDN is a zone name. The + rules governing the behavior of this stub server are given elsewhere + [1] [2]. + + Such stub servers should answer DISCOVER packets for its zone, and + will be found by the iterative "discover closest enclosing authority + server" by DISCOVER clients, either in the gethostbyname() or SRV + cases described above. Note that stub servers only answer with + zone names which match QNAME's, not with zone names which are owned + by QNAME's. + + The only deviation from the DNS[3][4] model is that a host (like, say, a + printer offering LPD services) has a DNS server which answers authoritatively + for something which hasn't been delegated to it. However, the only way that + such DNS servers can be discovered is with a new opcode, DISCOVER, which + is explicitly defined to discover undelegated zones for tightly scoped + purposes. Therefore this isn't officially a violation of DNS's coherency + principles. In some cases, a responder to DISCOVER, may not be traditional + DNS software, it could be special purpose software. + +3. IANA Considerations + + As a new opcode, the IANA will need to assign a numeric value + for the memnonic. The last OPCODE assigned was "5", for UPDATE. + Test implementations have used OPCODE "6". + +4. Security Considerations + + No new security considerations are known to be introduced with a new + opcode, however using multicast for service discovery has the potential + for denial of service, primarly from flooding attacks. It may also be + possible to enable deliberate misconfiguration of clients simply by + running a malicious DNS resolver that claims to be authoritative for + things that it is not. One possible way to mitigate this effect is by + use of credentials, such as CERT resource records within an RR set. + The TBDS project took this approach. + +5. Attribution: + + This material was generated in discussions on the mdns mailing list +hosted by Zocalo in March 2000. Paul Vixie, Stuart Cheshire, Bill Woodcock, +Erik Guttman and Bill Manning were active contributors. + +6. Author's Address + + Bill Manning + PO 12317 + Marina del Rey, CA. 90295 + +1.310.322.8102 + bmanning@karoshi.com + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + + Erik Guttman + Sun Microsystems + Eichh\367lzelstr. 7 + 74915 Waibstadt Germany + +49 6227 356 202 + erik.guttman@sun.com + +7. References + +Informational References: + +[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", + draft-ietf-dnsext-mdns-00.txt, November 2000. Expired + +[2] Woodcock, B., Manning, B., "Multicast Domain Name Service", + draft-manning-dnsext-mdns-00.txt, August 2000. Expired. + +Normative References: +[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + RFC 1034, November 1987. +[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", + RFC 1035, November 1987 + diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt new file mode 100644 index 0000000000..224e7ad169 --- /dev/null +++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt @@ -0,0 +1,240 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems +Feb 21, 2003 +Expires Aug 2, 2003 + + + + Dynamic reverse DNS for IPv6 + + + + +Status of this memo + + + This memo provides information to the Internet community. It does + not specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 [RFC2026]. + + 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. + + + +Abstract + + This document describes a method to dynamically generate PTR records + and corresponding A or AAAA records when the reverse path DNS tree is + not populated. + + A special domain dynrev.arpa. is reserved for that purpose. + + +1. Introduction + + In IPv4, the reverse path tree of the DNS under in-addr.arpa. + although not perfectly maintained, is still mostly usable and its + existence is important for a number of applications that relies on + its existence and decent status. Some applications performs some + (very) weak security checks based on it. Mail relays relies on it for + some anti-spams checks an some FTP server will not let you in unless + your IP address resolve properly with a PTR record. + + IPv6 addresses being much longer (and cumbersome) than IPv4 + addresses, it is to fear that the reverse path tree under ip6.arpa. + would not be as well maintained. Also, tools like 6to4, Isatap and + others have made creative use of the 128 bits of an IPv6 address to + automatically embed an IPv4 address to enable seamless connection to + the IPv6 Internet. However, no provision has been made to make sure + the reverse path tree gets automatically updated as well for those + new IPv6 addresses. One step furter, RFC3041 describes a mechanism + to basically use random bits in the bottom part of an IPv6 address to + preserver anonymity. If those addresses are to resolve in the reverse + path tree, it obviously has to be with anonymous data as well. + Another point to note is that home customer ISPs in IPv4 have a + current practice to pre-populate the reverse path tree with names + automatically derived from the IP addresses. This practice is no + longer possible in IPv6, where IP address allocation is not dense as + it is the case in IPv4. The mere size of typical customer allocation + (2^48 according to the recommendation of RFC3177) makes it + impossible. + + Applications that check the existence of PTR records usually follow + this by checking if the name pointed by the PTR resolve in a A (or + AAAA for IPv6) that match the original IP address. Thus the forward + path tree must also include the corresponding data. + + One simple approach of this problem is to simply declare the usage of + the reverse path DNS as described above obsolete. The author believe + this is too strong an approach for now. + + Similarly, a completely different approach would be to deprecate the + usage of DNS for the reverse tree altogether and replace it by + something inspired from ICMP name-info messages. The author believes + that this approached is an important departure from the current + practise and thus not very realistic. Also, there are some concerns + about the the security implications of this method as any node could + easily impersonate any name. This approach would fundamentally change + the underlying assumption of "I trust what has been put in the DNS by + the local administrators" to "I trust what has been configured on + each machine I query directly". + + + +2. Dynamic record generation + + If static pre-population of the tree is not possible anymore and data + still need to be returned to applications using getnameinfo(), the + alternative is dynamic record generation. This can be done is two + places: in the DNS servers responsible for the allocated space (/64 + or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the + sub resolver library or the recursive DNS server). + + 2.1. On the resolver side. + + The resolver, either in the recursive DNS server or in the stub + library could theoretically generate this data. + + In case DNSsec is in place, the recursive DNS server would have to + pretend these records are authentic. + + If the synthesis is done in the stub-resolver library, no record + needs to be actually generated, only the right information needs to + be passed to getnameinfo() and getaddrinfo(). If the synthesis is + done in the recursive DNS server, no modification is required to + existing stub resolvers. + + +2.2. On the server side. + + PTR records could be generated automatically by the server + responsible for the reverse path tree of an IPv6 prefix (a /64 or /48 + prefixes or basically anything in between) when static data is not + available. + + There could be impact on DNSsec as the zone or some parts of the zone + may need to be resigned each time a DNS query is made for an + unpopulated address. This can be seen as a DOS attack on a DNSsec + zone, so server side synthesis is not recommended if DNSsec is + deployed. + + + +3. Synthesis + + The algorithm is simple: Do the normal queries. If the query returns + No such domain, replace this answer by the synthetized one if + possible. + +3.1. PTR synthesis + + The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa. + where [X] is any valid DNS name. + + The fact that the synthetized PTR points to the dynrev.arpa. domain + is an indication to the applications that this record has been + dynamically generated. + + +3.2. A synthesis + + If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A + record for the string [X].dynrev.arpa. which value is d.c.b.a. with + a,b,c & d being integer [0..255] + + +3.3. AAAA synthesis + + If [X] is in the form + a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in- + addr.arpa, one can synthetized a AAAA record for the string + [X].dynrev.arpa. which value is + FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with + a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits. + + +3.4. Server side synthesis + + If synthesis is done on the server side, PTR could be set not to use + the dynrev.arpa domain but the local domain name instead. It culd be + for instance dynrev.mydomain.com. + + Note also that server side synthesis is not incompatible with + resolver side synthesis. + + + +4. IANA considerations + + The dynrev.arpa. domain is reserved for the purpose of this document. + + + +5. Security considerations + + Section 2. discusses the the interactions with DNSsec. + + + +6. Authors addresses + + Alain Durand + SUN Microsystems, Inc + 17, Network Circle + UMPK17-202 + Menlo Park, CA 94025 + USA + Mail: Alain.Durand@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt new file mode 100644 index 0000000000..f0ce70ab1c --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt @@ -0,0 +1,393 @@ + + + +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc. + November 2002 + + + DNS Zone Transfer Protocol Clarifications + + +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. + +Abstract + + In the Domain Name System, zone data is replicated among + authoritative DNS servers by means of the "zone transfer" protocol, + also known as the "AXFR" protocol. This memo clarifies, updates, and + adds missing detail to the original AXFR protocol specification in + RFC1034. + +1. Introduction + + The original definition of the DNS zone transfer protocol consists of + a single paragraph in [RFC1034] section 4.3.5 and some additional + notes in [RFC1035] section 6.3. It is not sufficiently detailed to + serve as the sole basis for constructing interoperable + implementations. This document is an attempt to provide a more + complete definition of the protocol. Where the text in RFC1034 + conflicts with existing practice, the existing practice has been + codified in the interest of interoperability. + + + + +Expires May 2003 [Page 1] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + 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]. + +2. The zone transfer request + + To initiate a zone transfer, the slave server sends a zone transfer + request to the master server over a reliable transport such as TCP. + The form of this request is specified in sufficient detail in RFC1034 + and needs no further clarification. + + Implementers are advised that one server implementation in widespread + use sends AXFR requests where the TCP message envelope size exceeds + the DNS request message size by two octets. + +3. The zone transfer response + + If the master server is unable or unwilling to provide a zone + transfer, it MUST respond with a single DNS message containing an + appropriate RCODE other than NOERROR. If the master is not + authoritative for the requested zone, the RCODE SHOULD be 9 + (NOTAUTH). + + Slave servers should note that some master server implementations + will simply close the connection when denying the slave access to the + zone. Therefore, slaves MAY interpret an immediate graceful close of + the TCP connection as equivalent to a "Refused" response (RCODE 5). + + If a zone transfer can be provided, the master server sends one or + more DNS messages containing the zone data as described below. + +3.1. Multiple answers per message + + The zone data in a zone transfer response is a sequence of answer + RRs. These RRs are transmitted in the answer section(s) of one or + more DNS response messages. + + The AXFR protocol definition in RFC1034 does not make a clear + distinction between response messages and answer RRs. Historically, + DNS servers always transmitted a single answer RR per message. This + encoding is wasteful due to the overhead of repeatedly sending DNS + message headers and the loss of domain name compression + opportunities. To improve efficiency, some newer servers support a + mode where multiple RRs are transmitted in a single DNS response + message. + + A master MAY transmit multiple answer RRs per response message up to + the largest number that will fit within the 65535 byte limit on TCP + + + +Expires May 2003 [Page 2] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + DNS message size. In the case of a small zone, this can cause the + entire transfer to be transmitted in a single response message. + + Slaves MUST accept messages containing any number of answer RRs. For + compatibility with old slaves, masters that support sending multiple + answers per message SHOULD be configurable to revert to the + historical mode of one answer per message, and the configuration + SHOULD be settable on a per-slave basis. + +3.2. DNS message header contents + + RFC1034 does not specify the contents of the DNS message header of + the zone transfer response messages. The header of each message MUST + be as follows: + + ID Copy from request + QR 1 + OPCODE QUERY + AA 1, but MAY be 0 when RCODE is not NOERROR + TC 0 + RD Copy from request, or 0 + RA Set according to availability of recursion, or 0 + Z 0 + AD 0 + CD 0 + RCODE NOERROR on success, error code otherwise + + The slave MUST check the RCODE in each message and abort the transfer + if it is not NOERROR. It SHOULD check the ID of the first message + received and abort the transfer if it does not match the ID of the + request. The ID SHOULD be ignored in subsequent messages, and fields + other than RCODE and ID SHOULD be ignored in all messages, to ensure + interoperability with certain older implementations which transmit + incorrect or arbitrary values in these fields. + +3.3. Additional section and SIG processing + + Zone transfer responses are not subject to any kind of additional + section processing or automatic inclusion of SIG records. SIG RRs in + the zone data are treated exactly the same as any other RR type. + +3.4. The question section + + RFC1034 does not specify whether zone transfer response messages have + a question section or not. The initial message of a zone transfer + response SHOULD have a question section identical to that in the + request. Subsequent messages SHOULD NOT have a question section, + though the final message MAY. The receiving slave server MUST accept + + + +Expires May 2003 [Page 3] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + any combination of messages with and without a question section. + +3.5. The authority section + + The master server MUST transmit messages with an empty authority + section. Slaves MUST ignore any authority section contents they may + receive from masters that do not comply with this requirement. + +3.6. The additional section + + The additional section MAY contain additional RRs such as transaction + signatures. The slave MUST ignore any unexpected RRs in the + additional section. It MUST NOT treat additional section RRs as zone + data. + +4. Zone data + + The purpose of the zone transfer mechanism is to exactly replicate at + each slave the set of RRs associated with a particular zone at its + primary master. An RR is associated with a zone by being loaded from + the master file of that zone at the primary master server, or by some + other, equivalent method for configuring zone data. + + This replication shall be complete and unaltered, regardless of how + many and which intermediate masters/slaves are involved, and + regardless of what other zones those intermediate masters/slaves do + or do not serve, and regardless of what data may be cached in + resolvers associated with the intermediate masters/slaves. + + Therefore, in a zone transfer the master MUST send exactly those + records that are associated with the zone, whether or not their owner + names would be considered to be "in" the zone for purposes of + resolution, and whether or not they would be eligible for use as glue + in responses. The transfer MUST NOT include any RRs that are not + associated with the zone, such as RRs associated with zones other + than the one being transferred or present in the cache of the local + resolver, even if their owner names are in the zone being transferred + or are pointed to by NS records in the zone being transferred. + + The slave MUST associate the RRs received in a zone transfer with the + specific zone being transferred, and maintain that association for + purposes of acting as a master in outgoing transfers. + +5. Transmission order + + RFC1034 states that "The first and last messages must contain the + data for the top authoritative node of the zone". This is not + consistent with existing practice. All known master implementations + + + +Expires May 2003 [Page 4] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + send, and slave implementations expect to receive, the zone's SOA RR + as the first and last record of the transfer. + + Therefore, the quoted sentence is hereby superseded by the sentence + "The first and last RR transmitted must be the SOA record of the + zone". + + The initial and final SOA record MUST be identical, with the possible + exception of case and compression. In particular, they MUST have the + same serial number. The slave MUST consider the transfer to be + complete when, and only when, it has received the message containing + the second SOA record. + + The transmission order of all other RRs in the zone is undefined. + Each of them SHOULD be transmitted only once, and slaves MUST ignore + any duplicate RRs received. + +6. Security Considerations + + The zone transfer protocol as defined in [RFC1034] and clarified by + this memo does not have any built-in mechanisms for the slave to + securely verify the identity of the master server and the integrity + of the transferred zone data. The use of a cryptographic mechanism + for ensuring authenticity and integrity, such as TSIG [RFC2845], + IPSEC, or TLS, is RECOMMENDED. + + The zone transfer protocol allows read-only public access to the + complete zone data. Since data in the DNS is public by definition, + this is generally acceptable. Sites that wish to avoid disclosing + their full zone data MAY restrict zone transfer access to authorized + slaves. + + These clarifications are not believed to themselves introduce any new + security problems, nor to solve any existing ones. + +Acknowledgements + + Many people have contributed input and commentary to earlier versions + of this document, including but not limited to Bob Halley, Dan + Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, + Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam + Trenholme, and Brian Wellington. + +References + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + + + +Expires May 2003 [Page 5] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, + S. Bradner, BCP 14, March 1997. + + [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. + Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. + +Author's Address + + Andreas Gustafsson + Nominum Inc. + 2385 Bay Rd + Redwood City, CA 94063 + USA + + Phone: +1 650 381 6004 + + Email: gson@nominum.com + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000 - 2002). 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 + or assist in its implmentation 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + + + +Expires May 2003 [Page 6] + +draft-ietf-dnsext-axfr-clarify-05.txt November 2002 + + + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires May 2003 [Page 7] + + diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt new file mode 100644 index 0000000000..bddf377df5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-14.txt @@ -0,0 +1,914 @@ + + + + + + + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT May 2003 + + + Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. + + + Delegation Signer Resource Record + + +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 + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on December 6, 2003. + + Copyright Notice + + Copyright (C) The Internet Society (2003). All rights reserved. + + + +Abstract + + The delegation signer (DS) resource record is inserted at a zone cut + (i.e., a delegation point) to indicate that the delegated zone is + digitally signed and that the delegated zone recognizes the indicated + key as a valid zone key for the delegated zone. The DS RR is a + modification to the DNS Security Extensions definition, motivated by + + + +Gudmundsson Expires December 2003 [Page 1] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + operational considerations. The intent is to use this resource record + as an explicit statement about the delegation, rather than relying on + inference. + + This document defines the DS RR, gives examples of how it is used and + the implications of this record on resolvers. This change is not + backwards compatible with RFC 2535. + This document updates RFC1035, RFC2535, RFC3008 and RFC3090. + + +1 Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535] and DNSSEC terminology [RFC3090] is important. + + Experience shows that when the same data can reside in two + administratively different DNS zones, the data frequently gets out of + sync. The presence of an NS RRset in a zone anywhere other than at + the apex indicates a zone cut or delegation. The RDATA of the NS + RRset specifies the authoritative servers for the delegated or + "child" zone. Based on actual measurements, 10-30% of all delegations + on the Internet have differing NS RRsets at parent and child. There + are a number of reasons for this, including a lack of communication + between parent and child and bogus name servers being listed to meet + registry requirements. + + DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to + have its KEY RRset signed by its parent to create a verifiable chain + of KEYs. There has been some debate on where the signed KEY RRset + should reside, whether at the child [RFC2535] or at the parent. If + the KEY RRset resides at the child, maintaining the signed KEY RRset + in the child requires frequent two-way communication between the two + parties. First the child transmits the KEY RRset to the parent and + then the parent sends the signature(s) to the child. Storing the KEY + RRset at the parent was thought to simplify the communication. + + DNSSEC [RFC2535] requires that the parent store a NULL KEY record for + an unsecure child zone to indicate that the child is unsecure. A NULL + KEY record is a waste: an entire signed RRset is used to communicate + effectively one bit of information--that the child is unsecure. + Chasing down NULL KEY RRsets complicates the resolution process in + many cases, because servers for both parent and child need to be + queried for the KEY RRset if the child server does not return it. + Storing the KEY RRset only in the parent zone simplifies this and + would allow the elimination of the NULL KEY RRsets entirely. For + large delegation zones the cost of NULL keys is a significant barrier + to deployment. + + + + + +Gudmundsson Expires December 2003 [Page 2] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + Another complication of the DNSSEC key model is that the KEY record + can be used to store public keys for other protocols in addition to + DNSSEC keys. There are number of potential problems with this, + including: + 1. The KEY RRset can become quite large if many applications and + protocols store their keys at the zone apex. Possible protocols + are IPSEC, HTTP, SMTP, SSH and others that use public key + cryptography. + 2. The KEY RRset may require frequent updates. + 3. The probability of compromised or lost keys, which trigger + emergency key rollover procedures, increases. + 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys. + 5. The parent may not meet the child's expectations in turnaround + time for resigning the KEY RRset. + + Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. + + +1.2 Reserved Words + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + +2 Specification of the Delegation key Signer + + This section defines the Delegation Signer (DS) RR type (type code + TBD) and the changes to DNS to accommodate it. + +2.1 Delegation Signer Record Model + + This document presents a replacement for the DNSSEC KEY record chain + of trust [RFC2535] that uses a new RR that resides only at the + parent. This record identifies the key(s) that the child uses to + self-sign its own KEY RRset. + + The chain of trust is now established by verifying the parent KEY + RRset, the DS RRset from the parent and the KEY RRset at the child. + This is cryptographically equivalent to using just KEY records. + + Communication between the parent and child is greatly reduced, since + the child only needs to notify the parent about changes in keys that + sign its apex KEY RRset. The parent is ignorant of all other keys in + the child's apex KEY RRset. Furthermore, the child maintains full + control over the apex KEY RRset and its content. The child can + maintain any policies regarding its KEY usage for DNSSEC with minimal + impact on the parent. Thus if the child wants to have frequent key + rollover for its DNS zone keys, the parent does not need to be aware + of it. The child can use one key to sign only its apex KEY RRset and + + + +Gudmundsson Expires December 2003 [Page 3] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + a different key to sign the other RRsets in the zone. + + This model fits well with a slow roll out of DNSSEC and the islands + of security model. In this model, someone who trusts "good.example." + can preconfigure a key from "good.example." as a trusted key, and + from then on trusts any data signed by that key or that has a chain + of trust to that key. If "example." starts advertising DS records, + "good.example." does not have to change operations by suspending + self-signing. DS records can also be used to identify trusted keys + instead of KEY records. Another significant advantage is that the + amount of information stored in large delegation zones is reduced: + rather than the NULL KEY record at every unsecure delegation required + by RFC 2535, only secure delegations require additional information + in the form of a signed DS RRset. + + The main disadvantage of this approach is that verifying a zone's KEY + RRset requires two signature verification operations instead of the + one required by RFC 2535. There is no impact on the number of + signatures verified for other types of RRsets. + + Even though DS identifies two roles for KEY's, Key Signing Key (KSK) + and Zone Signing Key (ZSK), there is no requirement that zone use two + different keys for these roles. It is expected that many small zones + will only use one key, while larger organizations will be more likely + to use multiple keys. + +2.2 Protocol Change + + All DNS servers and resolvers that support DS MUST support the OK bit + [RFC3225] and a larger message size [RFC3226]. In order for a + delegation to be considered secure the delegation MUST contain a DS + RRset. If a query contains the OK bit, a server returning a referral + for the delegation MUST include the following RRsets in the authority + section in this order: + If DS RRset is present: + parents copy of childs NS RRset + DS and SIG(DS) + If no DS RRset is present: + parents copy of childs NS RRset + parents zone NXT and SIG(NXT) + + This increases the size of referral messages and possilbly causing + some or all glue to be omitted. If the DS or NXT RRsets with + signatures do not fit in the DNS message, the TC bit MUST be set. + Additional section processing is not changed. + + A DS RRset accompanying a NS RRset indicates that the child zone is + secure. If a NS RRset exists without a DS RRset, the child zone is + unsecure (from the parents point of view). DS RRsets MUST NOT appear + + + +Gudmundsson Expires December 2003 [Page 4] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + at non-delegation points or at a zone's apex. + + Section 2.2.1 defines special considerations related to authoritative + servers responding to DS queries and replaces RFC2535 sections 2.3.4 + and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section + 2.2.3 updates RFC3090. + + +2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points + + DNS security views each zone as a unit of data completely under the + control of the zone owner with each entry (RRset) signed by a special + private key held by the zone manager. But the DNS protocol views the + leaf nodes in a zone that are also the apex nodes of a child zone + (i.e., delegation points) as "really" belonging to the child zone. + The corresponding domain names appear in two master files and might + have RRsets signed by both the parent and child zones' keys. A + retrieval could get a mixture of these RRsets and SIGs, especially + since one server could be serving both the zone above and below a + delegation point [RFC 2181]. + + Each DS RRset stored in the parent zone MUST be signed by at least + one of the parent zone's private key. The parent zone MUST NOT + contain a KEY RRset at any delegation point. Delegations in the + parent MAY contain only the following RR types: NS, DS, NXT and SIG. + The NS RRset MUST NOT be signed. The NXT RRset is the exceptional + case: it will always appear differently and authoritatively in both + the parent and child zones if both are secure. + + A secure zone MUST contain a self-signed KEY RRset at its apex. Upon + verifying the DS RRset from the parent, a resolver MAY trust any KEY + identified in the DS RRset as a valid signer of the child's apex KEY + RRset. Resolvers configured to trust one of the keys signing the KEY + RRset MAY now treat any data signed by the zone keys in the KEY RRset + as secure. In all other cases resolvers MUST consider the zone + unsecure. A DS RRset MUST NOT appear at a zone's apex. + + An authoritative server queried for type DS MUST return the DS RRset + in the answer section. + + +2.2.1.1 Special processing for DS queries + + When a server is authoritative for the parent zone at a delegation + point and receives a query for the DS record at that name, it will + return the DS from the parent zone. This is true whether or not it + is also authoritative for the child zone. + + + + + +Gudmundsson Expires December 2003 [Page 5] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + When the server is authoritative for the child zone at a delegation + point but not the parent zone, there is no natural response, since + the child zone is not authoritative for the DS record at the zone's + apex. As these queries are only expected to originate from recursive + servers which are not DS-aware, the authoritative server MUST answer + with: + RCODE: NOERROR + AA bit: set + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + That is, it answers as if it is authoritative and the DS record does + not exist. DS-aware recursive servers will query the parent zone at + delegation points, so will not be affected by this. + + A server authoritative for only the child zone at a delegation point + that is also a caching server MAY (if the RD bit is set in the query) + perform recursion to find the DS record at the delegation point, and + may return the DS record from its cache. In this case, the AA bit + MUST not be set in the response. + + +2.2.1.2 Special processing when child and an ancestor share server" + + Special rules are needed to permit DS RR aware servers to gracefully + interact with older caches which otherwise might falsely label a + server as lame because of the new placement of the DS RR set. + + Such a situation might arise when a server is authoritative for both + a zone and it's grandparent, but not the parent. This sounds like an + obscure example, but it is very real. The root zone is currently + served on 13 machines, and "root-servers.net." is served on 4 of the + same 13, but "net." is served elsewhere. + + When a server receives a query for (, DS, IN), the response + MUST be determined from reading these rules in order: + + + 1) If the server is authoritative for the zone that holds the DS RR + set (i.e., the zone that delegates away, aka the "parent" + zone), the response contains the DS RR set as an authoritative + answer. + + 2) If the server is offering recursive service and the RD bit is set + in the query, the server performs the query itself (according to the + rules for resolvers described below) and returns it's findings. + + 3) If the server is authoritative for the zone that holds the + 's SOA RR set, the response is an authoritative negative + + + +Gudmundsson Expires December 2003 [Page 6] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + answer as described in 2.2.1.1. + + 4) If the server is authoritative for a zone or zones above the + QNAME, a referral to the most enclosing zone's servers is made. + + 5) If the server is not authoritative for any part of the QNAME, a + response indicating a lame server for QNAME is given. + + Using these rules will require some special processing on the part of + a DS RR aware resolver. To illustrate this, an example is used. + + Assuming a server is authoritative for roots.example.net. and for the + root zone but not the intervening two zones (or the intervening two + label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS, + and QCLASS=IN. + + The resolver will issue this request (assuming no cached data) + expecting a referral to a net. server. Instead, rule number 3 above + applies and a negative answer is returned by the server. The + reaction by the resolver is not to accept this answer as final as it + can determine from the SOA RR in the negative answer the context + within which the server has answered. + + A solution to this is to instruct the resolver to hunt for the + authoritative zone of the data in a brute force manner. + + This can be accomplished by taking the owner name of the returned SOA + RR and strip off enough left-hand labels until a successful NS + response is obtained. A successful response here means that the + answer has NS records in it. (Entertaining the possibility that a + cut point may be two labels down in a zone.) + + Returning to the example, the response will include a negative answer + with either the SOA RR for "roots.example.net." or "example.net." + depending on whether roots.example.net is a delegated domain. In + either case, removing the least significant label of the SOA owner + name will lead to the location of the desired data. + + +2.2.1.3 Modification on KEY RR in the construction of Responses + + This section updates RFC2535 section 3.5 by replacing it with the + following: + + An query for KEY RR MUST NOT trigger any additional section + processing. Security aware resolver will include corresponding SIG + records in the answer section. + + + + + +Gudmundsson Expires December 2003 [Page 7] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + KEY records SHOULD NOT be added to additional records section in + response to any query. + + RFC2535 included rules to in add KEY records to additional section + when SOA or NS records where included in an answer. The is was done + to reduce round trips (in the case of SOA) and to force out NULL + KEY's (in the NS case), as this document obsoletes NULL keys there is + no need for the second case, the first case causes redundant + transfers of KEY RRset as SOA is included in the authority section of + negative answers. + + RFC2535 section 3.5 also included rule for adding KEY RRset to query + for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by + all applications therfore the rule is not needed anymore. + + +2.2.2 Signer's Name (replaces RFC3008 section 2.7) + + The signer's name field of a SIG RR MUST contain the name of the zone + to which the data and signature belong. The combination of signer's + name, key tag, and algorithm MUST identify a zone key if the SIG is + to be considered material. This document defines a standard policy + for DNSSEC validation; local policy may override the standard policy. + + There are no restrictions on the signer field of a SIG(0) record. + The combination of signer's name, key tag, and algorithm MUST + identify a key if this SIG(0) is to be processed. + + +2.2.3 Changes to RFC3090 + + A number of sections of RFC3090 need to be updated to reflect the DS + record. + + +2.2.3.1 RFC3090: Updates to section 1: Introduction + + Most of the text is still relevant but the words ``NULL key'' are to + be replaced with ``missing DS RRset''. In section 1.3 the last three + paragraphs discuss the confusion in sections of RFC 2535 that are + replaced in section 2.2.1 above. Therefore, these paragraphs are now + obsolete. + + +2.2.3.2 RFC3090 section 2.1: Globally Secured + + Rule 2.1.b is replaced by the following rule: + + + + + +Gudmundsson Expires December 2003 [Page 8] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a + private key whose public counterpart MUST appear in a zone signing + KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- + implement algorithm. This KEY RR MUST be identified by a DS RR in a + signed DS RRset in the parent zone. + + If a zone cannot get its parent to advertise a DS record for it, the + child zone cannot be considered globally secured. The only exception + to this is the root zone, for which there is no parent zone. + + +2.2.3.3 RFC3090 section 3: Experimental Status. + + The only difference between experimental status and globally secured + is the missing DS RRset in the parent zone. All locally secured zones + are experimental. + + +2.2.4 NULL KEY elimination + + RFC3445 section 3 elminates the top two bits in the flags field of + KEY RR. These two bits where used to indicate NULL KEY or NO KEY. + RFC3090 defines that zone that defines that zone is either secure or + not, eliminates the possible need to put NULL keys in the zone apex + to indicate that the zone is not secured for a algorithm. Along with + this document these other two elminate all uses for the NULL KEY, + Thus this document obsoletes NULL KEY. + +2.3 Comments on Protocol Changes + + Over the years there have been various discussions surrounding the + DNS delegation model, declaring it to be broken because there is no + good way to assert if a delegation exists. In the RFC2535 version of + DNSSEC, the presence of the NS bit in the NXT bit map proves there is + a delegation at this name. Something more explicit is needed and the + DS record addresses this need for secure delegations. + + The DS record is a major change to DNS: it is the first resource + record that can appear only on the upper side of a delegation. Adding + it will cause interoperabilty problems and requires a flag day for + DNSSEC. Many old servers and resolvers MUST be upgraded to take + advantage of DS. Some old servers will be able to be authoritative + for zones with DS records but will not add the NXT or DS records to + the authority section. The same is true for caching servers; in + fact, some may even refuse to pass on the DS or NXT records. + + + + + + + +Gudmundsson Expires December 2003 [Page 9] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + +2.4 Wire Format of the DS record + + The DS (type=TDB) record contains these fields: key tag, algorithm, + digest type, and the digest of a public key KEY record that is + allowed and/or used to sign the child's apex KEY RRset. Other keys + MAY sign the child's apex KEY RRset. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key tag | algorithm | Digest type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | digest (length depends on type) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (SHA-1 digest is 20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The key tag is calculated as specified in RFC2535. Algorithm MUST be + an algorithm number assigned in the range 1..251 and the algorithm + MUST be allowed to sign DNS data. The digest type is an identifier + for the digest algorithm used. The digest is calculated over the + canonical name of the delegated domain name followed by the whole + RDATA of the KEY record (all four fields). + + digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key + + Digest type value 0 is reserved, value 1 is SHA-1, and reserving + other types requires IETF standards action. For interoperabilty + reasons, as few digest algorithms as possible should be reserved. The + only reason to reserve additional digest types is to increase + security. + + DS records MUST point to zone KEY records that are allowed to + authenticate DNS data. The indicated KEY record's protocol field + MUST be set to 3; flag field bit 7 MUST be set to 1. The value of + other flag bits is not significant for the purposes of this document. + + The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless + of key size, new digest types probably will have larger digests. + + + + + +Gudmundsson Expires December 2003 [Page 10] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + +2.4.1 Justifications for Fields + + The algorithm and key tag fields are present to allow resolvers to + quickly identify the candidate KEY records to examine. SHA-1 is a + strong cryptographic checksum: it is computationally infeasible for + an attacker to generate a KEY record that has the same SHA-1 digest. + Combining the name of the key and the key rdata as input to the + digest provides stronger assurance of the binding. Having the key + tag in the DS record adds greater assurance than the SHA-1 digest + alone, as there are now two different mapping functions that a KEY RR + must match. + + This format allows concise representation of the keys that the child + will use, thus keeping down the size of the answer for the + delegation, reducing the probability of DNS message overflow. The + SHA-1 hash is strong enough to uniquely identify the key and is + similar to the PGP key footprint. The digest type field is present + for possible future expansion. + + The DS record is well suited to listing trusted keys for islands of + security in configuration files. + +2.5 Presentation Format of the DS Record + + The presentation format of the DS record consists of three numbers + (key tag, algorithm and digest type) followed by the digest itself + presented in hex: + example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 + +2.6 Transition Issues for Installed Base + + No backwards compatibility with RFC2535 is provided. + + RFC2535-compliant resolvers will assume that all DS-secured + delegations are locally secure. This is bad, but the DNSEXT Working + Group has determined that rather than dealing with both + RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is + preferable. Thus the only option for early adopters is to upgrade to + DS as soon as possible. + +2.6.1 Backwards compatibility with RFC2535 and RFC1035 + + This section documents how a resolver determines the type of + delegation. + RFC1035 delegation (in parent) has: + + RFC1035 NS + + RFC2535 adds the following two cases: + + + +Gudmundsson Expires December 2003 [Page 11] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + Secure RFC2535: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) + NXT bit map contains: NS SIG KEY NXT + KEY must be a NULL key. + + DNSSEC with DS has the following two states: + + Secure DS: NS + DS + SIG(DS) + NXT bit map contains: NS SIG NXT DS + Unsecure DS: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + + It is difficult for a resolver to determine if a delegation is secure + RFC 2535 or unsecure DS. This could be overcome by adding a flag to + the NXT bit map, but only upgraded resolvers would understand this + flag, anyway. Having both parent and child signatures for a KEY RRset + might allow old resolvers to accept a zone as secure, but the cost of + doing this for a long time is much higher than just prohibiting RFC + 2535-style signatures at child zone apexes and forcing rapid + deployment of DS-enabled servers and resolvers. + + RFC 2535 and DS can in theory be deployed in parallel, but this would + require resolvers to deal with RFC 2535 configurations forever. This + document obsoletes the NULL KEY in parent zones, which is a difficult + enough change that a flag day is required. + +2.7 KEY and corresponding DS record example + + This is an example of a KEY record and the corresponding DS record. + + dskey.example. KEY 256 3 1 ( + AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj + 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt + ) ; key id = 28668 + DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE + + + + + + + + + + + + + + + + +Gudmundsson Expires December 2003 [Page 12] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + +3 Resolver + +3.1 DS Example + + To create a chain of trust, a resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain "example." is trusted. Zone "example." + contains at least the following records: + example. SOA + example. NS ns.example. + example. KEY + example. NXT NS SOA KEY SIG NXT secure.example. + example. SIG(SOA) + example. SIG(NS) + example. SIG(NXT) + example. SIG(KEY) + secure.example. NS ns1.secure.example. + secure.example. DS tag=12345 alg=3 digest_type=1 + secure.example. NXT NS SIG NXT DS unsecure.example. + secure.example. SIG(NXT) + secure.example. SIG(DS) + unsecure.example NS ns1.unsecure.example. + unsecure.example. NXT NS SIG NXT example. + unsecure.example. SIG(NXT) + + In zone "secure.example." following records exist: + secure.example. SOA + secure.example. NS ns1.secure.example. + secure.example. KEY + secure.example. KEY + secure.example. NXT + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + secure.example. SIG(NXT) + + In this example the private key for "example." signs the DS record + for "secure.example.", making that a secure delegation. The DS record + states which key is expected to sign the KEY RRset at + "secure.example.". Here "secure.example." signs its KEY RRset with + the KEY identified in the DS RRset, thus the KEY RRset is validated + and trusted. + + This example has only one DS record for the child, but parents MUST + allow multiple DS records to facilitate key rollover and multiple KEY + algorithms. + + + + + +Gudmundsson Expires December 2003 [Page 13] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + The resolver determines the security status of "unsecure.example." by + examining the parent zone's NXT record for this name. The absence of + the DS bit indicates an unsecure delegation. Note the NXT record + SHOULD only be examined after verifying the corresponding signature. + +3.1 Resolver Cost Estimates for DS Records + + From a RFC2535 resolver point of view, for each delegation followed + to chase down an answer, one KEY RRset has to be verified. + Additional RRsets might also need to be verified based on local + policy (e.g., the contents of the NS RRset). Once the resolver gets + to the appropriate delegation, validating the answer might require + verifying one or more signatures. A simple A record lookup requires + at least N delegations to be verified and one RRset. For a DS-enabled + resolver, the cost is 2N+1. For an MX record, where the target of + the MX record is in the same zone as the MX record, the costs are N+2 + and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives + answer the same ratios hold true. + + The resolver may require an extra query to get the DS record and this + may add to the overall cost of the query, but this is never worse + than chasing down NULL KEY records from the parent in RFC2535 DNSSEC. + + DS adds processing overhead on resolvers and increases the size of + delegation answers, but much less than storing signatures in the + parent zone. + +4 Security Considerations: + + This document proposes a change to the validation chain of KEY + records in DNSSEC. The change is not believed to reduce security in + the overall system. In RFC2535 DNSSEC, the child zone has to + communicate keys to its parent and prudent parents will require some + authentication with that transaction. The modified protocol will + require the same authentication, but allows the child to exert more + local control over its own KEY RRset. + + There is a remote possibility that an attacker could generate a valid + KEY that matches all the DS fields, of a specific DS set, and thus + forge data from the child. This possibility is considered + impractical, as on average more than + 2 ^ (160 - ) + keys would have to be generated before a match would be found. + + An attacker that wants to match any DS record will have to generate + on average at least 2^80 keys. + + The DS record represents a change to the DNSSEC protocol and there is + an installed base of implementations, as well as textbooks on how to + + + +Gudmundsson Expires December 2003 [Page 14] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + + set up secure delegations. Implementations that do not understand the + DS record will not be able to follow the KEY to DS to KEY chain and + will consider all zones secured that way as unsecure. + +5 IANA Considerations: + + IANA needs to allocate an RR type code for DS from the standard RR + type space (type 43 requested). + + IANA needs to open a new registry for the DS RR type for digest + algorithms. Defined types are: + 0 is Reserved, + 1 is SHA-1. + Adding new reservations requires IETF standards action. + +6 Acknowledgments + + Over the last few years a number of people have contributed ideas + that are captured in this document. The core idea of using one key to + sign only the KEY RRset comes from discussions with Bill Manning and + Perry Metzger on how to put in a single root key in all resolvers. + Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob + Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, + Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek + Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David + Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark + Andrews, Harald Alvestrand, and others have provided useful comments. + +Normative References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC + 2535, March 1999. + +[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing + Authority'', RFC 3008, November 2000. + +[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone + Status'', RFC 3090, March 2001. + +[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC + 3225, December 2001. + +[RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource + Record (RR)``, RFC 3445, December 2002. + + + + + +Gudmundsson Expires December 2003 [Page 15] + +INTERNET-DRAFT Delegation Signer Record February 2003 + + +Informational References + +[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', + RFC 2181, July 1997. + +[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver + message size requirements'', RFC 3226, December 2001. + +Author Address + + Olafur Gudmundsson + 3821 Village Park Drive + Chevy Chase, MD, 20815 + USA + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + +Gudmundsson Expires December 2003 [Page 16] diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt new file mode 100644 index 0000000000..93fd0214e8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-06.txt @@ -0,0 +1,560 @@ + + +DNSEXT Working Group M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: May 2, 2003 T. Lemon + A. Gustafsson + Nominum, Inc. + November 1, 2002 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + + +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. + + This Internet-Draft will expire on May 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + It is possible for multiple DHCP clients to attempt to update the + same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or + the clients themselves perform the DNS updates, conflicts can arise. + To resolve such conflicts, "Resolution of DNS Name Conflicts"[1] + proposes storing client identifiers in the DNS to unambiguously + associate domain names with the DHCP clients to which they refer. + This memo defines a distinct RR type for this purpose for use by + DHCP clients and servers, the "DHCID" RR. + + + + +Stapp, et. al. Expires May 2, 2003 [Page 1] + +Internet-Draft The DHCID RR November 2002 + + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 4 + 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4 + 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4 + 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5 + 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . 7 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires May 2, 2003 [Page 2] + +Internet-Draft The DHCID RR November 2002 + + +1. Terminology + + 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[2]. + +2. Introduction + + A set of procedures to allow DHCP[3] clients and servers to + automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in + "Resolution of DNS Name Conflicts"[1]. + + Conflicts can arise if multiple DHCP clients wish to use the same + DNS name. To resolve such conflicts, "Resolution of DNS Name + Conflicts"[1] proposes storing client identifiers in the DNS to + unambiguously associate domain names with the DHCP clients using + them. In the interest of clarity, it is preferable for this DHCP + information to use a distinct RR type. This memo defines a distinct + RR for this purpose for use by DHCP clients or servers, the "DHCID" + RR. + + In order to avoid exposing potentially sensitive identifying + information, the data stored is the result of a one-way MD5[6] hash + computation. The hash includes information from the DHCP client's + REQUEST message as well as the domain name itself, so that the data + stored in the DHCID RR will be dependent on both the client + identification used in the DHCP protocol interaction and the domain + name. This means that the DHCID RDATA will vary if a single client + is associated over time with more than one name. This makes it + difficult to 'track' a client as it is associated with various + domain names. + + The MD5 hash algorithm has been shown to be weaker than the SHA-1 + algorithm; it could therefore be argued that SHA-1 is a better + choice. However, SHA-1 is significantly slower than MD5. A + successful attack of MD5's weakness does not reveal the original + data that was used to generate the signature, but rather provides a + new set of input data that will produce the same signature. Because + we are using the MD5 hash to conceal the original data, the fact + that an attacker could produce a different plaintext resulting in + the same MD5 output is not significant concern. + +3. The DHCID RR + + The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The + DHCID RR is only defined in the IN class. DHCID RRs cause no + additional section processing. The DHCID RR is not a singleton type. + + + + +Stapp, et. al. Expires May 2, 2003 [Page 3] + +Internet-Draft The DHCID RR November 2002 + + +3.1 DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its + interpretation by DHCP servers and clients are described below. + + DNS software should consider the RDATA section to be opaque. DHCP + clients or servers use the DHCID RR to associate a DHCP client's + identity with a DNS name, so that multiple DHCP clients and servers + may deterministically perform dynamic DNS updates to the same zone. + From the updater's perspective, the DHCID resource record RDATA + consists of a 16-bit identifier type, in network byte order, + followed by one or more bytes representing the actual identifier: + + < 16 bits > DHCP identifier used + < n bytes > MD5 digest + +3.2 DHCID Presentation Format + + In DNS master files, the RDATA is represented as a single block in + base 64 encoding identical to that used for representing binary data + in RFC2535[7]. The data may be divided up into any number of white + space separated substrings, down to single base 64 digits, which are + concatenated to form the complete RDATA. These substrings can span + lines using the standard parentheses. + +3.3 The DHCID RR Type Codes + + The DHCID RR Type Code specifies what data from the DHCP client's + request was used as input into the hash function. The type codes are + defined in a registry maintained by IANA, as specified in Section 7. + The initial list of assigned values for the type code is: + + 0x0000 = htype, chaddr from a DHCPv4 client's + DHCPREQUEST (RFC 2131) + 0x0001 = The data portion from a DHCPv4 client's Client + Identifier option (RFC 2132) + 0x0002 = The data portion (i.e., the DUID) from a DHCPv6 + client's Client Identifier option + (draft-ietf-dhc-dhcpv6-*.txt) + + 0x0003 - 0xfffe = Available to be assigned by IANA + + 0xffff = RESERVED + + + + + + + +Stapp, et. al. Expires May 2, 2003 [Page 4] + +Internet-Draft The DHCID RR November 2002 + + +3.4 Computation of the RDATA + + The DHCID RDATA is formed by concatenating the two type bytes with + some variable-length identifying data. + + < type > < data > + + The RDATA for all type codes other than 0xffff, which is reserved + for future expansion, is formed by concatenating the two type bytes + and a 16-byte MD5 hash value. The input to the hash function is + defined to be: + + data = MD5(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC2535[7], section 8.1. The type code and the + identifier are related as specified in Section 3.3: the type code + describes the source of the identifier. + + When the updater is using the client's link-layer address as the + identifier, the first two bytes of the DHCID RDATA MUST be zero. To + generate the rest of the resource record, the updater computes a + one-way hash using the MD5 algorithm across a buffer containing the + client's network hardware type, link-layer address, and the FQDN + data. Specifically, the first byte of the buffer contains the + network hardware type as it appeared in the DHCP 'htype' field of + the client's DHCPREQUEST message. All of the significant bytes of + the chaddr field in the client's DHCPREQUEST message follow, in the + same order in which the bytes appear in the DHCPREQUEST message. The + number of significant bytes in the 'chaddr' field is specified in + the 'hlen' field of the DHCPREQUEST message. The FQDN data, as + specified above, follows. + + When the updater is using the DHCPv4 Client Identifier option sent + by the client in its DHCPREQUEST message, the first two bytes of the + DHCID RR MUST be 0x0001, in network byte order. The rest of the + DHCID RR MUST contain the results of computing an MD5 hash across + the payload of the option, followed by the FQDN. The payload of the + option consists of the bytes of the option following the option code + and length. + + When the updater is using the DHCPv6 DUID sent by the client in its + REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, + in network byte order. The rest of the DHCID RR MUST contain the + results of computing an MD5 hash across the payload of the option, + followed by the FQDN. The payload of the option consists of the + bytes of the option following the option code and length. + + + + +Stapp, et. al. Expires May 2, 2003 [Page 5] + +Internet-Draft The DHCID RR November 2002 + + +3.5 Examples + +3.5.1 Example 1 + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client with + Ethernet MAC address 01:02:03:04:05:06 using domain name + "client.example.com" uses the client's link-layer address to + identify the client. The DHCID RDATA is composed by setting the two + type bytes to zero, and performing an MD5 hash computation across a + buffer containing the Ethernet MAC type byte, 0x01, the six bytes of + MAC address, and the domain name (represented as specified in + Section 3.4). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU + +3.5.2 Example 2 + + A DHCP server allocates the IPv4 address 10.0.12.99 to a client + which included the DHCP client-identifier option data + 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the + name "chi.example.com" on the client's behalf, and uses the DHCP + client identifier option data as input in forming a DHCID RR. The + DHCID RDATA is formed by setting the two type bytes to the value + 0x0001, and performing an MD5 hash computation across a buffer + containing the seven bytes from the client-id option and the FQDN + (represented as specified in Section 3.4). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 + +4. Use of the DHCID RR + + This RR MUST NOT be used for any purpose other than that detailed in + "Resolution of DNS Name Conflicts"[1]. Although this RR contains + data that is opaque to DNS servers, the data must be consistent + across all entities that update and interpret this record. + Therefore, new data formats may only be defined through actions of + the DHC Working Group, as a result of revising [1]. + +5. Updater Behavior + + The data in the DHCID RR allows updaters to determine whether more + than one DHCP client desires to use a particular FQDN. This allows + site administrators to establish policy about DNS updates. The DHCID + RR does not establish any policy itself. + + Updaters use data from a DHCP client's request and the domain name + that the client desires to use to compute a client identity hash, + + +Stapp, et. al. Expires May 2, 2003 [Page 6] + +Internet-Draft The DHCID RR November 2002 + + + and then compare that hash to the data in any DHCID RRs on the name + that they wish to associate with the client's IP address. If an + updater discovers DHCID RRs whose RDATA does not match the client + identity that they have computed, the updater SHOULD conclude that a + different client is currently associated with the name in question. + The updater SHOULD then proceed according to the site's + administrative policy. That policy might dictate that a different + name be selected, or it might permit the updater to continue. + +6. Security Considerations + + The DHCID record as such does not introduce any new security + problems into the DNS. In order to avoid exposing private + information about DHCP clients to public scrutiny, a one-way hash is + used to obscure all client information. In order to make it + difficult to 'track' a client by examining the names associated with + a particular hash value, the FQDN is included in the hash + computation. Thus, the RDATA is dependent on both the DHCP client + identification data and on each FQDN associated with the client. + + Administrators should be wary of permitting unsecured DNS updates to + zones which are exposed to the global Internet. Both DHCP clients + and servers SHOULD use some form of update authentication (e.g., + TSIG[10]) when performing DNS updates. + +7. IANA Considerations + + IANA is requested to allocate an RR type number for the DHCID record + type. + + This specification defines a new number-space for the 16-bit type + codes associated with the DHCID RR. IANA is requested to establish a + registry of the values for this number-space. + + Three initial values are assigned in Section 3.3, and the value + 0xFFFF is reserved for future use. New DHCID RR type codes are + tentatively assigned after the specification for the associated type + code, published as an Internet Draft, has received expert review by + a designated expert. The final assignment of DHCID RR type codes is + through Standards Action, as defined in RFC2434[11]. + +8. Acknowledgements + + Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, + and Ralph Droms for their review and suggestions. + +References + + [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP + + +Stapp, et. al. Expires May 2, 2003 [Page 7] + +Internet-Draft The DHCID RR November 2002 + + + Clients (draft-ietf-dhc-dns-resolution-*)", March 2001. + + [2] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + Mar 1997. + + [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC + 1034, Nov 1987. + + [5] Mockapetris, P., "Domain names - Implementation and + Specification", RFC 1035, Nov 1987. + + [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, + April 1992. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, Mar 1997. + + [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + (draft-ietf-dhc-dhcpv6-*.txt)", November 2002. + + [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", RFC 2434, October 1998. + + +Authors' Addresses + + Mark Stapp + Cisco Systems, Inc. + 250 Apollo Dr. + Chelmsford, MA 01824 + USA + + Phone: 978.244.8498 + EMail: mjs@cisco.com + + + + + + +Stapp, et. al. Expires May 2, 2003 [Page 8] + +Internet-Draft The DHCID RR November 2002 + + + Ted Lemon + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: mellon@nominum.com + + + Andreas Gustafsson + Nominum, Inc. + 950 Charter St. + Redwood City, CA 94063 + USA + + EMail: gson@nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires May 2, 2003 [Page 9] + +Internet-Draft The DHCID RR November 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Stapp, et. al. Expires May 2, 2003 [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt new file mode 100644 index 0000000000..7eee7845d3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-05.txt @@ -0,0 +1,1288 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 15, 2003 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 14, 2003 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-05 + +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. + + This Internet-Draft will expire on August 15, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + 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 + + + +Arends, et al. Expires August 15, 2003 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + services that the DNS security extensions do and do not provide. + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 6 + 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9 + 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10 + 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11 + 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12 + 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12 + 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13 + 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14 + 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14 + 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . . 20 + Informative References . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents ([13] and + [14]) update, clarify, and refine the security extensions originally + defined in RFC 2535 [3]. These security extensions consist of a set + of new resource record types and modifications to the existing DNS + protocol [2]. The new records and protocol modifications are not + fully described in this document, but are described in a family of + documents outlined in Section 9. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5, Section 6, Section 7, and Section 8 + discuss the effect that these security extensions will have on + resolvers, stub resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535, + 3008, 3090, 3225, 3226, and 3445, as well as several works in + progress: "Redefinition of the AD bit", "Delegation Signer Resource + Record", and "DNSSEC Opt-In". See [18] for more details on these + documents. + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide protection against + other types of attack, nor do they provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +2. Definitions of Important DNSSEC Terms + + authentication chain: In the DNSSEC model, a KEY RR signs a DS RR, + which hashes one RR in another KEY RRset, which in turn signs + another DS RR, which hashes one RR in yet another KEY RRset, and + so forth, finally ending, if all goes well, with a KEY RR which + signs whatever DNS data the end user was looking for in the first + place. This alternating succession of KEY RRsets and DS RRs forms + a chain of signed data, with each link in the chain vouching for + the next. If a signature somewhere in this chain has been + generated by an authentication key known to a security-aware + resolver, then the resolver can attempt to verify and authenticate + the signed chain of KEY and DS RRs from that point down to the + target data. + + authentication key: A public key which a security-aware resolver + trusts and can therefore use to verify data. A security-aware + resolver can discover trusted authentication keys in three ways. + First, the resolver is generally preconfigured to know about at + least one key which it should trust. Second, the resolver may be + able to discover both a new key and an associated DS RR which + contains a valid hash of the new key and which has been signed by + a key which the resolver trusts. Third, the resolver may be able + to determine that a new key has been signed by another key which + the resolver trusts. Note that the resolver must always be guided + by local policy when deciding whether to trust a new key, even if + the local policy is simply to trust any new key for which the + resolver is able verify the signature. + + 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 itself does not distinguish + between key signing keys and other DNSSEC authentication keys. + Key signing keys are discussed in more detail in [12]. + + security-aware name server: An entity acting in the role of a name + server (defined in section 2.4 of [1]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware name server is an entity which receives DNS + queries, sends DNS responses, supports the EDNS0 [4] message size + extension and the DO bit [8], and supports the RR types and + message header bits defined in this document set. + + + + +Arends, et al. Expires August 15, 2003 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + security-aware recursive name server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + security-aware resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [1]) which understands the DNS security + extensions defined in this document set. In particular, a + security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [4] message size + extension and the DO bit [8], and is capable of using the RR 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 [1]) which has at least a + minimal understanding the DNS security extensions defined in this + document set, but 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 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 performs its + own DNSSEC signature validity checks, while a security-aware stub + resolver does not, by definition. + + security-oblivious: The opposite of "security-aware". + + signed zone: A zone whose RRsets are signed and which contains + properly constructed KEY, SIG, NXT and (optionally) DS records. + + unsigned zone: The opposite of a "signed zone". + + 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 KEY 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. + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require minor changes to the DNS protocol. DNSSEC + adds four new resource record types (SIG, KEY, DS and NXT) and two + new message header bits (CD and AD). In order to support the larger + DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support [4]. Finally, DNSSEC requires support for the + DO bit [8], so that a security-aware resolver can indicate in its + queries that it wishes to receive DNSSEC RRs in response messages. + + These services protect against most of the threats to the Domain Name + System described in [11]. + +3.1 Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the SIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible: for example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers (public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [7], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions). + + A security-aware resolver can learn a zone's public key either by + having the key preconfigured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the KEY RR. Note that the private keys used + to sign zone data must be kept secure, and should be stored 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 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 resolver + or must have been learned and verified previously. Therefore, the + + + +Arends, et al. Expires August 15, 2003 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + resolver must be configured with at least one public key: if the + preconfigured key is a zone signing key, then it will authenticate + the associated zone; if the preconfigured key is a key signing key, + it will authenticate a zone signing key. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key in the DNS reply message along with the public key + itself, provided there is space available in the message. + + The authentication chain specified in the original DNS security + extensions proceeded from signed KEY record to signed KEY record, as + necessary, and finally to the queried RRset. The current + specification adds a new Delegation Signer (DS) RR type to simplify + some of the administrative tasks involved in signing delegations + across organizational boundaries. The DS RRset resides at a + delegation point in a parent zone and indicates the key or keys used + by the delegated child zone to self-sign the KEY RRset at the child + zone's apex. The child zone, in turn, uses one or more of the keys + in this KEY RRset to sign its zone data. The authentication chain is + therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS- + >KEY subchains. + + This authentication chain is normally constructed from the root of + the DNS hierarchy down to the leaf zones, and is normally based on + preconfigured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to trust + one or more preconfigured keys other than the root key, or may not + provide preconfigured knowledge of the root key, or may even prevent + the resolver from trusting particular keys for arbitrary reasons even + if those keys are properly signed with verifiable signatures. DNSSEC + provides mechanisms by which a security-aware resolver can determine + whether an RRset's signature is "valid" within the meaning of DNSSEC, + but authentication and trust, in the final analysis, are matters of + local policy, which may extend or even override the protocol + extensions defined in this document set. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NXT record. + The NXT 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 NXT + records require a canonical representation and ordering for domain + names in zones. Chains of NXT records explicitly describe the gaps, + or "empty space", between domain names in a zone, as well as listing + + + +Arends, et al. Expires August 15, 2003 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + the types of RRsets present at existing names. Each NXT record is + signed and authenticated using the mechanisms described in Section + 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + 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 [16]. Message + authentication schemes described in [5] and [7] address security + operations that pertain to these transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +5. Resolver Considerations + + A security-aware resolver needs to be able to perform necessary + cryptographic functions to verify digital signatures using at least + the mandatory-to-implement algorithms. Security-aware resolvers must + also be capable of forming a authentication chain from a newly + learned zone back to a authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary KEY, DS and SIG records. A security-aware resolver + should be configured with at least one authentication key as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + 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 + 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 + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [13] in order to avoid blocking valid signatures from getting + through to other security-aware resolvers which are clients of this + recursive name server and which are capable of performing their own + DNSSEC validity checks. + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +6. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even an unaugmented stub resolver may get some benefit from DNSSEC if + the recursive name servers it uses are security-aware, but for the + stub resolver to place any real reliance on DNSSEC services, the stub + resolver must trust both the recursive name servers in question and + the communication channels between itself and those name servers. + The first of these issues is a local policy issue: in essence, a stub + resolver has no real choice but to place itself at the mercy of the + recursive name servers that it uses, since it does not perform DNSSEC + validity checks on its own. The second issue requires some kind of + channel security mechanism; proper use of DNS transaction + authentication mechanisms such as SIG(0) or TSIG would suffice, as + would appropriate use of IPsec, and particular implementations may + have other choices available, such as operating system specific + interprocess communication mechanisms. Confidentiality is not needed + for this channel, but data integrity and message authentication are. + + {{AD bit currently ratholed, update this when its fate is settled}} + + There is one more step which a security-aware stub resolver can take + 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. + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +7. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (SIG, + KEY, DS and NXT records). SIG and NXT records may be generated by a + signing process prior to serving the zone. The SIG records that + accompany zone data have defined inception and expiration times, + which establish a validity period for the signatures and the zone + data the signatures cover. + +7.1 TTL values vs. SIG validity period + + It is important to note the distinction between an RRset's TTL value + and the signature validity period specified by the SIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later + than the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the SIG RR [13], on the other + hand, specify the time period during which the signature can be used + to validate the RRset that it covers. The signatures associated with + signed zone data are only valid for the time period specified by + these fields in the SIG RRs in question. TTL values cannot extend + the validity period of signed RRsets in a resolver's cache, but the + resolver may use the time remaining before expiration of the + signature validity period of a signed RRset as an upper bound for the + TTL of the signed RRset and its associated SIG RR in the resolver's + cache. + +7.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + SIG RR. The signature validity period of a SIG RR is a interval + during which the signature for one particular signed RRset can be + considered valid, and the signatures of different RRsets in a zone + may expire at different times. Re-signing one or more RRsets in a + zone will change one or more SIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, re- + signing any RRset in a zone may also trigger DNS NOTIFY messages and + zone transfers operations. + + + + + + +Arends, et al. Expires August 15, 2003 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +8. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (SIG, KEY, DS and NXT) 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. + + 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 + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private half of the zone signing key will have to be + kept online. This is an example of a situation where the ability to + separate the zone's KEY RRset into zone signing key(s) and key + signing key(s) may be useful, since the key singing key(s) in such a + case can still be kept offline. + + 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, so zone maintenance operations will + require some additional mechanisms (most likely some form of channel + security, such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +9. DNS Security Document Family + + The DNSSEC set of documents can be partitioned into five main groups + as depicted in Figure 1. All these documents are in turn under the + larger umbrella of the DNS base protocol documents described in [18]. + +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 | + +------------------+ +------------------+ + + Figure 1: DNSSEC Document Roadmap + + --------------------------------------------------------------------- + + +9.2 Categories of DNS Security Documents + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + + 1. DNS Security Introduction and Requirements (this document) + + 2. Resource Records for DNS Security Extensions [13] + + + + +Arends, et al. Expires August 15, 2003 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + 3. Protocol Modifications for the DNS Security Extensions [14] + + The "Digital Signature Algorithm Implementations" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + 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, + 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. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [15] and individual user public keys + (PGP, e-mail, and so forth) [17]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +10. IANA Considerations + + This document introduces no new IANA considerations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +11. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. This document discusses the capabilities and + limitations of these extensions. The extensions provide data origin + authentication and data integrity using digital signatures over + 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. + + 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. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with SIG 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 August 15, 2003 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + 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. + + DNSSEC add the ability for a hostile party to enumerate all the names + in a zone by following the NXT chain. NXT RRs assert which names do + not exist in a zone by linking from existing name to existing name + along a canonical ordering of all the names within a zone. Thus, an + attacker can query these NXT RRs in sequence to 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. + + 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 + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +12. Acknowledgements + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group. The authors would like to + acknowledge (in alphabetical order) the following people for their + contributions and comments on this document: + + Derek Atkins + Donald Eastlake + Miek Gieben + Olafur Gudmundsson + Olaf Kolkman + Ed Lewis + Ted Lindgreen + Bill Manning + Brian Wellington + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [7] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name + System", draft-ietf-dnsext-dns-threats-02 (work in progress), + February 2002. + + [12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK) + Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in + progress), December 2002. + + [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource + Records for DNS Security Extensions", draft-ietf-dnsext-dnssec- + records-02 (work in progress), November 2002. + + [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol + Modifications for the DNS Security Extensions", draft-ietf- + dnsext-dnssec-protocol-00 (work in progress), October 2002. + + + +Arends, et al. Expires August 15, 2003 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Informative References + + [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", RFC 2538, March 1999. + + [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [17] Schlyter, J., "Storing application public keys in the DNS", + draft-schlyter-appkey-02 (work in progress), February 2002. + + [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext- + dnssec-roadmap-06 (work in progress), November 2001. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 15, 2003 [Page 23] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt new file mode 100644 index 0000000000..1bfb560cd1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt @@ -0,0 +1,1456 @@ + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: August 28, 2003 M. Kosters + D. Blacka + Verisign, Inc. + February 27, 2003 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-05 + +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. + + This Internet-Draft will expire on August 28, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + In RFC 2535, delegations to unsigned subzones are cryptographically + secured. Maintaining this cryptography is not practical or + necessary. This document describes an "Opt-In" model that allows + administrators to omit this cryptography and manage the cost of + adopting DNSSEC with large zones. + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 1] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6 + 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6 + 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6 + 3.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7 + 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7 + 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8 + 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + Normative References . . . . . . . . . . . . . . . . . . . . 18 + Informative References . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 21 + B. Changes from Prior Versions . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . 25 + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 2] + +Internet-Draft DNSSEC Opt-In February 2003 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system, RFC 1035 + [1], DNS security extensions, RFC 2535 [2], and DNSSEC terminology + RFC 3090 [8] is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + + RRset: refers to a Resource Record Set, as defined by [6]. In this + document, the RRset is also defined to include the covering SIG + records, if any exist. + + signed name: refers to a DNS name that has, at minimum, a (signed) + NXT record. + + unsigned name: refers to a DNS name that does not (at least) have a + NXT record. + + covering NXT record/RRset: is the NXT record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NXT record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + + 2535/DS insecure delegation: refers to a signed name containing a + delegation (NS RRset), but lacking a DS RRset, signifying a + delegation to an unsigned subzone. + + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NXT record uses the + Opt-In methodology described in this document. + + 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 [5]. + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 3] + +Internet-Draft DNSSEC Opt-In February 2003 + + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NXT record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes a method of eliminating the superfluous + cryptography present in secure delegations to insecure zones. Using + "Opt-In", a zone administrator can choose to remove insecure + delegations from the NXT chain. This is accomplished by extending + the semantics of the NXT record by using a redundant bit in the type + map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 4] + +Internet-Draft DNSSEC Opt-In February 2003 + + +3. Protocol Additions + + In RFC 2535, delegation NS RRsets are not signed, but are instead + accompanied by a NXT RRset of the same name, and possibly a + ("no-key") KEY RR [2] or DS record [3]. The security status of the + subzone is determined by the presence of the KEY or DS records, + cryptographically proven by the NXT record. Opt-In expands this + definition by allowing insecure delegations to exist within an + otherwise signed zone without the corresponding NXT record at the + delegation's owner name. These insecure delegations are proven + insecure by using a covering NXT record. + + Since this represents a change of the interpretation of NXT records, + resolvers must be able to distinguish between RFC 2535 NXT records + and Opt-In NXT records. This is accomplished by "tagging" the NXT + records that cover (or potentially cover) insecure delegation nodes. + This tag is indicated by the absence of the NXT bit in the type map. + Since the NXT bit in the type map merely indicates the existence of + the record itself, this bit is redundant and safe for use as a tag. + + An Opt-In tagged NXT record does not assert the (non)existence of the + delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning the NXT chain. However, Opt-In + tagged NXT records do assert the (non)existence of other RRsets. + + An Opt-In NXT record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map, or the presence of a "no-key" KEY + RRset, and the NXT record does assert the existence of the + delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records + and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST + NOT be any insecure delegations (or any other records) between it and + the RRsets indicated by the 'next domain name' in the NXT RDATA. If + it is Opt-In, there MUST only be insecure delegations between it and + the next node indicated by the 'next domain name' in the NXT RDATA. + + In summary, + + o An Opt-In NXT type is identified by a zero-valued (or + not-specified) NXT bit in the type bit map of the NXT record. + + o A RFC2535 NXT type is identified by a one-valued NXT bit in the + type bit map of the NXT record. + + and, + + + +Arends, et al. Expires August 28, 2003 [Page 5] + +Internet-Draft DNSSEC Opt-In February 2003 + + + o An Opt-In NXT record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + + o An Opt-In NXT record does assert the (non)existence of RRsets with + the same owner name. + + +3.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +3.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NXT record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. + +3.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NXT RRset in the Authority section. + + This presents a change from RFC 2535, where the "no-key" KEY RRset + would be returned instead. However, in the delegation signer + proposal, NXT records already must be returned along with the + insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NXT record will have a different + owner name from the delegation RRset. This may require + implementations to do a NXT search on cached responses. + +3.1.3 Wildcards and Opt-In + + RFC 2535, in section 5.3, describes the practice of returning NXT + records to prove the non-existence of an applicable wildcard in + non-existent name responses. This NXT record can be described as a + "negative wildcard proof". The use of Opt-In NXT records changes the + necessity for this practice. For non-existent name responses when the + query name (qname) is covered by an Opt-In tagged NXT record, servers + MAY choose to omit the wildcard proof record, and clients MUST NOT + treat the absence of this NXT record as a validation error. + + The intent of the RFC 2535 negative wildcard proof requirement is to + prevent malicious users from undetectably removing valid wildcard + responses. In order for this cryptographic proof to work, the + resolver must be able to prove: + + + +Arends, et al. Expires August 28, 2003 [Page 6] + +Internet-Draft DNSSEC Opt-In February 2003 + + + 1. The exact qname does not exist. This is done by the "normal" NXT + record. + + 2. No applicable wildcard exists. This is done by returning a NXT + record proving that the wildcard does not exist (negative + wildcard proof). + + However, if the NXT record covering the exact qname is an Opt-In NXT + record, the resolver will not be able to prove the first part of this + equation, as the qname might exist as an insecure delegation. Thus, + since the total proof cannot be completed, the negative wildcard + proof record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NXT record does not change the + practice of returning a NXT along with a wildcard expansion. Even + though the Opt-In NXT will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +3.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [7]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NXT chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NXT records. + +3.2 Client Considerations + + Opt-In imposes some new requirements on DNS resolvers (caching or + otherwise). + +3.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NXT + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NXT record's span that + are not NS records or corresponding glue records. + +3.2.2 Validation Process Changes + + + + +Arends, et al. Expires August 28, 2003 [Page 7] + +Internet-Draft DNSSEC Opt-In February 2003 + + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NXT records to + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In RFC 2535, the security status is proven by existence of a + verified "no-key" KEY RRset. The absence of the "no-key" KEY + RRset indicates that the referred-to zone is secure. + + o Using Delegation Signer, the security status is proven by the + existence or absence of a DS RRset at the same name as the + delegation. The existence of the DS RRset indicates that the + referred-to zone is secure. The absence of the DS RRset is proven + using a verified NXT record of the same name that does not have + the DS bit set in the type map. This NXT record MAY also be + tagged as Opt-In. + + o Using Opt-In, the security status is proven by the existence of a + DS record (for secure) or the presence of a verified Opt-In tagged + NXT record that covers the delegation name. That is, the NXT + record does not have the NXT bit set in the type map, and the + delegation name falls between the NXT's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the subzone is secure or insecure. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NXT record, the resolver MUST NOT require proof (in the form + of a NXT record) that a wildcard did not exist. + +3.2.3 NXT Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NXT record when returning referrals that need them. This + requirement differs from Delegation Signer in that the covering NXT + will not have the same owner name as the delegation. Some + implementations may have to use new methods for finding these NXT + records. + +3.2.4 Use of the AD bit + + The AD bit, as defined by [4], MUST NOT be set when: + + o sending a non-existent name (NXDOMAIN) response where the covering + + + +Arends, et al. Expires August 28, 2003 [Page 8] + +Internet-Draft DNSSEC Opt-In February 2003 + + + NXT is tagged as Opt-In. + + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NXT record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NXT record actually proves. + For names that exist between the Opt-In NXT record's owner and "next" + names, the Opt-In NXT record cannot prove the non-existence or + existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 9] + +Internet-Draft DNSSEC Opt-In February 2003 + + +4. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for both "no-key" + KEY (in [2]) and NXT records for insecure delegations. This, in a + zone with a large number of delegations to unsigned subzones, can + lead to substantial space savings (both in memory and on disk). + Additionally, Opt-In allows for the addition or removal of insecure + delegations without modifying the NXT record chain. Zones that are + frequently updating insecure delegations (e.g., TLDs) can avoid the + substantial overhead of modifying and resigning the affected NXT + records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 10] + +Internet-Draft DNSSEC Opt-In February 2003 + + +5. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NXT records are tagged as Opt-In. + + Example A: Fully DS/Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. SIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. SIG NS ... + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY + EXAMPLE. SIG NXT ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. SIG A ... + FIRST-SECURE.EXAMPLE. NXT NOT-SECURE-2.EXAMPLE. A SIG + FIRST-SECURE.EXAMPLE. SIG NXT ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NXT SECOND-SECURE.EXAMPLE NS SIG + NOT-SECURE-2.EXAMPLE SIG NXT ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. SIG DS ... + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. SIG NXT ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., + "FIRST-SECURE.EXAMPLE A"), or a secure delegation + ("WWW.SECOND-SECURE.EXAMPLE A") will result in a standard RFC 2535 + response. + + A query for a nonexistent RRset will result in a response that + differs from RFC 2535 by: the NXT record will be tagged as Opt-In, + there may be no NXT record proving the non-existence of a matching + wildcard record, and the AD bit will not be set. + + + + +Arends, et al. Expires August 28, 2003 [Page 11] + +Internet-Draft DNSSEC Opt-In February 2003 + + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NXT record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG DS + SECOND-SECURE.EXAMPLE. SIG NXT ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NXT record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NXT record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT + + However, the other NXT records (FIRST-SECURE.EXAMPLE. and + SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are + insecure delegations in the range they define. (NOT-SECURE.EXAMPLE. + and UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is + part of the NXT chain and also covered by an Opt-In tagged NXT + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + removed from the zone without modifying and resigning the prior NXT + record. Delegations with names that fall between + NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or + removed without resigning any NXT records. + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 12] + +Internet-Draft DNSSEC Opt-In February 2003 + + +6. Transition Issues + + Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant + DNSSEC implementations will not recognize Opt-In tagged NXT records + as different from RFC 2535 NXT records. Because of this, RFC 2535 + implementations will reject all Opt-In insecure delegations within a + zone as invalid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 13] + +Internet-Draft DNSSEC Opt-In February 2003 + + +7. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilites are described in more detail in [10] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NXT record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 14] + +Internet-Draft DNSSEC Opt-In February 2003 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY + EXAMPLE. SIG NXT ... + + Additional Section: + + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 15] + +Internet-Draft DNSSEC Opt-In February 2003 + + +8. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 16] + +Internet-Draft DNSSEC Opt-In February 2003 + + +9. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 17] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-12 (work in progress), + December 2002. + + [4] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", + draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 18] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Informative References + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [8] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [9] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name + System", draft-ietf-dnsext-dns-threats-02 (work in progress), + November 2002. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 19] + +Internet-Draft DNSSEC Opt-In February 2003 + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 20] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NXT records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and the + zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + + V_A is the secure view as described above. + + V_B is the insecure view as described above. + + R_A is a response generated from V_A, following RFC 2535 [2]. + + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + + R_C is the response generated by combining R_A with R_B, as + described below. + + A query is DNSSEC-aware if it either has the DO bit [9] turned on, + or is for a DNSSEC-specific record type. + + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + + 2. Generate R_A. + + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + + 4. Generate R_B and combine it with R_A to form R_C: + + + +Arends, et al. Expires August 28, 2003 [Page 21] + +Internet-Draft DNSSEC Opt-In February 2003 + + + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + + 5. Return R_C. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 22] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Appendix B. Changes from Prior Versions + + Changes from version 04: + + Added definitions for "signed name" and "unsigned name". + + Added text to make it clear that insecure delegations may have + Opt-In NXT records of the same name. Updated the example to have + one of these. + + Changed Server-side requirements from MUST NOT to SHOULD NOT and + added some basic description of what action to take in the face of + violating the delegation-only restriction. + + Relaxed requirement that servers drop negative wildcard proof from + MUST to MAY, reiterated the client requirement. + + Added section on Dynamic Update declaring it to be undefined wrt + Opt-In. + + Essentially rewrote the "Security Considerations" section. It does + not actually say anything different, but hopefully it says it in a + clearer fashion. + + Split references into Normative and Informative. + + Fixed the example zone and responses to match Delegation Signer. + + Changes from version 03: + + Editorial changes for clarification only. + + Changes from version 02: + + Added text on changes to validation process, use of the AD bit, + and interactions with wildcards. Added wildcard caveats to the + "Security Considerations" section. Added "Transition Issues" + section. + + Changes from version 01: + + Changed to "delegation only". Strengthened "Security + Considerations" section. Added "Server Considerations" and "Client + Considerations" sections. Added AD bit requirement. + + Changes from version 00: + + Complete rewrite, altering approach from "views" to tagged NXT + + + +Arends, et al. Expires August 28, 2003 [Page 23] + +Internet-Draft DNSSEC Opt-In February 2003 + + + records + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 24] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires August 28, 2003 [Page 25] + +Internet-Draft DNSSEC Opt-In February 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 26] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt new file mode 100644 index 0000000000..2f04c08feb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-01.txt @@ -0,0 +1,2296 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: September 1, 2003 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + March 3, 2003 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-01 + +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. + + This Internet-Draft will expire on September 1, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describes the + DNS Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + + + +Arends, et al. Expires September 1, 2003 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6 + 2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7 + 2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10 + 3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11 + 3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11 + 3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12 + 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12 + 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13 + 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13 + 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13 + 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15 + 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15 + 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23 + 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 + 5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 + 5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27 + 5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27 + 5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28 + 5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 + 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31 + 5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31 + + + +Arends, et al. Expires September 1, 2003 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32 + 5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + Normative References . . . . . . . . . . . . . . . . . . . . 37 + Informative References . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 + A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 41 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) modify several aspects of the + DNS protocol. Section 2 defines the concept of a signed zone and + lists the requirements for zone signing. Section 3 describes the + modifications to authoritative name server behavior necessary to + handle signed zones. Section 4 describes the behavior of entities + which include security-aware resolver functions Finally, Section 5 + defines how to use DNSSEC RRs to authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [1] and RFC1035 [2]. + + This document is part of a family of documents which define the DNS + security extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. An + introduction to DNSSEC and definition of common terms can be found in + [9]. A definition of the DNSSEC resource records can be found in + [10]. This document defines the DNSSEC protocol modifications. + +1.2 Reserved Words + + 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. [4]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + + Use of NXT RRs throughout this document set will have to be modified + if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT + record requires input from the working group. This text describes + the NXT record as it was defined in RFC 2535, and substantial + portions of this document would need to be updated to incorporate + opt-in. The updates will be made if the WG adopts opt-in. + + Use of the AD bit requires input from the working group. Since the + AD bit usage is not resolved, this text attempts to capture current + ideas and drafts, but further input from the working group is + required. + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + + + +Arends, et al. Expires September 1, 2003 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +2. Zone Signing + + DNSSEC defines the concept of a signed zone. A signed zone includes + KEY, SIG, NXT and (optionally) DS records according to the rules + specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4, + respectively. Any zone which does not include these records + according to the rules in this section must be considered unsigned. + + Editors' note: Should this be "MUST be considered unsigned"? + + DNSSEC requires a change to the definition of the CNAME resource + record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to + appear at the same owner name as a CNAME RR. + + Section 2.6 shows a sample signed zone. + +2.1 Including KEY RRs in a Zone + + Editors' note: Unresolved inconsistency between paragraphs in this + section, regarding non-zone KEY RRs at the zone apex. SHOULD NOT, + or MUST NOT? + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create SIG RRs, there SHOULD be a corresponding KEY RR stored at the + zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone + key KEY RR has the Zone Key bit of the Flags RDATA field set to one. + See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the + zone apex. + + A signed zone MUST have at least one zone key KEY RR in its apex KEY + RRset. The KEY RRset at the zone apex MUST be self-signed by at + least one private key whose corresponding public key is a zone key + stored in the apex KEY RRset. + + Editors' note: The requirement listed in this paragraph may not be + necessary anymore, since the KEY RRset is self-signed anyway + (because the whole zone is signed). This is probably a pre-DS + relic, but we spotted this a few hours before the I-D deadline and + were too chicken to remove it on such short notice.... + + Other public keys associated with other DNS operations can be stored + in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs + MUST NOT appear at delegation names. Non-zone key KEY RRs also + SHOULD NOT appear at the zone apex, because large KEY RRsets add + processing time at resolvers. Non-zone key KEY RRs MAY appear at any + other name in the zone. + + + +Arends, et al. Expires September 1, 2003 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +2.2 Including SIG RRs in a Zone + + For each authoritative RRset in the zone (which excludes NS RRsets at + delegation points and glue RRsets), there MUST be at least one SIG + record that meets all of the following requirements: + + o The SIG owner name is equal to the RRset owner name; + + o The SIG class is equal to the RRset class; + + o The SIG Type Covered field is equal to the RRset type; + + o The SIG Original TTL field is equal to the TTL of the RRset; + + o The SIG RR's TTL is equal to the TTL of the RRset; + + o The SIG Labels field is equal to the number of labels in the RRset + owner name, not counting the null root label or any wildcard + label; + + o The SIG Signer's Name field is equal to the name of the zone + containing the RRset; and + + o The SIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key KEY record at the zone apex. + + The process for constructing the SIG RR for a given RRset is + described in [10]. An RRset MAY have multiple SIG RRs associated + with it. + + A SIG RR itself MUST NOT be signed, since signing a SIG RRset would + add no value and would create an unterminated dependency loop in the + signing process. + + The NS RRset which appears at the zone apex name MUST be signed, but + the NS RRsets which appear at delegation points (that is, the NS + RRsets in the parent zone which delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + The difference between the set of owner names which require SIG + records and the set of owner names which require NXT records is + subtle and worth highlighting. SIG records are present at the owner + names of all authoritative RRsets. NXT records are present at the + owner names of all names for which the signed zone is authoritative + and also at the owner names of delegations from the signed zone to + its children. Neither NXT nor SIG records are present (in the parent + zone) at the owner names of glue address RRsets. Note, however, that + + + +Arends, et al. Expires September 1, 2003 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + this distinction is for the most part only visible during the zone + signing process, because NXT RRsets are authoritative data, and + therefore are signed, thus any owner name which has an NXT RRset will + have SIG RRs as well in the signed zone. + +2.3 Including NXT RRs in a Zone + + Each owner name in the zone MUST have an NXT resource record, except + for the owner names of any glue address RRsets. The process for + constructing the NXT RR for a given name is described in [10]. + +2.4 Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a key used by the child zone to sign its apex KEY + RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT + appear at non-delegation points nor at a zone's apex. + + A DS RR SHOULD point to a KEY RR which is present in the child's apex + KEY RRset, and the child's apex KEY RRset SHOULD be signed by the + corresponding private key. + + Construction of a DS RR requires knowledge of the corresponding KEY + RR in the child zone, which implies communication between the child + and parent zones. This communication is an operational matter not + covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + SIG and NXT RRsets are REQUIRED at that name. Other types MUST NOT + be present at that name. + + This is a modification to the original CNAME definition given in [1]. + The original definition of the CNAME RR did not allow any other types + to co-exist with a CNAME record, but a signed zone requires NXT and + SIG RRsets for every authoritative name. To resolve this conflict, + the definition of the CNAME resource record is hereby modified to + allow for the co-existence of NXT and SIG RRsets. + +2.6 Example of a Secure Zone + + {{secure zone here}} + + Editors' note: Zone file example deferred pending hackery to add + zone files in a format usable by xml2rfc. Goal here is to show a + + + +Arends, et al. Expires September 1, 2003 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + (small) complete signed zone. + + The apex KEY set includes two KEY RRs, and the KEY RDATA Flags + indicate that each of these KEY RRs is a zone key. The first zone + KEY is used to sign the apex KEY RRset, and a DS record for this key + is provided to the parent zone. The second zone KEY is used to sign + all the other RRsets in the zone. A non-zone KEY RR is also stored + at "host1.example.com"; this KEY might be used by SIG(0) to + authenticate transactions from this host. + + The zone includes a wildcard entry "*.a.example.com". Note that the + "*.a.example.com" name is used in constructing NXT chains, and that + the SIG covering the "*.a.example.com" MX RRset has a label count of + 3. + + The zone also includes two delegations. The delegation to + "insecure.example.com" includes an NS RRset, glue address records, + and an NXT RR, but note that only the NXT RRset is signed. The + "secure.example.com" delegation provides a DS RR, and note that only + NXT and DS RRsets are signed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +3. Serving + + This section describes the behavior of a security-aware authoritative + name server. A security-aware authoritative name server MUST support + the EDNS0 [6] message size extension, MUST support a message size of + at least 1220 octets, and SHOULD support a message size of 4000 + octets [8]. Since functions specific to security-aware recursive + name servers included components of both resolving and serving, + issues specific to security-aware recursive name servers are + described in Section 4. + + Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR + DO [7] bit set to one, a security-aware authoritative name server for + a signed zone MUST include additional SIG, NXT, and DS RRs according + to the following rules: + + o SIG RRs which can be used to authenticate a response MUST be + included in the response automatically according to the rules in + Section 3.1; + + o NXT RRs which can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.3; + + o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be + included in referrals automatically according to the rules in + Section 3.4. + + DNSSEC does not change the DNS zone transfer protocol. Zone transfer + requirements are reviewed in Section 3.6. + + A security-aware name server which receives a DNS query which does + not include the EDNS OPT pseudo-RR, or which has the DO bit set to + zero, MUST treat the SIG, KEY, and NXT RRs as it would any other + RRset, and MUST NOT perform any of the additional processing + described above. Since the DS RR type has the peculiar property of + only existing in the parent zone at delegation points, DS RRs always + require some special processing, as described in Section 3.5. + +3.1 Including SIG RRs in a Response + + When a query has the DO bit set to one, the authoritative name server + SHOULD attempt to send SIG RRs which can be used to authenticate the + RRsets in the response. Inclusion of SIG RRs in a response is + subject to the following rules: + + o When a signed RRset is placed in the Answer section, its SIG RRs + are also placed in the Answer section. The SIG RRs have a higher + + + +Arends, et al. Expires September 1, 2003 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + priority for inclusion than any other RRsets which may need to be + included. If space does not permit the inclusion of these SIG + RRs, the response MUST be considered truncated, and the TC bit + MUST be set. + + o When a signed RRset is placed in the Authority section, its SIG + RRs are also placed in the Authority section. The SIG RRs have a + higher priority for inclusion than any other RRsets that may need + to be included. If space does not permit the inclusion of these + SIG RRs, the response MUST be considered truncated, and the TC bit + MUST be set. + + o When a signed RRset is placed in the Additional section, its SIG + RRs are also placed in the Additional section. If space does not + permit the inclusion of these SIG RRs, the response MUST NOT be + considered truncated just because these SIG RRs didn't fit. + + +3.2 Including KEY RRs In a Response + + When a query has the DO bit set to one and requests the SOA or NS RRs + at the apex of a signed zone, then a security-aware authoritative + name server for that zone SHOULD return the KEY RRset with the same + name in the Additional section. If Additional section processing + results in more data than will fit in the response message, address + glue RRs have higher priority than KEY RRs. SIG RR(s) associated + with the KEY RRset SHOULD also be included in the Additional section + (see Section 3.1). + + Editors' note: Didn't the WG decide that DS RR removes the need + for Additional section processing for KEY RRs? If so, this + subsection should be deleted. + + +3.3 Including NXT RRs In a Response + + Editors' note: This whole section uses the phrase "query name + exists", which is somewhat ambiguous when discussing internal + nodes with no RRs. We are reasonably certain that, as used here, + the phrase only refers to names which are the owner name for least + one RR. Better phrasing needed. + + When a query has the DO bit set to one, security-aware authoritative + name servers for a signed zone MUST include NXT RRs in each of the + following cases: + + Case 1: The query name exists, but the requested RR type does not + exist. + + + +Arends, et al. Expires September 1, 2003 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + Case 2: The query name does not exist, and no wildcard can be + expanded to answer the query. + + Case 3: The query name does not exist, but a wildcard can be expanded + to positively answer the query. + + Note that, in each case, a set of NXT RRs is included to provide + authenticated denial of existence. + + NXT RRs are also included in a referral response when no DS RR is + present; in this case, the NXT RR proves that no DS RR exists for the + delegation. Referrals are discussed in more detail in Section 3.4. + +3.3.1 Case 1: Query Name Exists, but RR Type Not Present + + If the query name exists but the requested RR type is not present at + the name, then the NXT RR associated with the query name MUST be + included in the Authority section. Any SIG(s) associated with the + NXT RRset are also included in the Authority section (see Section + 3.1) If space does not permit the inclusion of the NXT RR (or its + associate SIG RRs), the response MUST be considered truncated and the + TC bit MUST be set. + + Note that, since the query name exists, no wildcard expansion applies + to this query, and a single NXT RR suffices to prove the requested + type does not exist. + +3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches + + If the query name does not exist, and no wildcard expansion matches + the query, then the Authority section of the response MUST include + the following NXT RRs: + + o An NXT RR proving that there was no exact match for the name; and + + o An NXT RR proving that there was no wildcard which would have + matched the query. + + If space does not permit the inclusion of these NXT RRs, the response + MUST be considered truncated, and the TC bit MUST be set. Any SIG(s) + associated with the NXT RRsets MUST also be included in the Authority + section (see Section 3.1). + + Editors' note: Should lack of space to include the SIGs cause the + packet to be considered truncated? + + Appendix A provides an algorithm which computes the appropriate NXT + RRs to prove that no wildcard matches a given query name. + + + +Arends, et al. Expires September 1, 2003 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches + + If the query name does not exist, but a wildcard expansion can be + used to return a positive match to the query, then the wildcard- + expanded answer and any SIG RRs associated with the wildcard RR MUST + be returned in the Answer section. The Authority section of the + response MUST include the following NXT RRs: + + o An NXT RR which proves that there were no exact matches for the + QNAME and QTYPE; and + + o An NXT RR which proves that there are no closer wildcard entries + which could have been expanded to match the query. + + If space does not permit inclusion of these NXT RRs, the response + MUST be considered truncated, and the TC bit MUST be set. Any SIG + RRs associated with the NXT RRsets MUST also be included in the + response. + + Editors' note: Should lack of space to include the SIGs cause the + packet to be considered truncated? + + Appendix A provides an algorithm which computes the appropriate NXT + RRs to prove that no closer wildcard matches the query name. + +3.4 Including DS RRs In a Response + + When a query has the DO bit set to one, and a DS RR exists at the + query name, an authoritative security-aware name server returning a + referral for the delegation MUST include both the NS RRset and also + the DS RRset and its associated SIG RR(s). The NS RRset MUST be + placed before the DS RRset and its associated SIG RRs. + + When a query has the DO bit set to one, and no DS RR exists at the + query name, an authoritative security-aware name server returning a + referral for the delegation MUST include both the NS RRset and also + the NXT RR and associated SIG RR(s) which proves that the DS RRset + does not exist. The NS RRset MUST be placed before the NXT RRset and + its associated SIG RR(s). + + This increases the size of referral messages, and may cause some or + all glue RRs to be omitted. If space does not permit the inclusion + of the DS or NXT RRset and associated SIG RRs, the response MUST be + considered truncated, and the TC bit MUST be set. + +3.5 Responding to Queries for DS RRs + + The DS record is the first resource record type which appears only on + + + +Arends, et al. Expires September 1, 2003 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + the parent zone's side of a zone cut. In other words, the DS record + for the delegation of "example.com" is only stored in the "com" zone. + This introduces novel name server behavior, since the name server for + the child zone is authoritative for the name by the normal DNS rules + but the child zone does not contain the DS RR. A name server's + response to a DS query depends on whether the name server is + authoritative for the parent zone, the child zone, or both, as + described below. + + If a name server is authoritative for the parent zone, and receives a + query for the DS record at the delegated name, then the name server + MUST return the DS RRset from the parent zone. This rule applies + regardless of whether or not the name server is also authoritative + for the child zone. + + If the name server is authoritative for the child zone, is not + authoritative for the parent zone, and receives a query for the DS + record at the delegated name, there is no obvious response, because + the child zone is not authoritative for the DS record at the child + zone's apex, and the authoritative DS RR is only stored at the + parent. + + If the name server allows recursion, and the RD bit is set in the + query, the name server MAY perform recursion to find the DS record + for the delegated name from the parent zone, and MAY return the DS + record from its cache. In this case, the AA bit MUST NOT be set in + the response. + + If the name server does not perform recursion to find the DS RR, the + name server MUST reply with: + + RCODE: NOERROR + AA bit: set + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + In other words, a name server which is authoritative for the child + zone but not for the parent zone answers as if the DS record does not + exist. Note that security-aware resolvers will query the parent zone + at delegation points, and thus will not be affected by this behavior. + + For example, suppose that "example.com" is a delegation point, and a + name server receives a query for the "example.com" DS RRset. + + o If the name server is authoritative for "com", the name server + MUST reply with the "example.com" DS RRset from the "com" zone. + + o If the name server is authoritative for "example.com", is not + + + +Arends, et al. Expires September 1, 2003 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + authoritative for "com", and the RD bit is set to one in the + query, the name server MAY perform recursion to find the + "example.com" DS record. If the name server does not use + recursion to obtain the DS RR, the name server MUST reply as + though the DS RR did not exist: + + RCODE: NOERROR + AA bit: set + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + +3.6 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain SIG, KEY, NXT, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation, and these RRs are treated as any other resource record + type. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails meets any of the signing requirements + described in Section Section 2. The primary objective of a zone + transfer to ensure that all authoritative name servers have identical + copies of the zone. An authoritative name server which chooses to + perform its own zone validation MUST NOT selectively reject some RRs + and accept others. + + Note that the DS RR appears only in the parental side of a + delegation, and is authoritative data in the parent zone. For + example, the DS RR for "example.com" is stored in the "com" zone (the + parent zone) rather than in the "example.com" zone (the child zone). + As with any other authoritative RRset, the "example.com" DS RR MUST + be included the "com" zone transfer. + + Note that authoritative NXT RRs appear in both the parent and child + zones at a delegated name, and that the NXT RRs for the delegated + name in the parent and child zones are never identical to each other. + As with any other authoritative RRset, the parental NXT RR at a + delegated name MUST be included zone transfers of the parent zone, + while the NXT at the zone apex of the child zone MUST be included in + zone transfers of the child zone. + +3.7 Setting the AD and CD Bits in a Response + + Editors' note: This section seems a little lost here. Perhaps we + + + +Arends, et al. Expires September 1, 2003 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + should rearrange the section ordering slightly, or provide a + pointer to this subsection at the beginning of Section 3. + + DNSSEC allocates two new bits in the DNS message header: The CD + (Checking Disabled) bit and the AD (Authentic Data) bit. + + The CD bit is set in query messages by the resolver, and MUST be + copied into the response. If the CD bit is set to one, it indicates + that the resolver is willing to perform authentication, and thus that + the name server need not perform authentication on the RRsets in the + response. + + Regardless of the setting of the CD bit, the name server MAY choose + whether or not to perform authentication according to the local name + server policy. The CD bit MAY be used in constructing the local name + server policy. If local name server policy does perform + authentication, any RRsets rejected by the local authentication + policy MUST NOT be returned in a response (regardless of the CD bit). + + The AD bit is set by name servers, and indicates the data in the + response has been authenticated by the name server, according to the + local name server policy. The AD bit MUST NOT be set on a response + unless all of the RRsets in the Answer and Authority sections have + met the name server's local authentication policy. A resolver MUST + NOT trust the AD bit unless it communicates with the name server over + a secure transport mechanism and is explicitly configured to trust + the name server's policy. + +3.8 Example DNSSEC Responses + + The examples in this section use the following example zone to + demonstrate the formation of replies by an authoritative name server. + The zone has two name servers, a single child, and a wildcard MX RR. + The zone is completely signed and has a full NXT chain. + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + example.com. SOA (...) + SIG SOA ... + NS a.example.com. + NS b.example.com. + SIG NS ... + MX 10 a.example.com + SIG MX ... + KEY ... + SIG KEY ... + NXT *.example.com. + * MX 10 a.example.com. + SIG MX ... + NXT a.example.com. + a A 10.10.10.1 + SIG A ... + NXT b.example.com. + b A 10.10.10.2 + SIG A ... + NXT c.example.com. + c CNAME a.example.com. + SIG CNAME + NXT sub.example.com. + sub NS ns.sub.example.com. + SIG NS + DS ... + SIG DS + NXT *.example.com. + ns.sub A 10.10.10.3 + sub-nosig NS ns.sub-nosig.example.com. + NXT example.com. + ns.sub-nosig A 10.10.10.4 + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + A query to the authoritative name server for this zone for + QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce: + + Flags: QR=1, AA=1, RCODE=0 (NOERROR) + EDNS: DO=1, size=4000 + QUERY: + c.example.com. IN A + ANSWER: + c.example.com. IN A a.example.com + IN SIG CNAME + a.example.com. IN A 10.10.10.1 + IN SIG A + AUTHORITY: + example.com. IN NS a.example.com. + IN NS b.example.com. + IN SIG NS ... + ADDITIONAL: + a.example.com. IN A 10.10.10.1 + IN SIG A ... + b.example.com. IN A 10.10.10.2 + IN SIG A ... + example.com. IN KEY ... + IN SIG KEY ... + + A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would + results in a referral to a signed zone. The resolver can determine + that "sub.example.com" is signed because of the presence of the DS RR + with the hash of the "sub.example.com" zone key. + + Flags: QR=1, AA=1, RCODE=0 (NOERROR) + EDNS: DO=1, size=4000 + QUERY: + www.sub.example.com. IN A + ANSWER: + ;; empty + AUTHORITY: + sub.example.com. IN NS ns.sub.example.com. + IN DS ... + IN SIG DS ... + ADDITIONAL: + ns.sub.example.com. IN A 10.10.10.3 + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A + would result in a referral to an unsigned zone. The resolver knows + not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS + bit in the NXT RR bitmap in the referral is not set. Even if DNSSEC + RRs are present in responses from "sub-nosig.example.com" name + servers, the resolver will not be able to construct a authentication + chain, since there is a break between "sub-nosig.example.com" and its + delegating parent zone. + + Flags: QR=1, AA=1, RCODE=0 (NOERROR) + EDNS: DO=1, size=4000 + QUERY: + www.sub-nosig.example.com. IN A + ANSWER: + ;; empty + AUTHORITY: + sub-nosig.example.com. IN NS ns.sub-nosig.example.com. + IN NXT ;; (DS bit not set) + IN SIG NXT ... + ADDITIONAL: + ns.sub-nosig.example.com. IN A 10.10.10.4 + + A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name + error, because the name does not exist and is not covered by wildcard + expansion. Therefore, the name server must present proof that the + name does not exist, and that no wildcard expansion is present which + could have been used to answer the query. + + Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN) + EDNS: DO=1, size=4000 + QUERY: + f.example.com. IN A + ANSWER: + ;; empty + AUTHORITY: + example.com. IN SOA ... + IN SIG SOA ... + c.example.com. IN NXT sub.example.com. ... + IN SIG NXT ... + *.example.com. IN NXT a.example.com. ... + IN SIG NXT ... + ADDITIONAL: + example.com. IN KEY ... + IN SIG KEY ... + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX + RR synthesized via wildcard expansion. The name server must prove + that no exact match exists. + + Flags: QR=1, AA=1, RCODE=0 (NOERROR) + EDNS: DO=1, size=4000 + QUERY: + f.example.com. IN MX + ANSWER: + f.example.com. IN MX 10 a.example.com. + IN SIG MX ... + AUTHORITY: + example.com. IN NS a.example.com. + IN NS b.example.com. + IN SIG NS ... + c.example.com. IN NXT sub.example.com. + IN SIG NXT ... + ADDITIONAL: + a.example.com. IN A 10.10.10.1 + IN SIG A ... + b.example.com. IN A 10.10.10.2 + IN SIG A ... + example.com. IN KEY ... + IN SIG KEY ... + + If these responses came from a recursive name server which had all of + the necessary RRsets in its cache instead of from an authoritative + server, the only differences would be the TTLs and the header flags. + The AA bit would not be set, and the AD bit would be set if (and only + if) all the RRsets in a response passed the security policy checks of + the recursive name server. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +4. Resolving + + Editors' note: This section is still very rough, and some of the + text here duplicates text from other portions of this document. + This needs to be fixed (one way or another) during final editing. + Suggestions for better text would be welcome. + + This section describes the behavior of entities which include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in a + separate subsection. + + A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with + the DO [7] bit set to one when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver + MUST handle fragmented UDP packets correctly regardless of whether + any such fragmented packets were received via IPv4 or IPv6. Please + see [8] for discussion of these requirements. + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and MUST apply them to every + received response except when: + + o The security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + + o The response is the result of a query generated directly via some + form of application interface which instructed the security-aware + resolver not to perform validation for this query; or + + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + A security-aware resolver MUST attempt to retrieve missing DS, KEY, + or SIG RRs via explicit queries if the resolver needs these RRs in + order to perform signature verification. + + A security-aware resolver MUST attempt to retrieve missing a NXT RR + which the resolver needs to authenticate a NODATA response. In + + + +Arends, et al. Expires September 1, 2003 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + general it is not possible for a resolver to retrieve missing NXT + RRs, since the resolver will have no way of knowing the owner name of + the missing NXT RR, but in the specific case of a NODATA response, + the resolver does know the name of the missing NXT RR, and must + therefore attempt to retrieve it. + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between three + cases: + + 1. An RRset for which the resolver is able to build a chain of + signed KEY and DS RRs from a trusted starting point to the RRset. + In this case, the RRset should be signed, and is subject to + signature validation as described above. + + 2. An RRset for which the resolver knows that it has no chain of + signed KEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + 3. An RRset for which the resolver is not able to determine whether + or not the RRset should be signed, because the resolver is not + able to obtain the necessary DNSSEC RRs. This can occur due when + the security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + + A security-aware resolver MUST be capable of being preconfigured with + at least one trusted public key, and SHOULD be capable of being + preconfigured with multiple trusted public keys. Since a security- + aware resolver will not be able to validate signatures without such a + preconfigured trusted key, the resolver SHOULD have some reasonably + robust mechanism for obtaining such keys when it boots. + + Editors' note: Should support for multiple public keys be a MUST + rather than a SHOULD? + + A security-aware resolver SHOULD cache each response as a single + atomic entry, indexed by the triple , with the + single atomic entry containing the entire answer, including the named + RRset and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. + + Editors' note: This is implementation advice which came out of + discussions at various workshops and investigations into possible + implementation issues with the (as yet unsettled) opt-in proposal. + + + +Arends, et al. Expires September 1, 2003 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + All of this advice has been discussed in WG meetings, and as far + as the editors know these recommendations are not controversial, + but it is up to the WG to decide whether this sort of + implementation advice belongs in this document. + + +4.1 Recursive Name Servers + + As explained in [9], a security-aware recursive name server is an + entity which acts in both the security-aware name server and + security-aware resolver roles. This section uses the terms "name + server side" and "resolver side" to refer to the code within a + security-aware recursive name server which implements the security- + aware name server role and the code which implements the security- + aware resolver role, respectively. + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the initiating request does not have the DO bit set, the name server + side MUST remove any DNSSEC RRs from the response sent to the + initiating resolver, but the resolver side MUST follow the usual + rules for caching which would apply to any security-aware resolver. + + A security-aware recursive name server SHOULD NOT attempt to answer a + query by piecing together cached data it received in response to + previous queries that requested different QNAMEs, QTYPEs, or + QCLASSes. A security-aware recursive name server SHOULD NOT use NXT + RRs from one negative response to synthesize a response for a + different query. A security-aware recursive name server SHOULD NOT + use a previous wildcard expansion to generate a response to a + different query. + + Editors' note: Should any of the SHOULD NOTs in this paragraph be + MUST NOTs instead? + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + whether or not it is required to verify the response data it returns + to the name server side. + + Editors' note: What should a security-aware recursive name server + do if it receives a query with CD=1 and DO=0? + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +4.2 Stub resolvers + + A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR + with the DO [7] bit set to one when sending queries. + + A security-aware stub resolver MUST support a message size of at + least 1220 octets, SHOULD support a message size of 4000 octets, and + MUST advertise the supported message size using the "sender's UDP + payload size" field in the EDNS OPT pseudo-RR. A security-aware stub + resolver MUST handle fragmented UDP packets correctly regardless of + whether any such fragmented packets were received via IPv4 or IPv6. + Please see [8] for discussion of these requirements. + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. A security-aware stub resolver MAY include the + DNSSEC RRs returned by a security-aware recursive name server as part + of the data that it the stub resolver hands back to the application + which invoked it, but is not required to do so. + + A security-aware stub resolver SHOULD NOT set the CD bit when sending + queries, since, by definition, a security-aware stub resolver does + not validate signatures and thus depends on the security-aware + recursive name server to perform validation on its behalf. + + Editors' note: Should this SHOULD NOT be a MUST NOT? + + A security-aware stub resolver MUST NOT place any reliance on + signature validation allegedly performed on its behalf except when + the security-aware stub resolver obtained the data in question from a + trusted security-aware recursive name server via a secure channel. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires preconfigured knowledge of at least one + authenticated KEY RR. The process for obtaining and authenticating + this initial KEY RR is achieved via some external mechanism. For + example, a resolver could use some off-line authenticated exchange to + obtain a zone's KEY RR or obtain a DS RR that identifies and + authenticates a zone's KEY RR. The remainder of this section assumes + that the resolver has somehow obtained an initial set of + authenticated KEY RRs. + + An initial KEY RR can be used to authenticate a zone's apex KEY + RRset. To authenticate an apex KEY RRset using an initial key, the + resolver MUST: + + 1. Verify that the initial KEY RR appears in the apex KEY RRset, and + verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7) + set to one. + + 2. Verify that there is some SIG RR which covers the apex KEY RRset, + and that the combination of the SIG RR and the initial KEY RR + authenticates the KEY RRset. The process for using a SIG RR to + authenticate an RRset is described in Section 5.2. + + Once the resolver has authenticated the apex KEY RRset using an + initial KEY RR, delegations from that zone can be authenticated using + DS RRs. This allows a resolver to start from an initial key, and use + DS RRsets to proceed recursively down the DNS tree obtaining other + apex KEY RRsets. If the resolver were preconfigured with a root KEY + RR, and if every delegation had a DS RR associated with it, then the + resolver could obtain any apex KEY RRset. The process of using DS + RRs to authenticate referrals is described in Section 5.1. + + Once the resolver has authenticated a zone's apex KEY RRset, Section + 5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and + SIG RRs from the zone to authenticate any other RRsets in the zone. + Section 5.3 shows how the resolver can use authenticated NXT RRsets + from the zone to prove that an RRset is not present in the zone. + + When a resolver indicates support for DNSSEC, a security-aware name + server should attempt to provide the necessary KEY, SIG, NXT, and DS + RRsets in a response (see Section 3). However, a security-aware + resolver may still receive a response which that lacks the + appropriate DNSSEC RRs, whether due to configuration issues such as a + security-oblivious recursive name server which accidently interfere + with DNSSEC RRs or due to a deliberate attack in which an adversary + forges a response, strips DNSSEC RRs from a response, or modifies a + + + +Arends, et al. Expires September 1, 2003 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + query so that DNSSEC RRs appear not to be requested. The absence of + DNSSEC data in a response MUST NOT by itself be taken as an + indication that no authentication information exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Authenticating Referrals + + Once the apex KEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a KEY RR in the child + zone's apex KEY RRset, and contains a cryptographic digest of the + child zone's KEY RR. A strong cryptographic digest algorithm ensures + that an adversary can not easily generate a KEY RR that matches the + digest. Thus, authenticating the digest allows a resolver to + authenticate the matching KEY RR. The resolver can then use this + child KEY RR to authenticate the entire child apex KEY RRset. + + Given a DS RR for a delegation, the child zone's apex KEY RRset can + be authenticated if all of the following hold: + + o The DS RR has been authenticated using some KEY RR in the parent's + apex KEY RRset (see Section 5.2); + + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a KEY RR in the child zone's apex KEY RRset + which, when hashed using the digest algorithm specified in the DS + RR's Digest Type field, results in a digest value which matches + the Digest field of the DS RR; and + + o The matching KEY RR in the child zone has the Zone Flag bit set to + one, the corresponding private key has signed the child zone's + apex KEY RRset, and the resulting SIG RR authenticates the child + zone's apex KEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NXT RRset proving that no DS + RRset exists for the delegated name (see Section 3.4). A security- + aware resolver MUST send the parent a query for the DS RRset if the + referral includes neither a DS RRset nor a NXT RRset proving the + nonexistence of the DS RRset (see Section 4). + + If the resolver authenticates an NXT RRset which proves that no DS + RRset is present for this zone, then there is no authentication path + + + +Arends, et al. Expires September 1, 2003 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + leading from the parent to the child. If the resolver has an initial + KEY RR which belongs to the child zone or to any delegation below the + child zone, this initial KEY RR MAY be used to re-establish an + authentication path. If no such initial KEY RR exists, the resolver + can not authenticate RRsets at or below the child zone. + + Note that, for a signed delegation, there are two NXT RRs associated + with the delegated name. One NXT RR resides in the parent zone, and + can be used to prove whether a DS RRset exists for the delegated + name. The second NXT RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NXT RR and child NXT RR can always be distinguished, since the SOA + bit will be set in the child NXT RR and clear in the parent NXT RR. + A security-aware resolver MUST use the parent NXT RR when attempting + to prove that a DS RRset does not exist. + +5.2 Authenticating an RRSet Using a SIG RR + + A resolver can use a SIG RR and its corresponding KEY RR to attempt + to authenticate RRsets. The resolver first checks the SIG RR to + verify that it covers the RRset, has a valid time interval, and + identifies a valid KEY RR. The resolver then constructs the + canonical form of the signed data by appending the SIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, resolver uses the public key and signature + to authenticate the signed data. Section 5.2.1, Section 5.2.2, and + Section 5.2.3 describe each step in detail. + +5.2.1 Checking the SIG RR Validity + + A security-aware resolver can use a SIG RR to authenticate an RRset + if all of the following conditions hold: + + o The SIG RR and the RRset MUST have the same owner name and the + same class; + + o The SIG RR's Signer's Name field MUST be the name of the zone that + contains the RRset; + + o The SIG RR's Type Covered field MUST equal the RRset's type; + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the SIG RR's Labels field; + + o The resolver's notion of the current time MUST be less than or + equal to the time listed in the SIG RR's Expiration field; + + o The resolver's notion of the current time MUST be greater than or + + + +Arends, et al. Expires September 1, 2003 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + equal to the time listed in the SIG RR's Inception field; + + o The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some KEY RR in + the zone's apex KEY RRset; + + o The matching KEY RR MUST be present in the zone's apex KEY RRset, + and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one. + + It is possible for more than one KEY RR to match the conditions + above. In this case, the resolver can not predetermine which KEY RR + to use to authenticate the signature, MUST try each matching KEY RR + until the resolver has either validated the signature or has run out + of matching keys to try. + + Note that this authentication process is only meaningful if the + resolver authenticates the KEY RR before using it to validate + signatures. The matching KEY RR is considered to be authentic if: + + o The apex KEY RRset containing the KEY RR is considered authentic; + or + + o The RRset covered by the SIG RR is the apex KEY RRset itself, and + the KEY RR either matches an authenticated DS RR from the parent + zone or matches a DS RR or KEY RR which the resolver has been + preconfigured to believe to be authentic. + + +5.2.2 Reconstructing the Signed Data + + Once the SIG RR has met the validity requirements described in + Section 5.2.1, the resolver needs to reconstruct the original signed + data. The original signed data includes SIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The resolver should use the following to + reconstruct the original signed data: + + signed_data = SIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + SIG_RDATA is the wire format of the SIG RDATA fields with + the Signature field excluded and the Signer's Name in + canonical form. + + RR(i) = name | class | type | OrigTTL | RDATA length | RDATA + + + +Arends, et al. Expires September 1, 2003 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the SIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let sig_labels = the value of the SIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = RRset's fully qualified domain name in + canonical form + + if sig_labels = fqdn_labels, + name = fqdn + + if sig_labels < fqdn_labels, + name = "*." | the leftmost sig_label labels of the + fqdn + + if sig_labels > fqdn + the SIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + Editors' note: The algorithm above needs to be cross-checked very + carefully against the definitions in [10]. + + Section 5.4.1 gives an example of original name calculation. The + canonical forms for names and RRsets are defined in [10]. + + NXT RRsets at a delegation boundary require special processing. + There are two distinct NXT RRsets associated with a signed delegated + name. One NXT RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NXT RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NXT RRset and child NXT RRset can + always be distinguished since only the child NXT RRs will specify an + SOA RRset exists at the name. When reconstructing the original NXT + RRset for the delegation from the parent zone, the NXT RRs MUST NOT + + + +Arends, et al. Expires September 1, 2003 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + be combined with NXT RRs from the child zone, and when reconstructing + the original NXT RRset for the apex of the child zone, the NXT RRs + MUST NOT be combined with NXT RRs from the parent zone. + + Note also that each of the two NXT RRsets at a delegation point has a + corresponding SIG RR with an owner name matching the delegated name, + and each of these SIG RRs is authoritative data associated with the + same zone which contains the corresponding NXT RRset. If necessary, + a resolver can tell these SIG RRs apart by checking the Signer's Name + field. + +5.2.3 Checking the Signature + + Once the resolver has validated the SIG RR as described in Section + 5.2.1 and reconstructed the original signed data as described in + Section 5.2.2, the resolver can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the SIG RR identifies the cryptographic + algorithm to generate the signature. The signature itself is + contained in the Signature field of the SIG RDATA, and the public key + to used generate the signature is contained in the Public Key field + of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a + list of algorithm types, and provides pointers to the documents that + define each algorithm's use. + + Note that it is possible for more than one KEY RR to match the + conditions in Section 5.2.1. In this case, the resolver can only + determine which KEY RR by trying each matching key until the resolver + either succeeds in validating the signature or runs out of keys to + try. + + If the Labels field of the SIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.2.4 describes how + to determine whether a wildcard was applied properly. + + If other SIG RRs also cover this SIG RR, the local resolver security + policy determines whether the resolver also needs to test these SIG + RRs, and determines how to resolve conflicts if these SIG RRs lead to + differing results. + + If the resolver accepts the RRset as authentic, the resolver MUST set + the SIG RR's TTL and the TTL of each RR in the authenticated RRset to + the minimum of: + + + +Arends, et al. Expires September 1, 2003 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + o The RRset's TTL as received in the response; + + o The SIG RR's TTL as received in the response; and + + o The value in the SIG RR's Original TTL field. + + +5.2.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's fully qualified domain name is + greater than the Labels field in the covering SIG RDATA, then the + RRset and its covering SIG RR were created as a result of wildcard + expansion. Once the resolver has verified the signature as described + in Section 5.2, the resolver must take additional steps to verify the + non-existence of an exact match or closer wildcard match for the + query. Section 5.3 discusses these steps. + + Note that the response received by the resolver should include all + NXT RRs needed to authenticate the response (see Section 3.3). + +5.3 Authenticated Denial of Existence + + A resolver can use authenticated NXT RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NXT RRs for signed zones in their + responses to security-aware resolvers. + + Security-aware resolvers MUST first authenticate NXT RRsets according + to the standard RRset authentication rules described in Section 5.2, + then apply the NXT RRsets as follows: + + o If the requested RR name matches the owner name of an + authenticated NXT RR, then the NXT RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. Since the existence of the authenticated NXT + RR proves that the owner name exists in the zone, wildcard + expansion could not have been used to match the requested RR owner + name and type. + + o If the requested RR name would appear after an authenticated NXT + RR owner name and before the name listed in that NXT RR's Next + Domain Name field according to the canonical DNS name order + defined in [10], then no exact match for the requested RR name + exists in the zone. However, it is possible that a wildcard could + be used to match the requested RR owner name and type, so proving + that the requested RRset does not exist also requires proving that + no possible wildcard exists which could have been used to generate + + + +Arends, et al. Expires September 1, 2003 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + a positive response. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NXT RRset from the zone. If the complete set of necessary NXT + RRsets is not present in a response (perhaps due to truncation), then + a security-aware resolver MUST resend the query in order to attempt + to obtain the full collection of NXT RRs necessary to verify non- + existence of the requested RRset. As with all DNS operations, + however, the resolver MUST bound the work it puts into answering any + particular query. + +5.4 Example + +5.4.1 Example of Re-Constructing the Original Owner Name + + Suppose that a security-aware resolver receives a response containing + an answer RRset with an owner name of is "www.a.b.c.example.com". + This fully qualified domain name has 6 labels: "www", "a", "b", "c", + "example", and "com". What name the resolver should use when + reconstructing the original signed data depends on the value of the + SIG RR's Labels field. + + If the value of the SIG RR's Labels field is 6, then the SIG RR's + Labels field matches the number of labels in the owner name, and the + resolver should assume that this RRset is not the result of wildcard + expansion. The resolver should therefore use "www.a.b.c.example.com" + as the owner name when reconstructing the original signed data for + the signature check. + + If the value of the SIG RR's Labels field is less than 6, then the + SIG RR's Labels count is less than the number of labels in the + RRset's owner name, and the resolver should assume that this RRset is + the result of wildcard expansion. The resolver should therefore + reconstruct the original owner name by replacing the labels which + appear to be the result of wildcard expansion with a single "*." + label. For example, if the SIG RR's Labels field is 3, the resolver + should reconstruct the original owner name by prepending "*." to the + last 3 labels of the owner name of the answer RRset. Thus, the + resolver should use "*.c.example.com" as the owner name when + reconstructing the original signed data. + + If the value of the SIG RR's Labels field is greater than 6, then + this SIG RR cannot possibly be valid for the answer RRset, and there + is no point in attempting to validate the signature. + + + + + +Arends, et al. Expires September 1, 2003 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +5.4.2 Examples of Authenticating a Response + + Editors' note: Eventually this will be an example of the + authentication process for "www.example.com", starting from an + initial root key. + + Editors' note: Eventually this will be an example of the + authentication process for non-existent "www.a.b.c.example.com", + starting from an initial root key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +6. IANA Considerations + + This document introduces no IANA considerations. + + [10] contains a complete review of the IANA considerations introduced + by DNSSEC. + + Editors' note: This may not be true anymore, since the AD and CD + bit definitions are now in this document rather than in [10]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + + At this time, at least two substantial elements of the DNSSEC + specification have yet to be decided by the working group. The open + opt-in issue would change elements such as what RRsets must be + signed, would impact how wildcards are used, and would replace + authenticated denial of existence with authenticated denial of + security. Handling of the AD bit is also undecided. The AD bit (as + currently defined) is used to indicate the security status of RRsets + in the response. These items clearly raise security considerations + and will be addressed here as these issues are resolved in the + working group. + + DNSSEC introduces a number of denial of service issues. These issues + will also be addressed in a future version of these security + considerations. + + Please see [9] for general security considerations related to DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +8. Acknowledgements + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group and working group mailing list. + The co-authors of this draft would like to express their thanks for + the comments and suggestions received during the revision of these + security extension specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [8] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [9] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", draft-ietf- + dnsext-dnssec-intro-05 (work in progress), February 2003. + + [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for DNS Security Extensions", draft-ietf- + dnsext-dnssec-records-04 (work in progress), February 2003. + + [11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- + ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +Informative References + + [12] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [14] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [15] Gudmundsson, O., "Delegation Signer Resource Record", draft- + ietf-dnsext-delegation-signer-12 (work in progress), December + 2002. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +Appendix A. Algorithm For Handling Wildcard Expansion + + For zone (Z) and a name (N) that may occur in Z, the following + algorithm finds all wildcard RRsets that match N or returns an NXT + RRset that proves no wildcard expansion matches N. The algorithm was + written for clarity, not efficiency: + + 0. INPUT: a name (N) and a zone (Z). + INIT: NXT_SET = NULL + + 1. Construct S = sequence of all names in Z, sorted + into canonical order. + + 2. If N exists in S + There is an exact match for N. + Return all RRsets associated with N + Else + Add the name that would immediately + precede N in S to NXT_SET. + EndIf + + 3. Replace the leftmost label of N with * + + 4. If N exists in S + There is a positive wildcard match for N. + Return all RRsets associated with N + Else + Add the NXT for name that would immediately + precede N in S to NXT_SET. + EndIf + + 5. Remove the leading * from N. + + 6. If N exists in S + There is a name that terminates the wildcard search. + Add the NXT for N to NXT_SET and return NXT_SET. + Else + Goto Step 3 + EndIf + + Note: the algorithm is guaranteed to terminate since + eventually there will be a match or N will be + reduced to zone name itself and the zone name + must exist in S. + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications March 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires September 1, 2003 [Page 41] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt new file mode 100644 index 0000000000..23475b80c0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-03.txt @@ -0,0 +1,1848 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 26, 2003 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 25, 2003 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-03 + +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. + + This Internet-Draft will expire on August 26, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + + + +Arends, et al. Expires August 26, 2003 [Page 1] + +Internet-Draft DNSSEC Resource Records February 2003 + + + KEY, DS, SIG, and NXT resource records. The purpose and format of + each resource record is described in detail and an example of each + resource record is given. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 + 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6 + 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7 + 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7 + 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9 + 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 + 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12 + 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15 + 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15 + 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16 + 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16 + 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19 + + + +Arends, et al. Expires August 26, 2003 [Page 2] + +Internet-Draft DNSSEC Resource Records February 2003 + + + 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Canonical Form and Order of Resource Records . . . . . . . . 21 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 + 8. Security Considerations . . . . . . . . . . . . . . . . . . 24 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25 + Normative References . . . . . . . . . . . . . . . . . . . . 26 + Informative References . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 3] + +Internet-Draft DNSSEC Resource Records February 2003 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: KEY, SIG, NXT, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + ASCII representation. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in RFC1034 [1] and RFC1035 [2]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication the Domain Name System (DNS). An + introduction to DNSSEC and definition of common terms can be found in + [10]. A description of DNS protocol modifications can be found in + [11]. This document defines the DNSSEC resource records. + +1.2 Reserved Words + + 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 [5]. + +1.3 Editors Notes + +1.3.1 Open Technical Issues + + The NXT section (Section 4) may be updated in the next version if + DNSSEC-Opt-In [13] becomes part of DNSSEC. + + The cryptographic algorithm types (Appendix A) requires input from + the working group. The DSA algorithm was moved to OPTIONAL. This + had strong consensus in workshops and various discussions and a + separate internet draft solely to move DSA from MANDATORY to OPTIONAL + seemed excessive. This draft solicits input on that proposed change. + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + + + +Arends, et al. Expires August 26, 2003 [Page 4] + +Internet-Draft DNSSEC Resource Records February 2003 + + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 5] + +Internet-Draft DNSSEC Resource Records February 2003 + + +2. The KEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in KEY + resource records and are used in the DNSSEC authentication process + described in [11]. In a typical example, a zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a KEY RR. A resolver can then use these signatures to + authenticate RRsets from the zone. + + The KEY RR may also be used to store public keys associated with + other DNS operations such as TKEY [15]. In all cases, the KEY RR + plays a special role in secure DNS resolution and DNS message + processing. The KEY RR is not intended as a record for storing + arbitrary public keys. The KEY RR MUST NOT be used to store + certificates or public keys that do not directly relate to the DNS + infrastructure. Examples of certificates and public keys that MUST + NOT be stored in the KEY RR include X.509 certificates, IPSEC public + keys, and SSH public keys. + + The Type value for the KEY RR type is 25. + + The KEY RR is class independent. + + There are no special TTL requirements on the KEY record. + +2.1 KEY RDATA Wire Format + + The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet + Protocol Field, a 1 octet Algorithm Field , and the Public Key Field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the KEY record holds a DNS zone key and the KEY's owner name + MUST be the name of a zone. If bit 7 has value 0, then the KEY + record holds some other type of DNS public key, such as a public key + + + +Arends, et al. Expires August 26, 2003 [Page 6] + +Internet-Draft DNSSEC Resource Records February 2003 + + + used by TKEY. + + Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of + the KEY RR, and MUST be ignored upon reception. + + Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this + by allocating bit 15 as the KSK bit. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. + +2.1.5 Notes on KEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with an earlier version of the KEY record. + +2.2 The KEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field is represented as an unsigned decimal integer with a + value of either 0 or 256. + + The Protocol Field is represented as an unsigned decimal integer with + a value of 3. + + The Algorithm field is represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + The Public Key field is represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [3] Section 5.2. + +2.3 KEY RR Example + + The following KEY RR stores a DNS zone key for example.com. + + + + +Arends, et al. Expires August 26, 2003 [Page 7] + +Internet-Draft DNSSEC Resource Records February 2003 + + + example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl + +BBZH4b/0PY1kxkmvHjcZc8nokfzj31 + GajIQKY+5CptLr3buXA10hWqTkF7H6R + foRqXQeogmMHfpftf6zMv1LyBUgia7z + a6ZEzOJBOztyvhjL742iU/TpPSEDhm2 + SNKLijfUppn1UaNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the + Flags field has value 1. Value 3 is the fixed Protocol value. Value + 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [8]. The remaining text is a + base 64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 8] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3. The SIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Signatures are stored in SIG resource + records and are used in the DNSSEC authentication process described + in [11]. In a typical example, a zone signs its authoritative RRsets + using a private key and stores the corresponding signatures in SIG + RRs. A resolver can then use these SIG RRs to authenticate RRsets + from the zone. + + A SIG record contains the signature for an RRset with a particular + name, class, and type. The SIG RR specifies a validity interval for + the signature and uses the Algorithm, the Signer's Name, and the Key + Tag to identify the public key (KEY RR) that can be used to verify + the signature. + + The SIG RR may cover a transaction instead of an RRset. In this + case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear + in any zone, and its use and processing are outside the scope of this + document. Please see [7] for further details. + + The Type value for the SIG RR type is 24. + + The SIG RR MUST have the same class as the RRset it covers. + + The SIG RR TTL value SHOULD match the TTL value of the RRset it + covers. + +3.1 SIG RDATA Wire Format + + The RDATA for a SIG RR consists of a 2 octet Type Covered field, a 1 + octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL + field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type Covered | Algorithm | Labels | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original TTL | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Expiration | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + + + +Arends, et al. Expires August 26, 2003 [Page 9] + +Internet-Draft DNSSEC Resource Records February 2003 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset which is + covered by this SIG record. + + If Type Covered field has a value of 0, the record is referred to as + a transaction signature; please see [7] for further details. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original SIG + RR owner name. It is included to handle signatures associated with + wildcard owner names. + + To validate a signature, the validator requires the original owner + name that was used when the signature was created. If the original + owner name contains a wildcard label ("*"), the owner name may have + been expanded by the server during the response process, in which + case the validator will need to reconstruct the original owner name + in order to validate the signature. [11] describes how to use the + Labels field to reconstruct the original owner name. + + The value of the Label field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Label field MUST be less than or equal to + the number of labels in the SIG owner name. For example, + "www.example.com." has a Label field value of 3, and "*.example.com." + has a Label field value of 2. Root (".") has a Label field value of + 0. + + Note that, although the wildcard label is not included in the count + stored in the Label field of the SIG RR, the wildcard label is part + of the RRset's owner name when generating or verifying the signature. + + + +Arends, et al. Expires August 26, 2003 [Page 10] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a resolver requires the original TTL. [11] describes how + to use the Original TTL field value to reconstruct the original TTL. + + The Original TTL value MUST be greater than or equal to the TTL value + of the SIG record itself. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The SIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format, a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. A SIG RR can have an Expiration + field value which is numerically smaller than the Inception field + value if the expiration field value is near the 32-bit wrap-around + point or if the signature is long lived. Because of this, all + comparisons involving these fields MUST use "Serial number + arithmetic" as defined in [4]. As a direct consequence, the values + contained in these fields cannot refer to dates more than 68 years in + either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the KEY RR that + validates this signature. The process of calculating the Key Tag + value is given in Appendix B. + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the KEY RR + used to authenticate this signature. The Signer's Name field MUST + contain the name of the zone of the covered RRset, unless the Type + Covered field value is 0. A sender MUST NOT use DNS name compression + on the Signer's Name field when transmitting a SIG RR. A receiver + which receives a SIG RR containing a compressed Signer's Name field + SHOULD decompress the field value. + + + +Arends, et al. Expires August 26, 2003 [Page 11] + +Internet-Draft DNSSEC Resource Records February 2003 + + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature which covers + the SIG RDATA (excluding the Signature field) and the RRset specified + by the SIG owner name, SIG class, and SIG Type Covered field. + +3.1.8.1 Signature Calculation + + A signature covers the SIG RDATA (excluding the Signature Field) and + covers the RRset specified by the SIG owner name, SIG class, and SIG + Type Covered field. The RRset is in canonical form (see Section 6) + and the set RR(1),...RR(n) is signed as follows: + + signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + SIG_RDATA is the wire format of the SIG RDATA fields with + the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | class | type | TTL | RDATA length | RDATA; + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the SIG RR; + + Each RR MUST have the same class as the SIG RR; + + Each RR in the RRset MUST have the RR type listed in the + SIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the SIG + Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + canonical form; and + + The RRset MUST be sorted in canonical order. + + +3.2 The SIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field value is represented either as an unsigned + + + +Arends, et al. Expires August 26, 2003 [Page 12] + +Internet-Draft DNSSEC Resource Records February 2003 + + + decimal integer or as the mnemonic for the covered RR type. + + The Algorithm field value is represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value is represented as an unsigned decimal integer. + + The Original TTL field value is represented as an unsigned decimal + integer. + + The Signature Inception Time and Expiration Time field values are + represented in the form YYYYMMDDHHmmSS in UTC, where: + + YYYY is the year (0000-9999, but see Section 3.1.5); + + MM is the month number (01-12); + + DD is the day of the month (01-31); + + HH is the hour in 24 hours notation (00-23); + + mm is the minute (00-59); + + SS is the second (00-59). + + The Key Tag field is represented as an unsigned decimal integer. + + The Signer's Name field value is represented as a fully qualified + domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding see [3] Section 5.2. + +3.3 SIG RR Example + + The following a SIG RR stores the signature for the A RRset of + host.example.com: + + host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + + + +Arends, et al. Expires August 26, 2003 [Page 13] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The first four fields specify the owner name, TTL, Class, and RR type + (SIG). The "A" represents the Type Covered field. The value 5 + identifies the Algorithm used (RSA-SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the SIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of SIG RR owner name, class, and Type Covered + indicate that this SIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone KEY RR whose algorithm is 5 + and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 14] + +Internet-Draft DNSSEC Resource Records February 2003 + + +4. The NXT Resource Record + + The NXT resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NXT RR's owner name. The + complete set of NXT RRs in a zone both indicate which authoritative + RRsets exist in a zone and also form a chain of authoritative owner + names in the zone. This information is used to provide authenticated + denial of existence for DNS data, as described in [11]. + + The type value for the NXT RR is 30. + + The NXT RR is class independent. + +4.1 NXT RDATA Wire Format + + The RDATA of the NXT RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Map / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative RRset in the canonical ordering of the zone; see + Section 6.1 for an explanation of canonical ordering. The value of + the Next Domain Name field in the last NXT record in the zone is the + name of the zone apex (the owner name name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NXT RR. A receiver which receives an NXT + RR containing a compressed Next Domain Name field SHOULD decompress + the field value. + + Owner names of non-authoritative RRsets (such as glue records) MUST + NOT be listed in the Next Domain Name unless at least one + authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Map Field + + The Type Bit Map field identifies the RRset types which exist at the + NXT RR's owner name. + + + +Arends, et al. Expires August 26, 2003 [Page 15] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Each bit in the Type Bit Map field corresponds to an RR type. Bit 1 + corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), + and so forth. If a bit is set to 1, it indicates that an RRset of + that type is present for the NXT's owner name. If a bit is set to 0, + it indicates that no RRset of that type present for the NXT's owner + name. + + Bit 1 MUST NOT indicate glue address records. + + Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can + never appear in zone data. + + Trailing zero octets MUST be omitted. The length of the Type Bit Map + field varies, and is determined by the type code with the largest + numerical value among the set of RR types present at the NXT RR's + owner name. Trailing zero octets not specified MUST be interpreted + as zero octets. + + The above Type Bit Map format MUST NOT be used when an RR type code + with numerical value greater than 127 is present. + + Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A + value of 0 in bit 0 denotes the format described above, therefore bit + 0 MUST have a value of 0. The format and meaning of a Type Bit Map + with a value of 1 in bit 0 is undefined. + +4.1.3 Inclusion of Wildcard Names in NXT RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NXT RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [11] describes the impact of wildcards on authenticated denial of + existence. + +4.2 The NXT RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Map field is represented either as a sequence of RR type + mnemonics or as a sequence of unsigned decimal integers denoting the + RR type codes. + +4.3 NXT RR Example + + The following NXT RR identifies the RRsets associated with + + + +Arends, et al. Expires August 26, 2003 [Page 16] + +Internet-Draft DNSSEC Resource Records February 2003 + + + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT + + The first four text fields specify the name, TTL, Class, and RR type + (NXT). The entry host.example.com. is the next authoritative name + after alfa.example.com. (in canonical order). The A, MX, SIG and + NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated + with the name alfa.example.com. + + Note the NXT record can be used for authenticated denial of + existence. If the example NXT record were authenticated, it could be + used to prove that beta.example.com. does not exist, or could be + used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [11] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 17] + +Internet-Draft DNSSEC Resource Records February 2003 + + +5. The DS Resource Record + + The DS Resource Record refers to a KEY RR and is used in the DNS KEY + authentication process. A DS RR refers to a KEY RR by storing the + key tag, algorithm number, and a digest of KEY RR. Note that while + the digest should be sufficient to identify the key, storing the key + tag and key algorithm helps make the identification process more + efficient. By authenticating the DS record, a resolver can + authenticate the KEY RR to which the DS record points. The key + authentication process is described in [11]. + + The DS RR and its corresponding KEY RR have the same owner name, but + they are stored in different locations. The DS RR appears only on + the upper (parental) side of a delegation, and is authoritative data + in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding KEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in [11]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + There are no special TTL requirements on the DS resource record. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet + Algorithm field, a one octet Digest Type field, and a Digest field. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the KEY RR referred to by the + DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST + have Flags bit 7 set to value 1. + + + +Arends, et al. Expires August 26, 2003 [Page 18] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The Key Tag used by the DS RR is identical to the Key Tag used by the + SIG RR and Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the KEY RR referred + to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by the SIG RR and KEY RR. Appendix A.1 lists the + algorithm number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a KEY RR by including a digest of that KEY RR. + The Digest Type field identifies the algorithm used to construct the + digest and Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a KEY RR by including a digest of that KEY + RR. The Digest field holds the digest. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the KEY RR (abbreviated below as "key + RR name") with the KEY RDATA, and then applying the digest algorithm. + + digest = digest_algorithm( KEY RR name | KEY RDATA); + + "|" denotes concatenation + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + KEY RR size. Currently, the defined digest algorithm is SHA-1, which + produces a 20 octet digest. + +5.2 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field is represented as an unsigned decimal integer. + + The Algorithm field is represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field is represented as an unsigned decimal integer. + + + +Arends, et al. Expires August 26, 2003 [Page 19] + +Internet-Draft DNSSEC Resource Records February 2003 + + + The Digest is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.3 DS RR Example + + The following example shows a KEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." KEY RR, and value 5 denotes the algorithm used + by this "dskey.example.com." KEY RR. The value 1 is the algorithm + used to construct the digest, and the rest of the RDATA text is the + digest in hexadecimal. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 20] + +Internet-Draft DNSSEC Resource Records February 2003 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NXT name chain. A canonical RR form and ordering + within an RRset are required to construct and verify SIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + + 2. All uppercase US-ASCII letters in the owner name of the RR are + + + +Arends, et al. Expires August 26, 2003 [Page 21] + +Internet-Draft DNSSEC Resource Records February 2003 + + + replaced by the corresponding lowercase US-ASCII letters; + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS + names within the RDATA of the RR are replaced by the + corresponding lowercase US-ASCII letters; + + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + + 5. The RR's TTL is set to its original value as it appears in the + authoritative zone containing the RR or the Original TTL field of + the covering SIG RR. + + Editors' Note: the above definition sacrifices readability for an + attempt at precision. Please send better text! + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with same owner name, same class, + and same type are sorted by sorting the canonical forms of the RRs + while treating the RDATA portion of the canonical form of each RR as + a left justified unsigned octet sequence. The absence of an octet + sorts before the zero octet. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 22] + +Internet-Draft DNSSEC Resource Records February 2003 + + +7. IANA Considerations + + This document introduces one new IANA consideration. RFC 2535 [14] + created an IANA registry for DNS Security Algorithm Numbers. This + document re-assigns DNS Security Algorithm Number 252 to be + "reserved". This value is no longer available for assignment by + IANA. + + This document clarifies the use of existing DNS resource records. + For completeness, the IANA considerations from the previous documents + which defined these resource records are summarized below. No IANA + changes are made by this document other than the one change described + in the first paragraph of this section. + + [14] updated the IANA registry for DNS Resource Record Types, and + assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs, + respectively. [9] assigned DNS Resource Record Type 43 to DS. + + [14] created an IANA registry for DNSSEC Resource Record Algorithm + Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5 + was assigned by [8]. Value 252 is re-assigned by this document, as + noted above. + + [9] created an IANA registry for DNSSEC DS Digest Types, and assigned + value 0 to reserved and value 1 to SHA-1. + + [14] created an IANA Registry for KEY Protocol Values, but [16] re- + assigned all assigned values other than 3 to reserved and closed this + IANA registry. The registry remains closed, and all KEY records are + required to have Protocol Octet value of 3. + + The Flag bits in the KEY RR are not assigned by IANA, and there is no + IANA registry for these flags. All changes to the meaning of the KEY + RR Flag bits require a standards action. + + The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT + RR can only be assigned by a standards action. + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 23] + +Internet-Draft DNSSEC Resource Records February 2003 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. The use of these records is specified in a + separate document, and security considerations related to the use + these resource records are discussed in that document. + + The DS record points to a KEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing KEY RR, but it is theoretically possible for an + attacker to generate a KEY that matches all the DS fields. The + probability of constructing such a matching KEY depends on the type + of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select KEY resource records efficiently, + but it does not uniquely identify a single KEY resource record. It + is possible for two distinct KEY RRs to have the same owner name, the + same algorithm type, and the same key tag. An implementation which + used only the key tag to select a KEY RR might select the wrong + public key in some circumstances. Implementations MUST NOT assume + the key tag is unique public key identifier; this is clearly stated + in Appendix B. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 24] + +Internet-Draft DNSSEC Resource Records February 2003 + + +9. Acknowledgments + + This document was created from the input and ideas of several members + of the DNS Extensions Working Group and working group mailing list. + The co-authors of this draft would like to express their thanks for + the comments and suggestions received during the revision of these + security extension specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 25] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, September + 1993. + + [4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [7] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [9] Gudmundsson, O., "Delegation Signer Resource Record", draft- + ietf-dnsext-delegation-signer-12 (work in progress), December + 2002. + + [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", draft-ietf- + dnsext-dnssec-intro-05 (work in progress), February 2003. + + [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-00 (work in progress), + Februari 2003. + + [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf- + dnsext-unknown-rrs-04 (work in progress), September 2002. + + [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft- + ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003. + + + + + +Arends, et al. Expires August 26, 2003 [Page 26] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Informative References + + [14] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Software Consortium + 40 Gavin Circle + Reading, MA 01867 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + +Arends, et al. Expires August 26, 2003 [Page 27] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 28] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The KEY, SIG, and DS resource + records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + An "Algorithm Number" field in the KEY, SIG, and DS resource record + types identifies the cryptographic algorithm used by the resource + record. Algorithm specific formats are described in separate + documents. The following table lists the currently defined algorithm + types and provides references to their supporting documents: + + VALUE Algorithm RFC STATUS + 0 Reserved - - + 1 RSA/MD5 RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman RFC 2539 OPTIONAL + 3 DSA RFC 2536 OPTIONAL + 4 elliptic curve TBA OPTIONAL + 5 RSA/SHA1 RFC 3110 MANDATORY + 6-251 available for assignment - + 252 reserved - + 253 private see below OPTIONAL + 254 private see below OPTIONAL + 255 reserved - - + + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the KEY RR + and the signature area in the SIG RR begin with a wire encoded domain + name. Only local domain name compression is permitted. The domain + name indicates the private algorithm to use and the remainder of the + public key area is determined by that algorithm. Entities should + only use domain names they control to designate their private + algorithms. + + + + +Arends, et al. Expires August 26, 2003 [Page 29] + +Internet-Draft DNSSEC Resource Records February 2003 + + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the KEY RR + and the signature area in the SIG RR begin with an unsigned length + byte followed by a BER encoded Object Identifier (ISO OID) of that + length. The OID indicates the private algorithm in use and the + remainder of the area is whatever is required by that algorithm. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 30] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the SIG and DS resource record types provides a + mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a KEY record. Both the SIG and DS resource records have + corresponding KEY records. The Key Tag field in the SIG and DS + records can be used to help select the corresponding KEY RR + efficiently when more than one candidate KEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct KEY RRs to + have the same owner name, the same algorithm, and the same key tag. + The key tag is used to limit the possible candidate keys, but it does + not uniquely identify a KEY record. Implementations MUST NOT assume + that the key tag uniquely identifies a KEY RR. + + The key tag is the same for all KEY algorithm types except algorithm + 1 (please see Appendix B.1 for the definition of the key tag for + algorithm 1). For all algorithms other than algorithm 1, the key tag + is defined to be the output which would be generated by running the + ANSI C function shown below with the RDATA portion of the KEY RR as + input. It is not necessary to use the following reference code + verbatim, but the numerical value of the Key Tag MUST be identical to + what the reference implementation would generate for the same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described below rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the KEY RR. The code is written for + clarity, not efficiency. + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 31] + +Internet-Draft DNSSEC Resource Records February 2003 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the KEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a KEY + RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 32] + +Internet-Draft DNSSEC Resource Records February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 26, 2003 [Page 33] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt new file mode 100644 index 0000000000..b56f293cea --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-roadmap-07.txt @@ -0,0 +1,896 @@ + + +DNS Extensions S. Rose +Internet-Draft NIST +Expires: August 5, 2003 February 4, 2003 + + + DNS Security Document Roadmap + draft-ietf-dnsext-dnssec-roadmap-07 + +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. + + This Internet-Draft will expire on August 5, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + DNS Security (DNSSEC) technology is composed of extensions to the + Domain Name System (DNS) protocol that provide data integrity and + authentication to security aware resolvers and applications through + the use of cryptographic digital signatures. Several documents exist + to describe these extensions and the implementation-specific details + regarding specific digital signing schemes. The interrelationship + between these different documents is discussed here. A brief + overview of what to find in which document and author guidelines for + what to include in new DNS Security documents, or revisions to + existing documents, is described. + + + + + +Rose Expires August 5, 2003 [Page 1] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Interrelationship of DNS Security Documents . . . . . . . . . 4 + 3. Relationship of DNS Security Documents to other DNS + Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Recommended Content for new DNS Security Documents . . . . . . 9 + 4.1 Security Related Resource Records . . . . . . . . . . . . . . 9 + 4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9 + 4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10 + 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + Normative References . . . . . . . . . . . . . . . . . . . . . 13 + Informative References . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 2] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +1. Introduction + + This document is intended to provide guidelines for the development + of supplemental documents describing security extensions to the + Domain Name System (DNS). + + The main goal of the DNS Security (DNSSEC) extensions is to add data + authentication and integrity services to the DNS protocol. These + protocol extensions should be differentiated from DNS operational + security issues, which are beyond the scope of this effort. DNS + Security documents fall into one or possibly more of the following + sub-categories: new DNS security resource records, implementation + details of specific digital signing algorithms for use in DNS + Security and DNS transaction authentication. Since the goal of DNS + Security extensions is to become part of the DNS protocol standard, + additional documents that seek to refine a portion of the security + extensions will be introduced as the specifications progress along + the IETF standards track. + + There is a set of basic guidelines for each sub-category of documents + that explains what should be included, what should be considered a + protocol extension, and what should be considered an operational + issue. Currently, there are at least two documents that fall under + operational security considerations that deal specifically with the + DNS security extensions: the first is RFC 2541 [6] which deals with + the operational side of implementing the security extensions; the + other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These + documents should be considered part of the operational side of DNS, + but will be addressed as a supplemental part of the DNS Security + roadmap. That is not to say that these two documents are not + important to securing a DNS zone, but they do not directly address + the proposed DNS security extensions. Authors of documents that seek + to address the operational concerns of DNS security should be aware + of the structure of DNS Security documentation. + + It is assumed the reader has some knowledge of the Domain Name System + [2] and the Domain Name System Security Extensions. + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 3] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +2. Interrelationship of DNS Security Documents + + The DNSSEC set of documents can be partitioned into five main groups + as depicted in Figure 1. All of these documents in turn are under + the larger umbrella group of DNS base protocol documents. It is + possible that some documents fall into more than one of these + categories, such as RFC 2535, and should follow the guidelines for + the all of the document groups it falls into. However, it is wise to + limit the number of "uberdocuments" that try to be everything to + everyone. The documents listed in each category are current as to + the time of writing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 4] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + + --------------------------------------------------------------------- + + + + +--------------------------------+ + | | + | Base DNS Protocol Docs. | + | [RFC1035, RFC2181, etc.] | + | | + +--------------------------------+ + | + | + | + +------------+ +-----------+ +-------------+ + | New | | DNSSEC | | New | + | Security |----------| protocol |----------| Security | + | RRs | | | | Uses | + +------------+ | | +-------------+ + +-----------+ + | + | + +----------------------+*********************** + | * * + | * * + +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ + | DS | | | | Implementation | + | Algorithm | | Transactions | * Notes * + | Impl. | | | | | + +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+ + + + + + DNSSEC Document Roadmap + + --------------------------------------------------------------------- + + The "DNSSEC protocol" document set refers to the document that makes + up the groundwork for adding security to the DNS protocol [1]and + updates to this document. RFC 2535 laid out the goals and + expectations of DNS Security and the new security-related Resource + Records KEY, SIG, DS, and NXT [23]. Expanding from this document, + related document groups include the implementation documents of + various digital signature algorithms with DNSSEC, and documents + further refining the transaction of messages. It is expected that + RFC 2535 will be obsoleted by one or more documents that refine the + set of security extensions [22], [23], [24]. Documents that seek to + modify or clarify the base protocol documents should state so clearly + + + +Rose Expires August 5, 2003 [Page 5] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + + in the introduction of the document (as well as proscribe to the IETF + guidelines of RFC/Internet Draft author guidelines). Also, the + portions of the specification to be modified should be synopsized in + the new document for the benefit of the reader. The "DNSSEC + protocol" set includes the documents [1], [11], [12], [9], [14], + [15], [21], [16], [OPTIN], [17] and their derivative documents. + + The "New Security RRs" set refers to the group of documents that seek + to add additional Resource Records to the set of base DNS Record + types. These new records can be related to securing the DNS protocol + [1], [8], or using DNS security for other purposes such as storing + certificates [5]. Another related document is [26]. While not + detailing a new RR type, it defines a flag bit in the existing KEY + RR. This flag bit does not affect the protocol interpretation of the + RR, only a possible operational difference. Therefore, this draft is + place here and not with the protocol document set. + + The "DS Algorithm Impl" document set refers to the group of documents + that describe how a specific digital signature algorithm is + implemented to fit the DNSSEC Resource Record format. Each one of + these documents deals with one specific digital signature algorithm. + Examples of this set include [4], [5], [25], [19][18] and [13]. + + The "Transactions" document set refers to the group of documents that + deal with the message transaction sequence of security-related DNS + operations. The contents and sequence for operations such as dynamic + update [3], [11] and transaction signatures [10] are described in + this document category. Additional message transaction schemes to + support DNSSEC operation would also fall under this group, including + secret key establishment [7], [RENEW], and verification. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. Documents that fall in this category include the + use of DNS in the storage and distribution of certificates and + individual user public keys (PGP, e-mail, etc.) Some documents in + this group may fall beyond the DNSEXT WG scope, but they are included + because of their use of the security extensions. The documents in + this group should not propose any changes to the DNS protocol to + support other protocols; only how existing DNS security records and + transactions can be used to support other protocols. Such documents + include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and + IPSec keying information the DNS using new records and utilizing + DNSSEC to provide authentication and integrity checking. + + Lastly, there is a set of documents that should be classified as + "Implementation Notes". Because the DNS security extensions are + still in the developmental stage, there is an audience for documents + + + +Rose Expires August 5, 2003 [Page 6] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + + that detail the transition and implementation of the security + extensions. These have more to do with the practical side of DNS + operations, but can also point to places in the protocol + specifications that need improvement. An example of this type is the + report on the CAIRN DNSSEC testbed [CAIRN] This document was + submitted through the DNSOP Working Group at the time of this + writing, however the main concern of this document is the + implementation and limitations of the DNS security extensions, hence + their interest to the DNS security community. The CAIRN draft deals + with the implementation of a secure DNS. Authors of documents that + deal with the implementation and operational side of the DNSSEC + specifications would be advised/encouraged to submit their documents + to any other relevant DNS related WG meeting in the problem space. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 7] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +3. Relationship of DNS Security Documents to other DNS Documents + + The DNS security-related extensions should be considered a subset of + the DNS protocol. Therefore, all DNS security-related documents + should be seen as a subset of the main DNS architecture documents. + It is a good idea for authors of future DNS security documents to be + familiar with the contents of these base protocol documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 8] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +4. Recommended Content for new DNS Security Documents + + Documents that seek to make additions or revisions to the DNS + protocol to add security should follow common guidelines as to + minimum required content and structure. It is the purpose of this + document roadmap to establish criteria for content that any new DNS + security protocol specifications document should contain. These + criteria should be interpreted as a minimum set of information + required/needed in a document, any additional information regarding + the specific extension should also be included in the document. + These criteria are not officially part of the IETF guidelines + regarding RFC/Internet Drafts, but should be considered as guidance + to promote uniformity to Working Group documents. + + Since the addition of security to the DNS protocol is now considered + a general extension to the DNS protocol, any guideline for the + contents of a DNS Security document could be taken as a framework + suggestion for the contents of any DNS extension document. The + development process of the DNS security extensions could be used as a + model framework for any, more general DNS extensions. + +4.1 Security Related Resource Records + + Documents describing a new type of DNS Security Resource Record (RR) + should contain information describing the structure and use of the + new RR type. It is a good idea to only discuss one new type in a + document, unless the set of new resource records are closely related + or a protocol extension requires the use of more than one new record + type. Specifically, each document detailing a new security-related + RR type should include the following information: + + o The format of the new RR type, both "on the wire" (bit format) and + ASCII representation (for text zone files), if appropriate; + + o when and in what section of a DNS query/response this new RR type + is to be included; + + o at which level of the DNS hierarchy this new RR type is to be + considered authoritative (i.e. in a zone, in a zone's superzone) + and who is authoritative to sign the new RR; + + +4.2 Digital Signature Algorithm Implementations + + Documents describing the implementation details of a specific digital + signature algorithm such as [4] ,[13] (and others as new digital + signatures schemes are introduced) for use with DNS Security should + include the following information: + + + +Rose Expires August 5, 2003 [Page 9] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + + o The format/encoding of the algorithm's public key for use in a KEY + Resource Record; + + o the acceptable key size for use with the algorithm; + + o the current known status of the algorithm (as one of REQUIRED, + RECOMMENDED, or OPTIONAL). + + In addition, authors are encouraged to include any necessary + description of the algorithm itself, as well as any know/suspected + weaknesses as an appendix to the document. This is for reference + only, as the goals of the DNSEXT working group is to propose + extensions to the DNS protocol, not cryptographic research. + +4.3 Refinement of Security Procedures + + This set of documents includes DNS protocol operations that + specifically relate to DNS Security, such as DNS secret key + establishment [7] and security extensions to pre-existing or + proposed DNS operations such as dynamic update [3]. Documents that + describe a new set of DNS message transactions, or seek to refine a + current series of transactions that make up a DNS operation should + include the following information: + + o The order in which the DNS messages are sent by the operation + initiator and target; + + o the format of these DNS messages; + + o any required authentication mechanisms for each stage of the + operation and the required authority for that mechanism (i.e. + zone, host, or some other trusted authority such as a DNS + administrator or certificate authority); + + +4.4 The Use of DNS Security Extensions with Other Protocols + + Because of the flexibility and ubiquity of the DNS, there may exist + other Internet protocols and applications that could make use of, or + extend, the DNS security protocols. Examples of this type of + document include the use of DNS to support IPSEC [IPSEC-DNS], SSH + [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the + scope of this roadmap to describe the contents of this class of + documents. However, if uses or extensions require the addition or + modification of a DNS Resource Record type or DNS query/response + transactions, then the guidelines laid out in the previous sections + of this document should be adhered to. + + + + +Rose Expires August 5, 2003 [Page 10] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +5. Security Considerations + + This document provides a roadmap and guidelines for writing DNS + Security related documents. This document does not discuss the + aspects of the DNS security extensions. The reader should refer to + the documents outlined here for the details of the services and + shortcomings of DNS security. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 11] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +6. Acknowledgements + + In addition to the RFCs mentioned in this document, there are also + numerous Internet drafts that fall in one or more of the categories + of DNS Security documents mentioned above. Depending on where (and + if) these documents are on the IETF standards track, the reader may + not be able to access these documents through the RFC repositories. + All of these documents are "Work in Progress" and are subject to + change; therefore a version number is not supplied for the current + revision. Some Internet Drafts are in the RFC editor's queue or + nearing WG Last Call at the time of writing. These Drafts have been + placed in the References section. The drafts below are still subject + to agreement in the IETF. + + o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC + Implementation in the CAIRN Testbed". draft-ietf-dnsop- + dnsseccairn-NN.txt + + o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft- + kosters-dnsext-dnssec-opt-in-NN.txt + + o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely + publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt + + o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying + material in DNS". draft-richardson-ipsec-rr-NN.txt + + o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode". + draft-ietf-dnsext-tkey-renewal-mode-NN.txt + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 12] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +Normative References + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", RFC 2538, March 1999. + + [6] Eastlake, D., "DNS Security Operational Considerations", RFC + 2541, March 1999. + + [7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [8] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [9] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [12] Wellington, B., "Domain Name System Security (DNSSEC) Signing + Authority", RFC 3008, April 2000. + + [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + + + +Rose Expires August 5, 2003 [Page 13] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + + [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 14] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +Informative References + + [17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name + System (Work in Progress)", RFC XXXX. + + [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain + Name System (DNS) (Work in Progress)", RFC XXXX. + + [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS + (Work in Progress)", RFC XXXX. + + [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in + Progress)", RFC XXXX. + + [21] Wellington, B., "Redefinition of the DNS AD bit (Work in + Progress)", RFC XXXX. + + [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security + Introduction and Requirements (Work in Progress)", RFC XXXX. + + [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource + Records for DNS Security Extensions (Work in Progress)", RFC + XXXX. + + [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol + Modifications for the DNS Security Extensions (Work in + Progress)", RFC XXXX. + + [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm + for TSIG (Work in Progress)", RFC XXXX. + + [26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag + (Work in Progress)", RFC XXXX. + + +Author's Address + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-3460 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Rose Expires August 5, 2003 [Page 15] + +Internet-Draft DNSSEC Document Roadmap February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Rose Expires August 5, 2003 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-03.txt b/doc/draft/draft-ietf-dnsext-ecc-key-03.txt new file mode 100644 index 0000000000..ddb7fd763d --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-03.txt @@ -0,0 +1,812 @@ + +INTERNET-DRAFT ECC Keys in the DNS +Expires: June 2003 December 2002 + + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list or to the + authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. 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. + + + +Abstract + + A standard method for storing elliptic curve cryptographic keys in + the Domain Name System is described which utilizes DNS KEY resource + record. + + + + + + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve KEY Resource Records.....................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Performance Considerations.............................11 + 6. Security Considerations................................11 + 7. IANA Considerations....................................11 + + References................................................13 + + Authors' Addresses........................................14 + Expiration and File Name..................................14 + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 2535]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys in the DNS so they can be used for a variety of security + purposes. A DNS elliptic curve SIG resource record is not defined. + Familiarity with ECC cryptography is assumed [Menezes]. + + 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]. + + + +2. Elliptic Curve KEY Resource Records + + Elliptic curve public keys are stored in the DNS as KEY RRs using + algorithm number 4 (see [RFC 2535]). The structure of the RDATA + portion of this RR is as shown below. The first 4 octets, including + the flags, protocol, and algorithm fields are common to all KEY RRs. + The remainder is the "public key" part of the KEY RR. + + The period of key validity is not in the KEY RR but is indicated by + the SIG RR(s) which signs and authenticates the KEY RR(s) at that + domain name and class. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, we have defined + representations for every type of finite field, and every type of + elliptic curve. The reader should be aware that there is a unique + finite field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of KEY RR and MUST + be ignored when processing a KEY RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial + of degree D is X^D (which is not irreducible). The next is X^D+1, + which is sometimes irreducible, followed by X^D-1, which isn't. + Assuming odd P, this series continues to X^D - (P-1)/2, and then goes + to X^D + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than RSA + and DSA. Creation of a curve is slow, but not done very often. Key + generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of KEY RR sets stored within the DNS + consistent with adequate security. Keep in mind that in a secure + zone, an authenticating SIG RRset will also be returned. + + + +6. Security Considerations + + Many of the general security consideration in [RFC 2535] apply. Some + specific key generation considerations are given above. Of course, + the elliptic curve key stored in the DNS for an entity should not be + trusted unless it has been obtain via a trusted DNS resolver that + vouches for its security or unless the application using the key has + done a similar authentication. + + + +7. IANA Considerations + + Assignment of meaning to the remaining ECC KEY flag bits or to values + of ECC fields outside the ranges for which meaning in defined in this + document requires an IETF consensus as defined in [RFC 2434]. + + This specification uses algorithm number 4 for DNS elliptic curve KEY + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + RRs that was reserved for this purpose in [RFC 2535]. An elliptic + curve (algorithm = 4) SIG RR is not defined. Assignment of a meaning + to it requires an IETF Standards action. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + +References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", + March 1999. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August + 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", + 1986, Springer Graduate Texts in mathematics #106. + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Authors' Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: 1-801-423-7998(h) + 1-505-844-9079(w) + Email: rcs@cs.arizona.edu + rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-634-2066 (h) + +1 508-851-8280 (w) + FAX: +1 508-851-8507 (w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in June 2003. + + Its file name is draft-ietf-dnsext-ecc-key-03.txt. + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-06.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-06.txt new file mode 100644 index 0000000000..f8438c0683 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-gss-tsig-06.txt @@ -0,0 +1,1231 @@ + +INTERNET-DRAFT Stuart Kwan + Praerit Garg +February 28, 2003 James Gilroy +Expires August 28, 2003 Levon Esibov + Jeff Westhead + Microsoft Corp. + Randy Hall + Lucent Technologies + + + + GSS Algorithm for TSIG (GSS-TSIG) + + +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. + + +Abstract + +The TSIG protocol provides transaction level authentication for DNS. +TSIG is extensible through the definition of new algorithms. This +document specifies an algorithm based on the Generic Security Service +Application Program Interface (GSS-API) (RFC2743). This document updates +RFC 2845. + + + + + + + + + + + +Expires August 28, 2003 [Page 1] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +Table of Contents + +1: Introduction......................................................2 +2: Algorithm Overview................................................3 + 2.1: GSS Details...................................................4 + 2.2: Modifications to the TSIG protocol (RFC 2845).................4 +3: Client Protocol Details...........................................4 + 3.1: Negotiating Context...........................................5 + 3.1.1: Call GSS_Init_sec_context.................................5 + 3.1.2: Send TKEY Query to Server.................................7 + 3.1.3: Receive TKEY Query-Response from Server...................7 + 3.2: Context Established..........................................10 + 3.2.1: Terminating a Context....................................10 +4: Server Protocol Details..........................................10 + 4.1: Negotiating Context..........................................10 + 4.1.1: Receive TKEY Query from Client...........................11 + 4.1.2: Call GSS_Accept_sec_context..............................11 + 4.1.3: Send TKEY Query-Response to Client.......................12 + 4.2: Context Established..........................................13 + 4.2.1: Terminating a Context....................................13 +5: Sending and Verifying Signed Messages............................14 + 5.1: Sending a Signed Message - Call GSS_GetMIC...................14 + 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15 +6: Example usage of GSS-TSIG algorithm..............................16 +7: Security Considerations..........................................20 +8: IANA Considerations..............................................20 +9: Conformance......................................................20 +10:Acknowledgements.................................................20 +11:References.......................................................20 + +1. Introduction + +The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845] +protocol was developed to provide a lightweight authentication and +integrity of messages between two DNS entities, such as client and +server or server and server. TSIG can be used to protect dynamic +update messages, authenticate regular message or to off-load +complicated DNSSEC [RFC2535] processing from a client to a server and +still allow the client to be assured of the integrity of the answers. + +The TSIG protocol [RFC2845] is extensible through the definition of new +algorithms. This document specifies an algorithm based on the Generic +Security Service Application Program Interface (GSS-API) [RFC2743]. +GSS-API is a framework that provides an abstraction of security to the +application protocol developer. The security services offered can +include authentication, integrity, and confidentiality. + +The GSS-API framework has several benefits: +* Mechanism and protocol independence. The underlying mechanisms that +realize the security services can be negotiated on the fly and varied +over time. For example, a client and server MAY use Kerberos [RFC1964] +for one transaction, whereas that same server MAY use SPKM [RFC2025] +with a different client. + +Expires August 28, 2003 [Page 2] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +* The protocol developer is removed from the responsibility of +creating and managing a security infrastructure. For example, the +developer does not need to create new key distribution or key +management systems. Instead the developer relies on the security +service mechanism to manage this on its behalf. + +The scope of this document is limited to the description of an +authentication mechanism only. It does not discuss and/or propose an +authorization mechanism. Readers that are unfamiliar with GSS-API +concepts are encouraged to read the characteristics and concepts section +of [RFC2743] before examining this protocol in detail. It is also +assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034] +and [RFC1035]. + +The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", +"RECOMMENDED", and "MAY" in this document are to be interpreted as +described in RFC 2119 [RFC2119]. + + +2. Algorithm Overview + +In GSS, client and server interact to create a "security context". +The security context can be used to create and verify transaction +signatures on messages between the two parties. A unique security +context is required for each unique connection between client and +server. + +Creating a security context involves a negotiation between client and +server. Once a context has been established, it has a finite lifetime +for which it can be used to secure messages. Thus there are three +states of a context associated with a connection: + + +----------+ + | | + V | + +---------------+ | + | Uninitialized | | + | | | + +---------------+ | + | | + V | + +---------------+ | + | Negotiating | | + | Context | | + +---------------+ | + | | + V | + +---------------+ | + | Context | | + | Established | | + +---------------+ | + | | + +----------+ + +Expires August 28, 2003 [Page 3] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +Every connection begins in the uninitialized state. + + +2.1 GSS Details + +Client and server MUST be locally authenticated and have acquired +default credentials before using this protocol as specified in +Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. + +The GSS-TSIG algorithm consists of two stages: + +I. Establish security context. The Client and Server use the +GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the +tokens that they pass to each other using [RFC2930] as a transport +mechanism. + +II. Once the security context is established it is used to generate and +verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These +signatures are exchanged by the Client and Server as a part of the TSIG +records exchanged in DNS messages sent between the Client and Server, +as described in [RFC2845]. + + +2.2 Modifications to the TSIG protocol (RFC 2845) + +Modification to RFC 2845 allows use of TSIG through signing server's +response in an explicitly specified place in multi message exchange +between two DNS entities even if client's request wasn't signed. + +Specifically Section 4.2 of RFC 2845 MUST be modified as follows. + +Replace: +"The server MUST not generate a signed response to an unsigned +request." + +With: +"The server MUST not generate a signed response to an unsigned request, +except in case of response to client's unsigned TKEY query if secret +key is established on server side after server processed client's +query. Signing responses to unsigned TKEY queries MUST be explicitly +specified in the description of an individual secret key establishment +algorithm." + + + +3. Client Protocol Details + +A unique context is required for each server to which the client sends +secure messages. A context is identified by a context handle. A +client maintains a mapping of servers to handles, + + (target_name, key_name, context_handle) + +Expires August 28, 2003 [Page 4] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +The value key_name also identifies a context handle. The key_name is +the owner name of the TKEY and TSIG records sent between a client and a +server to indicate to each other which context MUST be used to process +the current request. + +DNS client and server MAY use various underlying security mechanisms to +establish security context as described in sections 3 and 4. At the +same time, in order to guarantee interoperability between DNS clients +and servers that support GSS-TSIG it is REQUIRED that security +mechanism used by client enables use of Kerberos v5 (see Section 9 +for more information). + + +3.1 Negotiating Context + +In GSS, establishing a security context involves the passing of opaque +tokens between the client and the server. The client generates the +initial token and sends it to the server. The server processes the +token and if necessary, returns a subsequent token to the client. The +client processes this token, and so on, until the negotiation is +complete. The number of times the client and server exchange tokens +depends on the underlying security mechanism. A completed negotiation +results in a context handle. + +The TKEY resource record [RFC2930] is used as the vehicle to transfer +tokens between client and server. The TKEY record is a general +mechanism for establishing secret keys for use with TSIG. For more +information, see [RFC2930]. + + +3.1.1 Call GSS_Init_sec_context + +To obtain the first token to be sent to a server, a client MUST call +GSS_Init_sec_context API. +The following input parameters MUST be used. The outcome of the call is +indicated with the output values below. Consult Sections 2.2.1 +"GSS_Init_sec_context call" of [RFC2743] for syntax definitions. + + INPUTS + CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use + default"). Client MAY instead specify some other valid handle + to its credentials. + CONTEXT HANDLE input_context_handle = 0 + INTERNAL NAME targ_name = "DNS@" + OBJECT IDENTIFIER mech_type = Underlying security + mechanism chosen by implementers. To guarantee + interoperability of the implementations of the GSS-TSIG + mechanism client MUST specify a valid underlying security + mechanism that enables use of Kerberos v5 (see Section 9 for + more information). + OCTET STRING input_token = NULL + BOOLEAN replay_det_req_flag = TRUE + +Expires August 28, 2003 [Page 5] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + BOOLEAN mutual_req_flag = TRUE + BOOLEAN deleg_req_flag = TRUE + BOOLEAN sequence_req_flag = TRUE + BOOLEAN anon_req_flag = FALSE + BOOLEAN integ_req_flag = TRUE + INTEGER lifetime_req = 0 (0 requests a default + value). Client MAY instead specify another upper bound for the + lifetime of the context to be established in seconds. + OCTET STRING chan_bindings = Any valid channel bindings + as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] + + OUTPUTS + INTEGER major_status + CONTEXT HANDLE output_context_handle + OCTET STRING output_token + BOOLEAN replay_det_state + BOOLEAN mutual_state + INTEGER minor_status + OBJECT IDENTIFIER mech_type + BOOLEAN deleg_state + BOOLEAN sequence_state + BOOLEAN anon_state + BOOLEAN trans_state + BOOLEAN prot_ready_state + BOOLEAN conf_avail + BOOLEAN integ_avail + INTEGER lifetime_rec + +If returned major_status is set to one of the following errors + + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_OLD_TOKEN + GSS_S_DUPLICATE_TOKEN + GSS_S_NO_CONTEXT + GSS_S_BAD_NAMETYPE + GSS_S_BAD_NAME + GSS_S_BAD_MECH + GSS_S_FAILURE + +then the the client MUST abandon the algorithm and MUST NOT use the +GSS-TSIG algorithm to establish this security contex. This document +does not prescribe which other mechanism could be used to establish +a security context. Next time when this client needs to establish +security context, the client MAY use GSS-TSIG algorithm. + +Success values of major_status are GSS_S_CONTINUE_NEEDED and +GSS_S_COMPLETE. The exact success code is important during later +processing. + +Expires August 28, 2003 [Page 6] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +The values of replay_det_state and mutual_state indicate if the +security package provides replay detection and mutual authentication, +respectively. If returned major_status is GSS_S_COMPLETE AND one or both +of these values are FALSE, the client MUST abandon this algorithm. + +Client's behavior MAY depend on other OUTPUT parameters according +to the policy local to the client. + +The handle output_context_handle is unique to this negotiation and +is stored in the client's mapping table as the context_handle that +maps to target_name. + + + +3.1.2 Send TKEY Query to Server + +An opaque output_token returned by GSS_Init_sec_context is transmitted +to the server in a query request with QTYPE=TKEY. The token itself +will be placed in a Key Data field of the RDATA field in the TKEY +resource record in the additional records section of the query. The +owner name of the TKEY resource record set queried for and the owner +name of the supplied TKEY resource record in the additional records +section MUST be the same. This name uniquely identifies the security +context to both the client and server, and thus the client SHOULD use +a value which is globally unique as described in [RFC2930]. To achieve +global uniqueness, the name MAY contain a UUID/GUID [ISO11578]. + + TKEY Record + NAME = client-generated globally unique domain name string + (as described in [RFC2930]) + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [RFC2930]) + Key Size = size of output_token in octets + Key Data = output_token + +The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, +Error, Other Size and Data Fields, MUST be set according to [RFC2930]. + +The query is transmitted to the server. + +Note: if the original client call to GSS_Init_sec_context returned any +major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then +the client MUST NOT send TKEY query. Client's behavior in this case is +described above in Section 3.1.1. + + +3.1.3 Receive TKEY Query-Response from Server + +Upon the reception of the TKEY query DNS server MUST respond according +to the description in Section 4. This Section specifies the behavior +of the client after it receives the matching response to its query. + +Expires August 28, 2003 [Page 7] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +The next processing step depends on the value of major_status from the +most recent call that client performed to GSS_Init_sec_context: either +GSS_S_COMPLETE or GSS_S_CONTINUE. + + +3.1.3.1 Value of major_status == GSS_S_COMPLETE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_COMPLETE and a non-NULL output_token was sent to the server, +then the client side component of the negotiation is complete and the +client is awaiting confirmation from the server. + +Confirmation is in the form of a query response with RCODE=NOERROR +and with the last client supplied TKEY record in the answer section +of the query. The response MUST be signed with a TSIG record. Note +that server is allowed to sign a response to unsigned client's query +due to modification to the RFC 2845 specified in Section 2.2 above. +The signature in the TSIG record MUST be verified using the procedure +detailed in section 5, Sending and Verifying Signed Messages. If the +response is not signed, OR if the response is signed but signature is +invalid, then an attacker has tampered with the message in transit or +has attempted to send the client a false response. In this case the +client MAY continue waiting for a response to its last TKEY query until +the time period since the client sent last TKEY query expires. Such a +time period is specified by the policy local to the client. This is a +new option that allows DNS client to accept multiple answers for one +query ID and select one (not necessarily the first one) based on some +criteria. + +If the signature is verified the context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security context. + + +3.1.3.2 Value of major_status == GSS_S_CONTINUE + +If the last call to GSS_Init_sec_context yielded a major_status value +of GSS_S_CONTINUE, then the negotiation is not yet complete. The server +will return to the client a query-response with a TKEY record in the +Answer section. If the DNS message error is not NO_ERROR or error field +in the TKEY record is not 0 (i.e. no error), then the client MUST +abandon this negotiation sequence. The client MUST delete an active +context by calling GSS_Delete_sec_context providing the associated +context_handle. The client MAY repeat the negotiation sequence starting +with the uninitialized state as described in section 3.1. To prevent +infinite looping the number of attempts to establish a security context +MUST be limited to ten or less. + +If the DNS message error is NO_ERROR and error filed in the TKEY record +is 0 (i.e. no error), then the client MUST pass a token specified in the +Key Data field in the TKEY resource record to GSS_Init_sec_context +using the same parameters values as in previous call except values for +CONTEXT HANDLE input_context_handle and OCTET STRING input_token as +described below: + +Expires August 28, 2003 [Page 8] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + + INPUTS + CONTEXT HANDLE input_context_handle = context_handle (this is the + context_handle corresponding to the key_name which is the + owner name of the TKEY record in the answer section in the + TKEY query response) + OCTET STRING input_token = token from Key field of + TKEY record + +Depending on the following OUTPUT values of GSS_Init_sec_context + INTEGER major_status + OCTET STRING output_token +the client MUST take one of the following actions: + +If OUTPUT major_status is set to one of the following values + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_OLD_TOKEN + GSS_S_DUPLICATE_TOKEN + GSS_S_NO_CONTEXT + GSS_S_BAD_NAMETYPE + GSS_S_BAD_NAME + GSS_S_BAD_MECH + GSS_S_FAILURE + +the client MUST abandon this negotiation sequence. This means that the +client MUST delete an active context by calling GSS_Delete_sec_context +providing the associated context_handle. The client MAY repeat the +negotiation sequence starting with the uninitialized state as described +in section 3.1. To prevent infinite looping the number of attempts to +establish a security context MUST be limited to ten or less. + +If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then +client MUST act as described below. + +If the response from the server was signed, and the OUTPUT major_status +is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified +using the procedure detailed in section 5, Sending and Verifying Signed +Messages. If the signature is invalid, then the client MUST abandon this +negotiation sequence. This means that the client MUST delete an active +context by calling GSS_Delete_sec_context providing the associated +context_handle. The client MAY repeat the negotiation sequence starting +with the uninitialized state as described in section 3.1. To prevent +infinite looping the number of attempts to establish a security context +MUST be limited to ten or less. + +If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet +finished. The token output_token MUST be passed to the server in a TKEY +record by repeating the negotiation sequence beginning with section + +Expires August 28, 2003 [Page 9] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +3.1.2. The client MUST place a limit on the number of continuations in +a context negotiation to prevent endless looping. Such limit SHOULD NOT +exceed value of 10. + +If major_status is GSS_S_COMPLETE and output_token is non-NULL, the +client-side component of the negotiation is complete but the token +output_token MUST be passed to the server by repeating the negotiation +sequence beginning with section 3.1.2. + +If major_status is GSS_S_COMPLETE and output_token is NULL, context +negotiation is complete. The context state is advanced to Context +Established. Proceed to section 3.2 for usage of the security context. + + +3.2 Context Established + +When context negotiation is complete, the handle context_handle MUST be +used for the generation and verification of transaction signatures. + +The procedures for sending and receiving signed messages are described +in section 5, Sending and Verifying Signed Messages. + + +3.2.1 Terminating a Context + +When the client is not intended to continue using the established +security context, the client SHOULD delete an active context by +calling GSS_Delete_sec_context providing the associated context_handle, +AND client SHOULD delete the established context on the DNS server +by using TKEY RR with the Mode field set to 5, i.e. "key deletion" +[RFC2930]. + + + +4. Server Protocol Details + +As on the client-side, the result of a successful context negotiation +is a context handle used in future generation and verification of the +transaction signatures. + +A server MAY be managing several contexts with several clients. +Clients identify their contexts by providing a key name in their +request. The server maintains a mapping of key names to handles: + + (key_name, context_handle) + + + +4.1 Negotiating Context + +A server MUST recognize TKEY queries as security context negotiation +messages. + +Expires August 28, 2003 [Page 10] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +4.1.1 Receive TKEY Query from Client + +Upon receiving a query with QTYPE = TKEY, the server MUST examine +whether the Mode and Algorithm Name fields of the TKEY record in the +additional records section of the message contain values of 3 and +gss-tsig, respectively. If they do, then the (key_name, context_handle) +mapping table is searched for the key_name matching the owner name of +the TKEY record in the additional records section of the query. If the +name is found in the table and the security context for this name is +established and not expired, then the server MUST respond to the query +with BADNAME error in the TKEY error field. If the name is found in the +table and the security context is not established, the corresponding +context_handle is used in subsequent GSS operations. If the name is +found but the security context is expired, then the server deletes this +security context, as described in Section 4.2.1, and interprets this +query as a start of new security context negotiation and performs +operations described in Section 4.1.2 and 4.1.3. If the name is not +found, then the server interprets this query as a start of new security +context negotiation and performs operations described in Section 4.1.2 +and 4.1.3. + + + +4.1.2 Call GSS_Accept_sec_context + +The server performs its side of a context negotiation by calling +GSS_Accept_sec_context. The following input parameters MUST be used. The +outcome of the call is indicated with the output values below. Consult +Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743] +for syntax definitions. + + INPUTS + CONTEXT HANDLE input_context_handle = 0 if new negotiation, + context_handle matching + key_name if ongoing negotiation + OCTET STRING input_token = token specified in the Key + field from TKEY RR (from Additional records Section of + the client's query) + CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use + default"). Server MAY instead specify some other valid handle + to its credentials. + OCTET STRING chan_bindings = Any valid channel bindings + as specified in Section 1.1.6 "Channel Bindings" in [RFC2743] + + OUTPUTS + INTEGER major_status + CONTEXT_HANDLE output_context_handle + OCTET STRING output_token + INTEGER minor_status + INTERNAL NAME src_name + OBJECT IDENTIFIER mech_type + BOOLEAN deleg_state + +Expires August 28, 2003 [Page 11] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + + BOOLEAN mutual_state + BOOLEAN replay_det_state + BOOLEAN sequence_state + BOOLEAN anon_state + BOOLEAN trans_state + BOOLEAN prot_ready_state + BOOLEAN conf_avail + BOOLEAN integ_avail + INTEGER lifetime_rec + CONTEXT_HANDLE delegated_cred_handle + +If this is the first call to GSS_Accept_sec_context in a new +negotiation, then output_context_handle is stored in the server's +key-mapping table as the context_handle that maps to the name of the +TKEY record. + + +4.1.3 Send TKEY Query-Response to Client + +The server MUST respond to the client with a TKEY query response with +RCODE = NOERROR, that contains a TKEY record in the answer section. + +If OUTPUT major_status is one of the following errors the error field +in the TKEY record set to BADKEY. + + GSS_S_DEFECTIVE_TOKEN + GSS_S_DEFECTIVE_CREDENTIAL + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_DUPLICATE_TOKEN + GSS_S_OLD_TOKEN + GSS_S_NO_CRED + GSS_S_CREDENTIALS_EXPIRED + GSS_S_BAD_BINDINGS + GSS_S_NO_CONTEXT + GSS_S_BAD_MECH + GSS_S_FAILURE + +If OUTPUT major_status is set to GSS_S_COMPLETE or +GSS_S_CONTINUE_NEEDED then server MUST act as described below. + +If major_status is GSS_S_COMPLETE the server component of the +negotiation is finished. If output_token is non-NULL, then it MUST be +returned to the client in a Key Data field of the RDATA in TKEY. The +error field in the TKEY record is set to NOERROR. The message MUST be +signed with a TSIG record as described in section 5, Sending and +Verifying Signed Messages. Note that server is allowed to sign a +response to unsigned client's query due to modification to the RFC +2845 specified in Section 2.2 above. The context state is advanced to +Context Established. Section 4.2 discusses the usage of the security +context. + + + +Expires August 28, 2003 [Page 12] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +If major_status is GSS_S_COMPLETE and output_token is NULL, then the +TKEY record received from the client MUST be returned in the Answer +section of the response. The message MUST be signed with a TSIG record +as described in section 5, Sending and Verifying Signed Messages. Note +that server is allowed to sign a response to unsigned client's query +due to modification to the RFC 2845 specified in section 2.2 above. The +context state is advanced to Context Established. Section 4.2 discusses +the usage of the security context. + +If major_status is GSS_S_CONTINUE, the server component of the +negotiation is not yet finished. The server responds to the TKEY +query with a standard query response, placing in the answer section a +TKEY record containing output_token in the Key Data RDATA field. The +error field in the TKEY record is set to NOERROR. The server MUST limit +the number of times that a given context is allowed to repeat, to +prevent endless looping. Such limit SHOULD NOT exceed value of 10. + +In all cases except if major_status is GSS_S_COMPLETE and output_token +is NULL other TKEY record fields MUST contain the following values: + NAME = key_name + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [RFC2930]) + Key Size = size of output_token in octets + +The remaining fields in the TKEY RDATA, i.e. Inception, Expiration, +Error, Other Size and Data Fields, MUST be set according to [RFC2930]. + + + +4.2 Context Established + +When context negotiation is complete, the handle context_handle +is used for the generation and verification of transaction signatures. +The handle is valid for a finite amount of time determined by the +underlying security mechanism. A server MAY unilaterally terminate +a context at any time (see section 4.2.1). + +Server SHOULD limit the amount of memory used to cache established +contexts. + +The procedures for sending and receiving signed messages are given in +section 5, Sending and Verifying Signed Messages. + + +4.2.1 Terminating a Context + +A server can terminate any established context at any time. The +server MAY hint to the client that the context is being deleted by +including a TKEY RR in a response with the Mode field set to 5, i.e. +"key deletion" [RFC2930]. +An active context is deleted by calling GSS_Delete_sec_context +providing the associated context_handle. + +Expires August 28, 2003 [Page 13] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +5. Sending and Verifying Signed Messages + +5.1 Sending a Signed Message - Call GSS_GetMIC + +The procedure for sending a signature-protected message is specified +in [RFC2845]. The data to be passed to the signature routine includes +the whole DNS message with specific TSIG variables appended. For the +exact format, see [RFC2845]. For this protocol, use the following +TSIG variable values: + + TSIG Record + NAME = key_name that identifies this context + RDATA + Algorithm Name = gss-tsig + +Assign the remaining fields in the TSIG RDATA appropriate values +as described in [RFC2845]. + +The signature is generated by calling GSS_GetMIC. The following input +parameters MUST be used. The outcome of the call is indicated with the +output values specified below. Consult Sections 2.3.1 "GSS_GetMIC +call" of the RFC 2743[RFC2743] for syntax definitions. + + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = outgoing message plus TSIG + variables (per [RFC2845]) + INTEGER qop_req = 0 (0 requests a default + value). Caller MAY instead specify other valid value (for + details see Section 1.2.4 in [RFC2743]) + + OUTPUTS + INTEGER major_status + INTEGER minor_status + OCTET STRING per_msg_token + +If major_status is GSS_S_COMPLETE, then signature generation +succeeded. The signature in per_msg_token is inserted into the +Signature field of the TSIG RR and the message is transmitted. + +If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or +GSS_S_FAILURE the caller MUST delete the security context, return to the +uninitialized state and SHOULD negotiate a new security context, as +described above in Section 3.1 + +If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry +for key_name from the (target_ name, key_name, context_handle) mapping +table, return to the uninitialized state and SHOULD negotiate a new +security context, as described above in Section 3.1 + +If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the +GSS_GetMIC call with allowed QOP value. The number of such repetitions +MUST be limited to prevent infinite loops. + +Expires August 28, 2003 [Page 14] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +5.2 Verifying a Signed Message - Call GSS_VerifyMIC + +The procedure for verifying a signature-protected message is specified +in [RFC2845]. +The NAME of the TSIG record determines which context_handle maps to +the context that MUST be used to verify the signature. If the NAME +does not map to an established context, the server MUST send a +standard TSIG error response to the client indicating BADKEY in the +TSIG error field (as described in [RFC2845]). + +For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: + INPUTS + CONTEXT HANDLE context_handle = context_handle for key_name + OCTET STRING message = incoming message plus TSIG + variables (per [RFC2845]) + OCTET STRING per_msg_token = Signature field from TSIG RR + + OUTPUTS + INTEGER major_status + INTEGER minor_status + INTEGER qop_state + +If major_status is GSS_S_COMPLETE, the signature is authentic and the +message was delivered intact. Per [RFC2845], the timer values of the +TSIG record MUST also be valid before considering the message to be +authentic. The caller MUST not act on the request or response in the +message until these checks are verified. + +When a server is processing a client request, +the server MUST send a standard TSIG error response to the client +indicating BADKEY in the TSIG error field as described in [RFC2845], +if major_status is set to one of the following values + GSS_S_DEFECTIVE_TOKEN + GSS_S_BAD_SIG (GSS_S_BAD_MIC) + GSS_S_DUPLICATE_TOKEN + GSS_S_OLD_TOKEN + GSS_S_UNSEQ_TOKEN + GSS_S_GAP_TOKEN + GSS_S_CONTEXT_EXPIRED + GSS_S_NO_CONTEXT + GSS_S_FAILURE + + +If the timer values of the TSIG record are invalid, the message MUST +NOT be considered authentic. If this error checking fails when a server +is processing a client request, the appropriate error response MUST be +sent to the client according to [RFC2845]. + + + + + + +Expires August 28, 2003 [Page 15] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +6. Example usage of GSS-TSIG algorithm + +This Section describes an example where a Client, client.example.com, +and a Server, server.example.com, establish a security context according +to the algorithm described above. + + + I. Client initializes security context negotiation + To establish a security context with a server, server.example.com, the + Client calls GSS_Init_sec_context with the following parameters + (Note that some INPUT and OUTPUT parameters not critical for this + algorithm are not described in this example) + CONTEXT HANDLE input_context_handle = 0 + INTERNAL NAME targ_name = "DNS@server.example.com" + OCTET STRING input_token = NULL + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + + The OUTPUTS parameters returned by GSS_Init_sec_context include + INTEGER major_status = GSS_S_CONTINUE_NEEDED + CONTEXT HANDLE output_context_handle context_handle + OCTET STRING output_token output_token + BOOLEAN replay_det_state = TRUE + BOOLEAN mutual_state = TRUE + + Client verifies that replay_det_state and mutual_state values are + TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a + success OUTPUT major_status value, client stores context_handle that + maps to "DNS@server.example.com" and proceeds to the next step. + + + II. Client sends a query with QTYPE = TKEY to server + Client sends a query with QTYPE = TKEY for a client-generated globally + unique domain name string, 789.client.example.com.server.example.com. + Query contains a TKEY record in its Additional records section with + the following fields (Note that some fields not specific to this + algorithm are not specified) + + NAME = 789.client.example.com.server.example.com. + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [RFC2930]) + Key Size = size of output_token in octets + Key Data = output_token + + After the key_name 789.client.example.com.server.example.com. + is generated it is stored in the client's (target_name, key_name, + context_handle) mapping table. + + + + + +Expires August 28, 2003 [Page 16] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + III. Server receives a query with QTYPE = TKEY + When server receives a query with QTYPE = TKEY, the server verifies + that Mode and Algorithm fields in the TKEY record in the Additional + records section of the query are set to 3 and "gss-tsig" respectively. + It finds that the key_name 789.client.example.com.server.example.com. + is not listed in its (key_name, context_handle) mapping table. + + + IV. Server calls GSS_Accept_sec_context + To continue security context negotiation server calls + GSS_Accept_sec_context with the following parameters (Note that some + INPUT and OUTPUT parameters not critical for this algorithm are not + described in this example) + INPUTS + CONTEXT HANDLE input_context_handle = 0 + OCTET STRING input_token = token specified in the Key + field from TKEY RR (from Additional + records section of the client's query) + The OUTPUTS parameters returned by GSS_Accept_sec_context include + INTEGER major_status = GSS_S_CONTINUE_NEEDED + CONTEXT_HANDLE output_context_handle context_handle + OCTET STRING output_token output_token + + Server stores the mapping of the + 789.client.example.com.server.example.com. to OUTPUT context_handle + in its (key_name, context_handle) mapping table. + + + V. Server responds to the TKEY query + Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's + call to GSS_Accept_sec_context, the server responds to the TKEY query + placing in the answer section a TKEY record containing output_token in + the Key Data RDATA field. The error field in the TKEY record is set to + 0. The RCODE in the query response is set to NOERROR. + + + VI. Client processes token returned by server + When the client receives the TKEY query response from the server, the + client calls GSS_Init_sec_context with the following parameters (Note + that some INPUT and OUTPUT parameters not critical for this algorithm + are not described in this example) + CONTEXT HANDLE input_context_handle = the context_handle stored + in the client's mapping table entry (DNS@server.example.com., + 789.client.example.com.server.example.com., context_handle) + INTERNAL NAME targ_name = "DNS@server.example.com" + OCTET STRING input_token = token from Key field of TKEY + record from the Answer section of the server's response + BOOLEAN replay_det_req_flag = TRUE + BOOLEAN mutual_req_flag = TRUE + + + The OUTPUTS parameters returned by GSS_Init_sec_context include + INTEGER major_status = GSS_S_COMPLETE + +Expires August 28, 2003 [Page 17] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + + CONTEXT HANDLE output_context_handle = context_handle + OCTET STRING output_token = output_token + BOOLEAN replay_det_state = TRUE + BOOLEAN mutual_state = TRUE + + Since the major_status is set to GSS_S_COMPLETE the client side + security context is established, but since the output_token is not + NULL client MUST send a TKEY query to the server as described below. + + + VII. Client sends a query with QTYPE = TKEY to server + Client sends to the server a TKEY query for the + 789.client.example.com.server.example.com. name. Query contains a TKEY + record in its Additional records section with the following fields + (Note that some INPUT and OUTPUT parameters not critical to this + algorithm are not described in this example) + NAME = 789.client.example.com.server.example.com. + RDATA + Algorithm Name = gss-tsig + Mode = 3 (GSS-API negotiation - per [RFC2930]) + Key Size = size of output_token in octets + Key Data = output_token + + + VIII. Server receives a TKEY query + When the server receives a TKEY query, the server verifies that Mode + and Algorithm fields in the TKEY record in the Additional records + section of the query are set to 3 and gss-tsig, repectively. It + finds that the key_name 789.client.example.com.server.example.com. is + listed in its (key_name, context_handle) mapping table. + + + IX. Server calls GSS_Accept_sec_context + To continue security context negotiation server calls + GSS_Accept_sec_context with the following parameters (Note that some + INPUT and OUTPUT parameters not critical for this algorithm are not + described in this example) + INPUTS + CONTEXT HANDLE input_context_handle = context_handle from the + (789.client.example.com.server.example.com., context_handle) + entry in the server's mapping table + OCTET STRING input_token = token specified in the Key + field of TKEY RR (from Additional records Section of + the client's query) + + The OUTPUTS parameters returned by GSS_Accept_sec_context include + INTEGER major_status = GSS_S_COMPLETE + CONTEXT_HANDLE output_context_handle = context_handle + OCTET STRING output_token = NULL + + + + +Expires August 28, 2003 [Page 18] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + + Since major_status = GSS_S_COMPLETE, the security context on the + server side is established, but the server still needs to respond to + the client's TKEY query, as described below. The security context + state is advanced to Context Established. + + + X. Server responds to the TKEY query + Since the major_status = GSS_S_COMPLETE in the last server's call to + GSS_Accept_sec_context and the output_token is NULL, the server + responds to the TKEY query placing in the answer section a TKEY record + that was sent by the client in the Additional records section of the + client's latest TKEY query. In addition to this server places a + TSIG record in additional records section of its response. Server + calls GSS_GetMIC to generate a signature to include it in the TSIG + record. The server specifies the following GSS_GetMIC INPUT + parameters: + CONTEXT HANDLE context_handle = context_handle from the + (789.client.example.com.server.example.com., context_handle) + entry in the server's mapping table + OCTET STRING message = outgoing message plus TSIG + variables (as described in [RFC2845]) + + The OUTPUTS parameters returned by GSS_GetMIC include + INTEGER major_status = GSS_S_COMPLETE + OCTET STRING per_msg_token + + Signature field in the TSIG record is set to per_msg_token. + + + XI. Client processes token returned by server + Client receives the TKEY query response from the server. Since the + major_status was GSS_S_COMPLETE in the last client's call to + GSS_Init_sec_context, the client verifies that the server's response + is signed. To validate the signature client calls GSS_VerifyMIC with + the following parameters: + + INPUTS + CONTEXT HANDLE context_handle = context_handle for + 789.client.example.com.server.example.com. key_name + OCTET STRING message = incoming message plus TSIG + variables (as described in [RFC2845]) + OCTET STRING per_msg_token = Signature field from TSIG RR + included in the server's query response + + Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the + signature is validated, security negotiation is complete and the + security context state is advanced to Context Established. These + client and server will use the established security context to sign + and validate the signatures when they exchange packets with each + other until the context expires. + + + +Expires August 28, 2003 [Page 19] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +7. Security Considerations + +This document describes a protocol for DNS security using GSS-API. +The security provided by this protocol is only as effective as the +security provided by the underlying GSS mechanisms. + +All the security considerations from RFC2845, RFC2930 and RFC 2743 +apply to the protocol described in this document. + + +8. IANA Considerations + +The authors request that the IANA reserve the TSIG Algorithm name +gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource +records. This Algorithm name refers to the algorithm described in this +document. The requirement to have this name registered with IANA is +specified in RFC 2845. + + +9. Conformance + +The GSS API using SPNEGO [RFC2478] provides maximum flexibility to +choose the underlying security mechanisms that enables security context +negotiation. GSS API using SPNEGO [RFC2478] enables client and server to +negotiate and choose such underlying security mechanisms on the fly. To +support such flexibility, DNS clients and servers SHOULD specify SPNEGO +mech_type in their GSS API calls. At the same time, in order to +guarantee interoperability between DNS clients and servers that support +GSS-TSIG it is required that +- DNS servers specify SPNEGO mech_type +- GSS APIs called by DNS client support Kerberos v5 +- GSS APIs called by DNS server support SPNEGO [RFC2478] and + Kerberos v5. + +In addition to these, GSS APIs used by DNS client and server MAY also +support other underlying security mechanisms. + + +10. Acknowledgements + +The authors of this document would like to thank the following people +for their contribution to this specification: Chuck Chan, Mike Swift, +Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake 3rd and Erik +Nordmark. + + +11. References + +[RFC2743] J. Linn, "Generic Security Service Application Program + Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories, + January 2000. + + + +Expires August 28, 2003 [Page 20] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + +[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000, + +[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, Motorola, September 2000. + +[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions," + RFC 2535, IBM, March 1999. + +[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update," + RFC 2137, CyberCash, April 1997. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1034, November 1987. + +[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", + RFC 1964, OpenVision Technologies, June 1996. + +[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", + RFC 2025, Bell-Northern Research, October 1996. + +[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API + Negotiation Mechanism", RFC 2478, Bull, December 1998. + +[ISO11578]"Information technology", "Open Systems + Interconnection", "Remote Procedure Call", + ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html. + + +12. Author's Addresses + +Stuart Kwan Praerit Garg +Microsoft Corporation Microsoft Corporation +One Microsoft Way One Microsoft Way +Redmond, WA 98052 Redmond, WA 98052 +USA USA +skwan@microsoft.com praeritg@microsoft.com + +James Gilroy Levon Esibov +Microsoft Corporation Microsoft Corporation +One Microsoft Way One Microsoft Way +Redmond, WA 98052 Redmond, WA 98052 +USA USA +jamesg@microsoft.com levone@microsoft.com + + + +Expires August 28, 2003 [Page 21] + +INTERNET-DRAFT GSS-TSIG February 28, 2003 + + +Randy Hall Jeff Westhead +Lucent Technologies Microsoft Corporation +400 Lapp Road One Microsoft Way +Malvern PA 19355 Redmond, WA 98052 +USA USA +randyhall@lucent.com jwesth@microsoft.com + + + +Expires August 28, 2003 [Page 22] diff --git a/doc/draft/draft-ietf-dnsext-insensitive-03.txt b/doc/draft/draft-ietf-dnsext-insensitive-03.txt new file mode 100644 index 0000000000..60260c3105 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-insensitive-03.txt @@ -0,0 +1,580 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Clarifies STD0013 Motorola Laboratories +Expires September 2003 April 2003 + + + + Domain Name System (DNS) Case Insensitivity Clarification + ------ ---- ------ ----- ---- ------------- ------------- + + + Donald E. Eastlake 3rd + + + +Status of This Document + + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group at namedroppers@ops.ietf.org. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. 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. + + + +Abstract + + Domain Name System (DNS) names are "case insensitive". This document + explains exactly what that means and provides a clear specification + of the rules. This clarification should not have any interoperability + consequences. + + + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Acknowledgements + + The contributions to this document of Rob Austein, Olafur + Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, + Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully + acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Case Insensitivity of DNS Labels........................3 + 2.1 Escaping Unusual DNS Label Octets......................3 + 2.2 Example Labels with Escapes............................4 + 2.3 Name Lookup Case Insensitivity.........................4 + 2.4 Original DNS Label Types...............................5 + 3. Additional DNS Case Insensitivity Considerations........5 + 3.1 CLASS Case Insensitivity Considerations................5 + 3.2 Extended Label Type Case Insensitivity Considerations..5 + 4. Case on Input and Output................................6 + 4.1 DNS Output Case Preservation...........................6 + 4.2 DNS Input Case Preservation............................6 + 4.3 Wildcard Matching......................................7 + 5. Internationalized Domain Names..........................7 + 6. Security Considerations.................................7 + + Normative References.......................................9 + Informative References.....................................9 + -02 to -03 Changes........................................10 + Author's Address..........................................10 + Expiration and File Name..................................10 + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS Case Insensitivity + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. Each node in the DNS tree has a name consisting of + zero or more labels [STD 13][RFC 1591, 2606] that are treated in a + case insensitive fashion. This document clarifies the meaning of + "case insensitive" for the DNS. + + 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]. + + + +2. Case Insensitivity of DNS Labels + + DNS was specified in the era of [ASCII]. DNS names were expected to + look like most host names or Internet email address right halves (the + part after the at-sign, "@") or be numeric as in the in-addr.arpa + part of the DNS name space. For example, + + foo.example.net. + aol.com. + www.gnu.ai.mit.edu. + or 69.2.0.192.in-addr.arpa. + + Case varied alternatives to the above would be DNS names like + + Foo.ExamplE.net. + AOL.COM. + WWW.gnu.AI.mit.EDU. + or 69.2.0.192.in-ADDR.ARPA. + + The individual octets of which DNS names consist are not limited to + valid ASCII character codes. They are as 8-bit bytes and all values + are allowed. Many applications, however, interprete them as ASCII + characters. + + + +2.1 Escaping Unusual DNS Label Octets + + In Master Files [STD 13] and other human readable and writable ASCII + contexts, an escape is needed for the byte value for period (0x2E, + ".") and all octet values outside of the inclusive range of 0x21 ("!") + to 0x7E ("~"). That is to say, 0x2E and all octet values in the two + inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. + + One typographic convention for octets that do not correspond to an + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS Case Insensitivity + + + ASCII printing graphic is to use a back-slash followed by the value of + the octet as an unsigned integer represented by exactly three decimal + digits. + + The same convention can be used for printing ASCII characters so that + they will be treated as a normal label character. This includes the + back-slash character used in this convention itself and the special + label separator period (".") which can be expressed as \092 and \046 + respectively. It is advisable to avoid using a backslash to quote an + immediately following non-printing ASCII character code to avoid + implementation difficulties. + + A back-slash followed by only one or two decimal digits is + undefined. A back-slash followed by four decimal digits produces two + octets, the first octet having the value of the first three digits + considered as a decimal number and the second octet being the + character code for the fourth decimal digit. + + + +2.2 Example Labels with Escapes + + The first example below shows embedded spaces and a period (".") + within a label. The second one show a 5 octet label where the second + octet has all bits zero, the third is a backslahs, + and the fourth octet has all bits one. + + Donald\032E\.\032Eastlake\0323rd.example. + and a\000\\\255z.example. + + + +2.3 Name Lookup Case Insensitivity + + The design decision was made that comparisons on name lookup for DNS + queries should be case insensitive [STD 13]. That is to say, a lookup + string octet with a value in the inclusive range of 0x41 to 0x5A, the + upper case ASCII letters, MUST match the identical value and also + match the corresponding value in the inclusive range 0x61 to 0x7A, + the lower case ASCII letters. And a lookup string octet with a lower + case ASCII letter value MUST similarly match the identical value and + also match the corresponding value in the upper case ASCII letter + range. + + (Historical Note: the terms "upper case" and "lower case" were + invented after movable type. The terms originally referred to the + two font trays for storing, in partitioned areas, the different + physical type elements. Before movable type, the nearest equivalent + terms were "majuscule" and "minuscule".) + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS Case Insensitivity + + + One way to implement this rule would be, when comparing octets, to + subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A + before the comparison. Such an operation is commonly known as "case + folding" but implementation via case folding is not required. Note + that the DNS case insensitivity does NOT correspond to the case + folding specified in iso-8859-1 or iso-8859-2. For example, the + octets 0xDD (\221) and 0xFD (\253) do NOT match although in other + contexts, where they are interpreted as the upper and lower case + version of "Y" with an acute accent, they might. + + + +2.4 Original DNS Label Types + + DNS labels in wire encoded names have a type associated with them. + The original DNS standard [RFC 1035] had only two types. ASCII + labels, with a length of from zero to 63 octets and indirect labels + which consist of an offset pointer to a name location elsewhere in + the wire encoding on a DNS message. (The ASCII label of length zero + is reserved for use as the name of the root node of the name tree.) + ASCII labels follow the ASCII case conventions described above. + Indirect labels are, in effect, replaced by the name to which they + point which is then treated with the case insensitivity rules in this + document. + + + +3. Additional DNS Case Insensitivity Considerations + + This section clarifies the effect of DNS CLASS and extended Label + Type on case insensitivity. + + + +3.1 CLASS Case Insensitivity Considerations + + As described in [STD 13] and [RFC 2929], DNS has an additional axis + for data location called CLASS. The only CLASS in global use at this + time is the "IN" or Internet CLASS. + + The handling of DNS label case is not CLASS dependent. + + + +3.2 Extended Label Type Case Insensitivity Considerations + + DNS was extended by [RFC 2671] to have additional label type numbers + available. (The only such type defined so far is the BINARY type [RFC + 2673].) + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS Case Insensitivity + + + The ASCII case insensitivity conventions, or case folding, only apply + to ASCII labels, that is to say, label type 0x0, whether appearing + directly or invoked by indirect labels. + + + +4. Case on Input and Output + + While ASCII label comparisons are case insensitive, case MUST be + preserved on output, except when output is optimized by the use of + indirect labels, and preserved when convenient on input. + + + +4.1 DNS Output Case Preservation + + [STD 13] views the DNS namespace as a node tree. ASCII output is as + if a name was marshalled by taking the label on the node whose name + is to be output, converting it to a typographically encoded ASCII + string, walking up the tree outputting each label encountered, and + preceding all labels but the first with a period ("."). Wire output + follows the same sequence but each label is wire encoded and no + periods inserted. No "case conversion" or "case folding" is done + during such output operations. However, to optimize output, indirect + labels may be used to point to names elsewhere in the DNS answer. In + determining whether the name to be pointed to is the "same" as the + remainder of the name being optimized, the case insensitive + comparison specified above is done. Thus such optimization MAY + destroy the output preservation of case. This type of optimization is + commonly called "name compression". + + + +4.2 DNS Input Case Preservation + + Originally, DNS input came from an ASCII Master File as defined in + [STD 13]. DNS Dynamic update has been added as a source of DNS data + [RFC 2136, 3007]. When a node in the DNS name tree is created by such + input, no case conversion is done and the case of ASCII labels is + preserved if they are for nodes being created. However, when a name + label is input for a node that already exist in DNS data being + augmented or updated, the situation is more complex. Implemenations + may retain the case first input for such a label or allow new input + to override the old case or maintain separate copies preserving the + input case. + + For example, if data with owner name "foo.bar.example" is input and + then later data with owner name "xyz.BAR.example" is input, the name + of the label on the "bar.example" node, i.e. "bar", might or might + not be changed to "BAR" or the actual input case could be preserved. + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS Case Insensitivity + + + Thus later retrieval of data stored under "xyz.bar.example" in this + case can easily result is obtaining data with "xyz.BAR.example". The + same considerations apply when inputting multiple data records with + owner names differing only in case. From the example above, if an "A" + record is stored under owner name "xyz.BAR.example" and then a second + "A" record under "XYZ.BAR.example", the second MAY be stored with the + first (lower case initial label) name. + + Note that the order of insertion into a server database of the DNS + name tree nodes that appear in a Master File is not defined so that + the results of inconsistent capitalization in a Master File are + unpredicatable output capitalization. + + + +4.3 Wildcard Matching + + There is one additional instance of note, which reflects the general + rules that output case reflects input case unless there is + conflicting capitalization in the DNS database or the output case is + hidden by name compression. This is when a query matches a wildcard + in the DNS database at a server. In that case, the answer SHOULD + reflect the input case of the label or labels that matched the + wildcard unless they are replaced by an indirect label which MAY + point to a name with different capitalization. + + + +5. Internationalized Domain Names + + A scheme has been adopted for "internationalized domain names" and + "internationalized labels" as described in [RFC 3490, 3454, 3491, and + 3492]. It makes most of [UNICODE] available through a separate + application level transformation from internationalized domain name + to DNS domain name and from DNS domain name to internationalized + domain name. Any case insensitivity that internationalized domain + names and labels have varies depending on the script and is handled + entirely as part of the transformation described in [RFC 3454] and + [RFC 3491] which should be seen for further details. This is not a + part of the DNS as standardized in STD 13. + + + +6. Security Considerations + + The equivalence of certain DNS label types with case differences, as + clarified in this document, can lead to security problems. For + example, a user could be confused by believing two domain names + differing only in case were actually different names. + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS Case Insensitivity + + + Furthermore, a domain name may be used in contexts other than the + DNS. It could be used as a case sensitive index into some data base + system. Or it could be interpreted as binary data by some integrity + or authentication code system. These problems can usually be handled + by using a standardized or "canonical" form of the DNS ASCII type + labels, that is, always map the ASCII letter value octets in ASCII + labels to some specific pre-chosen case, either upper case or lower + case. An example of a canonical form for domain names (and also a + canonical ordering for them) appears in Section 8 of [RFC 2535]. See + also [UNKRR]. + + Finally, a non-DNS name may be stored into DNS with the false + expectation that case will always be preserved. For example, although + this would be quite rare, on a system with case sensitive email + address local parts, an attempt to store two "RP" records that + differed only in case would probably produce unexpected results that + might have security implications. That is because the entire email + address, including the possibly case sensitive local or left hand + part, is encoded into a DNS name in a readable fashion where the case + of some letters might be changed on output as described above. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS Case Insensitivity + + +Normative References + + [ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + [RFC 1034, 1035] - See [STD 13]. + + [RFC 2119] - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner, March 1997. + + [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", November 2000. + + [STD 13] + - P. Mockapetris, "Domain names - concepts and facilities", RFC + 1034, November 1987. + - P. Mockapetris, "Domain names - implementation and + specification", RFC 1035, November 1987. + + [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", + draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. + + + +Informative References + + [RFC 1591] - J. Postel, "Domain Name System Structure and + Delegation", March 1994. + + [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain + Name System (DNS) IANA Considerations", September 2000. + + [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August + 1999. + + [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", + August 1999. + + [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of + Internationalized String ("stringprep")", December 2002. + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS Case Insensitivity + + + [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", March 2003. + + [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile + for Internationalized Domain Names (IDN)", March 2003. + + [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode + for Internationalized Domain Names in Applications (IDNA)", March + 2003. + + [UNICODE] - The Unicode Consortium, "The Unicode Standard", + . + + + +-02 to -03 Changes + + The following changes were made between draft version -02 and -03: + + 1. Add internationalized domain name section and references. + + 2. Change to indicate that later input of a label for an existing DNS + name tree node may or may not be normalized to the earlier input or + override it or both may be preserved. + + 3. Numerous minor wording changes. + + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-851-8280 (w) + +1 508-634-2066 (h) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires September 2003. + + Its file name is draft-ietf-dnsext-insensitive-03.txt. + + + + + +D. Eastlake 3rd [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt b/doc/draft/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt new file mode 100644 index 0000000000..01ed924aca --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt @@ -0,0 +1,1178 @@ + + + + + + +INTERNET-DRAFT H. Kitamura + NEC Corporation +Expires in six months 2 December 2002 + + Domain Name Auto-Registration for Plugged-in IPv6 Nodes + + +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. + +Abstract + + This document describes a scheme of "Domain Name Auto-Registration + for Plugged-in IPv6 Nodes" mechanism that makes it possible to + register both regular and inverse domain name information of plugged- + in IPv6 nodes to DNS servers automatically. + + Since IPv6 addresses are too long to remember and EUI64-based + addresses are too complicated to remember, there are strong + requirements to use logical names that are easy to remember instead + of IPv6 addresses to specify IPv6 nodes and to register domain name + information of plugged-in IPv6 nodes automatically. + + In order to meet the requirements, a mechanism is proposed as one of + the IPv6 auto-configuration (plug and play) functions. After the + Address Autoconfiguration [ADDR-AUTO] has been executed, it works as + a succeeding plug and play mechanism. + + This document clarifies problems that we meet when we apply the + Dynamic Updates in the DNS [DYN-DNS] to automatic domain name + information registration mechanisms. This document describes the + Domain Name Auto-Registration mechanism as a solution to these + problems. + + + +H. Kitamura [Page 1] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + The Domain Name Auto-Registration mechanism, in addition to its main + functionality, provides two types of additional benefits. + + One is that IP address information that should be registered to the + DNS is collected automatically. The mechanism can also be used under + (non plug and play) manual configuration situations in a different + manner from its main functionality. Under such situations, network + administrators meet a problem that it is not easy to collect IP + address information to register to the DNS. The mechanism solves it. + + The other is that a plugged-in IPv6 node can obtain its domain name + information (FQDN and DNS zone suffix) without having new functions + installed into it. By simply executing inverse DNS name resolving + procedures with its IPv6 address argument, the plugged-in IPv6 node + can obtain its FQDN and DNS zone suffix with ease. + + +1. Introduction + + This document describes a scheme of "Domain Name Auto-Registration + for Plugged-in IPv6 Nodes" mechanism that makes it possible to + register both regular and inverse domain name information of plugged- + in IPv6 nodes to DNS servers automatically. + + In order to specify destination nodes to communicate, SOME + identifiers are necessary for users. Since IPv6 addresses are too + long to remember and EUI64-based addresses are too complicated to + remember, they are not suitable for such identifiers. Logical names + are suitable identifiers because they are easy to remember. + Therefore, there are strong requirements to use logical names instead + of IPv6 addresses to specify IPv6 destination nodes and to register + domain name information of plugged-in IPv6 nodes automatically. + + In order to meet the requirements, a mechanism is proposed as one of + the IPv6 auto-configuration (plug and play) functions. After the + Address Autoconfiguration [ADDR-AUTO] has been executed, it works as + a succeeding plug and play mechanism. + + It is known that the Dynamic Updates in the DNS [DYN-DNS] have + already been defined and that they can help automatic domain name + information registration mechanisms. However, some problems need to + be solved to apply this idea to actual situations. + + This document clarifies problems that we meet when we apply the + Dynamic Updates in the DNS [DYN-DNS] to automatic domain name + information registration mechanisms. This document describes the + Domain Name Auto-Registration mechanism as a solution to these + problems. + + + +H. Kitamura [Page 2] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + Basic target situations for the mechanism are plug and play + situations. Accordingly, it has been designed for plugged-in IPv6 + nodes under plug and play situations. + + We have to consider the following issues to design the "Domain Name + Auto-Registration for Plugged-in IPv6 Nodes" mechanism. + + 1. Plugged-in IPv6 nodes do not have sufficient capability to show + their preferences. In most cases, it is difficult for plugged-in + IPv6 nodes to show their preferences for their domain names. + + 2. Since it is not easy to install new function to all IPv6 nodes, it + is desirable to achieve the mechanism without installing new + functions into plugged-in IPv6 nodes. + + 3. It is essential to have (register) SOME domain name for a + plugged-in node. It is NOT main concern for a plugged-in node + which actual name is assigned to it. + + Thus, the idea of "default domain name" is introduced. When a new + plugged-in IPv6 node appears, its appearance is automatically + detected and a default domain name is selected for it, and both + regular and inverse information of the default domain name are + registered to appropriate DNS servers. + + This document does not deal with cases where IPv6 nodes want to + register domain names that they absolutely prefer. Such cases do not + fall within the target range of plug and play situations; they will + be supported under manual configuration situations. + + There are various types of plugged-in IPv6 nodes that can/cannot show + their preferences for their domain names. In order to meet various + plug and play situations, this document considers several cases. + + The Domain Name Auto-Registration mechanism is basically designed for + domain name registrations for global unicast addresses. By setting + the query scope of the target DNS server appropriately, the mechanism + will be able to be applied to domain name registrations for site- + local and link-local scope unicast addresses. + + The Domain Name Auto-Registration mechanism, in addition to its main + functionality, provides two types of additional benefits. + + One is that IP address information that should be registered to the + DNS is collected automatically. The mechanism can also be used under + (non plug and play) manual configuration situations in a different + manner from its main functionality. Under such situations where + network is maintained by administrators manually, administrators meet + + + +H. Kitamura [Page 3] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + a problem that it is not easy to collect IP address information to + register to the DNS. The mechanism solves the problem, and IP address + information to register to the DNS is collected automatically. + + Under manual configuration situations, the automatic DNS registration + procedure that is the last procedure of the mechanism can be replaced + by the administrators' manual registration (not by the Dynamic + Updates). + + + The other is that a plugged-in IPv6 node can obtain its domain name + information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6 + nodes know its IPv6 address that are automatically configured by the + Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse + DNS name resolving procedures with the IPv6 address argument, the + plugged-in IPv6 node can obtain information on its domain names (FQDN + and DNS zone suffix) easily. Since all IPv6 nodes have DNS name + resolving functions for both regular and inverse queries, this + procedure can be achieved without installing new functions into IPv6 + nodes. + + +2. Problems in applying the Dynamic Updates mechanism + + This section clarifies problems that we meet when we apply the + Dynamic Updates in the DNS [DYN-DNS] to automatic domain name + information registration mechanisms. + + 1: Ordinary DNS servers accept Dynamic Updates messages only from + trusted nodes. + + Since it is difficult for plugged-in IPv6 nodes to become trusted + nodes of the DNS servers, Dynamic Updates messages from plugged-in + IPv6 nodes are usually not accepted by the DNS servers. + + 2: It is difficult for plugged-in IPv6 nodes to know the location of + the appropriate DNS server to register their domain name + information to. + ([DNS-DISC] discusses on issues of this type.) + + 3: It is difficult for plugged-in IPv6 nodes to prepare sufficient + domain name information to register. They need to know their DNS + zone suffix information to prepare FQDN for registration, but it + is difficult for them to acquire it. + ([DNS-DISC] also discusses on issues of this type.) + + 4: There is no explicit method to avoid duplicated, conflicting name + registrations. + + + +H. Kitamura [Page 4] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + When a DNS server receives Dynamic Updates messages that are + correctly formatted and authenticated, the server accepts them and + updates DNS database with them without checking for duplication. + (It is essentially difficult for a DNS server to distinguish + overwrite (update) registrations from duplicate registrations.) + + 5: Basically, there is no mechanism to control (restrict) the number + of issued Dynamic Updates messages for plugged-in nodes. + + In order to minimize the effects of malicious or misconfigured + registration requests, it is necessary to control them. + + 6: It is not clear when domain name registration requests must be + issued. It is necessary to define trigger timings to start + registrations. + + +3. Basic Design of the Domain Name Auto-Registration + + This section describes the basic design of the Domain Name Auto- + Registration mechanism. The mechanism solves all of the above- + mentioned problems. + + +3.1 Design Policies + + The Domain Name Auto-Registration mechanism is composed of two new + functions. One is the "Detector" function, which detects appearances + of new plugged-in IPv6 nodes. The other is the "Registrar" function, + which registers detected domain name information to DNS servers. + These functions are introduced into the IPv6 network system to + achieve the mechanism. + + There are several reasons why the mechanism is implemented as two + functions. + + 1. To make the mechanism easy to control + + By concentrating administrative operations only on the Registrar + side, administrative costs are reduced and the mechanism is + basically maintained by administering only Registrars. + + The number of DNS servers' trusted nodes that require much + administrative operation is reduced. + + Since registration information is aggregated at Registrars, it + becomes easy to control registrations and minimize the effects of + malicious or misconfigured registration requests. + + + +H. Kitamura [Page 5] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + 2. To make Detector easy to implement + + There are certain constraints in placing Detectors on the IPv6 + network. Thus, it is necessary for Detectors to be simple enough + to be installed on IPv6 nodes of any type. + + This need is filled by putting all the intelligent operations into + Registrars. + + Furthermore, the system becomes well balanced since intelligent + operations are not placed on each end link. + + 3. To make the mechanism flexible and enable it to be applied + to various environments (office networks, home networks, etc.) + + If the mechanism is applied to home networks, Registrars can be + placed at the Provider side, and Detectors can be placed at the + User side. + + + Figure 1 and 2 show typical examples that indicate locations where + Detector and Registrar functions are placed on the IPv6 network. + + Figure 1 shows a case for a single link, and Figure 2 shows a case + for multiple links. + + + + + | +------------+ + | | DNS Server | + +-+-+ %%%%%%%%%%%% ############# +------+-----+ + | R | % Detector % # Registrar # / + +-+-+ %%%%%%%%%%%% ############# +---+ + | | | / + ----+---------+-------+------+---------------+----- + | + +===========+ + | Plugged-in| + | IPv6 Node | + +===========+ + + Fig. 1 Single-Link Case Example + + + + + + + + +H. Kitamura [Page 6] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + +------------+ + | DNS Server | + ############# +------+-----+ + # Registrar # / + ############# +---+ + | / + ----+-----------+------------+-------+------ + | | + +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% + | R1| % Detector1 % | R2| % Detector2 % + +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%% + | | | | + ----+-----+-----+----- ----+-----+-----+----- + | | + +===========+ +===========+ + | Plugged-in| | Plugged-in| + | IPv6 Node | | IPv6 Node | + +===========+ +===========+ + + Fig. 2 Multiple-Link Case Example + + + One Registrar can take charge of multiple Detectors, and one + Registrar can cover multiple DNS zones. + + Multiple Detectors can provide detected information for one DNS zone. + If the corresponding Registrars of these Detectors are different, + multiple Registrars can cover one DNS zone. + + Therefore, Registrars must be designed to support both cases. + + + +3.2 Detector Function + + The role of a "Detector" is to detect appearances of new plugged-in + IPv6 nodes and to send the detected information to a "Registrar" + without applying any selection rules to it. + + Detectors are NOT required to perform any "intelligent" operations. + + A Detector knows the location of its corresponding Registrar. (This + location is configured manually.) Detected information must be sent + securely from the Detector to the Registrar by using some kind of + secure communication method (e.g., [TSIG]-like authentication, IPsec + (AH, ESP), [TLS]). + + + + + +H. Kitamura [Page 7] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + Since a Detector must be placed where appearances of new plugged-in + IPv6 nodes can be detected, the Detector location is restricted. + + In typical cases, appearances are detected by watching for DAD + packets that are issued from plugged-in IPv6 nodes (see section 3.4). + So, the Detector must be placed where it can listen to link-local + scope multicast packets. In other words, a Detector must be placed on + each link to achieve the mechanism. + + The Detector function can be implemented on routers, because its + operations are simple and lightweight and routers are located at + suitable places for listening to link-local scope multicast packets + that are issued from plugged-in IPv6 nodes. + + In order to identify Detectors, each Detector must have its own + Detector ID. Since a Detector is placed on each link, the Detector's + IP address that is connected to its watching link can be used for the + Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm + is also applied here.) When a Detector sends detected information to + a Registrar, the Detector ID is attached to it. + + In order to meet "temporary address" [RFC3041] issues (see section + 5), a link-layer address of a detected IP address is also attached to + detected information. + + Some simple protocol is necessary to send detected information from + the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS- + HTTP]-based simple protocol is shown. + +3.3 Registrar Function + + The role of a "Registrar" is to prepare appropriate domain name + information for registration and to register it by sending Dynamic + Update messages to the corresponding "DNS servers". + + Appropriate domain name information for registration is created from + detected information that is sent from the Detector. Some sort of + intelligent algorithm is necessary in such procedures. One of the + roles of the algorithm is to minimize the effects of malicious or + misconfigured registration requests. + + Registrars are required to perform "intelligent" operations. + + By using some sort of algorithm, the Registrar verifies (checks) + whether detected information must be registered (see section 3.5). + After the verification procedures are completed, the Registrar + selects a "default domain name" for the detected information. + + + + +H. Kitamura [Page 8] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + In order to prepare appropriate domain name information, the + Registrar must know the appropriate DNS zone suffix for detected + information. (The suffix is configured manually.) The DNS zone suffix + depends on the Detector ID information. + + A Registrar must know the locations of "DNS servers" that correspond + to detected information for registration (both regular DNS zone + prefix and its inverse zone). Registrars must be trusted nodes of the + DNS servers and Dynamic Update messages must be sent securely from + the Registrar to the DNS servers by using some sort of secure + communication methods. The [TSIG] technique would be suitable for + authenticating the messages. + + A Registrar has a database table to manage such knowledge. The + following elements are managed in the database table: + Detector IDs, DNS zone suffixes, locations of DNS servers, applied + algorithms (naming rules, how to deal with link-local or site-local + scope addresses, etc.) and keys for secure communications. + + A Registrar can be placed anywhere in the IPv6 network, because the + Registrar communicates only with Detectors and DNS servers, all + communications are unicast. + + In order to optimize the communication path for packets between them, + the Registrar is usually placed in the network upstream from the + Detectors (see Fig.2). + + Detected information that is sent from Detectors is aggregated at the + Registrar. + + The Registrar may frequently execute inverse DNS name resolving + procedures to verify (check) whether detected information must be + registered. It is recommended to put a DNS cache server function on + the same node where the Registrar is placed to reduce inverse DNS + name resolving traffic (see section 3.5). + +3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes + + In order to detect appearances of new plugged-in IPv6 nodes, the + Detector must watch or receive packets from new plugged-in nodes. + Accordingly, detection methods on the Detector are categorized into + two types. + + One is detection of the appearance of "standard" plugged-in nodes + that do not issue special packets to show their appearance. The other + is detection of the appearance of "active" plugged-in nodes that + issue special packets to show their appearance. + + + + +H. Kitamura [Page 9] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + We can assume there will be complex cases in which standard and + active plugged-in nodes are mixed together. For purposes of + simplification, such cases are not discussed here. + +3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes + + In this case, plugged-in nodes do NOT issue special dedicated packets + to show their appearance. (Current standard networks are composed of + such nodes.) So, the Detector must watch for packets that are issued + somewhere from new plugged-in nodes. + + The initial procedure for a standard plugged-in IPv6 node is to auto- + configure its address and do DAD (Duplicate Address Detection) [ADDR- + AUTO]. + + DAD packets have sufficient characteristics for an appearance- + detection method, because they are issued only when IPv6 nodes are + plugged in, and address information for the plugged-in IPv6 nodes is + included in DAD packets. + + By watching for only DAD packets, the Detector can detect appearances + of new plugged-in IPv6 nodes, and DAD packets become triggers to + start Domain Name Auto-Registration. + + This method enables the mechanism to function without introducing new + protocols and without installing new functions into plugged-in IPv6 + nodes. + + + DAD packets are issued not only for global addresses but also for + link-local or site-local scope addresses. All detected information is + sent to the Registrar, and the manner of dealing with information for + non-global addresses is determined by Registrar algorithms that are + indicated by Detector IDs of the detected information. + + + This method works effectively on ordinary IPv6 links where DAD + packets are issued. However, on extraordinary IPv6 links where DAD + packets are not issued, it does not work. On such links, there must + be another initial procedure that substitutes the DAD function. Such + a procedure can be used as a trigger for a detection method on + extraordinary IPv6 links. + + (IP addresses can be assigned by other methods (e.g., DHCP). Domain + name registration mechanisms for such cases will be discussed further + in other documents.) + + + + + +H. Kitamura [Page 10] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + +3.4.2 Detecting Appearance of "Active" Plugged-in Nodes + + In this case, plugged-in nodes issue special dedicated packets to + show their appearance. The Detector must listen for and receive + packets from the new plugged-in nodes. + + Since plugged-in nodes do not know the location of the Detector, + anycast or multicast packets are used for the special dedicated + packets. + + In this method, plugged-in nodes can actively show their preference + for their domain names. However, it will be difficult to show their + preference under plug and play situations. + + In order to achieve the method, new protocols must be defined and new + functions must be installed into plugged-in IPv6 nodes. + (This will be discussed further in other documents.) + +3.5 Methods of Controlling Registration + + If received Dynamic Update messages are correctly formatted and + authenticated, the DNS server accepts them without checking for any + duplication, because the DNS server can not distinguish overwrite + (update) registrations from duplicate registrations. It is difficult + to achieve a mechanism for avoiding duplicated registrations on the + DNS server side. + + Therefore, registrations by the Dynamic Update messages must be + controlled on the Registrar side. This control mechanism also helps + to minimize the effects of malicious or misconfigured registration + requests. + + Plugged-in nodes may switch on and off frequently and issue DAD + packets frequently. Since the Detector sends detected information + without applying any selection rules to it, all detected information + is sent to the Registrar. Thus, the Registrar must have some + information verification mechanism to avoid duplicated registrations. + + All candidate information (detected addresses) for registration is + checked by using inverse DNS resolving queries of them. If there is + FQDN information that matches the detected address, such registration + candidates are not registered. + + Only when FQDN information for it is NOT found and it is verified + that the detected information is based on first appearance of the + plugged-in node, appropriate domain name information for registration + is prepared and both regular and inverse domain name information for + it are registered to the DNS servers by the Dynamic Update messages. + + + +H. Kitamura [Page 11] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + By using this verification mechanism, the Registrar does not have to + have a local database to maintain the status of the detected + information and no DNS registration inconsistency problems are + caused. + + By restricting the number of Dynamic Update messages that are sent + from the Registrar per unit of time, the effects of malicious or + misconfigured registration requests are minimized. + + +3.6 Naming Rules for Default Domain Names + + This section describes a method of setting "default domain names" for + plugged-in nodes. + + A fully qualified "default domain name" is composed of a node's + original prefix part and a DNS zone suffix part that is the same for + each site or link. + + Since a DNS zone suffix is given to the Registrar manually, only the + naming rules for a node's original prefix are discussed here. A + naming rule algorithm for a node's prefix is given to the Registrar + manually. + + It is not necessary to define naming rules for a node's prefix + explicitly in this document. Each site can define its own naming + rules (algorithms) per link according to site policy. + + This document shows some example naming rules for a node's prefix + name. + + 1. Prefix Letter(s) + Number + + This is the easiest rule. First, prefix letter(s) that depends on + each link (Detector ID) is/are selected, and the following number + is selected after that. + + The following numbers comprise sequential numbers. In order to + achieve this, the Registrar must remember the last selected + number. + + There are some situations where using sequential numbers is not + favorable because the next number could be easily predicted. In + those cases, random numbers can be used, which makes it necessary + to implement the Registrar with a duplicate number check + mechanism. + + + + + +H. Kitamura [Page 12] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + 2. Predefined Names + + The Registrar prepares predefined names (e.g., names of flowers) + that are used for prefix names for plugged-in nodes. Random or + sequential numbers can be used to prepare predefined names. + + This method can be used for an environment where the number of + plugged-in nodes can be estimated and the number is not + excessively large. + + 3. Use Preferences of Plugged-in Nodes. + + The Registrar inquires the preference or property of a plugged-in + node, and uses the obtained information as a hint to define a + prefix name for the plugged-in node. + + There are two types of methods for plugged-in nodes to indicate + their preference or property. + + + One is "passive" indication. Plugged-in nodes do NOT become an + initiator to indicate their preferences. The Registrar becomes an + initiator and issues query packets to plugged-in nodes. Existing + protocol (e.g., Node Information Query [NIQ], SNMP) is used for + it. + + For a detected global address, the Registrar can use Node + Information Query [NIQ] to obtain hint information to define a + name for the plugged-in node. + + By using [SNMP], the Registrar can also obtain hint information to + define a name for the plugged-in node. Plugged-in nodes use parts + of MIB to indicate their preferences or properties. It is possible + to define a special MIB for this purpose. Also, some parts of + currently existing MIB can be used for it. Most plugged-in nodes + have already set some property information (OS type, version, + etc.) to their MIB when they are plugged in. Such information can + be used for a hint to define a prefix name. (The Registrar must + have an appropriate read access right to such MIB information.) + + The other is "active" indication. Plugged-in nodes become an + initiator to indicate their preferences and issue special + dedicated packets for it. Since plugged-in nodes do not know the + location of the Detector or Registrar, anycast or multicast + packets are used for them. It is possible to attach name + preference information to packets that are used for showing the + appearance of plugged-in nodes. The Registrar can receive such + information via the Detector. + + + +H. Kitamura [Page 13] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + In order to achieve the "active" indication method, new protocols + must be defined and new functions must be installed into plugged- + in IPv6 nodes. + (This will be discussed further in other documents.) + + +4. Procedures of the Domain Name Auto-Registration + + Figure 3 shows an example of typical Domain Name Auto-Registration + procedures at IPv6 links where DAD packets are issued. DAD packets + are used for the appearance detection method (for standard plugged-in + IPv6 nodes). + + Plugged-in Router Detector Registrar DNS servers + IPv6 Node + | link local | | | | + (a)|---DAD NS--->----------->| | | + (b)| no NA | | | | + (c)| | |----------->| | + | | | | | + | global | | | | + (d)|(----RS--->)| | | | + (e)|<----RA-----| | | | + (f)|---DAD NS--->----------->| | | + (g)| no NA | | | | + (h)| | |----------->| | + | | | | | + (i)| | | |----------->| + (j)| | | |<-----------| + | | | | | + (k)|(<-----------------------------------)| | + (l)|(----------------------------------->)| | + | | | | | + (m)| | | |----------->| + (n)| | | |<-----------| + | | | | | + (o)| | | |----------->| + (p)| | | |<-----------| + (q)| | | |----------->| + (r)| | | |<-----------| + | | | | | + + Fig. 3 Example of Typical Auto-Registration Procedures + + (a) and (b) are DAD procedures for the link-local address of the + Plugged-in Node. (b) is a procedure to verify that there is no NA + (reply to NS) and the link-local address is not duplicated on the + link. + + + +H. Kitamura [Page 14] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + The Detector watches (a) and (b), and detects the appearance of new + plugged-in IPv6 nodes. (c) is a procedure for sending the detected + information, to which the Detector ID is attached. The scope of the + detected address is not checked at the Detector. + + After the Registrar receives the detected information by the + procedure (c), the scope of the detected address and the decision + algorithm (which depends on the Detector ID) are checked on the + Registrar. + + In typical cases, the decision algorithm shows that link-local + addresses are not candidates for registration. In such cases, the + detected information for the link-local address is discarded at this + point. + + (d)(e)(f) and (g) are DAD procedures for the global address of the + Plugged-in Node. (d) is an optional procedure. (g) is a procedure to + verify that there is no NA (reply to NS) and that the global address + is not duplicated. + + The Detector watches (f) and (g), and detects the appearance of new + plugged-in IPv6 nodes. (h) is a procedure for sending the detected + information, to which the Detector ID is attached. + + After the Registrar receives the detected information by the + procedure (h), the scope of the detected address and decision + algorithm (which depends on Detector ID) are checked on the + Registrar. + + In typical cases, the decision algorithm shows that global addresses + are candidates for registration. In such cases, check procedures to + avoid duplicated registrations are started at this point. + + (i) and (j) are check procedures to verify that the detected address + is must be registered to the DNS. The Registrar checks for the + existence of FQDN information for the detected address by executing + "inverse DNS name resolving" procedures with the detected address + argument. + + If the existence of FQDN information for the detected address is + verified, such detected address information for registration is + canceled and discarded at this point. + + If the existence is not verified, the Registrar starts preparing + "default domain name" information for the candidate IPv6 address. DNS + zone suffix information that depends on the Detector ID is taken from + the Registrar's manually configured database table, and the naming + rule algorithm that depends on the Detector ID is also taken from it. + + + +H. Kitamura [Page 15] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + By following the defined naming rule algorithm, the plugged-in node's + prefix name is selected. + + (k) and (l) are optional procedures for preparing "default domain + name." If the naming rule that is applied for the detected address + stipulates inquiring the preference or property of the node, (k) and + (l) are executed and such information is obtained by the Registrar. + The obtained information is used as a hint to select the prefix name + of the plugged-in node. + + A candidate "default domain name" for the detected address is + prepared here. + + (m) and (n) are check procedures to verify that the candidate + "default domain name" is not used by anyone. The Registrar checks for + the existence of the candidate "default domain name" by executing + "regular DNS name resolving" procedures with the candidate "default + domain name." + + If the existence is not verified, it becomes fully qualified "default + domain name." If the existence is verified, the Registrar restarts + and repeats preparing a candidate "default domain name" for the + detected address. + + + After fully qualified "default domain name" information to register + is prepared, (o)(p)(q) and (r) are executed to register both regular + and inverse domain name information to the DNS servers by the Dynamic + Update messages. + + (Under manual configuration situations, (o)(p)(q) and (r) procedures + are replaced by the administrators' manual registration (not by the + Dynamic Updates).) + + +5. Treatment of "Temporary Addresses" in the Mechanism + + "Temporary address" is defined in [RFC3041]. Temporary addresses are + detected in this mechanism, because DAD packets are issued when + temporary address are generated. + + There are two views whether domain names for temporary addresses + should be registered to the DNS or not. + + One view is that domain names for temporary addresses should NOT be + registered to the DNS, because temporary addresses are temporary and + they are introduced to lessen privacy concerns. + + + + +H. Kitamura [Page 16] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + The other view is domain names for temporary addresses should be + registered to the DNS. [RFC3041] discusses on this issue at section 4 + of [RFC3041]. In order to meet conventional inverse-DNS-based + "authentication," nodes could register temporary addresses in the DNS + using random names. The Domain Name Auto-Registration mechanism can + provide a solution for this issue. + + Since there are two views for domain names registration of temporary + addresses, which view should be chosen is depends on site policies. + + + +5.1 How to Distinguish "Temporary Addresses" from Public Addresses + + In order to apply above discussed policies, it is necessary to + distinguish "temporary addresses" from public addresses. + + Only with IP address information, it is difficult to tell that a + detected address is a temporary address or a public addresses. So, + link-layer address information is utilized to achieve this operation + (see section 3.2). + + By utilizing link-layer address information, we can easily tell that + a detected address is a EUI64-based address or not. (This operation + is called a "EUI64 check" operation.) + + If a detected address is a EUI64-based, it is not a temporary + address. It is a normal target address for the Domain Name Auto- + Registration mechanism. + + If not, it must be a either temporary address or manually configured + address. We can assume that a domain name for a manually configured + address must have been registered in the DNS manually. + + In the mechanism, an IP address whose domain name has been already + registered does not become a candidate. It is verified by "inverse + DNS name resolving" check procedures (see (i) and (j) procedures in + Figure 3). + + By applying a "EUI64 check" operation after "inverse DNS name + resolving" check procedures, we can assume that non EUI64-based + address must be a temporary address. Since temporary addresses are + distinguished from public addresses, we can apply above discussed + policies to temporary addresses. + + + + + + + +H. Kitamura [Page 17] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + +6. Security Considerations + + After the Address Autoconfiguration [ADDR-AUTO] has been executed, + the Domain Name Auto-Registration works as a succeeding of the plug + and play mechanism. The plugged-in IPv6 nodes' appearances detection + method is depend on the Address Autoconfiguration. + + Thus, the items that are described in the Security Considerations + section of the Address Autoconfiguration [ADDR-AUTO] are also + applicable to this document. + + In addition, the following security issues are considered. + + Since the Detector must send detected information to the Registrar + securely, some sort of secure communication method (e.g., [TSIG]-like + authentication, IPsec (AH, ESP), [TLS]) must be used. + + The Registrars must be trusted nodes of the DNS servers and Dynamic + Update messages must be sent securely from the Registrar to the DNS + servers by using some sort of secure communication method. The [TSIG] + technique would be suitable for authenticating the messages. + + In order to minimize the effects of malicious or misconfigured + registration requests, the Registrar restricts the number of Dynamic + Update messages that are sent from the Registrar per unit of time. + + + + + + + + + + + + + + + + + + + + + + + + + + +H. Kitamura [Page 18] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + +Appendix A. HTTP-based simple protocol between Detector and Registrar + + a. Design of HTTP parameters + + - Request Parameters + method = + detectorID = + IP-address = + link-layer-address = + source = + time-detected = + + - Response Parameters + result = + address = + hostname = + namehint = + error = + time-accepted = + + b. Message Examples + + - Request message + POST /cgi-bin/registrar.cgi HTTP/1.1 + Host: registrar-host + Content-Length: mmm + User-Agent: DAD-detector + Content-type: application/x-pnp-dnar + + method=register/2.0 + detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1 + IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0 + link-layer-address=00:00:4c:zz:zz:zz + source=DAD-detector + time-detected=1013078377 + + - Response message + HTTP/1.1 200 OK + Content-Type : text/plain + Content-Length : nnn + Connection : close + + result=REGISTER + address=3ffe:yyyy::202:b3ff:fe2d:68c0 + hostname=host.example.com + namehint=none + time-accepted=1013078378 + + + + +H. Kitamura [Page 19] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + +References + + [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification," RFC2460, December 1998. + + [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)," RFC 2461, December 1998. + + [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address + Autoconfiguration," RFC2462, December 1998. + + [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic + Updates in the Domain Name System," RFC 2136, April 1997. + + [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B. + Wellington, "Secret Key Transaction Signatures for DNS + (TSIG)," RFC 2845, May 2000. + + [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", + RFC2246, January 1999 + + [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures + ( SIG(0)s)," RFC2931, September 2000. + + [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update," RFC3007, November 2000. + + [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing + Authority," RFC 3008, November 2000. + + [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol + Operations for Version 2 of the Simple Network Management + Protocol (SNMPv2)," RFC1905, January 1996. + + [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless + Address Autoconfiguration in IPv6," RFC3041, January 2001 + + [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1" + RFC2616, June 1999 + + [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1" + RFC2817, May 2000 + + + + + + + + + +H. Kitamura [Page 20] + +INTERNET-DRAFT Domain Name Auto-Registration December 2002 + + + [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local + unicast addresses for DNS resolver," + , October 2002 + + [DEF-ADDR] R. Draves, "Default Address Selection for IPv6," + , August 2002 + + + [NIQ] M. Crawford, "IPv6 Node Information Queries," + , May 2002 + + + + + + +Author's Address: + + Hiroshi Kitamura + NEC Corporation + Development Laboratories + (Igarashi Building 4F) 11-5, Shibaura 2-Chome, + Minato-Ku, Tokyo 108-8557, JAPAN + + Phone: +81 (3) 5476-1071 + Fax: +81 (3) 5476-1005 + Email: kitamura@da.jp.nec.com + + + + + + + + + + + + + + + + + + + + + + + + +H. Kitamura [Page 21] diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt new file mode 100644 index 0000000000..dba5f909f8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt @@ -0,0 +1,560 @@ + + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: August 18, 2003 J. Schlyter + Carlstedt Research & + Technology + E. Lewis + ARIN + February 17, 2003 + + + KEY RR Key-Signing Key (KSK) Flag + draft-ietf-dnsext-keyrr-key-signing-flag-06 + +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. + + This Internet-Draft will expire on August 18, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + With the DS resource record the concept of key-signing and + zone-signing keys has been introduced. During key-exchanges with the + parent there is a need to differentiate between these zone- and + key-signing keys. We propose a flag to indicate which key is used as + key-signing key. + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 1] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 7. Internationalization Considerations . . . . . . . . . . . . . 5 + 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6 + 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6 + 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6 + 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6 + 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 6 + 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 2] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6] + + With the definition of the DS Resource Record [5] the concept of a + key being either a key-signing key (KSK) or zone-signing key(ZSK) has + been introduced into DNSSEC[3]. A KSK is one that signs the zone's + KEY RR set, and is a key that is either used to generate a DS RR or + is distributed to resolvers that use the key as the root of a trusted + subtree[4]. + + In early deployment tests, the use of two keys has been prevalent, + one key for exchange with delegating zone and the other key to sign + the zone. These dual roles were defined to allow a zone to more + rapidly change the ZSK without a high volume of traffic needed to + make new DS RRs. Because of this, participants have had to manage + two keys at all times, one acting as a KSK and the other ZSK (per + cryptographic algorithm). In practice, participants used a longer + key for the KSK or resorted to writing the footprints on paper. + + There is a need to differentiate between a KSK and a ZSK by the zone + administrator. This need is driven by knowing which keys are to be + sent for DS RRs, which keys are to be distributed to resolvers, and + which keys are fed to the signer application at the appropriate time. + + While addressing this need it is important that the distinction is + made in a way compatible with single key zone, those whose KSK and + ZSK is one in the same. The best way to address this is to define a + bit setting in the KEY RR flags field that is ignored in the + resolver. This allows for both dual key and single key management to + be workable. + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + + + + + + + + + + + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 3] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + +2. The Key-Signing Key (KSK) Flag + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |K| protocol | algorithm | + | |S| | | + | |K| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + KEY RR Format + + The KSK bit (TBD) in the flags field is assigned to be the + key-signing key flag. If the the bit is set to 1 the key is intended + to be used as key-signing key. One SHOULD NOT assign special meaning + to the key if the bit is set to 0. The document proposes using the + current 15th bit [1] as the KSK bit. This way operators can recognize + the key-signing by the even or odd-ness of the decimal representation + of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The KSK flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the KSK flag does not change the DNS resolution and resolution + protocol. + +4. Operational Guidelines + + The KSK bit is set by the key-generator and used by the zone signer: + + The KSK bit is used to indicate that the key represented in the KEY + RR is intended to sign the KEY RR set of the zone. As the KSK bit is + within the data that is used to compute a KEY RR's footprint, + changing the KSK bit will change the identity of the key within DNS. + + When a key pair is created, the operator needs to indicate whether + the KSK bit is to be set in the KEY RR. The KSK bit is recommended + whenever the public key of the key pair will be distributed to the + parent zone to build the authentication chain or if the public key is + to be distributed for static configuration in verifiers. + + When signing a zone, it is intended that the key(s) with the KSK bit + + + +Kolkman, et al. Expires August 18, 2003 [Page 4] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a KSK bit set will sign the KEY + RR set, such keys might be pending retirement or not yet in use. + + When verifying a RR set, the KSK bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the KSK flag provides a hint on which key to be used as + trusted root, administrators can choose to ignore the flag when + configuring a trusted root for their resolvers. + + Using the flag a key roll over can be automated. The parent can use + an existing trust relation to verify key sets in which a new key with + the KSK flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to used in the resolution + protocol or to determine the security status of a key. The flag is to + be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating key exchanges, we think + the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a key exchange + where a key set, containing two keys with the KSK flag set, is sent + to the parent. The parent verifies the key set with the existing + trust relation and creates the new DS RR from the key that the + current DS is not pointing to. This key exchange might be replayed. + Parents are encouraged to implement a replay defence. A simple + defence can be based on a registry of keys that have been used to + generate DS RRs during the most recent roll over. + +6. IANA Considerations + + draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags + field except for the zone key flag in the KEY RR. We propose to use + the 15'th bit as the KSK bit; the decimal representation of the + flagfield will then be odd for key-signing keys. + +7. Internationalization Considerations + + + + +Kolkman, et al. Expires August 18, 2003 [Page 5] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + There are no internationalization considerations. + +8. Document Changes + +8.1 draft version 00 -> 01 + + Clean up of references and correction of typos; + + modified Abstract text a little; + + Added explicit warning for replay attacks to the security section; + + Removed the text that hinted on a distinction between a + key-signing key configured in resolvers and in parent zones. + + +8.2 draft version 01 -> 02 + + Added IANA and Internationalization section. + + Split references into informational and normative. + + Spelling and style corrections. + + +8.3 draft version 02 -> 03 + + Changed the name from KS to KSK, this to prevent confusion with + NS, DS and other acronyms in DNS. + + In the security section: Rewrote the section so that it does not + suggest to use a particular type of registry and that it is clear + that a key registry is only one of the defences possible. + + Spelling and style corrections. + + +8.4 draft version 03 -> 04 + + Text has been made consistent with the statement: 'No special + meaning should be assigned to the bit not being set.' + + Made explicit that the keytag changes in SIG RR. + + +8.5 draft version 04 -> 05 + + One occurrence of must and one occurrence of should uppercased + + + +Kolkman, et al. Expires August 18, 2003 [Page 6] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + (RFC2119). + + Reordering of sentences in section 3, so that the point of the bit + NOT being used in resolving is made directly. + + To make explicit that the KSK is used at key generation and at + signing time I added the first sentence to section 4. + + Some minor style and spelling corrections. + + +8.6 draft version 05 -> 06 + + References and acronyms where stripped from the Abstract. the + Introduction and the the Operational Guideline section were + rewritten in such a way that the draft does not suggest any use of + the bit in the verification process and that the draft does not + enforce, but suggests, the use of a key- and zone-signing key. + + Added 'and verification' in the sentence "MUST NOT be used during + the resolving and verification process" (protocol changes + section). + + +9. Acknowledgements + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Olafur Gudmundsson, Daniel Karrenberg, Dan + Massey, Marcos Sanz and Sam Weiler have contributed ideas and + provided feedback. + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI. + +Normative References + + [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work + in progress), September 2002. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [4] Lewis, E., "DNS Security Extension Clarification on Zone + + + +Kolkman, et al. Expires August 18, 2003 [Page 7] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + Status", RFC 3090, March 2001. + +Informative References + + [5] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-12 (work in progress), + December 2002. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story"", ISBN 0151002177 (50th anniversery edition), April 1996. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + Carlstedt Research & Technology + Stora Badhusgatan 18-20 + Goteborg SE-411 21 + Sweden + + EMail: jakob@crt.se + URI: http://www.crt.se/~jakob/ + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 8] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman, et al. Expires August 18, 2003 [Page 9] + +Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires August 18, 2003 [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-mdns-19.txt b/doc/draft/draft-ietf-dnsext-mdns-19.txt new file mode 100644 index 0000000000..f87df7cde9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-19.txt @@ -0,0 +1,1260 @@ + + + + + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +12 May 2003 + + + Linklocal Multicast Name Resolution (LLMNR) + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. + +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 + +Today, with the rise of home networking, there are an increasing number +of ad-hoc networks operating without a Domain Name System (DNS) server. +In order to allow name resolution in such environments, Link-Local +Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all +current and future DNS formats, types and classes, while operating on a +separate port from DNS, and with a distinct resolver cache. + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name resolution using LLMNR ........................... 4 + 2.1 Sender behavior ................................. 5 + 2.2 Responder behavior .............................. 5 + 2.3 Unicast queries ................................. 6 + 2.4 Addressing ...................................... 7 + 2.5 Off-link detection .............................. 8 + 2.6 Retransmissions ................................. 8 + 2.7 DNS TTL ......................................... 9 +3. Usage model ........................................... 9 + 3.1 Unqualified names ............................... 10 + 3.2 LLMNR configuration ............................. 10 +4. Conflict resolution ................................... 12 + 4.1 Considerations for multiple interfaces .......... 13 + 4.2 API issues ...................................... 14 +5. Security considerations ............................... 15 + 5.1 Scope restriction ............................... 15 + 5.2 Usage restriction ............................... 16 + 5.3 Cache and port separation ....................... 17 + 5.4 Authentication .................................. 17 +6. IANA considerations ................................... 17 +7. Normative References .................................. 17 +8. Informative References ................................ 18 +Acknowledgments .............................................. 19 +Authors' Addresses ........................................... 19 +Intellectual Property Statement .............................. 20 +Full Copyright Statement ..................................... 20 + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +1. Introduction + +This document discusses Link Local Multicast Name Resolution (LLMNR), +which operates on a separate port from the Domain Name System (DNS), +with a distinct resolver cache, but does not change the format of DNS +packets. LLMNR supports all current and future DNS formats, types and +classes. However, since LLMNR only operates on the local link, it +cannot be considered a substitute for DNS. + +The goal of LLMNR is to enable name resolution in scenarios in which +conventional DNS name resolution is not possible. These include +scenarios in which hosts are not configured with the address of a DNS +server, where configured DNS servers do not reply to a query, or where +they respond with errors, as described in Section 3. + +LLMNR queries are sent to and received on port TBD. Link-scope +multicast addresses are used to prevent propagation of LLMNR traffic +across routers, potentially flooding the network; for details, see +Section 2.4. LLMNR queries can also be sent to a unicast address, as +described in Section 2.3. + +Propagation of LLMNR packets on the local link is considered sufficient +to enable name resolution in small networks. The assumption is that if +a network has a home gateway, then the network either has DNS and DHCPv4 +servers or the home gateway provides DHCPv4 and DNS server +functionality. By providing Dynamic Host Configuration Service for +IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS, +which is also authoritative for the A RRs of local hosts, it is possible +to support resolution of local host names over IPv4. + +For small IPv6 networks, equivalent functionality can be provided by +implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for +DNS configuration [DHCPv6DNS], as well providing a DNS server with +support for dynamic DNS, which is also authoritative for the AAAA RRs of +local hosts, it is possible to support the resolution of local host +names over IPv6 as well as IPv4. + +In the future, LLMNR may be defined to support greater than link-scope +multicast. This would occur if LLMNR deployment is successful, the +assumption that LLMNR is not needed on multiple links proves incorrect, +and multicast routing becomes ubiquitous. For example, it is not clear +that this assumption will be valid in large ad hoc networking scenarios. + +Once we have experience in LLMNR deployment in terms of administrative +issues, usability and impact on the network it will be possible to +reevaluate which multicast scopes are appropriate for use with multicast +name resolution mechanisms. + + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Service discovery in general, as well as discovery of DNS servers using +LLMNR in particular, is outside of the scope of this document, as is +name resolution over non-multicast capable media. + +1.1. Requirements + +In this document, several words are used to signify the requirements of +the specification. These words are often capitalized. The key words +"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD +NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be +interpreted as described in [RFC2119]. + +1.2. Terminology + +Responder A host that listens to LLMNR queries, and responds to + those for which it is authoritative. + +Sender A host that sends an LLMNR query. Typically a host is + configured as both a sender and a responder. However, a + host may be configured as a sender, but not a responder + or as a responder, but not a sender. + +Routable address + An address other than a linklocal address. This includes + site local and globally routable addresses, as well as + private addresses. + +2. Name resolution using LLMNR + +A typical sequence of events for LLMNR usage is as follows: + +[1] A sender needs to resolve a query for a name "host.example.com", + so it sends an LLMNR query to the link-scope multicast address. + +[2] A responder responds to this query only if it is authoritative + for the domain name "host.example.com". The responder sends + a response to the sender via unicast over UDP. + +[3] Upon the reception of the response, the sender performs the checks + described in Section 2.5. If these conditions are met, then the + sender uses and caches the returned response. If not, then the + sender ignores the response and continues waiting for the response. + +Further details of sender and responder behavior are provided in the +sections that follow. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +2.1. Sender behavior + +A sender sends an LLMNR query for any legal resource record type (e.g. +A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As +described in Section 2.3, a sender may also send a unicast query. An +LLMNR sender MAY send a request for any name. + +The RD (Recursion Desired) bit MUST NOT be set in a query. If a +responder receives a query with the header containing RD set bit, the +responder MUST ignore the RD bit. + +The sender MUST anticipate receiving no replies to some LLMNR queries, +in the event that no responders are available within the link-scope or +in the event no positive non-null responses exist for the transmitted +query. If no positive response is received, a resolver treats it as a +response that no records of the specified type and class exist for the +specified name (it is treated the same as a response with RCODE=0 and an +empty answer section). + +2.2. Responder behavior + +A responder MUST listen on UDP port TBD on the link-scope multicast +address(es) and on UDP and TCP port TBD on the unicast address(es) that +could be set as the source address(es) when the responder responds to +the LLMNR query. A host configured as a responder MUST act as a sender +to verify the uniqueness of names as described in Section 4. + +Responders MUST NOT respond to LLMNR queries for names they are not +authoritative for, except in the event of a discovered conflict, as +described in Section 4. Responders SHOULD respond to LLMNR queries for +names and addresses they are authoritative for. This applies to both +forward and reverse lookups. + +As an example, a computer "host.example.com." configured to respond to +LLMNR queries is authoritative for the name "host.example.com.". On +receiving an LLMNR A/AAAA resource record query for the name +"host.example.com." the host authoritatively responds with A/AAAA +record(s) that contain IP address(es) in the RDATA of the resource +record. + +If a responder is authoritative for a name, it MAY respond with RCODE=0 +and an empty answer section, if the type of query does not match a RR +owned by the responder. For example, if the host has a AAAA RR, but no +A RR, and an A RR query is received, the host would respond with RCODE=0 +and an empty answer section. + +If a DNS server is running on a host that supports LLMNR, the DNS server +MUST respond to LLMNR queries only for the RRSets owned by the host on + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +which the server is running, but MUST NOT respond for other records for +which the server is authoritative. + +In conventional DNS terminology a DNS server authoritative for a zone is +authoritative for all the domain names under the zone root except for +the branches delegated into separate zones. Contrary to conventional +DNS terminology, an LLMNR responder is authoritative only for the zone +root. + +For example the host "host.example.com." is not authoritative for the +name "child.host.example.com." unless the host is configured with +multiple names, including "host.example.com." and +"child.host.example.com.". As a result, "host" cannot reply to a query +for "child" with NXDOMAIN. The purpose of limiting the name authority +scope of a responder is to prevent complications that could be caused by +coexistence of two or more hosts with the names representing child and +parent (or grandparent) nodes in the DNS tree, for example, +"host.example.com." and "child.host.example.com.". + +In this example (unless this limitation is introduced) an LLMNR query +for an A resource record for the name "child.host.example.com." would +result in two authoritative responses: a name error received from +"host.example.com.", and a requested A record - from +"child.host.example.com.". To prevent this ambiguity, LLMNR enabled +hosts could perform a dynamic update of the parent (or grandparent) zone +with a delegation to a child zone. In this example a host +"child.host.example.com." would send a dynamic update for the NS and +glue A record to "host.example.com.", but this approach significantly +complicates implementation of LLMNR and would not be acceptable for +lightweight hosts. + +A response to a LLMNR query is composed in exactly the same manner as a +response to the unicast DNS query as specified in [RFC1035]. Responders +MUST NOT respond using cached data, and the AA (Authoritative Answer) +bit MUST be set. The response is sent to the sender via unicast. A +response to an LLMNR query MUST have RCODE set to zero. Responses with +RCODE set to zero are referred to in this document as "positively +resolved". LLMNR responders may respond only to queries which they can +resolve positively. + +2.3. Unicast queries and responses + +Unicast queries SHOULD be sent when: + + a. A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + b. The sender's LLMNR cache contains an NS resource record that + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + + enables the sender to send a query directly to the hosts + authoritative for the name in the query, or + + c. The sender queries for a PTR RR. + +If a TC (truncation) bit is set in the response, then the sender MAY use +the response if it contains all necessary information, or the sender MAY +discard the response and resend the query over TCP using the unicast +address of the responder. The RA (Recursion Available) bit in the +header of the response MUST NOT be set. If the RA bit is set in the +response header, the sender MUST ignore the RA bit. + +Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP +unicast LLMNR queries MUST be sent using TCP, using the same connection +as the query. If the sender of a TCP query receives a response not +using TCP, the response MUST be silently discarded. Unicast UDP queries +MAY be responded to with an empty answer section and the TC bit set, so +as to require the sender to resend the query using TCP. Senders MUST +support sending TCP queries, and Responders MUST support listening for +TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on +the TCP listen socket to one (1) so that SYN-ACK packets will have TTL +(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming +connection from off-link since the Sender will not receive a SYN-ACK +from the Responder. + +If an ICMP "Time Exceeded" message is received in response to a unicast +UDP query, or if TCP connection setup cannot be completed in order to +send a unicast TCP query, this is treated as a response that no records +of the specified type and class exist for the specified name (it is +treated the same as a response with RCODE=0 and an empty answer +section). The UDP sender receiving an ICMP "Time Exceeded" message +SHOULD verify that the ICMP error payload contains a valid LLMNR query +packet, which matches a query that is currently in progress, so as to +guard against a potential Denial of Service (DoS) attack. If a match +cannot be made, then the sender relies on the retransmission and timeout +behavior described in Section 2.6. + +2.4. Addressing + +IPv4 administratively scoped multicast usage is specified in +"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope +multicast address a given responder listens to, and to which a sender +sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a +given responder listens to, and to which a sender sends all queries, is +TBD. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +2.5. Off-link detection + +The source address of LLMNR queries and responses MUST be "on link". +The destination address of an LLMNR query MUST be a link-scope multicast +address or an "on link" unicast address; the destination address of an +LLMNR response MUST be an "on link" unicast address. On receiving an +LLMNR query, the responder MUST check whether it was sent to the LLMNR +multicast address; if it was sent to another multicast address, then the +query MUST be silently discarded. + +For IPv4, an "on link" address is defined as a link-local address or an +address whose prefix belongs to a subnet on the local link; for IPv6 +[RFC2460] an "on link" address is either a link-local address, defined +in [RFC2373], or an address whose prefix belongs to a subnet on the +local link. A sender SHOULD prefer RRs including reachable addresses +where RRs involving both reachable and unreachable addresses are +returned in response to a query. + +In composing LLMNR queries, the sender MUST set the Hop Limit field in +the IPv6 header and the TTL field in IPv4 header of the response to one +(1). Even when LLMNR queries are sent to a link-scope multicast +address, it is possible that some routers may not properly implement +link-scope multicast, or that link-scope multicast addresses may leak +into the multicast routing system. Therefore setting the IPv6 Hop Limit +or IPv4 TTL field to one provides an additional precaution against +leakage of LLMNR queries. + +In composing a response to an LLMNR query, the responder MUST set the +Hop Limit field in the IPv6 header and the TTL field in IPv4 header of +the response to one (1). This is done so as to prevent the use of LLMNR +for denial of service attacks across the Internet. + +Implementation note: + + In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket + options are used to set the TTL of outgoing unicast and multicast + packets. The IP_RECVTTL socket option is available on some platforms + to retrieve the IPv4 TTL of received packets with recvmsg(). + [RFC2292] specifies similar options for setting and retrieving the + IPv6 Hop Limit. + +2.6. Retransmissions + +In order to avoid synchronization, LLMNR queries and responses are +delayed by a time uniformly distributed between 0 and 200 ms. + +If an LLMNR query sent over UDP is not resolved within the timeout +interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +the query in order to assure that it was received by a host capable of +responding to it. Since a multicast query sender cannot know beforehand +whether it will receive no response, one response, or more than one +response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all +possible responses, rather than considering the multicast query answered +after the first response is received. A unicast query sender considers +the query answered after the first response is received, so that it only +waits for LLMNR_TIMEOUT if no response has been received. + +LLMNR implementations SHOULD dynamically estimate the timeout value +(LLMNR_TIMEOUT) based on the last response received, on a per-interface +basis, using the algorithms described in [RFC2988], with a minimum +timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be +attempted more than 3 times. Where LLMNR queries are sent using TCP, +retransmission is handled by the transport layer. + +2.7. DNS TTL + +The responder should use a pre-configured TTL value in the records +returned in the LLMNR query response. Due to the TTL minimalization +necessary when caching an RRset, all TTLs in an RRset MUST be set to the +same value. In the additional and authority section of the response the +responder includes the same records as a DNS server would insert in the +response to the unicast DNS query. + +3. Usage model + +LLMNR is a peer-to-peer name resolution protocol that is not intended as +a replacement for DNS. By default, LLMNR requests SHOULD be sent only +when no manual or automatic DNS configuration has been performed, when +DNS servers do not respond, or when they respond to a query with RCODE=3 +(Authoritative Name Error) or RCODE=0, and an empty answer section. + +As noted in [DNSPerf], even when DNS servers are configured, a +significant fraction of DNS queries do not receive a response, or result +in a negative responses due to missing inverse mappings or NS records +that point to nonexistent or inappropriate hosts. Given this, support +for LLMNR as a secondary name resolution mechanism has the potential to +result in a large number of inappropriate queries without the following +additional restrictions: + +[1] If a DNS query does not receive a response, prior to falling + back to LLMNR, the query SHOULD be retransmitted at least + once. + +[2] Where a DNS server is configured, by default a sender + SHOULD send LLMNR queries only for names that are either + unqualified or exist within the default domain. Where no + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + + DNS server is configured, an LLMNR query MAY be sent for + any name. + +[3] A responder with both link-local and routable addresses + MUST respond to LLMNR queries for A/AAAA RRs only with + routable address(es). This encourages use of routable + address(es) for establishment of new connections. + +[4] A sender SHOULD send LLMNR queries for PTR RRs + via unicast, as specified in Section 2.3. + +RRs returned in LLMNR responses MUST only include values that are valid +on the local interface, such as IPv4 or IPv6 addresses valid on the +local link or names defended using the mechanism described in Section 4. +In particular: + +[1] If a link-scope IPv6 address is returned in a AAAA RR, that + address MUST be valid on the local link over which LLMNR is + used. + +[2] If an IPv4 address is returned, it must be reachable through + the link over which LLMNR is used. + +[3] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be valid on the local interface. + +3.1. Unqualified names + +The same host MAY use LLMNR queries for the resolution of unqualified +host names, and conventional DNS queries for resolution of other DNS +names. + +If a name is not qualified and does not end in a trailing dot, for the +purposes of LLMNR, the implicit search order is as follows: + +[1] Request the name with the current domain appended. +[2] Request just the name. + +This is the behavior suggested by [RFC1536]. LLMNR uses this technique +to resolve unqualified host names. + +3.2. LLMNR configuration + +LLMNR usage MAY be configured manually or automatically on a per +interface basis. By default, LLMNR responders SHOULD be enabled on all +interfaces, at all times. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is +possible for a dual stack host to be configured with the address of a +DNS server over IPv4, while remaining unconfigured with a DNS server +suitable for use over IPv6. In these situations, a dual stack host will +send AAAA queries to the configured DNS server over IPv4. + +However, an IPv6-only host unconfigured with a DNS server suitable for +use over IPv6 will be unable to resolve names using DNS. Since +automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and +[DNSDisc]) are not yet widely deployed, and not all DNS servers support +IPv6, lack of IPv6 DNS configuration may be a common problem in the +short term, and LLMNR may prove useful in enabling linklocal name +resolution over IPv6. + +For example, a home network may provide a DHCPv4 server but may not +support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a +circumstance, IPv6-only hosts will not be configured with a DNS server. +Where a DNS server is configured but does not support dynamic client +update over IPv6 or DHCPv6-based dynamic update, hosts on the home +network will not be able to dynamically register or resolve the names of +local IPv6 hosts. If the configured DNS server responds to AAAA RR +queries sent over IPv4 or IPv6 with an authoritative name error +(RCODE=3), then it will not be possible to resolve the names of +IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for +local name resolution. + +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure LLMNR on an interface. The LLMNR Enable Option, described in +[LLMNREnable], can be used to explicitly enable or disable use of LLMNR +on an interface. The LLMNR Enable Option does not determine whether or +in which order DNS itself is used for name resolution. The order in +which various name resolution mechanisms should be used can be specified +using the Name Service Search Option for DHCP [RFC2937]. + +3.2.1. Configuration consistency + +It is possible that DNS configuration mechanisms will go in and out of +service. In these circumstances, it is possible for hosts within an +administrative domain to be inconsistent in their DNS configuration. + +For example, where DHCP is used for configuring DNS servers, one or more +DHCP servers can go down. As a result, hosts configured prior to the +outage will be configured with a DNS server, while hosts configured +after the outage will not. Alternatively, it is possible for the DNS +configuration mechanism to continue functioning while configured DNS +servers fail. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Unless unconfigured hosts periodically retry configuration, an outage in +the DNS configuration mechanism will result in hosts continuing to +prefer LLMNR even once the outage is repaired. Since LLMNR only enables +linklocal name resolution, this represents an unnecessary degradation in +capabilities. As a result, it is recommended that hosts without a +configured DNS server periodically attempt to obtain DNS configuration. +A default retry interval of two (2) minutes is RECOMMENDED. + +4. Conflict resolution + +The sender MUST anticipate receiving multiple replies to the same LLMNR +query, in the event that several LLMNR enabled computers receive the +query and respond with valid answers. When this occurs, the responses +MAY first be concatenated, and then treated in the same manner that +multiple RRs received from the same DNS server would. + +There are some scenarios when multiple responders MAY respond to the +same query. There are other scenarios when only one responder MAY +respond to a query. Resource records for which the latter queries are +submitted are referred as UNIQUE throughout this document. The +uniqueness of a resource record depends on a nature of the name in the +query and type of the query. For example it is expected that: + + - multiple hosts may respond to a query for an SRV type record + - multiple hosts may respond to a query for an A or AAAA type + record for a cluster name (assigned to multiple hosts in + the cluster) + - only a single host may respond to a query for an A or AAAA + type record for a hostname. + +Every responder that responds to an LLMNR query AND includes a UNIQUE +record in the response: + + 1. MUST verify that there is no other host within the scope of the + LLMNR query propagation that can return a resource record + for the same name, type and class. + 2. MUST NOT include a UNIQUE resource record in the + response without having verified its uniqueness. + +Where a host is configured to respond to LLMNR queries on more than one +interface, each interface should have its own independent LLMNR cache. +For each UNIQUE resource record in a given interface's configuration, +the host MUST verify resource record uniqueness on that interface. To +accomplish this, the host MUST send an LLMNR query for each UNIQUE +resource record. + +By default, a host SHOULD be configured to behave as though all RRs are +UNIQUE. Uniqueness verification is carried out when the host: + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + + - starts up or + - is configured to respond to the LLMNR queries on an interface or + - is configured to respond to the LLMNR queries using additional + UNIQUE resource records. + +When a host that owns a UNIQUE record receives an LLMNR query for that +record, the host MUST respond. After the client receives a response, it +MUST check whether the response arrived on another interface. If this +is the case, then the client can use the UNIQUE resource record in +response to LLMNR queries. If not, then it MUST NOT use the UNIQUE +resource record in response to LLMNR queries. + +The name conflict detection mechanism doesn't prevent name conflicts +when previously partitioned segments are connected by a bridge. In such +a situation, name conflicts are detected when a sender receives more +than one response to its LLMNR multicast query. In this case, the +sender sends the first response that it received to all responders that +responded to this query except the first one, using UDP unicast. A host +that receives a query response containing a UNIQUE resource record that +it owns, even if it didn't send such a query, MUST verify that no other +host within the LLMNR scope is authoritative for the same name, using +the mechanism described above. Based on the result, the host detects +whether there is a name conflict and acts accordingly. + +4.1. Considerations for Multiple Interfaces + +A multi-homed host may elect to configure LLMNR on only one of its +active interfaces. In many situations this will be adequate. However, +should a host need to configure LLMNR on more than one of its active +interfaces, there are some additional precautions it MUST take. +Implementers who are not planning to support LLMNR on multiple +interfaces simultaneously may skip this section. + +A multi-homed host checks the uniqueness of UNIQUE records as described +in Section 4. The situation is illustrated in figure 1. + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + +In this situation, the multi-homed myhost will probe for, and defend, +its host name on both interfaces. A conflict will be detected on one +interface, but not the other. The multi-homed myhost will not be able +to respond with a host RR for "myhost" on the interface on the right +(see Figure 1). The multi-homed host may, however, be configured to use +the "myhost" name on the interface on the left. + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Since names are only unique per-link, hosts on different links could be +using the same name. If an LLMNR client sends requests over multiple +interfaces, and receives replies from more than one, the result returned +to the client is defined by the implementation. The situation is +illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + +If host myhost is configured to use LLMNR on both interfaces, it will +send LLMNR queries on both interfaces. When host myhost sends a query +for the host RR for name "A" it will receive a response from hosts on +both interfaces. + +Host myhost will then send the first responder's response to the second +responder, who will attempt to verify the uniqueness of host RR for its +name, but will not discover a conflict, since the conflicting host +resides on a different link. Therefore it will continue using its name. + +Host myhost cannot distinguish between the situation shown in Figure 2, +and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + +This illustrates that the proposed name conflict resolution mechanism +does not support detection or resolution of conflicts between hosts on +different links. This problem can also occur with unicast DNS when a +multi-homed host is connected to two different networks with separated +name spaces. It is not the intent of this document to address the issue +of uniqueness of names within DNS. + +4.2. API issues + +[RFC2553] provides an API which can partially solve the name ambiguity +problem for applications written to use this API, since the sockaddr_in6 +structure exposes the scope within which each scoped address exists, and +this structure can be used for both IPv4 (using v4-mapped IPv6 +addresses) and IPv6 addresses. + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Following the example in Figure 2, an application on 'myhost' issues the +request getaddrinfo("A", ...) with ai_family=AF_INET6 and +ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both +interfaces and the resolver library will return a list containing +multiple addrinfo structures, each with an associated sockaddr_in6 +structure. This list will thus contain the IPv4 and IPv6 addresses of +both hosts responding to the name 'A'. Link-local addresses will have a +sin6_scope_id value that disambiguates which interface is used to reach +the address. Of course, to the application, Figures 2 and 3 are still +indistinguishable, but this API allows the application to communicate +successfully with any address in the list. + +5. Security Considerations + +LLMNR is by nature a peer-to-peer name resolution protocol. It is +therefore inherently more vulnerable than DNS, since existing DNS +security mechanisms are difficult to apply to LLMNR and an attacker only +needs to be misconfigured to answer an LLMNR query with incorrect +information. + +In order to address the security vulnerabilities, the following +mechanisms are contemplated: + +[1] Scope restrictions. + +[2] Usage restrictions. + +[3] Cache and port separation. + +[4] Authentication. + +These techniques are described in the following sections. + +5.1. Scope restriction + +With LLMNR it is possible that hosts will allocate conflicting names for +a period of time, or that attackers will attempt to deny service to +other hosts by allocating the same name. Such attacks also allow hosts +to receive packets destined for other hosts. + +Since LLMNR is typically deployed in situations where no trust model can +be assumed, it is likely that LLMNR queries and responses will be +unauthenticated. In the absence of authentication, LLMNR reduces the +exposure to such threats by utilizing queries sent to a link-scope +multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) +fields to one (1) on both queries and responses. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +While this limits the ability of off-link attackers to spoof LLMNR +queries and responses, it does not eliminate it. For example, it is +possible for an attacker to spoof a response to a frequent query (such +as an A/AAAA query for a popular Internet host), and using a TTL or Hop +Limit field larger than one (1), for the forged response to reach the +LLMNR sender. There also are scenarios such as public "hotspots" where +attackers can be present on the same link. + +These threats are most serious in wireless networks such as 802.11, +since attackers on a wired network will require physical access to the +home network, while wireless attackers may reside outside the home. +Link-layer security can be of assistance against these threats if it is +available. + +5.2. Usage restriction + +As noted in Section 3, LLMNR is intended for usage in a limited set of +scenarios. + +If an interface has been configured via any automatic configuration +mechanism which is able to supply DNS configuration information, then +LLMNR SHOULD NOT be used as the primary name resolution mechanism on +that interface, although it MAY be used as a name resolution mechanism +of last resort. + +Note: enabling LLMNR for use in situations where a DNS server has been +configured will result in upgraded hosts changing their default behavior +without a simultaneous update to configuration information. Where this +is considered undesirable, LLMNR SHOULD NOT be enabled by default, so +that hosts will neither listen on the link-scope multicast address, nor +will it send queries to that address. + +Use of LLMNR as a name resolution mechanism increases security +vulnerabilities. For example, if an LLMNR query is sent whenever a DNS +server does not respond in a timely way, then an attacker can execute a +denial of service attack on the DNS server(s) and then poison the LLMNR +cache by responding to the resulting LLMNR queries with incorrect +information. + +The vulnerability is more serious if LLMNR is given higher priority than +DNS among the enabled name resolution mechanisms. In such a +configuration, a denial of service attack on the DNS server would not be +necessary in order to poison the LLMNR cache, since LLMNR queries would +be sent even when the DNS server is available. In addition, the LLMNR +cache, once poisoned, would take precedence over the DNS cache, +eliminating the benefits of cache separation. As a result, LLMNR is +best thought of as a name resolution mechanism of last resort. + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +5.3. Cache and port separation + +In order to prevent responses to LLMNR queries from polluting the DNS +cache, LLMNR implementations MUST use a distinct, isolated cache for +LLMNR on each interface. The use of separate caches is most effective +when LLMNR is used as a name resolution mechanism of last resort, since +this minimizes the opportunities for poisoning the LLMNR cache, and +decreases reliance on it. + +LLMNR operates on a separate port from DNS, reducing the likelihood that +a DNS server will unintentionally respond to an LLMNR query. + +5.4. Authentication + +LLMNR does not require use of DNSSEC, and as a result, responses to +LLMNR queries may be unauthenticated. If authentication is desired, and +a pre-arranged security configuration is possible, then IPsec ESP with a +null-transform MAY be used to authenticate LLMNR responses. In a small +network without a certificate authority, this can be most easily +accomplished through configuration of a group pre-shared key for trusted +hosts. + +6. IANA Considerations + +This specification does not create any new name spaces for IANA +administration. LLMNR requires allocation of a port TBD for both TCP +and UDP. Assignment of the same port for both transports is requested. +LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that +has been previously allocated to LLMNR by IANA. It also requires +allocation of a link-scope multicast IPv6 address. + +7. Normative References + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP + 23, RFC 2365, July 1998. + + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + +[RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + +[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + +8. Informative References + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and + Suggested Fixes", RFC 1536, October 1993. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for + IPv6", RFC 2292, February 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, + "Basic Socket Interface Extensions for IPv6", RFC 2553, + March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6 + Service", Internet draft (work in progress), draft-droms- + dhcpv6-stateless-guide-01.txt, October 2002. + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness + of Caching", IEEE/ACM Transactions on Networking, Volume + 10, Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site + local unicast addresses to communicate with recursive DNS + servers", Internet draft (work in progress), draft-ietf- + ipv6-dns-discovery-07.txt, October 2002. + +[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", Internet + draft (work in progress), draft-ietf-zeroconf- + ipv4-linklocal-07.txt, August 2002. + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft + (work in progress), draft-guttman-mdns-enable-02.txt, + April 2002. + +[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet + draft (work in progress), draft-ietf-ipn-gwg-icmp-name- + lookups-09.txt, May 2002. + +Acknowledgments + +This work builds upon original work done on multicast DNS by Bill +Manning and Bill Woodcock. Bill Manning's work was funded under DARPA +grant #F30602-99-1-0523. The authors gratefully acknowledge their +contribution to the current specification. Constructive input has also +been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert +Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron +Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van- +Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku +Savela. + +Authors' Addresses + +Levon Esibov +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +EMail: levone@microsoft.com + +Bernard Aboba +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +Phone: +1 425 706 6605 +EMail: bernarda@microsoft.com + +Dave Thaler +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + +Phone: +1 425 703 8835 +EMail: dthaler@microsoft.com + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Intellectual Property Statement + +The IETF takes no position regarding the validity or scope of any +intellectual property or other rights that might be claimed to pertain +to the implementation or use of the technology described in this +document or the extent to which any license under such rights might or +might not be available; 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 rights +which may cover technology that may be required to practice this +standard. Please address the information to the IETF Executive +Director. + +Full Copyright Statement + +Copyright (C) The Internet Society (2003). 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 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 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 Internet organizations, +except as needed for the purpose of developing Internet standards in +which case the procedures for copyrights defined in the Internet +Standards process must be followed, or as required to translate it into +languages other than English. The limited permissions granted above are +perpetual and will not be revoked by the Internet Society or its +successors or assigns. This document and the information contained +herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 12 May 2003 + + +Open Issues + +Open issues with this specification are tracked on the following web +site: + +http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + +Expiration Date + +This memo is filed as , and expires +November 22, 2003. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + diff --git a/doc/draft/draft-ietf-dnsext-obsolete-iquery-04.txt b/doc/draft/draft-ietf-dnsext-obsolete-iquery-04.txt new file mode 100644 index 0000000000..b434b129a2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-obsolete-iquery-04.txt @@ -0,0 +1,223 @@ +DNSEXT Working Group David C Lawrence +INTERNET-DRAFT Nominum + July 2002 +Updates: RFC 1035 + + + + + Obsoleting IQUERY + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + 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 + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org. + + This draft expires on 14 January 2003. + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. + +Abstract + + The IQUERY method of performing inverse DNS lookups, specified in + RFC 1035, has not been generally implemented and has usually been + operationally disabled where it has been implemented. Both reflect + a general view in the community that the concept was unwise and + that the widely-used alternate approach of using PTR queries and + reverse-mapping records is preferable. Consequently, this document + deprecates the IQUERY operation and updates RFC 1035 to declare it + entirely obsolete. + + +Expires Jan 2003 [Page 1] + +INTERNET-DRAFT Obsoleting IQUERY July 2002 + +1 - Introduction + + As specified in RFC 1035 (section 6.4), the IQUERY operation for + DNS queries is used to look up the name(s) which are associated + with the given value. The value being sought is provided in the + query's answer section and the response fills in the question + section with one or more 3-tuples of type, name and class. + + As noted in [RFC1035], section 6.4.3, inverse query processing can + put quite an onerous burden on a server. A server would need to + perform either an exhaustive search of its database or maintain a + separate database that is keyed by the values of the primary + database. Both of these approaches could strain system resource + use, particularly for servers that are authoritative for millions + of names. + + Response packet from these megaservers could be exceptionally + large, and easily run into megabyte sizes. For example, using + IQUERY to find every domain that is delegated to one of the + nameservers of a large ISP could return tens of thousands of + 3-tuples in the question section. This could easily be used to + launch denial of service attacks. + + Operators of servers that do support IQUERY in some form (such as + very old BIND 4 servers) generally opt to disable it. This is + largely due to bugs in insufficiently-exercised code, or concerns + about exposure of large blocks of names in their zones by probes + such as inverse MX queries. + + IQUERY is also somewhat inherently crippled by being unable to tell + a requestor where it needs to go to get the information that was + requested. The answer is very specific to the single server that + was queried. This is sometimes a handy diagnostic tool, but + apparently not enough so that server operators like to enable it, + or request implementation where it's lacking. + + No known clients use IQUERY to provide any meaningful service. The + only common reverse mapping support on the Internet, mapping + address records to names, is provided through the use of PTR + records in the in-addr.arpa tree and has served the community well + for many years. + + Based on all of these factors, this draft proposes that the IQUERY + operation for DNS servers be officially obsoleted. + +2 - Requirements + + The key word "SHOULD" in this document is to be interpreted as + described in RFC 2119, namely that there may exit valid reasons + to ignore a particular item, but the full implications must be + understood and carefully weighed before choosing a different course. + +Expires Jan 2003 [Page 2] + +INTERNET-DRAFT Obsoleting IQUERY July 2002 + +3 - Effect on RFC 1035 + + The effect of this document is to change the definition of opcode 1 + from that originally defined in section 4.1.1 of RFC 1035, and to + entirely supersede section 6.4 (including subsections) of RFC 1035. + + The definition of opcode 1 is hereby changed to: + + "1 an inverse query (IQUERY) (obsolete)" + + + The text in section 6.4 of RFC 1035 is now considered obsolete. + The following is an applicability statement regarding the IQUERY + opcode: + + Inverse queries using the IQUERY opcode were originally described + as the ability to look up the names that are associated with a + particular RR. Their implementation was optional and never + achieved widespread use. Therefore IQUERY is now obsolete, and + name servers SHOULD return a "Not Implemented" error when an IQUERY + request is received. + +4 - Security Considerations + + Since this document obsoletes an operation that was once available, + it is conceivable that someone was using it as the basis of a + security policy. However, since the most logical course for such a + policy to take in the face of a lack of positive response from a + server is to deny authentication/authorization, it is highly + unlikely that removing support for IQUERY will open any new + security holes. + + Note that if IQUERY is not obsoleted, securing the responses with + DNSSEC is extremely difficult without out-on-the-fly digital signing. + +5 - IANA Considerations + + The IQUERY opcode of 1 should be permanently retired, not to be + assigned to any future opcode. + +6 - Acknowledgments + + Olafur Gudmundsson was the instigator for this action. + Matt Crawford, John Klensin, Erik Nordmark and Keith Moore + contributed some improved wording as the matter of how to handle + obsoleting functionality described by an Internet Standard. + + + + + + +Expires Jan 2003 [Page 3] + +INTERNET-DRAFT Obsoleting IQUERY July 2002 + +7 - References + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + +[RFC2026] S. Bradner, ``The Internet Standards Process -- Revision 3'', + BCP 9, RFC 2026, October 1996. + +[RFC2119] S. Bradner, ``Key Words for Use in RFCs to Indicate + Requirement Levels'', BCP 14, RFC 2119, March 1997. + +8 - Author's Address + + David C Lawrence + Nominum, Inc. + 2385 Bay Rd + Redwood City CA 94063 + USA + + Phone: +1.650.779.6042 + EMail: tale@nominum.com + +9 - Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + +Expires Jan 2003 [Page 4] diff --git a/doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt b/doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt new file mode 100644 index 0000000000..52c8333ce0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc1886bis-02.txt @@ -0,0 +1,390 @@ +Internet Engineering Task Force S. Thomson, Cisco +INTERNET-DRAFT C. Huitema, Microsoft +February 28, 2003 V. Ksinant, 6WIND +Expires August 28, 2003 M. Souissi, AFNIC + + + + + + DNS Extensions to support IP version 6 + + + +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." + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + This Internet Draft expires August 28, 2003. + + + +Abstract + + This document defines the changes that need to be made to the Domain + Name System to support hosts running IP version 6 (IPv6). The + changes include a resource record type to store an IPv6 address, + a domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + + This Document combines RFC1886 and changes to RFC 1886 made by + RFC 3152, obsoleting both. Changes mainly consist in replacing + the IP6.INT domain by IP6.ARPA as defined in RFC 3152. + + + + + + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 1] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + + +Table of Contents + + 1. Introduction............................................. 2 + 2. New resource record definition and domain................ 2 + 2.1. AAAA record type.................................... 3 + 2.2. AAAA data format.................................... 3 + 2.3. AAAA query.......................................... 3 + 2.4. Textual format of AAAA records...................... 3 + 2.5. IP6.ARPA domain..................................... 3 + 3. Modifications to existing query types.................... 4 + 4. Security Considerations.................................. 4 + 5. IANA Considerations...................................... 4 + APPENDIX A: Changes from RFC-1886............................ 4 + Acknowledgments.............................................. 5 + References................................................... 5 + Authors' Addresses........................................... 6 + Full Copyright Statement..................................... 7 + + +1. INTRODUCTION + + Current support for the storage of Internet addresses in the Domain + Name System (DNS)[1,2] cannot easily be extended to support IPv6 + addresses[3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses in DNS, this document + defines the following extensions: + + o A resource record type is defined to map a domain name to an + IPv6 address. + + o A domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. The + existing support for IPv4 addresses is retained. Transition issues + related to the co-existence of both IPv4 and IPv6 addresses in DNS + are discussed in [4]. + + +2. RESOURCE RECORD DEFINITION AND DOMAIN + + A record type is defined to store a host's IPv6 address. A host + that has more than one IPv6 address must have more than one such + record. + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 2] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + +2.1 AAAA record type + + The AAAA resource record type is a record specific to the Internet + class that stores a single IPv6 address. + + The IANA assigned value of the type is 28 (decimal). + + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not perform additional section processing. + + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of a IPv6 address as defined in [3]. + + +2.5 IP6.ARPA Domain + + A special domain is defined to look up a record given an address. The + intent of this domain is to provide a way of mapping an IPv6 address + to a host name, although it may be used for other purposes as well. + The domain is rooted at IP6.ARPA. + + An IPv6 address is represented as a name in the IP6.ARPA domain by a + sequence of nibbles separated by dots with the suffix ".IP6.ARPA". + The sequence of nibbles is encoded in reverse order, i.e. the + low-order nibble is encoded first, followed by the next low-order + nibble and so on. Each nibble is represented by a hexadecimal digit. + For example, the inverse lookup domain name corresponding to the + address + + 4321:0:1:2:3:4:567:89ab + + would be + +b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. + ARPA. + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 3] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + +3. MODIFICATIONS TO EXISTING QUERY TYPES + + All existing query types that perform type A additional section + processing, i.e. name server (NS), location of services (SRV) and + mail exchange (MX) query types, must be redefined to perform both + type A and type AAAA additional section processing. These definitions + mean that a name server must add any relevant IPv4 addresses and any + relevant IPv6 addresses available locally to the additional section + of a response when processing any one of the above queries. + + +4. SECURITY CONSIDERATIONS + + Any information obtained from the DNS must be regarded as unsafe + unless techniques specified in [7] or [8] are used. The definitions + of the AAAA record type and of the IP6.ARPA domain do not change the + model for use of these techniques. + + So, this specification is not believed to cause any new security + problems, nor to solve any existing ones. + +5. IANA CONSIDERATIONS + + There are no IANA assignments to be performed. + +APPENDIX A: Changes from RFC 1886 + + The following changes were made from RFC 1886 "DNS Extensions to + support IP version 6": + + - Replaced the "IP6.INT" domain by "IP6.ARPA". + - Mentioned SRV query types in section 3 "MODIFICATIONS TO + EXISTING QUERY TYPES" + - Added security considerations. + - Updated references : + * From RFC 1884 to RFC 2373 (IP Version 6 Addressing + Architecture). + * From "work in progress" to RFC 2893 (Transition Mechanisms for + IPv6 Hosts and Routers). + * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. + - Updated document abstract + - Added table of contents + - Added full copyright statement + - Added IANA considerations section + + + + + + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 4] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + +Acknowledgements + + Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien + Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael + Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), + Frederic Roudaut (IRISA) and G6 group for their help during the RFC + 1886 Interop tests sessions. + + Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + + +Normative References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and Specifica- + tion", STD 13, RFC 1035, USC/Information Sciences Institute, + November 1987. + + [3] Hinden, R., and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, Nokia, Cisco, July 1998. + This RFC is being updated. The current draft is + "draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and + S. Deering, October 25, 2002 + + + +Informative References + + [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems + Inc., August 2000. + This RFC is being updated. The current draft is + "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and + E. Nordmark, February 24, 2003 + + [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, Bellcore, INRIA, December 1995. + + [6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August + 2001. + + [7] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, IBM, March 1999 + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000. + + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 5] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + + +Authors' Addresses + + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + Telephone: 732-635-3086 + Email: sethomso@cisco.com + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + Email: huitema@microsoft.com + + + Vladimir Ksinant + 6WIND S.A. + Immeuble Central Gare - Bat.C + 1, place Charles de Gaulle + 78180, Montigny-Le-Bretonneux - France + Phone: +33 1 39 30 92 36 + Email: vladimir.ksinant@6wind.com + + + Mohsen Souissi + AFNIC + Immeuble International + 2, rue Stephenson, + 78181, Saint-Quentin en Yvelines Cedex - France + Phone: +33 1 39 30 83 40 + Email: Mohsen.Souissi@nic.fr + + + + + + + + + + + + + + + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 6] + +INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003 + +Full Copyright Statement + + + Copyright (C) The Internet Society (date). 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 or assist in its implmentation 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 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 Internet + organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights + defined in the Internet Standards process must be followed, or + as required to translate it into languages other than English. + + The limited permissions granted above are perpetual and will + not be revoked by the Internet Society or its successors or + assigns. + + This document and the information contained herein is provided + on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE + OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY + IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE." + + The IETF takes no position regarding the validity or scope of + any intellectual property or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; 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 rights which may cover technology that may be + required to practice this standard. Please address the + information to the IETF Executive Director. + + +draft-ietf-dnsext-rfc1886bis-02.txt [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-03.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-03.txt new file mode 100644 index 0000000000..deaf5ddd0a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-03.txt @@ -0,0 +1,1235 @@ + + + + + + +DNSEXT Working Group Yuji Kamite +INTERNET-DRAFT NTT Communications + Masaya Nakayama +Expires: Sep. 3, 2003 The University of Tokyo + Mar. 3, 2003 + + + + + TKEY Secret Key Renewal Mode + + +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 + + +Abstract + + + This document defines a new mode in TKEY [RFC2930] and proposes an + atomic method for changing secret keys used for TSIG [RFC2845] + periodically. Originally, TKEY provides methods of setting up shared + secrets other than manual exchange, but it cannot control timing of + key renewal very well though it can add or delete shared keys + separately. This proposal is a systematical key renewal procedure + intended for preventing signing DNS messages with old and non-safe + keys permanently. + + + + + + + +Kamite, et. al. [Page 1] + +INTERNET-DRAFT Mar. 2003 + + + Table of Contents + + +1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 + 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 +2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 + 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 + 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6 + 2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8 + 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9 + 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 + 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 + 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 + 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 + 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 +3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14 +4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 15 + 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 +5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 + 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 +6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 +7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 +8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19 +9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 +10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 +Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. [Page 2] + +INTERNET-DRAFT Mar. 2003 + + +1. Introduction + + TSIG [RFC2845] provides DNS message integrity and the + request/transaction authentication by means of message authentication + codes (MAC). TSIG is a practical solution in view of calculation + speed and availability. However, TSIG does not have exchanging + mechanism of shared secret keys between server and resolver, and + administrators might have to exchange secret keys manually. TKEY + [RFC2930] is introduced to solve such problem and it can exchange + secrets for TSIG via networks. + + In various modes of TKEY, a server and a resolver can add or delete a + secret key be means of TKEY message exchange. However, the existing + TKEY does not care fully about the management of keys which became + too old, or dangerous after long time usage. + + It is ideal that the number of secret which a pair of hosts share + should be limited only one, because having too many keys for the same + purpose might not only be a burden to resolvers for managing and + distinguishing according to servers to query, but also does not seem + to be safe in terms of storage and protection against attackers. + Moreover, perhaps holding old keys long time might give attackers + chances to compromise by scrupulous calculation. + + Therefore, when a new shared secret is established by TKEY, the + previous old secret should be revoked immediately. To accomplish + this, DNS servers must support a protocol for key renewal. This + document specifies procedure to refresh secret keys between two hosts + which is defined within the framework of TKEY, and it is called "TKEY + Secret Key Renewal Mode". + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + +1.1. Defined Words + + * Inception Time: Beginning of the shared secret key lifetime. This + value is determined when the key is generated. + + * Expiry Limit: Time limit of the key's validity. This value is + determined when a new key is generated. After Expiry Limit, server + and client (resolver) must not authenticate TSIG signed with the key. + Therefore, Renewal to the next key should be carried out before + Expiry Limit. + + * Partial Revocation Time: Time when server judges the key is too old + + + +Kamite, et. al. [Page 3] + +INTERNET-DRAFT Mar. 2003 + + + and must be updated. It must be between Inception Time and Expiry + Limit. This value is determined by server freely following its + security policy. e.g., If the time from Inception to Partial + Revocation is short, renewal will be carried out more often, which + might be safer. + + * Revocation Time: Time when the key becomes invalid and can be + removed. This value is not determined in advance because it is the + actual time when revocation is completed. + + * Adoption Time: Time when the new key is adopted as the next key + formally. After Adoption, the key is valid and server and client can + generate or verify TSIG making use of it. Adoption Time also means + the time when it becomes possible to remove the previous key, so + Revocation and Adoption are usually done at the same time. + + + Partial + Inception Revocation Revocation Expiry Limit + | | | | + |----------------|- - - - - - >>|- (revoked) -| + | | | | + previous key | | | + |- - - -|-------------------->> time + | | new key + Inception Adoption + + +1.2. New Format and Assigned Numbers + + TSIG + ERROR = (PartialRevoke), to be defined + + TKEY + Mode = (server assignment for key renewal), to be defined + Mode = (Diffie-Hellman exchange for key renewal), to be + defined + Mode = (resolver assignment for key renewal), to be defined + Mode = (key adoption), to be defined + + +1.3. Overview of Secret Key Renewal Mode + + When a server receives a query from a client signed with a TSIG key, + It always checks if the present time is within the range of usage + duration it considers safe. If it is judged that the key is too old, + i.e., after Partial Revocation Time, the server comes to be in + Partial Revocation state about the key, and this key is called + + + +Kamite, et. al. [Page 4] + +INTERNET-DRAFT Mar. 2003 + + + partially revoked. + + In this state, whenever a client sends a normal query (e.g., question + about A RR) other than TKEY Renewal request with TSIG signed with the + old key, the server returns an error message to notify that the time + to renew has come. This is called "PartialRevoke" error message. + + The client which got this error is able to notice that it is + necessary to refresh the secret. To make a new shared secret, it + sends a TKEY Renewal request, in which several keying methods are + available. It can make use of TSIG authentication signed with the + partially revoked key mentioned above. + + After new secret establishment, the client sends a TKEY Adoption + request for renewal confirmation. This can also be authenticated with + the partially revoked key. If this is admitted by the server, the new + key is formally adopted, and at the same time the corresponding old + secret is invalidated. Then the client can send the first query again + signed with the new key. + + Key renewal procedure is executed based on two-phase commit + mechanism. The first phase is the TKEY Renewal request and its + response, which means preparatory confirmation for key update. The + second phase is Adoption request and its response. If the server gets + request and client receives the response successfully, they can + finish renewal process. If any error happens and renewal process + fails during these phases, client should roll back to the beginning + of the first phase, and send TKEY Renewal request again. This + rollback can be done until the Expiry Limit of the key. + + + +2. Shared Secret Key Renewal + + Suppose a server and a client agree to change their TSIG keys + periodically. Key renewal procedure is defined between two hosts. + +2.1. Key Usage Time Check + + Whenever a server receives a query with TSIG and can find a key that + is used for signing it, the server checks its Inception Time, Partial + Revocation Time and Expiry Limit (this information is usually + memorized by the server). + + When the present time is before Inception Time, the server MUST NOT + verify TSIG with the key, and server acts the same way as when no + valid key is found, following [RFC2845]. + + + + +Kamite, et. al. [Page 5] + +INTERNET-DRAFT Mar. 2003 + + + When the present time is equal to Inception Time, or between + Inception Time and Partial Revocation Time, the behavior of the + server is the same as when a valid key is found, required in + [RFC2845]. + + When the present time is the same as the Partial Revocation Time, or + between the Partial Revocation Time and Expiry Limit, the server + comes to be in Partial Revocation state about the TSIG key and + behaves according to the next section. + + When the present time is the same as the Expiry Time or after it, the + server MUST NOT verify TSIG with the key, and returns error messages + in the same way as when no valid key is found, following [RFC2845]. + + +2.2. Partial Revocation + + In Partial Revocation state, we say the server has partially revoked + the key and the key has become a "partially revoked key". + + If server has received a query signed with the partially revoked key + for TKEY Renewal request (See section 2.3.) or "key adoption" request + (See section 2.4.), then server does proper process following each + specification. + + If server receives other types of query signed with the partially + revoked key and the corresponding MAC is verified, then server SHOULD + return TSIG error message for response whose error code is + "PartialRevoke" (See section 9.). However, if it is for TKEY key + deletion request ([RFC2930] 4.2), server MAY process usual deletion + operation defined therein. + + PartialRevoke error messages have the role to inform clients of the + keys' partial revocation and urge them to send TKEY Renewal requests. + These error responses MUST be signed with those partial revoked keys + if the queries are signed with them. They are sent only when the keys + used for queries' TSIG are found to be partially revoked. If the MAC + of TSIG cannot be verified with the partially revoked keys, servers + MUST NOT return PartialRevoke error with MAC, but should return + another error such as "BADSIG" without MAC; in other words, a server + informs its key's partial revocation only when the MAC in the + received query is valid. + + +2.3. Key Renewal Message Exchange + + If a client has received a PartialRevoke error and authenticated the + response based on TSIG MAC, it sends a TKEY query for Key Renewal (in + + + +Kamite, et. al. [Page 6] + +INTERNET-DRAFT Mar. 2003 + + + this document, we call it Renewal request, too.) to the server. The + request MUST be signed with TSIG or SIG(0) [RFC2931] for + authentication. If TSIG is selected, the client can sign it with the + partial revoked key. + + Key Renewal can use one of several keying methods which is indicated + in "Mode" field of TKEY RR, and its message structure is dependent on + that method. + + The server which has received Key Renewal request first tries to + verify TSIG or SIG(0) accompanying it. If the TSIG is signed and + verified with the partially revoked key, the request MUST be + authenticated. + + After authentication, server must check existing old key's validity. + If the partially revoked key indicated in the request TKEY's OldName + and OldAlgorithm field (See section 2.3.1.) does not really exist at + the server, "BADKEY" [RFC2845] is given in Error field for response. + If any other error happens, server returns appropriate error messages + following the specification described in section 2.5. If there are no + errors, server returns a Key Renewal answer. This answer MUST be + signed with TSIG or SIG(0) for authentication. + + When this answer is successfully returned and no error is detected by + client, a new shared secret can be established. The details of + concrete keying procedure are given in the section 2.5. + + As a result of this message exchange, client comes to know the newly + generated key's attributes such as key's name, Inception Time and + Expiry Limit. They are decided finally by the server, and are told to + the client; in particular, however, once the server has decided + Expiry Limit and returned a response, it should obey the decision as + far as it can. In other words, they SHOULD NOT change time values for + checking Expiry Limit in the future without any special reason, such + as security issue like "Emergency Compulsory Revocation" described in + section 8. + + On the other hand, Partial Revocation Time of this generated key is + not decided based on the request, and not informed to the client. The + server can determine any value as long as it is between Inception + Time and Expiry Limit. However, it is recommended that the period + from Inception to Partial Revocation should be fixed as the server + side's configuration or should be set the same as the corresponding + old key's one. + + Note: + Even after the response is returned to client, possibly server + sometimes receives another Renewal TKEY request whose OldName + + + +Kamite, et. al. [Page 7] + +INTERNET-DRAFT Mar. 2003 + + + indicates the same partial revoked key. Mostly such messages + originate in client's resending or rollback because of some kinds + of errors. In this case, the server processes keying again and + MUST replace the associated secret with the newest produced + secret. The secret key produced before comes to be invalid and + should be removed from memory; this process is called secret + overwrite. Moreover, This regenerated key's name MUST always be + different from the one which it overwrites for secret key's + uniqueness and distinction. See section 6, too. + + Even if client sends Key Renewal request though the key described + in OldName has not been partially revoked yet, server must do + renewal processes. But at the moment when the server accepts such + requests with valid authentication, it MUST forcibly consider the + key is already partially revoked, that is, the key's Partial + Revocation Time must be changed into the present time (i.e., the + time when the server receives the request). + +2.3.1. TKEY RR structure for Key Renewal + + TKEY RR for Key Renewal message has the structure given below. In + principle, format and definition for each field follows [RFC2930]. + Note that each keying scheme sometimes needs different interpretation + of RDATA field; for detail, see section 2.5. + + + Field Type Comment + ------- ------ ------- + NAME domain used for a new key, see below + TYPE u_int16_t (defined in [RFC2930]) + CLASS u_int16_t (defined in [RFC2930]) + TTL u_int32_t (defined in [RFC2930]) + RDLEN u_int16_t (defined in [RFC2930]) + RDATA: + Algorithm: domain algorithm for a new key + Inception: u_int32_t about the keying material + Expiration: u_int32_t about the keying material + Mode: u_int16_t scheme for key agreement + see section 9. + Error: u_int16_t see description below + Key Size: u_int16_t see description below + Key Data: octet-stream + Other Size: u_int16_t (defined in [RFC2930]) + size of other data + Other Data: newly defined: see description below + + + + + + +Kamite, et. al. [Page 8] + +INTERNET-DRAFT Mar. 2003 + + + For "NAME" field, both non-root and root name are allowed. It may + be used for a new key's name in the same manner as [RFC2930] 2.1. + + "Algorithm" specifies which algorithm is used for agreed keying + material, which is used for identification of the next key. + + "Inception" and "Expiration" are used for the valid period of + keying material. The meanings differ somewhat according to whether + the message is request or answer, and its keying scheme. + + "Key Data" has different meanings according to keying schemes. + + "Mode" field stores the value in accordance with the keying method, + and see section 2.5. Servers and clients supporting TKEY Renewal + method MUST implement "Diffie-Hellman exchange for key renewal" + scheme. All other modes are OPTIONAL. + + "Error" is an extended RCODE which includes "PartialRevoke" value + too. See section 9. + + "Other Data" field has the structure given below. They describe + attributes of the key to be renewed. + + in Other Data filed: + + Field Type Comment + ------- ------ ------- + OldNAME domain name of the old key + OldAlgorithm domain algorithm of the old key + + + "OldName" indicates the name of the previous key (usually, + this is partially revoked key's name that client noticed by + PartialRevoke answer from server), and "OldAlogirthm" + indicates its algorithm. + + +2.4. Key Adoption + +2.4.1. Query for Key Adoption + + After receiving a TKEY Renewal answer, the client gets the same + secret as the server. Then, it sends a TKEY Adoption request. The + request's question section's QNAME field is the same as the NAME + filed of TKEY written below. In additional section, there is one TKEY + RR that has the structure and values described below. + + + + + +Kamite, et. al. [Page 9] + +INTERNET-DRAFT Mar. 2003 + + + "NAME" field is the new key's name to be adopted which was already + generated by Renewal message exchange. "Algorithm" is its algo- + rithm. "Inception" means the key's Inception Time, and "Expiration" + means Expiry Limit. + + "Mode" field is the value of "key adoption". See section 9. + + "Other Data" field in Adoption has the same structure as that of + Renewal request message. "OldName" means the previous old key, and + "OldAlogirthm" means its algorithm. + + Key Adoption request MUST be signed with TSIG or SIG(0) for + authentication. The client can sign TSIG with the previous key. Note + that until Adoption is finished, the new key is treated as invalid, + thus it cannot be used for authentication immediately. + + +2.4.2. Response for Key Adoption + + The server which has received Adoption request, it verifies TSIG or + SIG(0) accompanying it. If the TSIG is signed with the partially + revoked key and can be verified, the message MUST be authenticated. + + If the next new key indicated by the request TKEY's "NAME" is not + really present at the server, BADNAME [RFC2845] is given in Error + field and the error message is returned. + + If the next key really exists and it has not been adopted formally + yet, the server confirms the previous key's existence indicated by + the "OldName" and "OldAlgorithm" field. If it succeeds, the server + executes Adoption of the next key and Revocation of the previous key. + Response message duplicates the request's TKEY RR with NOERROR, + including "OldName" and "OldAlgorithm" that indicate the revoked key. + + If the next key exists but it is already adopted, the server returns + a response message regardless of the substance of the request TKEY's + "OldName". In this response, Response TKEY RR has the same data as + the request's one except as to its "Other Data" that is changed into + null (i.e., "Other Size" is zero), which is intended for telling the + client that the previous key name was ignored, and the new key is + already available. + + Client sometimes has to retry Adoption request. Suppose the client + sent request signed with the partially revoked key, but its response + did not return successfully (e.g., due to the drop of UDP packet). + Client will probably retry Adoption request; however, the request + will be refused in the form of TSIG "BADKEY" error because the + previous key was already revoked. In this case, client should + + + +Kamite, et. al. [Page 10] + +INTERNET-DRAFT Mar. 2003 + + + retransmit Adoption request signed with the next key, and expect a + response which has null "Other Data" for confirming the completion of + renewal. + + +2.5. Keying Schemes + + In Renewal message exchanges, there are no limitations as to which + keying method is actually used. The specification of keying + algorithms is independent of the general procedure of Renewal that is + described in section 2.3. + + Now this document specifies three algorithms in this section, but + other future documents can make extensions defining other methods. + + +2.5.1. DH Exchange for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.1. This + specification only describes the difference from it and special + notice; assume that all other points, such as keying material + computation, are the exactly same as the specification of [RFC2930] + 4.1. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + the client's Diffie-Hellman public key [RFC2539]. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "DH exchange for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is used as a random, following [RFC2930] 4.1. + + Response + The server which received this request first verifies the TSIG or + SIG(0). After authentication, the old key's existence validity is + checked, following section 2.3. If any incompatible DH key is + found in the request, "BADKEY" [RFC2845] is given in Error field + for response. "FORMERR" is given if the query included no DH KEY. + + If there are no errors, the server processes a response according + + + +Kamite, et. al. [Page 11] + +INTERNET-DRAFT Mar. 2003 + + + to Diffie-Hellman algorithm and returns the answer. In this + answer, there is one TKEY RR in answer section and KEY RR(s) in + additional section. + + As long as no error has occurred, all values of TKEY are equal to + that of the request message except TKEY NAME, TKEY RDLEN, RDATA's + Inception, Expiration, Key Size and Key Data. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client will have to use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" should be set to be the time when the new + key is actually generated or the time before it, and it will be + regarded as Inception Time. "Expiration" is determined by the + server, and it will be regarded as Expiry Limit. + + TKEY "Key Data" is used as an additional nonce, following + [RFC2930] 4.1. + + The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in + the additional section and a server Diffie-Hellman KEY RR will + also be present in the answer section, following [RFC2930] 4.1. + + +2.5.2. Server Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.4. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.4. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + used in encrypting the response. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "server assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is provided following the specification of + [RFC2930] 4.4. + + + +Kamite, et. al. [Page 12] + +INTERNET-DRAFT Mar. 2003 + + + Response + The server which received this request first verifies the TSIG or + SIG(0). Resolver KEY RR is also authenticated by means of + verifying that TSIG or SIG(0). After authentication, the old key's + existence validity is checked, following section 2.3. "FORMERR" is + given if the query specified no encryption key. + + If there are no errors, the server response contains one TKEY RR + in the answer section, and echoes the KEY RR provided in the query + in the additional information section. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client will have to use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" should be set to be the time when the new + key is actually generated or the time before it, and it will be + regarded as Inception Time. "Expiration" is determined by the + server, and it will be regarded as Expiry Limit. + + TKEY "Key Data" is the assigned keying data encrypted under the + public key in the resolver provided KEY RR, which is the same as + [RFC2930] 4.4. + + +2.5.3. Resolver Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.5. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.5. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. TKEY RR + has the encrypted keying material and KEY RR is the server public + key used to encrypt the data. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "resolver assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is the encrypted keying material. + + + +Kamite, et. al. [Page 13] + +INTERNET-DRAFT Mar. 2003 + + + Response + The server which received this request first verifies the TSIG or + SIG(0). After authentication, the old key's existence validity is + checked, following section 2.3. "FORMERR" is given if the server + does not have the corresponding private key for the KEY RR that + was shown in the request. + + If there are no errors, the server returns response. The response + must have a TKEY RR in the answer section to tell the shared key's + name and its usage time values. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client will have to use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" should be set to be the time when the new + key is actually generated or the time before it, and it will be + regarded as Inception Time. "Expiration" is determined by the + server, and it will be regarded as Expiry Limit. + + +2.6. Considerations about Non-compliant Hosts + + Key Renewal requests and responses must be exchanged between hosts + which can understand them and do proper processes. "PartialRevoke" + error messages will be only ignored if they should be returned to + non-compliant hosts. + + Note that server does not inform actively the necessity of renewal to + clients, but inform it as responses invoked by client's query. + Server needs not care whether the "PartialRevoke" errors has reached + client or not. If client has not received yet because of any reasons + such as packet drops, it will resend the queries, and finally will be + able to get "PartialRevoke" information. + + +3. Secret Storage + + Every server should keep all secrets and attached information, e.g., + Inception Time, Expiry Limit, etc. safely to be able to recover from + unexpected stop. To accomplish this, formally adopted keys should be + memorized not only on memory, but also be stored in the form of some + files. Make sure that this should be protected strongly not to be + read by others. If possible, they should be stored in encrypted form. + + + + + + + +Kamite, et. al. [Page 14] + +INTERNET-DRAFT Mar. 2003 + + +4. Compulsory Key Revocation by Server + + There is a rare but possible case that although servers have already + partially revoked keys, clients do not try to send any Renewal + requests. If this state continues, in the future it will become the + time of Expiry Limit. After Expiry Limit, the keys will be expired + and completely removed, so this is called Compulsory Key Revocation + by server. + + If Expiry Limit is too distant from the Partial Revocation Time, then + even though very long time passes, clients will be able to refresh + secrets only if they add TSIG signed with those old partially revoked + keys into requests, which is not safe. + + On the other hand, if Expiry Limit is too close to Partial Revocation + Time, perhaps clients might not be able to notice their keys' Partial + Revocation by getting "PartialRevoke" errors. + + Therefore, servers should set proper Expiry Limit to their keys, + considering both their keys' safety, and enough time for clients to + send requests and process renewal. + + +4.1. Example + + It might be ideal to provide both SIG(0) and TSIG as authentication + methods. For example: + + A client and a server start SIG(0) authentication at first, to + establish TSIG shared keys by means of "Query for Diffie-Hellman + Exchanged Keying" as described in [RFC2930] 4.1. Once they get + shared secret, they keep using TSIG for usual queries and + responses. After a while the server returns a "ParitalRevoke" error + and they begin a key renewal process. Both TSIG signed with + partially revoked keys and SIG(0) are okay for authentication, but + TSIG would be easier to use considering calculation efficiency. + + If any troubles should happen such as client host's long suspension + against expectation, the server will do Compulsory Revocation. + After recovery if the client sends a key Renewal request to refresh + the old key, it will fail because the key is removed from the + server. So, the client will send "Query for Diffie-Hellman + Exchanged Keying" with SIG(0) to make a new shared key again. + + + + + + + + +Kamite, et. al. [Page 15] + +INTERNET-DRAFT Mar. 2003 + + +5. Special Considerations for Two servers' Case + + This section refers to the case where both two hosts are DNS servers + which can act as full resolvers as well. If one server (called Server + A) comes to want to refresh a shared key (called "Key A-B"), it will + await a TKEY Renewal request from the other server (called Server B). + But perhaps Server A will have to send queries with TSIG immediately + to Server B to resolve some queries if it is asked by other clients. + + At this time, Server A is allowed to send a Renewal request to Server + B, if Server A finds the key to use now is too old and should be + renewed. To provide this function, both servers should be able to + receive and process key renewal request from each other if they agree + to refresh their shared secret keys. + + Note that the initiative in key renewal belongs to Server A because + it can notice the Partial Revocation Time and decide key renewal. If + Server B has information about Partial Revocation Time as well, it + can also decide for itself to send Renewal request to Server A. But + it is not essential for both two servers have information about key + renewal timing. + + +5.1. To Cope with Collisions of Renewal Requests + + At least one of two hosts which use Key Renewal must know their key + renewal information such as Partial Revocation Time. It is okay that + both hosts have it. + + Provided that both two servers know key renewal timing information, + there is possibility for them to begin partial revocation and sending + Renewal requests to each other at the same time. Such collisions will + not happen so often because Renewal requests are usually invoked when + hosts want to send queries, but it is possible. + + When one of two servers try to send Renewal requests, it must protect + old secrets that it has partially revoked and prevent it from being + refreshed by any requests from the other server (i.e., it must lock + the old secret during the process of renewal). While the server is + sending Renewal requests and waiting responses, it ignores the other + server's Renewal requests. + + Therefore, servers might fail to change secrets by means of their own + requests to others. After failure they will try to resend, but they + should wait for random delays by the next retries. If they get any + Renewal requests from others while they are waiting, their shared + keys may be refreshed, then they do not need to send any Renewal + requests now for themselves. + + + +Kamite, et. al. [Page 16] + +INTERNET-DRAFT Mar. 2003 + + +6. Key Name Considerations + + Since both servers and clients have only to distinguish new secrets + and old ones, keys' names do not need to be specified strictly. But + it is recommended that some serial number or key generation time + should be added to the name and that the names of keys between the + same pair of hosts should have some common labels among their keys. + For example, suppose A.example.com. and B.example.com. share the key + ".A.example.com.B.example.com." such as + "10010.A.example.com.B.example.com.". After key renewal, they change + their secret and name into "10011.A.example.com.B.example.com." If + secret overwrite occurs as a result of client's retransmission, + server must change the next key's name somehow; for example, server + increases serial number forcibly, or add some random numbers to the + name. + + Servers and clients must be able to use keys properly according to + servers to query. Because TSIG secret keys themselves do not have any + particular IDs to be distinguished and would be identified by their + names and algorithm, it must be understood correctly what keys are + refreshed. + + +7. Example Usage of Secret Key Renewal Mode + + This is an example of Renewal mode usage where a Server, + server.example.com, and a Client, client.exmple.com have an initial + shared secret key named "00.client.example.com.server.example.com". + + (1) The time values about key + "00.client.example.com.server.example.com" was set as follows: + Inception Time is at 6:00, Expiry Limit is at 11:00. + + (2) At Server, a time value about renewal timing has been set too: + Partial Revocation Time is at 8:00. + + (3) Suppose the present time is 7:00. If Client sends a query + signed with key "00.client.example.com.server.example.com" to ask + the IP address of "www.somedomain.com", finally it will get a + proper answer from Server with valid TSIG (NOERROR). + + (4) At 9:00. Client sends a query signed with key + "00.client.example.com.server.example.com" to ask the IP address of + "www.otherdomain.com". But it will not get a proper answer from + Server. The response does not have any IP address information about + "www.otherdomain.com". Instead, it includes valid TSIG MAC signed + with "00.client.example.com.server.example.com", and its Error Code + indicates PartialRevoke. + + + +Kamite, et. al. [Page 17] + +INTERNET-DRAFT Mar. 2003 + + + (5) At 9:01. Client sends a Renewal request to Server. This request + is signed with key "00.client.example.com.server.example.com". It + includes data such as: + + Question Section: + QNAME = 01.client.example.com. (Client can set this freely) + TYPE = TKEY + + Additional Section: + 01.client.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value which means 8:55) + Expiration = (value which means 14:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a KEY RR for DH and a TSIG RR. + + (6) As soon as Server receives this request, it verifies TSIG. It + is signed with the partially revoked key + "00.client.example.com.server.example.com". and Server accepts the + request. It creates a new key by Diffie-Hellman calculation and + returns an answer which includes data such as: + + Answer Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 8:55) + Expiration = (value meaning 14:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + Answer Section also contains KEY RRs for DH. + + Additional Section also contains a TSIG RR. + This response is signed with key + "00.client.example.com.server.example.com" without error. + + At the same time, Server decides to set the Partial Revocation Time + of this new key "01.client.example.com.server.example.com." as + 11:00. + + (7) Client gets the response and checks TSIG MAC, and calculates + Diffie-Hellman. It will get a new key, and it has been named + "01.client.example.com.server.example.com" by Server. + + + + + +Kamite, et. al. [Page 18] + +INTERNET-DRAFT Mar. 2003 + + + (8) At 9:02. Client sends an Adoption request to Server. This + request is signed with the previous key + "00.client.example.com.server.example.com". It includes: + + Question Section: + QNAME = 01.client.example.com.server.example.com. + TYPE = TKEY + + Additional Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value which means 8:55) + Expiration = (value which means 14:00) + Mode = (key adoption) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a TSIG RR. + + (9) Server verifies the query's TSIG. It is signed with the + previous key and authenticated. It returns a response whose TKEY RR + is the same as the request's one. The response is signed with key + "00.client.example.com.server.example.com.". As soon as the + response is sent, Server revokes and removes the previous key. At + the same time, key "01.client.example.com.server.example.com." is + validated. + + (10) Client acknowledges the success of Adoption by receiving the + response. Then, it will retry to send an original question about + "www.otherdomain.com". It is signed with the adopted key + "01.client.example.com.server.example.com", so Server authenticates + it and returns an answer. + + (11) This key is used until 11:00. After that, it will be partially + revoked again. + + +8. Security Considerations + + This document considers about how to refresh shared secret. Secret + changed by this method is used at servers in support of TSIG + [RFC2845]. + + [RFC2104] says that current attacks to HMAC do not indicate a + specific recommended frequency for key changes but periodic key + refreshment is a fundamental security practice that helps against + potential weaknesses of the function and keys, and limits the damage + of an exposed key. TKEY Secret Key Renewal provides the method of + + + +Kamite, et. al. [Page 19] + +INTERNET-DRAFT Mar. 2003 + + + periodical key refreshment. + + TKEY Secret Key Renewal forbids clients to send queries as long as + they do not change old keys. This means that when keys become old, + clients must spend rather lots of time to get answers they wanted + originally because at first they must send key Renewal requests. Thus + the usage period of secrets should be considered carefully based on + both TKEY processing performance and security. + + This document specifies the procedure of periodical key renewal, but + actually there is possibility for servers to have no choice other + than revoking their secret keys immediately especially when the keys + are found to be compromised by attackers. This is called "Emergency + Compulsory Revocation". For example, suppose the original Expiry + Limit was set at 15:00, Partial Revocation Time at 12:00 and + Inception Time at 10:00. if at 11:00 the key is found to be + compromised, the server sets Expiry Limit forcibly to be 11:00 or + before it. + + Consequently, once Compulsory Revocation (See section 4.) is carried + out, normal renewal process described in this document cannot be done + any more as far as the key is concerned. But, after such accidents + happened, the two hosts are able to establish secret keys and begin + renewal procedure only if they have other (non-compromised) shared + TSIG keys or safe SIG(0) keys for the authentication of initial + secret establishment such as Diffie-Hellman Exchanged Keying. + + +9. IANA Considerations + + IANA needs to allocate a value for "DH exchange for key renewal", + "server assignment for key renewal", "resolver assignment for key + renewal" and "key adoption" in the mode filed of TKEY. It also needs + to allocate a value for "PartialRevoke" from the extended RCODE + space. + + +10. References + +[RFC2104] + H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message + Authentication", RFC2104, February 1997. + +[RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + + + + +Kamite, et. al. [Page 20] + +INTERNET-DRAFT Mar. 2003 + + +[RFC2539] + D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", RFC 2539, March 1999. + +[RFC2845] + Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, + May 2000. + +[RFC2930] + D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', + RFC 2930, September 2000. + +[RFC2931] + D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s + )", RFC 2931, September 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. [Page 21] + +INTERNET-DRAFT Mar. 2003 + + +Authors' Addresses + + Yuji Kamite + NTT Communications Corporation + Innovative IP Architecture Center, + Tokyo Opera City Tower 21F, + 20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku, + Tokyo, 163-1421, Japan. + EMail: y.kamite@ntt.com + + + Masaya Nakayama + The University of Tokyo + Information Technology Center, + 2-11-16 Yayoi, Bunkyo-ku, + Tokyo, 113-8658, Japan. + EMail: nakayama@nc.u-tokyo.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. [Page 22] + diff --git a/doc/draft/draft-ietf-dnsext-unknown-rrs-05.txt b/doc/draft/draft-ietf-dnsext-unknown-rrs-05.txt new file mode 100644 index 0000000000..54412bb008 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-unknown-rrs-05.txt @@ -0,0 +1,447 @@ + +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsext-unknown-rrs-05.txt Nominum Inc. + March 2003 + +Updates: RFC 1034, RFC 2163, RFC 2535 + + + + Handling of Unknown DNS Resource Record Types + + +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. + +Abstract + + Extending the Domain Name System with new Resource Record (RR) types + currently requires changes to name server software. This document + specifies the changes necessary to allow future DNS implementations + to handle new RR types transparently. + +1. Introduction + + The DNS is designed to be extensible to support new services through + the introduction of new resource record (RR) types. In practice, + deploying a new RR type currently requires changes to the name server + software not only at the authoritative DNS server that is providing + the new information and the client making use of it, but also at all + slave servers for the zone containing it, and in some cases also at + caching name servers and forwarders used by the client. + + + +Expires September 2003 [Page 1] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + Because the deployment of new server software is slow and expensive, + the potential of the DNS in supporting new services has never been + fully realized. This memo proposes changes to name servers and to + procedures for defining new RR types aimed at simplifying the future + deployment of new RR types. + + 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]. + +2. Definition + + An "RR of unknown type" is an RR whose RDATA format is not known to + the DNS implementation at hand, such that it cannot be converted to a + type-specific text format, compressed, or otherwise handled in a + type-specific way, and whose type is not an assigned QTYPE or Meta- + TYPE in RFC2929 section 3.1 nor within the range reserved in that + section for assignment only to QTYPEs and Meta-TYPEs. + + In the case of a type whose RDATA format is class specific, an RR is + considered to be of unknown type when the RDATA format for that + combination of type and class is not known. + +3. Transparency + + To enable new RR types to be deployed without server changes, name + servers and resolvers MUST handle RRs of unknown type transparently. + That is, they must treat the RDATA section of such RRs as + unstructured binary data, storing and transmitting it without change + [RFC1123]. + + To ensure the correct operation of equality comparison (section 6) + and of the DNSSEC canonical form (section 7) when an RR type is known + to some but not all of the servers involved, servers MUST also + exactly preserve the RDATA of RRs of known type, except for changes + due to compression or decompression where allowed by section 4 of + this memo. In particular, the character case of domain names that + are not subject to compression MUST be preserved. + +4. Domain Name Compression + + RRs containing compression pointers in the RDATA part cannot be + treated transparently, as the compression pointers are only + meaningful within the context of a DNS message. Transparently + copying the RDATA into a new DNS message would cause the compression + pointers to point at the corresponding location in the new message, + which now contains unrelated data. This would cause the compressed + name to be corrupted. + + + +Expires September 2003 [Page 2] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + To avoid such corruption, servers MUST NOT compress domain names + embedded in the RDATA of types that are class-specific or not well- + known. This requirement was stated in RFC1123 without defining the + term "well-known"; it is hereby specified that only the RR types + defined in RFC1035 are to be considered "well-known". + + The specifications of a few existing RR types have explicitly allowed + compression contrary to this specification: RFC2163 specified that + compression applies to the PX RR, and RFC2535 allowed compression in + SIG RRs and NXT RRs records. Since this specification disallows + compression in these cases, it is an update to RFC2163 (section 4) + and RFC2535 (sections 4.1.7 and 5.2). + + Receiving servers MUST decompress domain names in RRs of well-known + type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, + NXT, NAPTR, and SRV (although the current specification of the SRV RR + in RFC2782 prohibits compression, RFC2052 mandated it, and some + servers following that earlier specification are still in use). + + Future specifications for new RR types that contain domain names + within their RDATA MUST NOT allow the use of name compression for + those names, and SHOULD explicitly state that the embedded domain + names MUST NOT be compressed. + + As noted in RFC1123, the owner name of an RR is always eligible for + compression. + +5. Text Representation + + In the "type" field of a master file line, an unknown RR type is + represented by the word "TYPE" immediately followed by the decimal RR + type number, with no intervening whitespace. In the "class" field, + an unknown class is similarly represented as the word "CLASS" + immediately followed by the decimal class number. + + This convention allows types and classes to be distinguished from + each other and from TTL values, allowing the "[] [] + " and "[] [] " forms of + RFC1035 to both be unambiguously parsed. + + The RDATA section of an RR of unknown type is represented as a + sequence of white space separated words as follows: + + The special token \# (a backslash immediately + followed by a hash sign), which identifies the + RDATA as having the generic encoding defined + herein rather than a traditional type-specific + encoding. + + + +Expires September 2003 [Page 3] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + An unsigned decimal integer specifying the + RDATA length in octets. + + Zero or more words of hexadecimal data encoding + the actual RDATA field, each containing an even + number of hexadecimal digits. + + If the RDATA is of zero length, the text representation contains only + the \# token and the single zero representing the length. + + An implementation MAY also choose to represent some RRs of known type + using the above generic representations for the type, class and/or + RDATA, which carries the benefit of making the resulting master file + portable to servers where these types are unknown. Using the generic + representation for the RDATA of an RR of known type can also be + useful in the case of an RR type where the text format varies + depending on a version, protocol, or similar field (or several) + embedded in the RDATA when such a field has a value for which no text + format is known, e.g., a LOC RR [RFC1876] with a VERSION other than + 0. + + Even though an RR of known type represented in the \# format is + effectively treated as an unknown type for the purpose of parsing the + RDATA text representation, all further processing by the server MUST + treat it as a known type and take into account any applicable type- + specific rules regarding compression, canonicalization, etc. + + The following are examples of RRs represented in this manner, + illustrating various combinations of generic and type-specific + encodings for the different fields of the master file format: + + a.example. CLASS32 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + b.example. HS TYPE62347 \# 0 + e.example. IN A \# 4 0A000001 + e.example. CLASS1 TYPE1 10.0.0.2 + +6. Equality Comparison + + Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs + to be compared for equality. Two RRs of the same unknown type are + considered equal when their RDATA is bitwise equal. To ensure that + the outcome of the comparison is identical whether the RR is known to + the server or not, specifications for new RR types MUST NOT specify + type-specific comparison rules. + + This implies that embedded domain names, being included in the + overall bitwise comparison, are compared in a case-sensitive manner. + + + +Expires September 2003 [Page 4] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + As a result, when a new RR type contains one or more embedded domain + names, it is possible to have multiple RRs owned by the same name + that differ only in the character case of the embedded domain + name(s). This is similar to the existing possibility of multiple TXT + records differing only in character case, and not expected to cause + any problems in practice. + +7. DNSSEC Canonical Form and Ordering + + DNSSEC defines a canonical form and ordering for RRs [RFC2535, + section 8.1]. In that canonical form, domain names embedded in the + RDATA are converted to lower case. + + The downcasing is necessary to ensure the correctness of DNSSEC + signatures when case distinctions in domain names are lost due to + compression, but since it requires knowledge of the presence and + position of embedded domain names, it cannot be applied to unknown + types. + + To ensure continued consistency of the canonical form of RR types + where compression is allowed, and for continued interoperability with + existing implementations that already implement the RFC2535 canonical + form and apply it to their known RR types, the canonical form remains + unchanged for all RR types whose whose initial publication as an RFC + was prior to the initial publication of this specification as an RFC + (RFC TBD). + + As a courtesy to implementors, it is hereby noted that the complete + set of such previously published RR types that contain embedded + domain names, and whose DNSSEC canonical form therefore involves + downcasing according to the DNS rules for character comparisons, + consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, + DNAME, and A6. + + This document specifies that for all other RR types (whether treated + as unknown types or treated as known types according to an RR type + definition RFC more recent than than RFC TBD), the canonical form is + such that no downcasing of embedded domain names takes place, and + otherwise identical to the canonical form specified in RFC2535 + section 8.1. + + Note that the owner name is always set to lower case according to the + DNS rules for character comparisons, regardless of the RR type. + + The DNSSEC canonical RR ordering is as specified in RFC2535 section + 8.3, where the octet sequence is the canonical form as revised by + this specification. + + + +Expires September 2003 [Page 5] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + +8. Additional Section Processing + + Unknown RR types cause no additional section processing. Future RR + type specifications MAY specify type-specific additional section + processing rules, but any such processing MUST be optional as it can + only be performed by servers for which the RR type in case is known. + +9. IANA Considerations + + The IANA is hereby requested to verify that specifications for new RR + types requesting an RR type number comply with this specification. + In particular, the IANA MUST NOT assign numbers to new RR types whose + specification allows embedded domain names to be compressed. + +10. Security Considerations + + This specification is not believed to cause any new security + problems, nor to solve any existing ones. + +Normative References + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC1123] - Requirements for Internet Hosts -- Application and + Support, R. Braden, Editor, October 1989. + + [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, + S. Bradner, BCP 14, March 1997. + + [RFC2535] - Domain Name System Security Extensions. D. Eastlake, + March 1999. + + [RFC2613] - Using the Internet DNS to Distribute MIXER Conformant + Global Address Mapping (MCGAM), C. Allocchio, January 1998. + + [RFC2929] - Domain Name System (DNS) IANA Considerations, D. + Eastlake, E. Brunner-Williams, B. Manning, September 2000. + +Non-normative References + + [RFC1876] - A Means for Expressing Location Information in the Domain + Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January + 1996. + + + + +Expires September 2003 [Page 6] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + [RFC2052] - A DNS RR for specifying the location of services (DNS + SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782. + + [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE), + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997. + + [RFC2782] - A DNS RR for specifying the location of services (DNS + SRV), A. Gulbrandsen, P. Vixie, L. Esibov, February 2000. + +Author's Address + + Andreas Gustafsson + Nominum Inc. + 2385 Bay Rd + Redwood City, CA 94063 + USA + + Phone: +1 650 381 6004 + + Email: gson@nominum.com + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001 - 2002). 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 + or assist in its implmentation 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + + + +Expires September 2003 [Page 7] + +draft-ietf-dnsext-unknown-rrs-05.txt March 2003 + + + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to pertain + to the implementation or use of the technology described in this + document or the extent to which any license under such rights might or + might not be available; 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires September 2003 [Page 8] + + diff --git a/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt b/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt new file mode 100644 index 0000000000..eaa6b8d9c9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-interim-signed-root-01.txt @@ -0,0 +1,769 @@ + + +Internet Draft Johan Ihr‰n +draft-ietf-dnsop-interim-signed-root-01.txt Autonomica +February 2003 +Expires in six months + + + An Interim Scheme for Signing the Public DNS Root + + +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. + + +Abstract + + This memo documents a proposed mechanism for a first stage of a + transition from an unsigned DNS root to a signed root, such that + the data in the root zone is accompanied by DNSSEC signatures to + allow validation. + + The underlying reason for signing the root zone is to be able to + provide a more secure DNS hierarchy, where it is possible to + distinguish false answers from correct answers. + + For the special case of the DNS root zone, an interim scheme is + proposed. This scheme is mostly aimed at securing the root zone + itself for technical and operational reasons, and to give + operational experience of DNSSEC. + + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC 2119. + + The term "zone" refers to the unit of administrative control in the + Domain Name System. "Name server" denotes a DNS name server that is + authoritative (i.e. knows all there is to know) for a DNS zone, + typically the root zone. A "resolver", finally, is a DNS "client", + i.e. an entity that sends DNS queries to authoritative nameservers + and interpret the results. + + +2. Motivation for signing the DNS root + + In the special case of the root zone there are very strong reasons + to take a slow and conservative approach to any changes with + operational impact. Signing the root is such a change. + + DNSSEC[RFC2535, RFC3090] has been in development for a number of + years now and still has not reached the point where the last flag + day is behind us. + + However, during the years of DNSSEC development and refinement + [RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure, + Opt-in, Wild-card-optimize], the Internet has matured and more and + more businesses and other organizations have become dependent on + the stability and constant availability of the Internet. + + It is therefore prudent to do everything in our power to ensure + that the DNS infrastructure works as well as possible and, when + appropriate and possible, adding enhancements and functionality. + + The time is now right for yet another step of improvement by + signing the root zone. By doing that any Internet user that so + wishes will obtain the ability of verifying responses received from + the root nameservers. + + Since this is new operational ground the objective is not maximum + security but rather an "Internet-wide" controlled experiment with a + signed root zone, where the trade off is that we utilize the fact + that there are operators in place that can help even though they + are not sufficiently staffed to do off-line signing in a 24x7 + mode. For this reason it is fully possible to even do automatic + signing, since the purpose is to ensure that DNSSEC works + operationally with a signed root zone and gain experience from the + exercise. + + It should be pointed out, however, that the experimental part is + only the added DNSSEC records. The traditional records in the root + zone remain unchanged and the new records will only be visible to + DNSSEC-aware resolvers that explicitly ask to see these new + records. + + +2.1. Motivation for signing the root zone now + + The reason DNSSEC is not yet widely deployable is that the problem + of key management remains unsolved, especially where communication + between the zone administrators for a parent zone and child zone is + required. + + However, during the past year a solution to this problem has been + found (in the form of a new record type, DS aka Delegation Signer) + [DS], discussed, implemented and tested. Therefore, it is finally + reasonable to consider DNSSEC deployment to be a real possibility + within the next 12 months. + + In the case of the root zone the particular importance of managing + the transition with zero operational mistakes is a strong reason to + separate the signing of the zone itself, with the associated key + management issues, from the future management of signed delegations + (of top level domains). + + Although support for Delegation Signer has been implemented and + tested it is not yet generally available except experimentally. For + this reason signed delegations for productions zones will have to + wait a bit longer. Furthermore, it will take some time to ensure + that the entire RSS aka Root Server System is capable of supporting + the protocol changes that accompany the new support for Delegation + Signer. + + By signing now it will be possible to work through the operational + issues with signing the zone itself without at the same time having + to manage the additional complexity of signed delegations. Also, by + explicitly not supporting any signed delegations, it is also + possible to recover in a graceful way should new operational + problems turn up. + + Because of these operational and technical issues there is a + "window of opportunity" to sign the root zone before the status of + implementation of "full DNSSEC", including Delegation Signer + support, change to "generally available", thereby increasing the + pressure for signed delegations from the root zone. + + +3. Trust in DNSSEC Keys + + In the end the trust that a validating resolver will be able to put + in a key that it cannot validate within DNSSEC will have to be a + function of + + * trust in the key issuer + + * trust in the distribution method + + * trust in extra, out-of-band verification + + For any security apex, i.e. a node in the DNS hierarchy that issues + out-of-band "trusted keys", it is of critical importance that this + function produces a positive result (i.e. the resolver gains + sufficient confidence in the keys to decide to trust them). The + particular case of the root zone is no different, although possibly + it is more crucial than many other security apexes. + + To ensure that the resulting trust is maximized it is necessary to + work with all the parameters that are available. In the case of the + key issuer there is the possibility of chosing a key issuer that + has a large "trust base" (i.e. is already trusted by a large + fraction of the resolver population). However, it is also possible + to expand the aggregated trust base by using multiple simultaneous + key issuers, as described in [Threshold-Validation]. + + Furthermore, with multiple trusted keys it will be possible for a + validating resolver to optimize for the "right compromise" between + + * maximum security (as expressed by all available signatures by all + available keys verifying correctly + + * maximum redundancy (as in the DNS lookup being validated if there + is any signature by any trusted key available) + + Without multiple, independent trusted keys the rollover operation + will always be a dangerous operation where it is likely that some + fraction of the resolver population lose their ability to verify + lookups (and hence start to fail hard). I.e. the validating + resolver will be forced to adopt the "maximum security" policy, + since there is no alternative. + + With multiple, independent trusted keys, however, it is possible to + design for improved redundancy by trusting lookups that are only + validated against a subset of the available keys. This will make + rollovers much less risky to the extent that it will be possible to + "survive" even emergency rollovers without any immediate + configuration chagnes in the validating resolver. + + +4. Interim signing of the root zone + + At present all the authoritative servers for the root zone pull the + zone from a primary master. I.e. any changes at the primary master + will propagate via NOTIFY[RFC1996] and subsequent + AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers. + + Between the primary master and the slaves transactions are signed + with TSIG[RFC2845] signatures. This mechanism is already in place, + and there is operational experience with periodic key rollover of + the TSIG keys. + + +4.1. Design philosophy + + By introducing a signing step into the distribution of the zone + file complexity is increased. To avoid introducing new single + points of failure it is therefore important to ensure that any + added or changed steps are as redundant as possible. + + The assumption is that the operators of the root servers are + trusted and that consistency of the zone among the root servers is + a crucial property that MUST be preserved in emergencies. + + To ensure that consistency is maintained new single points of + failure SHOULD NOT be introduced by the signing step. Therefore a + structure where several parties have the ability to sign the zone + is proposed. Furthermore, such a design helps avoid any individual + party becoming a de facto single zone signing authority. + + +4.2. Proposed new management structure for the root zone + + Taking into account the already existing infrastructure for + management of TSIG keys and rollover of these keys the following + structure is proposed: + + * Day-to-day signing of the root zone is performed by a subgroup of + the root server operators referred to as "signing operators". For + this task individual, per-operator, Zone Signing Keys, ZSKs, are + used. + + * The set of Zone Signing Keys are signed by several Key Signing + Keys, KSKs, at any particular time. The public part of KSKs in + use have to be statically configured as "trusted keys" in all + resolvers that want to be able to perform validation of + responses. + + * Key rollover, the operation when an old KSK is exchanged for a + new KSK, is managed with minimal overlap and on a frequent basis + of no less than three times per year per KSK. The rollover + schedule is chosen to be frequent enough to not make long-term + trust possible while being low enough to not become operationally + infeasible. + + +4.2.1. Management and distribution of the zone file + + The present, unsigned zone is published by the official slaves, the + "root nameservers", transferring the zone securely from a primary + master and subsequently using the data to respond to queries. This + mechanism is changed into: + + * The unsigned root zone is transferred securely from the primary + master to a set of "signing primaries" managed by the operators + participating in signing the zone. This is done via the + traditional mechanisms NOTIFY + AXFR/IXFR + TSIG. + + * The root nameservers change their configuration so that they + replace the present, single, primary master as the source of the + zone with a set of multiple possible "signing primaries" as + masters that provide the signed zone. + + * When a new, unsigned zone, is published by the primary master it + will automatically be transferred to the pre-signing servers. The + responsible operator will then sign the new zone and publish it + from his signing primary. Since the serial number is higher than + what the official root nameservers presently have the official + root nameservers will all transfer the zone from this source + (because of the redundant configuration with multiple possible + masters for the signed zone). + + * The operators that participate in signing rotate the signing + responsibility among themselves. Should the responsible operator + be unable to do this for any reason then any of the others are + able to do the signing instead. Traceability is maintained since + the zone signing keys are individual. + + * To avoid having several "backup signing operators" possibly sign + at exactly the same time backups are allocated "time windows" + within which they are allowed to publish a signed zone. + + With N signers, each signer is assigned a unique number R in + [1..N]. + + T = 2*k*((S-R) mod N) + + T is time to wait in seconds, S current serial number. The length + of the window is k, thereby separating each signing window with + an interval where signing is not allowed. + + The constant k is used to create sufficient separation of the + signers with respect to time used to sign and time needed to + distribute the zone. A reasonable value for k would be in the + order of 1800 seconds. + + * Because the digital signatures in the signed root zone MUST NOT + expire it is necessary to ensure that the unsigned zone does + change sufficiently often to cause new signing to occur within + the validity period of the old signatures. This is most easily + accomplished by a dummy update that only increments the serial + number in the SOA record. + + This new requirement will not cause any operational problems, + since in fact the root zone is maintained this way since several + years back. + + +4.2.2. Management of the Key Signing Keys + + Key Signing Keys, KSKs, are periodically issued by a several "Key + Signing Key Holders", KSK holders, individually. These KSKs consist + of a private part that should always be kept secret and a public + part that should be published as widely as possible since it will + be used as a "trusted key" in resolver configurations. + + The public part of each KSK should be included in the keyset for + "." as described in [Threshold-Validation]. I.e. the keyset will be + the union of the public parts of all KSKs and all ZSKs, Zone + Signing Keys. + + * Each KSK holder should generate a sequence of KSKs where the + public parts will be used to include in the keyset for "." and + the private parts will be used for signing the keyset. + + * Each KSK holder should, on request from the signing operators, + send in the public part of the KSK. The union of the public parts + of KSKs and the corresponding public parts of ZSKs, as collected + by the signing operators, constitute a "keyset". + + * Each KSK holder should, on request from the signing operators, + sign the complete keyset with the private part of the associated + KSK and send in the resulting signature to the signing operators + for inclusion in the signed zone. + + +4.2.3. Management of the Zone Signing Keys and the keyset signatures + + A subgroup of the root operators that choose to participate in + signing the zone each hold an individual "Zone Signing Key", + ZSK. The subgroup of operators may include all operators, but that + is not necessary as long as a sufficient number to achieve + redundancy in "signing ability" participates. + + * The complete keyset (i.e. all the public parts of KSKs and ZSKs) + should be signed by each KSK holder individually, generating a + new signature for the keyset which is sent back to the signing + operators via an out-of-band mechanism. + + * The signing operators should verify each received signature + against the corresponding key in the keyset and, unless invalid, + accept the signature into the set of signatures associated with + this keyset as described in [Threshold-Validation]. + + * The signing operators should include one of the keysets together + with all the KSK signatures in the zone file according to an + agreed upon rotation schedule. + + +4.2.4. Management of key rollover + + The Key Signing Keys should, for this interim scheme, be relatively + short-lived and rolled over frequently. The direct intent is that + it should not be possible to put long term trust in the keys. + Therefore, by design, every resolver that chooses to configure + these as "trusted keys" (to be able to validate lookups) will have + to change the configuration periodically. + + This is, after all, only an interim method of root zone signing. + + * Key rollover is executed by changing from one signed keyset to + another. I.e. from a keyset signed by one set of KSKs to a keyset + signed by a partially different set of KSKs. By not rolling all + the KSKs at the same time redundancy is improved. + + * Technically the signing operators are able to initiate key + rollover, although except for the case of a suspected key + compromise (with subsequent immediate key rollover) this ability + should only be used according to an established schedule. + + * New Key Signing Keys will be published as widely as possible, + however exactly how and where to publish the keys is by itself an + area where it is necessary to acquire more experience. Especially + for the case of individual hosts and other devices this will be a + significant issue to deal with. + + * Since the keys expire within a few months the aim is to make it + as difficult as possible to configure an interim key and then + forget about it long enough to still trust an interim key when a + long term design for signing the root zone emerges. + + +4.2.5. The role of the KSK holder + + With multiple KSKs it is possible to have multiple individual KSK + holders. Each will perform the role of authenticating the identity + of the signing operators, through the act of signing the keyset + that includes the operator Zone Signing Keys. + + The chain of authority that defines editorial control over the zone + contents is entirely separate from this and is in no way affected. + + I.e. the KSK holder is only asserting identity of the holders of + ZSKs and does not in any way take part in issues regarding zone + contents. In this respect the role of a KSK holder is much like + that of a public notary or a Certificate Authority. + + The primary function that the KSK holder is performing is adding + trust to the authenticity of the Zone Signing Keys and this trust + has to be propagated down to validating resolvers. Therefore an + obvious key characteristic of a KSK holder is that it should + already be trusted by as large a fraction of the "resolver + population" as possible. In this document that fraction is referred + to as the "trust base" of a KSK holder. + + The key characteristics of a KSK holder will be entities that + + * already are trusted by some part of the "resolver population", + i.e. have a "trust base" + + * are multiple entities that complement each other (so that the + aggregated "trust base" grows) + + * are willing to help work on methods for distributing their + trusted keys to the resolvers (hard problem) + + The requirement on the individual KSK holders is that they must be + able to + + * establish a secure out-of-band communication path in + collaboration with the signing operators which will be used for + authenticated exchange of the unsigned keyset and generated + signatures + + * periodically generate strong keys using a good random number + generator + + * manage their keys (i.e. use them for signing the operator keyset + and keeping the private key appropriately secret) + + +4.2.5.6. Suggestions for KSK holders + + Regional Internet Registries, RIRs, are suggested to be one + suitable choice of KSK holders. However, since every KSK holder + will act on its own there is no requirement that all RIRs + participate, although more than one would be good. Other suitable + KSK holders may exist and as long as the requirements are met more + would be better within the packe size limitations that are + discussed in [Threshold-Validation]. + + The basis of the suggestion of RIRs is + + * their neutrality + + * their proven record of service to the Internet community + + * that they don't have the domain name system as their primary + field of activity + + * their geographical diversity + + * the fact that they are, by definition, not a single entity, but + rather a collective of organizations. + + +5. Risk Analysis + + A change in the management of the root zone is always a risk. But + that is all the more reason to do it carefully and after due + consideration, rather than as a result of an immediate and urgent + need. The gains of a signed root zone have to be judged against the + added complexity of the signing step. + + However, added complexity, in one form or another, is basically + unavoidable. It is possible to argue for or against implementation + details, but in the end the benefits of a signed root will have to + be compared against some amount of added complexity. If the cost or + risk of this complexity is deemed to be too high, then it is not + possible to sign the DNS root zone. If that is the conclusion; then + it is obviously important to reach it as soon as possible. + + The same is true for the need for operational experience with a + signed root zone. There is no method of acquiring this experience + except by signing the root zone, so that is what is being proposed. + + Some identified scenarios: + + +5.1. What will the consequences of a signed root zone be for old + resolver software? + + Nameservers that are authoritative for signed zones only give out + these signatures when explicitly asked for them. Therefore, the + presence of signatures in the root zone will not have any impact at + all on the majority of resolvers on the Internet that does not + validate lookups. + + +5.2. What happens if a signing operator fails to sign the zone on + time? + + Literally nothing. I.e. the root zone that is published will be the + version prior to the last change. This is not believed to be a + major problem, since all changes to the data in the root zone are + characterized by long overlaps in time. Furthermore every change is + preceded by an administrative process that takes several days or + even weeks. Because of this, a failure to install a new version of + the root zone for even so long as a day will not noticeably change + the turn-around time for changes in the root zone. + + +5.3. What happens if several signing operators by mistake sign the + same version? + + Literally nothing. One signing operator will be first, according to + the mechanism designed to separate the different backup signing + operators described in 3.3.1. The signed zone published by this + operator will be the version of the signed root zone that all the + root nameservers pick up. + + When the second signing operator signs the zone the serial number + in the zone will be unchanged, and therefore the root nameservers + will not pick this zone up but instead stay with the first version. + + +5.4. What happens if the unsigned zone is compromised between the + primary master and the signing primaries? + + This is basically the same threat as the zone being compromised + between the primary master and the root servers in the traditional + unsigned case. To guard against this possibility every zone + transfer is already protected by a TSIG signature. + + Because of this the root zone file cannot get transferred to the + signing primaries unless the transaction signature matches, thereby + proving that the zone contents are uncompromised. The consequence + is that if the zone transfers are somehow compromised in transit, + they will not get signed and therefore the published root zone will + remain the signed version of the last uncompromised transfer. + + +5.5. What are the security implications for the new "signing + primaries"? Will they not have to be as secure as the primary + master is now? + + Yes. However, the entire root server system is based upon trust, + i.e. the entire Internet is trusting the present root server system + because there is no alternative to doing that. This proposal is not + about changing the need for trust in the root server system. It is + about providing a method of determining authenticity of data, + something that is presently missing. + + The root operators are already trusted to provide a root server + system based upon secure servers lacking validation mechanisms. It + is therefore a bit difficult to argue for not trusting them to + provide an improved system that adds exactly the lacking validation + mechanisms on a basis of not trusting them to secure the servers + involved. In both cases trust is involved, the difference is that + in the latter case validation is possible. + + Furthermore, the proposed signing primaries will not need to have + publicly known addresses (just as the present primary master is not + publicly known), nor will they need to be able to communicate with + anyone outside the well defined set of servers that are part of the + root server system. Because of this it will be significantly easier + to secure the signing primaries than the already present task of + securing the DNS root nameservers. + + +5.6. What happens if a Zone Signing Key is compromised? + + If this happens it is necessary to do an emergency rollover of the + keyset that includes the compromised key. I.e. the old keyset (and + its signatures) is replaced by a new keyset containing new ZSKs but + the same, uncompromised, KSKs and its signatures. Then the root + zone is re-signed using one of the new Zone Signing Keys. + + This problem is not unique to a signed root zone, it is inherent in + any activity involving cryptographic keys. + + Also note that there will be no need to change any configuration in + the resolver end. The rollover is an entirely atomic operation + inside the management structure of the root zone. + + +5.7. What happens if a Key Signing Key is compromised? + + Depending on the trust model used by individual validating + resolvers one of two things will happen. + + Resolvers that through local policy have chosen to trust this KSK + alone will need to change their configuration to instead trust + other KSKs, either available from other KSK holders or a new + trusted key made available by the same KSK holder that held the + compromised key. + + Resolvers that have chosen to require multiple signatures by KSKs + for the root zone will not have to do any emergency key rollover at + all, since validation of lookups will still work, based upon the + integrity of the other trusted keys that have not been compromised. + + In the management end it is necessary to do an emergency rollover + of the keyset including the compromised key and the suggested + method is by switching to a keyset that only changes the + compromised KSK and the ZSKs and keeps all other KSKs. Such keysets + should be prepared and signed in advance. + + The new signed keyset is added to the root zone and then the zone + is re-signed using one of the new Zone Signing Keys. In this case, + since a Key Signing Key is changed, every resolver that choose to + trust that KSK holder will over time have to configure the new key + to be able to validate lookups. + + This problem is not unique to a signed root zone, it is inherent in + any activity involving cryptographic keys. + + +5.8. Does the out-of-band communication between the signing operators + and the RIRs holding the key-signing keys add a new failure mode? + + Yes. The traditional DNSSEC design assumes that (for an arbitrary + zone, not particularly for the root zone) the key-signing key is + managed by the same entity that manages the operator keys and hence + no communication issue exists. + + In this case it is important that the signing operators do not hold + the responsibility for the key-signing keys. The root server + operators should only act as a "publishing service" for the root + zone contents, not as the entity that verifies correctness of the + published data. + + However, apart from established secure methods of out-of-band + communication being available, there is also the very real + possibility of managing these exchanges with actual eye-to-eye + contact. Representatives for the RIRs and the root server operators + already meet on a regular basis during IETF meetings and the + different RIR meetings. + + +6. Security Considerations + + Signing the DNS root zone is all about security. A signed root zone + may aid applications and organizations all over the Internet in + improving their security by enabling validation of DNS lookups. + + Signing the root zone does add a new management step and therefore + it is important to ensure that possible failures in this management + step does not leave the published root zone in a state that is + actually worse than the original unsigned state. + + The various failure modes that have been identified all show this + property of not being any worse than the unsigned case. + + There is however one scenario that changes drastically with the + proposed distributed signing scheme and that is the consequences of + one signing operator intentionally changing the contents of the + root zone prior to the actual signing. In the unsigned case this + will cause the root zone to become inconsistent (i.e. the responses + vary depending upon which server it comes from), while in the + signed case the root zone will remain consistent but with erroneous + data in it. + + It is my belief (this is impossible to prove) that the risk of + human error among the operators, however small, is still far + greater than the risk of willful misconduct. Therefore, the + proposed design that enforces consistency among the roots, is + actually also an improvement in stability and security. + + Se further section 4 for a more complete risk analysis. + + +7. IANA Considerations + + NONE. + + +8. References + +8.1. Normative. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. + March 1999. + + [RFC3090] DNS Security Extension Clarification on Zone Status. + E. Lewis. March 2001. + + [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996. + + [RFC1996] A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY). P. Vixie. August 1996. + + [RFC2845] Secret Key Transaction Authentication for DNS (TSIG). + P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington. + May 2000. + +8.2. Informative. + + [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake. + September 2000. + + [RFC3007] Secure Domain Name System (DNS) Dynamic Update. + B. Wellington. November 2000. + + [RFC3008] Domain Name System Security (DNSSEC) Signing Authority. + B. Wellington. November 2000. + + [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS). D. Eastlake 3rd. May 2001. + + [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. + December 2001. + + [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size + requirements. O. Gudmundsson. December 2001. + + [Delegation-Signer] Delegation Signer Resource Record. + O. Gudmundsson. October 2002. Work In Progress. + + [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone + Transfer Protocol Clarifications. A. Gustafsson. March + 2002. Work In Progress. + + [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of + DNS AD bit. B. Wellington, O Gudmundsson. June 2002. + Work In Progress. + + [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In + R. Arends, M Kosters, D. Blacka. June 2002. Work In + Progress. + + [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard- + optimization-NN.txt DNSSEC Wildcard optimization. + O. Kolkman, J. Ihren, R. Arends. September 2002. + Work In Progress. + + [Threshold-Validation] + draft-ihren-dnsop-threshold-validation-00.txt Threshold + validation: A Mechanism for Improved Trust and Redundancy + for DNSSEC Keys. J. Ihren. February 2003. Work In + Progress. + +9. Acknowledgments. + + To help me produce this document I have received lots and lots of + comments from many people around the Internet with suggestions for + lots and lots sorely needed improvements. Among the folks who + helped out are, in no particular order: Paul Vixie, Bill Manning, + Ôlafur Gumundsson, Rob Austein, Patrik F„ltstr÷m, Olaf Kolkman, + Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman + and M…ns Nilsson. + + +10. Authors' Address + +Johan Ihr‰n +Autonomica AB +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt new file mode 100644 index 0000000000..2920cad2fa --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt @@ -0,0 +1,480 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems,inc. +Feb, 27, 2003 Johan Ihren +Expires August, 28, 2003 Autonomica + + + IPv6 DNS transition issues + + + + +Status of this memo + + This memo provides information to the Internet community. It does not + specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + This memo summarizes DNS related issues when transitioning a network + to IPv6. Consensus and open issues are presented. + + + +1. Representing IPv6 addresses in DNS records + + In the direct zones, according to [RFC3363], IPv6 addresses are + represented using AAAA records [RFC1886]. In the reverse zone, IPv6 + addresses are represented using PTR records in nibble format under + the ip6.arpa. tree [RFC3152]. + + + +2. IPv4/IPv6 name space + +2.1 Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS data is + served. Likewise, "IPv6 name server" indicates a name server + available over IPv6 transport. + + +2.2. Introduction to the problem of name space fragmentation: + following the referral chain + + The caching resolver that tries to lookup a name starts out at the + root, and follows referrals until it is referred to a nameserver that + is authoritative for the name. If somewhere down the chain of + referrals it is referred to a nameserver that is only accessible over + a type of transport that is unavailable, a traditional nameserver is + unable to finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen and the complete + DNS hierarchy starts to fragment into a graph where authoritative + nameservers for certain nodes are only accessible over a certain + transport. What is feared is that a node using only a particular + version of IP, querying information about another node using the same + version of IP can not do it because, somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + through a "translator", i.e. they have to use a second name server on + a so-called "dual stack" host as a "forwarder" since they cannot + access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of old legacy IPv4 name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in a foreseeable time. + Instead, it is expected that the transition will be from IPv4 only to + a mixture of IPv4 and IPv6, with DNS data of theoretically three + categories depending on whether it is available only over IPv4 + transport, only over IPv6 or both. + + The latter is the best situation, and a major question is how to + ensure that it as quickly as possible becomes the norm. However, + while it is obvious that some DNS data will only be available over v4 + transport for a long time it is also obvious that it is important to + avoid fragmenting the name space available to IPv4 only hosts. I.e. + during transition it is not acceptable to break the name space that + we presently have available for IPv4-only hosts. + + +2.3 Policy based avoidance of name space fragmentation. + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and they can mostly be regarded + as "experimental". However, as soon as there is a root name server + available over IPv6 transport it is reasonable to expect that it will + become more common to have zones served by IPv6 servers over time. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + The RECOMMENDED approach to maintain name space continuity is to use + administrative policies: + - every recursive DNS server SHOULD be either IPv4-only or dual + stack, + - every single DNS zone SHOULD be served by at least one IPv4 + reachable DNS server. + + This rules out IPv6-only recursive DNS servers and DNS zones served + only by IPv6-only DNS servers. This approach could be revisited + if/when translation techniques between IPv4 and IPv6 were to be + widely deployed. + + In order to enforce the second point, the zone validation process + SHOULD ensure that there is at least one IPv4 address record + available for the name servers of any child delegations within the + zone. + + + +3. Local Scope addresses. + + [IPv6ADDRARCH] define three scopes of addresses, link local, site + local and global. + +3.1 Link local addresses + + Local addresses SHOULD NOT be published in the DNS, neither in the + forward tree nor in the reverse tree. + + +3.2 Site local addresses + + Note: There is an ongoing discussion in the IPv6 wg on the + usefulness of site local addresses that may end up deprecating or + limiting the use of Site Local addresses. + + + Site local addresses are an evolution of private addresses [RFC1918] + in IPv4. The main difference is that, within a site, nodes are + expected to have several addresses with different scopes. [ADDRSELEC] + recommends to use the lowest possible scope possible for + communications. That is, if both site local & global addresses are + published in the DNS for node B, and node A is configured also with + both site local & global addresses, the communication between node A + and B has to use site local addresses. + + For reasons illustrated in [DontPublish], site local addresses SHOULD + NOT be published in the public DNS. They MAY be published in a site + view of the DNS if two-face DNS is deployed. + + For a related discussion on how to handle those "local" zones, see + [LOCAL]. + + +3.3 Reverse path DNS for site local addresses. + + The main issue is that the view of a site may be different on a stub + resolver and on a fully recursive resolver it points to. A simple + scenario to illustrate the issue is a home network deploying site + local addresses. Reverse DNS resolution for site local addresses has + to be done within the home network and the stub resolver cannot + simply point to the ISP DNS resolver. + + Site local addresses SHOULD NOT be populated in the public reverse + tree. If two-face DNS is deployed, site local addresses MAY be + populated in the local view of reverse tree. + + + +4. Automatic population of the Reverse path DNS + + Getting the reverse tree DNS populated correctly in IPv4 is not an + easy exercise and very often the records are not really up to date or + simply are just not there. As IPv6 addresses are much longer than + IPv4 addresses, the situation of the reverse tree DNS will probably + be even worse. + + A fairly common practice from IPv4 ISP is to generate PTR records for + home customers automatically from the IPv4 address itself. Something + like: + + 1.2.3.4.in-addr.arpa. IN PTR 4.3.2.1.local-ISP.net + + It is not clear today if something similar need to be done in IPv6, + and, if yes, what is the best approach to this problem. + + As the number of possible PTR records would be huge (2^80) for a /48 + prefix, a possible solution would be to use wildcards entries like: + + *.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local- + ISP.net + + However, the use of wildcard is generally discouraged and this may + not be an acceptable solution. + + An alternative approach is to dynamically synthetize PTR records, + either on the server side or on the resolver side. This approach is + discussed at length in [DYNREVERSE]. + + Other solutions like the use of ICMP name lookups [ICMPNL] have been + proposed but failed to reach consensus. It would work if and only the + remote host is reachable at the time of the request and one can + somehow trust the value that would be returned by the remote host. + the + + A more radical approach would be not to pre-populate the reverse tree + at all. This approach claims that applications that misuse reverse + DNS for any kind of access control are fundamentally broken and + should be fixed without introducing any kludge in the DNS. There is a + certain capital of sympathy for this, however, ISP who who pre- + generate statically PTR records for their IPv4 customers do it for a + reason, and it is unlikely that this reason will disappear with the + introduction of IPv6. + + + +5. Privacy extension addresses + + [RFC3041] defines privacy extensions for IPv6 stateless + autoconfiguration where the interface ID is a random number. As those + addresses are designed to provide privacy by making it more difficult + to log and trace back to the user, it makes no sense to in the + reverse tree DNS to have them pointing to a real name. + + [RFC3041] type addresses SHOULD NOT be published in the reverse tree + DNS pointing to meaningful names. A generic, catch-all name MAY be + acceptable. An interesting alternative would be to use dynamic + synthesis as in [DYNREVERSE]. + + + +6. 6to4 + + 6to4 addresses can be published in the forward DNS, however special + care is needed in the reverse tree. See [6to4ReverseDNS] for details. + The delegation of 2.0.0.2.ip6.arpa. is suggested in [6to4ARPA], + however, delegations in the reverse zone under 2.0.0.2.ip6.arpa are + the core of the problem. Delegating the next 32 bits of the IPv4 + address used in the 6to4 domain won't scale and delegating on less + may require cooperation from the upstream IPSs. The problem here is + that, especially in the case of home usage of 6to4, the entity being + delegated the x.y.z.t.2.0.0.2.ip6.arpa. zone (the ISP) may not be the + same as the one using 6to4 (the end customer). the + + Another problem with reverse DNS for 6to4 addresses is that the 6to4 + prefix may be transient. One of the usage scenario of 6to4 is to have + PCs connected via dial-up use 6to4 to connect to the IPv6 Internet. + In such a scenario, the lifetime of the 6to4 prefix is the same as + the DHCP lease of the IPv4 address it is derived from. It means that + the reverse DNS delegation is only valid for the same duration. + + A possible approach is not to populate the reverse tree DNS for 6to4 + addresses. Another one is to use dynamic synthesis as described in + [DYNREVERSE]. + + + + +7. Recursive DNS server discovery + + [DNSdiscovery] has been proposed to reserve a well known site local + unicast address to configure the DNS resolver as a last resort + mechanism, when no other information is available. Another approach + is to use a DHCPv6 extensions [DHCPv6DNS]. + + + +8. DNSsec + + There is nothing specific to IPv6 or IPv4 in DNSsec. However, + translation tools such as NAT-PT [RFC2766] introduce a DNS-ALG that + will break DNSsec by imposing a change in the trust model. See [DNS- + ALG] for details. + + + +9. Security considerations + + Using wildcard DNS records in the reverse path tree may have some + implication when used in conjunction with DNSsec. Security + considerations for referenced documents are described in those memos + and are not replicated here. + + + +10. Author addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + Mail: Alain.Durand@sun.com + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm, Sweden + Mail: johani@autonomica.se + + + +11. References + + [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B. + Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February + 1996. + + [RFC2766] Network Address Translation - Protocol Translation (NAT- + PT). + G. Tsirtsis, P. Srisuresh. February 2000. + + [RFC3041] Privacy Extensions for Stateless Address Autoconfiguration + in IPv6, + T. Narten, R. Draves, January 2001. + + [RFC3152] Delegation of ip6.arpa, R. Bush, August 2001. + + [RFC3363] Representing Internet Protocol version 6 (IPv6) Addresses + in the Domain Name System (DNS), R. Bush, A. Durand, B. + Fink, O. Gudmundsson, T. Hain. August 2002. + + [DYNREVERSE] Dynamic reverse DNS for IPv6, A. Durand, + draft-durand-dnsops-dynreverse-00.txt, work in progress. + + [DNS-ALG] Issues with NAT-PT DNS ALG in RFC2766, A. Durand, + draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work in + progress. + + [LOCAL] Operational Guidelines for "local" zones in the DNS, + Kato, A., Vixie, P., draft-kato-dnsop-local-zones-00.txt, + work in progress. + + [ICMPNL] Use of ICMPv6 node information query for reverse DNS lookup, + Jun-ichiro itojun Hagino, draft-itojun-ipv6-nodeinfo- + revlookup-00.txt, work in progress. + + [IPv6ADDRARCH] IP Version 6 Addressing Architecture, R. Hinden, + draft-ipngwg-addr-arch-v3-11.txt, work in progress. + + [6to4ARPA] Delegation of 2.0.0.2.ip6.arpa, Bush, R., Damas, J., + draft-ymbk-6to4-arpa-delegation-00.txt, work in progress. + + [6to4ReverseDNS] 6to4 and DNS, K. Moore, draft-moore-6to4-dns-03.txt, + work in progress. + + [DNSdiscovery] Well known site local unicast addresses for DNS + resolver, + A. Durand, J. hagano, D. Thaler, draft-ietf-ipv6-dns- + discovery-07.txt, work in progress. + + [DHCPv6DNS] DNS Configuration options for DHCPv6, Droms, R. + draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, work in + progress. + + + +12. Full Copyright Statement + + "Copyright (C) The Internet Society (2001). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-serverid-01.txt b/doc/draft/draft-ietf-dnsop-serverid-01.txt new file mode 100644 index 0000000000..b0e9f27501 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-serverid-01.txt @@ -0,0 +1,283 @@ + + + + + + +INTERNET-DRAFT David Conrad +draft-ietf-dnsop-serverid-01.txt Nominum, Inc. + November, 2002 + + Identifying an Authoritative Name Server + +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. + +Abstract + + A standardized mechanism to determine the identity of a name server + responding to a particular query would be useful, particularly as a + diagnostic aid. This document describes an identification convention + used in one widely deployed implementation of the DNS protocol and + proposes a slight modification to that convention aimed at addressing + some implementation concerns. + +1. Introduction + + Determining the identity of the name server responding to a query has + become more complex due primarily to the proliferation of various + load balancing techniques. This document describes a convention used + by one particular DNS server implementation to provide identifying + information and proposes a slight modification to that convention to + address concerns regarding implementation neutrality. + + Note that this document makes no value judgements as to whether or + not the convention in current use is good or bad; it merely documents + + + +Expires May, 2003 [Page 1] + +draft-ietf-dnsop-serverid-01.txt May, 2002 + + + the covention's existence and proposes a slight redefinition of the + convention to address non-technical implementation concerns. + +2. Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. However, relying on the IP address of the name server + has become more problematic due the deployment of various load + balancing solutions, including the use of shared unicast addresses as + documented in [RFC3258]. + + An unfortunate side effect of these load balancing solutions is that + traditional methods of determining which server is responding can be + unreliable. Specifically, non-DNS methods such as ICMP ping, TCP + connections, or non-DNS UDP packets (e.g., as generated by tools such + as "traceroute"), etc., can end up going to a different server than + that which receives the DNS queries. + + This proposal makes the assumption that an identification mechanism + that relies on the DNS protocol is more likely to be successful + (although not guaranteed) in going to the same machine as a "normal" + DNS query. + +3. Historical Conventions + + Recent versions of the commonly deployed Berkeley Internet Name + Domain implementation of the DNS protocol suite from the Internet + Software Consortium [BIND] support a way of identifying a particular + server via the use of a standard, if somewhat unusual, DNS query. + Specifically, a query to a late model BIND server for a TXT resource + record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will + return a string that can be configured by the name server + administrator to provide a unique identifier for the responding + server (defaulting to the value of a gethostname() call). This + mechanism, which is an extension of the BIND convention of using + CHAOS class TXT RR queries to sub-domains of the "BIND." domain for + version information, has been copied by several name server vendors. + + For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A + query for a TXT RR for this name will return an administratively re- + definable string which defaults to the version of the server + responding. + +4. An Implementation Neutral Convention + + The previously described use of the CHAOS class "BIND." domain has + + + +Expires May, 2003 [Page 2] + +draft-ietf-dnsop-serverid-01.txt May, 2002 + + + (rightly) been viewed by many implementors as not being standardized + nor being implementation neutral. As such, a standard mechanism to + identify a particular machine among a shared unicast set of machines + serving the same DNS data does not currently exist. + + Since a name server conforming to [RFC1034] and [RFC1035] should + support the CHAOS class and the use of TXT resource record queries in + the CHAOS class to derive information about a name server has been + used in several independent name server implementations, the quickest + way of supporting the identification of a particular name server out + of a set of name servers all sharing the same unicast prefix would + likely be to standardize on the BIND convention, albeit with a slight + modification to address implementation neutrality concerns. + + The convention proposed here simply redefines the top level CHAOS + domain to be "SERVER." instead of "BIND.". Since using the actual + hostname may be considered an information leakage security risk, the + use of the actual hostname of the server is discouraged and instead a + unique per-server identifier should be used. As the BIND convention + of "HOSTNAME" implies the use of a hostname, the domain name + "ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in + the CHAOS class will return an administratively defined string that + can be used to differentiate among multiple servers. + + To make this convention useful, DNS operators wishing to identify + their servers uniquely MUST, for EACH server, put a unique string for + the RDATA of the TXT record associated with the "ID.SERVER." domain + in class CHAOS. For example, given two machines "a.example.com" and + "b.example.com" that receive DNS queries at the same IP address, the + name server administrator could include + + $ORIGIN SERVER. + ID CH TXT "a" + + in the appropriate zone file on machine "a.example.com" and + + $ORIGIN SERVER. + ID CH TXT "b" + + in the appropriate zone file on machine "b.example.com". + + Queries for TXT RRs of "id.server" in class CHAOS to the IP address + serving both "a.example.com" and "b.example.com" should return "a" or + "b" depending on which machine the query was routed. + + Implementors MUST provide a way to disable returning this identifying + information. Implementors SHOULD provide a way to limit who can + query for the identifying information. + + + +Expires May, 2003 [Page 3] + +draft-ietf-dnsop-serverid-01.txt May, 2002 + + + The use of other names in the CHAOS class "SERVER." domain are beyond + the scope of this document. + +IANA Considerations + + The "SERVER." domain in the CHAOS class should be reserved by IANA + and a registry should be created that reserves the "ID" name. In the + future, requests may be submitted for other sub-domains of "SERVER.", + e.g., "VERSION.SERVER." and the IANA should take appropriate action. + +Security Considerations + + Providing identifying information as to which server is responding + can be seen as information leakage and thus a security risk. It may + be appropriate to restrict who can query for the "ID.SERVER." domain. + Filtering on source address would be one way in which restrictions + can be applied. + + The identifer returned via an "ID.SERVER." query SHOULD NOT contain + the hostname or other information that could be considered sensitive. + +Acknowledgements + + The technique for host identification documented here derive from + practices implemented by Paul Vixie of the Internet Software + Consortium in the Berkeley Internet Name Domain package. Useful + comments on earlier drafts were provided by Bob Halley, Brian + Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and + members of the ICANN Root Server System Advisory Council. Additional + explanatory information provided due to questions received from Randy + Bush. + +References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specifications", RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via + Shared Unicast Addresses", RFC 3258, April, 2002. + +Author's Address + + + + +Expires May, 2003 [Page 4] + +draft-ietf-dnsop-serverid-01.txt May, 2002 + + + David Conrad + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1 650 381 6003 + Fax: +1 650 381 6055 + Email: david.conrad@nominum.com + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + +Expires May, 2003 [Page 5] + diff --git a/doc/draft/draft-ietf-idn-punycode-03.txt b/doc/draft/draft-ietf-idn-punycode-03.txt new file mode 100644 index 0000000000..9240e60cf7 --- /dev/null +++ b/doc/draft/draft-ietf-idn-punycode-03.txt @@ -0,0 +1,1495 @@ +INTERNET-DRAFT Adam M. Costello +draft-ietf-idn-punycode-03.txt 2002-Oct-08 +Expires 2003-Apr-08 + + Punycode: A Bootstring encoding of Unicode for IDNA + +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 + + Distribution of this document is unlimited. + +Abstract + + Punycode is a simple and efficient transfer encoding syntax designed + for use with Internationalized Domain Names in Applications [IDNA]. + It uniquely and reversibly transforms a Unicode string [UNICODE] + into an ASCII string [ASCII]. ASCII characters in the Unicode + string are represented literally, and non-ASCII characters are + represented by ASCII characters that are allowed in host name labels + (letters, digits, and hyphens). This document defines a general + algorithm called Bootstring that allows a string of basic code + points to uniquely represent any string of code points drawn from + a larger set. Punycode is an instance of Bootstring that uses + particular parameter values specified by this document, appropriate + for IDNA. + +Contents + + 1. Introduction + 1.1 Features + 1.2 Interaction of protocol parts + 2. Terminology + 3. Bootstring description + 3.1 Basic code point segregation + 3.2 Insertion unsort coding + 3.3 Generalized variable-length integers + 3.4 Bias adaptation + 4. Bootstring parameters + 5. Parameter values for Punycode + 6. Bootstring algorithms + 6.1 Bias adaptation function + 6.2 Decoding procedure + 6.3 Encoding procedure + 6.4 Overflow handling + 7. Punycode examples + 7.1 Sample strings + 7.2 Decoding traces + 7.3 Encoding traces + 8. Security considerations + 9. References (non-normative) + A. Author contact information + B. Mixed-case annotation + C. Disclaimer and license + D. Punycode sample implementation + +1. Introduction + + [IDNA] describes an architecture for supporting internationalized + domain names. Labels containing non-ASCII characters can be + represented by ACE labels, which begin with a special ACE prefix and + contain only ASCII characters. The remainder of the label after the + prefix is a Punycode encoding of a Unicode string satisfying certain + constraints. For the details of the prefix and constraints, see + [IDNA] and [NAMEPREP]. + + Punycode is an instance of a more general algorithm called + Bootstring, which allows strings composed from a small set of + "basic" code points to uniquely represent any string of code points + drawn from a larger set. Punycode is Bootstring with particular + parameter values appropriate for IDNA. + +1.1 Features + + Bootstring has been designed to have the following features: + + * Completeness: Every extended string (sequence of arbitrary code + points) can be represented by a basic string (sequence of basic + code points). Restrictions on what strings are allowed, and on + length, can be imposed by higher layers. + + * Uniqueness: There is at most one basic string that represents a + given extended string. + + * Reversibility: Any extended string mapped to a basic string can + be recovered from that basic string. + + * Efficient encoding: The ratio of basic string length to + extended string length is small. This is important in the + context of domain names because RFC 1034 [RFC1034] restricts the + length of a domain label to 63 characters. + + * Simplicity: The encoding and decoding algorithms are reasonably + simple to implement. The goals of efficiency and simplicity are + at odds; Bootstring aims at a good balance between them. + + * Readability: Basic code points appearing in the extended string + are represented as themselves in the basic string (although the + main purpose is to improve efficiency, not readability). + + Punycode can also support an additional feature that is not used + by the ToASCII and ToUnicode operations of [IDNA]. When extended + strings are case-folded prior to encoding, the basic string can + use mixed case to tell how to convert the folded string into a + mixed-case string. See appendix B "Mixed-case annotation". + +1.2 Interaction of protocol parts + + Punycode is used by the IDNA protocol [IDNA] for converting domain + labels into ASCII; it is not designed for any other purpose. It is + explicitly not designed for processing arbitrary free text. + +2. Terminology + + 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 [RFC2119]. + + A code point is an integral value associated with a character in a + coded character set. + + As in the Unicode Standard [UNICODE], Unicode code points are + denoted by "U+" followed by four to six hexadecimal digits, while a + range of code points is denoted by two hexadecimal numbers separated + by "..", with no prefixes. + + The operators div and mod perform integer division; (x div y) is the + quotient of x divided by y, discarding the remainder, and (x mod y) + is the remainder, so (x div y) * y + (x mod y) == x. Bootstring + uses these operators only with nonnegative operands, so the quotient + and remainder are always nonnegative. + + The break statement jumps out of the innermost loop (as in C). + + An overflow is an attempt to compute a value that exceeds the + maximum value of an integer variable. + +3. Bootstring description + + Bootstring represents an arbitrary sequence of code points (the + "extended string") as a sequence of basic code points (the "basic + string"). This section describes the representation. Section 6 + "Bootstring algorithms" presents the algorithms as pseudocode. + Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the + algorithms for sample inputs. + + The following sections describe the four techniques used in + Bootstring. "Basic code point segregation" is a very simple + and efficient encoding for basic code points occurring in the + extended string: they are simply copied all at once. "Insertion + unsort coding" encodes the non-basic code points as deltas, and + processes the code points in numerical order rather than in order of + appearance, which typically results in smaller deltas. The deltas + are represented as "generalized variable-length integers", which use + basic code points to represent nonnegative integers. The parameters + of this integer representation are dynamically adjusted using "bias + adaptation", to improve efficiency when consecutive deltas have + similar magnitudes. + +3.1 Basic code point segregation + + All basic code points appearing in the extended string are + represented literally at the beginning of the basic string, in their + original order, followed by a delimiter if (and only if) the number + of basic code points is nonzero. The delimiter is a particular + basic code point, which never appears in the remainder of the basic + string. The decoder can therefore find the end of the literal + portion (if there is one) by scanning for the last delimiter. + +3.2 Insertion unsort coding + + The remainder of the basic string (after the last delimiter if there + is one) represents a sequence of nonnegative integral deltas as + generalized variable-length integers, described in section 3.3. The + meaning of the deltas is best understood in terms of the decoder. + + The decoder builds the extended string incrementally. Initially, + the extended string is a copy of the literal portion of the basic + string (excluding the last delimiter). The decoder inserts + non-basic code points, one for each delta, into the extended string, + ultimately arriving at the final decoded string. + + At the heart of this process is a state machine with two state + variables: an index i and a counter n. The index i refers to + a position in the extended string; it ranges from 0 (the first + position) to the current length of the extended string (which refers + to a potential position beyond the current end). If the current + state is , the next state is if i is less than the + length of the extended string, or if i equals the length of + the extended string. In other words, each state change causes i to + increment, wrapping around to zero if necessary, and n counts the + number of wrap-arounds. + + Notice that the state always advances monotonically (there is no + way for the decoder to return to an earlier state). At each state, + an insertion is either performed or not performed. At most one + insertion is performed in a given state. An insertion inserts the + value of n at position i in the extended string. The deltas are + a run-length encoding of this sequence of events: they are the + lengths of the runs of non-insertion states preceeding the insertion + states. Hence, for each delta, the decoder performs delta state + changes, then an insertion, and then one more state change. (An + implementation need not perform each state change individually, but + can instead use division and remainder calculations to compute the + next insertion state directly.) It is an error if the inserted code + point is a basic code point (because basic code points were supposed + to be segregated as described in section 3.1). + + The encoder's main task is to derive the sequence of deltas that + will cause the decoder to construct the desired string. It can do + this by repeatedly scanning the extended string for the next code + point that the decoder would need to insert, and counting the number + of state changes the decoder would need to perform, mindful of the + fact that the decoder's extended string will include only those + code points that have already been inserted. Section 6.3 "Encoding + procedure" gives a precise algorithm. + +3.3 Generalized variable-length integers + + In a conventional integer representation the base is the number of + distinct symbols for digits, whose values are 0 through base-1. Let + digit_0 denote the least significant digit, digit_1 the next least + significant, and so on. The value represented is the sum over j of + digit_j * w(j), where w(j) = base^j is the weight (scale factor) + for position j. For example, in the base 8 integer 437, the digits + are 7, 3, and 4, and the weights are 1, 8, and 64, so the value is + 7 + 3*8 + 4*64 = 287. This representation has two disadvantages: + First, there are multiple encodings of each value (because there + can be extra zeros in the most significant positions), which is + inconvenient when unique encodings are needed. Second, the integer + is not self-delimiting, so if multiple integers are concatenated the + boundaries between them are lost. + + The generalized variable-length representation solves these two + problems. The digit values are still 0 through base-1, but now + the integer is self-delimiting by means of thresholds t(j), each + of which is in the range 0 through base-1. Exactly one digit, the + most significant, satisfies digit_j < t(j). Therefore, if several + integers are concatenated, it is easy to separate them, starting + with the first if they are little-endian (least significant digit + first), or starting with the last if they are big-endian (most + significant digit first). As before, the value is the sum over j of + digit_j * w(j), but the weights are different: + + w(0) = 1 + w(j) = w(j-1) * (base - t(j-1)) for j > 0 + + For example, consider the little-endian sequence of base 8 digits + 734251... Suppose the thresholds are 2, 3, 5, 5, 5, 5... This + implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) + = 90, 90*(8-5) = 270, and so on. 7 is not less than 2, and 3 is + not less than 3, but 4 is less than 5, so 4 is the last digit. The + value of 734 is 7*1 + 3*6 + 4*30 = 145. The next integer is 251, + with value 2*1 + 5*6 + 1*30 = 62. Decoding this representation + is very similar to decoding a conventional integer: Start with a + current value of N = 0 and a weight w = 1. Fetch the next digit d + and increase N by d * w. If d is less than the current threshold + (t) then stop, otherwise increase w by a factor of (base - t), + update t for the next position, and repeat. + + Encoding this representation is similar to encoding a conventional + integer: If N < t then output one digit for N and stop, otherwise + output the digit for t + ((N - t) mod (base - t)), then replace N + with (N - t) div (base - t), update t for the next position, and + repeat. + + For any particular set of values of t(j), there is exactly one + generalized variable-length representation of each nonnegative + integral value. + + Bootstring uses little-endian ordering so that the deltas can be + separated starting with the first. The t(j) values are defined in + terms of the constants base, tmin, and tmax, and a state variable + called bias: + + t(j) = base * (j + 1) - bias, + clamped to the range tmin through tmax + + The clamping means that if the formula yields a value less than tmin + or greater than tmax, then t(j) = tmin or tmax, respectively. (In + the pseudocode in section 6 "Bootstring algorithms", the expression + base * (j + 1) is denoted by k for performance reasons.) These + t(j) values cause the representation to favor integers within a + particular range determined by the bias. + +3.4 Bias adaptation + + After each delta is encoded or decoded, bias is set for the next + delta as follows: + + 1. Delta is scaled in order to avoid overflow in the next step: + + let delta = delta div 2 + + But when this is the very first delta, the divisor is not 2, but + instead a constant called damp. This compensates for the fact + that the second delta is usually much smaller than the first. + + 2. Delta is increased to compensate for the fact that the next + delta will be inserting into a longer string: + + let delta = delta + (delta div numpoints) + + numpoints is the total number of code points encoded/decoded so + far (including the one corresponding to this delta itself, and + including the basic code points). + + 3. Delta is repeatedly divided until it falls within a threshold, + to predict the minimum number of digits needed to represent the + next delta: + + while delta > ((base - tmin) * tmax) div 2 + do let delta = delta div (base - tmin) + + 4. The bias is set: + + let bias = + (base * the number of divisions performed in step 3) + + (((base - tmin + 1) * delta) div (delta + skew)) + + The motivation for this procedure is that the current delta provides + a hint about the likely size of the next delta, and so t(j) is + set to tmax for the more significant digits starting with the one + expected to be last, tmin for the less significant digits up through + the one expected to be third-last, and somewhere between tmin and + tmax for the digit expected to be second-last (balancing the hope of + the expected-last digit being unnecessary against the danger of it + being insufficient). + +4. Bootstring parameters + + Given a set of basic code points, one needs to be designated as + the delimiter. The base cannot be greater than the number of + distinguishable basic code points remaining. The digit-values in + the range 0 through base-1 need to be associated with distinct + non-delimiter basic code points. In some cases multiple code points + need to have the same digit-value; for example, uppercase and + lowercase versions of the same letter need to be equivalent if basic + strings are case-insensitive. + + The initial value of n cannot be greater than the minimum non-basic + code point that could appear in extended strings. + + The remaining five parameters (tmin, tmax, skew, damp, and the + initial value of bias) need to satisfy the following constraints: + + 0 <= tmin <= tmax <= base-1 + skew >= 1 + damp >= 2 + initial_bias mod base <= base - tmin + + Provided the constraints are satisfied, these five parameters affect + efficiency but not correctness. They are best chosen empirically. + + If support for mixed-case annotation is desired (see appendix B), + make sure that the code points corresponding to 0 through tmax-1 all + have both uppercase and lowercase forms. + +5. Parameter values for Punycode + + Punycode uses the following Bootstring parameter values: + + base = 36 + tmin = 1 + tmax = 26 + skew = 38 + damp = 700 + initial_bias = 72 + initial_n = 128 = 0x80 + + Although the only restriction Punycode imposes on the input integers + is that they be nonnegative, these parameters are especially + designed to work well with Unicode [UNICODE] code points, which + are integers in the range 0..10FFFF (but not D800..DFFF, which are + reserved for use by the UTF-16 encoding of Unicode). The basic code + points are the ASCII [ASCII] code points (0..7F), of which U+002D + (-) is the delimiter, and some of the others have digit-values as + follows: + + code points digit-values + ------------ ---------------------- + 41..5A (A-Z) = 0 to 25, respectively + 61..7A (a-z) = 0 to 25, respectively + 30..39 (0-9) = 26 to 35, respectively + + Using hyphen-minus as the delimiter implies that the encoded string + can end with a hyphen-minus only if the Unicode string consists + entirely of basic code points, but IDNA forbids such strings from + being encoded. The encoded string can begin with a hyphen-minus, + but IDNA prepends a prefix. Therefore IDNA using Punycode conforms + to the RFC 952 rule that host name labels neither begin nor end with + a hyphen-minus [RFC952]. + + A decoder MUST recognize the letters in both uppercase and lowercase + forms (including mixtures of both forms). An encoder SHOULD output + only uppercase forms or only lowercase forms, unless it uses + mixed-case annotation (see appendix B). + + Presumably most users will not manually write or type encoded + strings (as opposed to cutting and pasting them), but those who do + will need to be alert to the potential visual ambiguity between the + following sets of characters: + + G 6 + I l 1 + O 0 + S 5 + U V + Z 2 + + Such ambiguities are usually resolved by context, but in a Punycode + encoded string there is no context apparent to humans. + +6. Bootstring algorithms + + Some parts of the pseudocode can be omitted if the parameters + satisfy certain conditions (for which Punycode qualifies). These + parts are enclosed in {braces}, and notes immediately following the + pseudocode explain the conditions under which they can be omitted. + + Formally, code points are integers, and hence the pseudocode assumes + that arithmetic operations can be performed directly on code points. + In some programming languages, explicit conversion between code + points and integers might be necessary. + +6.1 Bias adaptation function + + function adapt(delta,numpoints,firsttime): + if firsttime then let delta = delta div damp + else let delta = delta div 2 + let delta = delta + (delta div numpoints) + let k = 0 + while delta > ((base - tmin) * tmax) div 2 do begin + let delta = delta div (base - tmin) + let k = k + base + end + return k + (((base - tmin + 1) * delta) div (delta + skew)) + + It does not matter whether the modifications to delta and k + inside adapt() affect variables of the same name inside the + encoding/decoding procedures, because after calling adapt() the + caller does not read those variables before overwriting them. + +6.2 Decoding procedure + + let n = initial_n + let i = 0 + let bias = initial_bias + let output = an empty string indexed from 0 + consume all code points before the last delimiter (if there is one) + and copy them to output, fail on any non-basic code point + if more than zero code points were consumed then consume one more + (which will be the last delimiter) + while the input is not exhausted do begin + let oldi = i + let w = 1 + for k = base to infinity in steps of base do begin + consume a code point, or fail if there was none to consume + let digit = the code point's digit-value, fail if it has none + let i = i + digit * w, fail on overflow + let t = tmin if k <= bias {+ tmin}, or + tmax if k >= bias + tmax, or k - bias otherwise + if digit < t then break + let w = w * (base - t), fail on overflow + end + let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?) + let n = n + i div (length(output) + 1), fail on overflow + let i = i mod (length(output) + 1) + {if n is a basic code point then fail} + insert n into output at position i + increment i + end + + The full statement enclosed in braces (checking whether n is a basic + code point) can be omitted if initial_n exceeds all basic code + points (which is true for Punycode), because n is never less than + initial_n. + + In the assignment of t, where t is clamped to the range tmin through + tmax, "+ tmin" can always be omitted. This makes the clamping + calculation incorrect when bias < k < bias + tmin, but that cannot + happen because of the way bias is computed and because of the + constraints on the parameters. + + Because the decoder state can only advance monotonically, and there + is only one representation of any delta, there is therefore only + one encoded string that can represent a given sequence of integers. + The only error conditions are invalid code points, unexpected + end-of-input, overflow, and basic code points encoded using deltas + instead of appearing literally. If the decoder fails on these + errors as shown above, then it cannot produce the same output for + two distinct inputs. Without this property it would have been + necessary to re-encode the output and verify that it matches the + input in order to guarantee the uniqueness of the encoding. + +6.3 Encoding procedure + + let n = initial_n + let delta = 0 + let bias = initial_bias + let h = b = the number of basic code points in the input + copy them to the output in order, followed by a delimiter if b > 0 + {if the input contains a non-basic code point < n then fail} + while h < length(input) do begin + let m = the minimum {non-basic} code point >= n in the input + let delta = delta + (m - n) * (h + 1), fail on overflow + let n = m + for each code point c in the input (in order) do begin + if c < n {or c is basic} then increment delta, fail on overflow + if c == n then begin + let q = delta + for k = base to infinity in steps of base do begin + let t = tmin if k <= bias {+ tmin}, or + tmax if k >= bias + tmax, or k - bias otherwise + if q < t then break + output the code point for digit t + ((q - t) mod (base - t)) + let q = (q - t) div (base - t) + end + output the code point for digit q + let bias = adapt(delta, h + 1, test h equals b?) + let delta = 0 + increment h + end + end + increment delta and n + end + + The full statement enclosed in braces (checking whether the input + contains a non-basic code point less than n) can be omitted if all + code points less than initial_n are basic code points (which is true + for Punycode if code points are unsigned). + + The brace-enclosed conditions "non-basic" and "or c is basic" can be + omitted if initial_n exceeds all basic code points (which is true + for Punycode), because the code point being tested is never less + than initial_n. + + In the assignment of t, where t is clamped to the range tmin through + tmax, "+ tmin" can always be omitted. This makes the clamping + calculation incorrect when bias < k < bias + tmin, but that cannot + happen because of the way bias is computed and because of the + constraints on the parameters. + + The checks for overflow are necessary to avoid producing invalid + output when the input contains very large values or is very long. + + The increment of delta at the bottom of the outer loop cannot + overflow because delta < length(input) before the increment, and + length(input) is already assumed to be representable. The increment + of n could overflow, but only if h == length(input), in which case + the procedure is finished anyway. + +6.4 Overflow handling + + For IDNA, 26-bit unsigned integers are sufficient to handle all + valid IDNA labels without overflow, because any string that + needed a 27-bit delta would have to exceed either the code point + limit (0..10FFFF) or the label length limit (63 characters). + However, overflow handling is necessary because the inputs are not + necessarily valid IDNA labels. + + If the programming language does not provide overflow detection, + the following technique can be used. Suppose A, B, and C are + representable nonnegative integers and C is nonzero. Then A + B + overflows if and only if B > maxint - A, and A + (B * C) overflows + if and only if B > (maxint - A) div C, where maxint is the greatest + integer for which maxint + 1 cannot be represented. Refer to + appendix D "Punycode sample implementation" for demonstrations of + this technique in the C language. + + The decoding and encoding algorithms shown in sections 6.2 and + 6.3 handle overflow by detecting it whenever it happens. Another + approach is to enforce limits on the inputs that prevent overflow + from happening. For example, if the encoder were to verify that + no input code points exceed M and that the input length does not + exceed L, then no delta could ever exceed (M - initial_n) * (L + 1), + and hence no overflow could occur if integer variables were capable + of representing values that large. This prevention approach would + impose more restrictions on the input than the detection approach + does, but might be considered simpler in some programming languages. + + In theory, the decoder could use an analogous approach, limiting the + number of digits in a variable-length integer (that is, limiting the + number of iterations in the innermost loop). However, the number + of digits that suffice to represent a given delta can sometimes + represent much larger deltas (because of the adaptation), and hence + this approach would probably need integers wider than 32 bits. + + Yet another approach for the decoder is to allow overflow to occur, + but to check the final output string by re-encoding it and comparing + to the decoder input. If and only if they do not match (using a + case-insensitive ASCII comparison) overflow has occurred. This + delayed-detection approach would not impose any more restrictions on + the input than the immediate-detection approach does, and might be + considered simpler in some programming languages. + + In fact, if the decoder is used only inside the IDNA ToUnicode + operation [IDNA], then it need not check for overflow at all, + because ToUnicode performs a higher level re-encoding and + comparison, and a mismatch has the same consequence as if the + Punycode decoder had failed. + +7. Punycode examples + +7.1 Sample strings + + In the Punycode encodings below, the ACE prefix is not shown. + Backslashes show where line breaks have been inserted in strings too + long for one line. + + The first several examples are all translations of the sentence "Why + can't they just speak in ?" (courtesy of Michael Kaplan's + "provincial" page [PROVINCIAL]). Word breaks and punctuation have + been removed, as is often done in domain names. + + (A) Arabic (Egyptian): + u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644 + u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F + Punycode: egbpdaj6bu4bxfgehfvwxn + + (B) Chinese (simplified): + u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587 + Punycode: ihqwcrb4cv8a8dqg056pqjye + + (C) Chinese (traditional): + u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587 + Punycode: ihqwctvzc91f659drss3x8bo0yb + + (D) Czech: Proprostnemluvesky + U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074 + u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D + u+0065 u+0073 u+006B u+0079 + Punycode: Proprostnemluvesky-uyb24dma41a + + (E) Hebrew: + u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8 + u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2 + u+05D1 u+05E8 u+05D9 u+05EA + Punycode: 4dbcagdahymbxekheh6e0a7fei0b + + (F) Hindi (Devanagari): + u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D + u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939 + u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947 + u+0939 u+0948 u+0902 + Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd + + (G) Japanese (kanji and hiragana): + u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092 + u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B + Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa + + (H) Korean (Hangul syllables): + u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774 + u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74 + u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C + Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\ + psd879ccm6fea98c + + (I) Russian (Cyrillic): + U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E + u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440 + u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A + u+0438 + Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l + + (J) Spanish: PorqunopuedensimplementehablarenEspaol + U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070 + u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070 + u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061 + u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070 + u+0061 u+00F1 u+006F u+006C + Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a + + (K) Vietnamese: + Tisaohkhngthch\ + nitingVit + U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B + u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068 + u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067 + U+0056 u+0069 u+1EC7 u+0074 + Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g + + The next several examples are all names of Japanese music artists, + song titles, and TV programs, just because the author happens to + have them handy (but Japanese is useful for providing examples + of single-row text, two-row text, ideographic text, and various + mixtures thereof). + + (L) 3B + u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F + Punycode: 3B-ww4c5e180e575a65lsy2b + + (M) -with-SUPER-MONKEYS + u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074 + u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D + U+004F U+004E U+004B U+0045 U+0059 U+0053 + Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n + + (N) Hello-Another-Way- + U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F + u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D + u+305D u+308C u+305E u+308C u+306E u+5834 u+6240 + Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b + + (O) 2 + u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032 + Punycode: 2-u9tlzr9756bt3uc0v + + (P) MajiKoi5 + U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059 + u+308B u+0035 u+79D2 u+524D + Punycode: MajiKoi5-783gue6qz075azm5e + + (Q) de + u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0 + Punycode: de-jg4avhby1noc0d + + (R) + u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067 + Punycode: d9juau41awczczp + + The last example is an ASCII string that breaks the existing rules + for host name labels. (It is not a realistic example for IDNA, + because IDNA never encodes pure ASCII labels.) + + (S) -> $1.00 <- + u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020 + u+003C u+002D + Punycode: -> $1.00 <-- + +7.2 Decoding traces + + In the following traces, the evolving state of the decoder is + shown as a sequence of hexadecimal values, representing the code + points in the extended string. An asterisk appears just after the + most recently inserted code point, indicating both n (the value + preceeding the asterisk) and i (the position of the value just after + the asterisk). Other numerical values are decimal. + + Decoding trace of example B from section 7.1: + + n is 128, i is 0, bias is 72 + input is "ihqwcrb4cv8a8dqg056pqjye" + there is no delimiter, so extended string starts empty + delta "ihq" decodes to 19853 + bias becomes 21 + 4E0D * + delta "wc" decodes to 64 + bias becomes 20 + 4E0D 4E2D * + delta "rb" decodes to 37 + bias becomes 13 + 4E3A * 4E0D 4E2D + delta "4c" decodes to 56 + bias becomes 17 + 4E3A 4E48 * 4E0D 4E2D + delta "v8a" decodes to 599 + bias becomes 32 + 4E3A 4EC0 * 4E48 4E0D 4E2D + delta "8d" decodes to 130 + bias becomes 23 + 4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D + delta "qg" decodes to 154 + bias becomes 25 + 4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D + delta "056p" decodes to 46301 + bias becomes 84 + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 * + delta "qjye" decodes to 88531 + bias becomes 90 + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587 + + Decoding trace of example L from section 7.1: + + n is 128, i is 0, bias is 72 + input is "3B-ww4c5e180e575a65lsy2b" + literal portion is "3B-", so extended string starts as: + 0033 0042 + delta "ww4c" decodes to 62042 + bias becomes 27 + 0033 0042 5148 * + delta "5e" decodes to 139 + bias becomes 24 + 0033 0042 516B * 5148 + delta "180e" decodes to 16683 + bias becomes 67 + 0033 5E74 * 0042 516B 5148 + delta "575a" decodes to 34821 + bias becomes 82 + 0033 5E74 0042 516B 5148 751F * + delta "65l" decodes to 14592 + bias becomes 67 + 0033 5E74 0042 7D44 * 516B 5148 751F + delta "sy2b" decodes to 42088 + bias becomes 84 + 0033 5E74 0042 7D44 91D1 * 516B 5148 751F + +7.3 Encoding traces + + In the following traces, code point values are hexadecimal, while + other numerical values are decimal. + + Encoding trace of example B from section 7.1: + + bias is 72 + input is: + 4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587 + there are no basic code points, so no literal portion + next code point to insert is 4E0D + needed delta is 19853, encodes as "ihq" + bias becomes 21 + next code point to insert is 4E2D + needed delta is 64, encodes as "wc" + bias becomes 20 + next code point to insert is 4E3A + needed delta is 37, encodes as "rb" + bias becomes 13 + next code point to insert is 4E48 + needed delta is 56, encodes as "4c" + bias becomes 17 + next code point to insert is 4EC0 + needed delta is 599, encodes as "v8a" + bias becomes 32 + next code point to insert is 4ED6 + needed delta is 130, encodes as "8d" + bias becomes 23 + next code point to insert is 4EEC + needed delta is 154, encodes as "qg" + bias becomes 25 + next code point to insert is 6587 + needed delta is 46301, encodes as "056p" + bias becomes 84 + next code point to insert is 8BF4 + needed delta is 88531, encodes as "qjye" + bias becomes 90 + output is "ihqwcrb4cv8a8dqg056pqjye" + + Encoding trace of example L from section 7.1: + + bias is 72 + input is: + 0033 5E74 0042 7D44 91D1 516B 5148 751F + basic code points (0033, 0042) are copied to literal portion: "3B-" + next code point to insert is 5148 + needed delta is 62042, encodes as "ww4c" + bias becomes 27 + next code point to insert is 516B + needed delta is 139, encodes as "5e" + bias becomes 24 + next code point to insert is 5E74 + needed delta is 16683, encodes as "180e" + bias becomes 67 + next code point to insert is 751F + needed delta is 34821, encodes as "575a" + bias becomes 82 + next code point to insert is 7D44 + needed delta is 14592, encodes as "65l" + bias becomes 67 + next code point to insert is 91D1 + needed delta is 42088, encodes as "sy2b" + bias becomes 84 + output is "3B-ww4c5e180e575a65lsy2b" + +8. Security considerations + + Users expect each domain name in DNS to be controlled by a single + authority. If a Unicode string intended for use as a domain label + could map to multiple ACE labels, then an internationalized domain + name could map to multiple ASCII domain names, each controlled by + a different authority, some of which could be spoofs that hijack + service requests intended for another. Therefore Punycode is + designed so that each Unicode string has a unique encoding. + + However, there can still be multiple Unicode representations of the + "same" text, for various definitions of "same". This problem is + addressed to some extent by the Unicode standard under the topic of + canonicalization, and this work is leveraged for domain names by + Nameprep [NAMEPREP]. + +9. References (non-normative) + + [ASCII] Vint Cerf, "ASCII format for Network Interchange", + 1969-Oct-16, RFC 20. + + [IDNA] Patrik Faltstrom, Paul Hoffman, Adam M. Costello, + "Internationalizing Domain Names In Applications (IDNA)", + draft-ietf-idn-idna. + + [NAMEPREP] Paul Hoffman, Marc Blanchet, "Nameprep: A + Stringprep Profile for Internationalized Domain Names", + draft-ietf-idn-nameprep. + + [PROVINCIAL] Michael Kaplan, "The 'anyone can be provincial!' page", + http://www.trigeminal.com/samples/provincial.html. + + [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host + Table Specification", 1985-Oct, RFC 952. + + [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", + 1987-Nov, RFC 1034. + + [UNICODE] The Unicode Consortium, "The Unicode Standard", + http://www.unicode.org/unicode/standard/standard.html. + +A. Author contact information + + Adam M. Costello + University of California, Berkeley + http://www.nicemice.net/amc/ + +B. Mixed-case annotation + + In order to use Punycode to represent case-insensitive strings, + higher layers need to case-fold the strings prior to Punycode + encoding. The encoded string can use mixed case as an annotation + telling how to convert the folded string into a mixed-case string + for display purposes. Note, however, that mixed-case annotation + is not used by the ToASCII and ToUnicode operations specified in + [IDNA], and therefore implementors of IDNA can disregard this + appendix. + + Basic code points can use mixed case directly, because the decoder + copies them verbatim, leaving lowercase code points lowercase, and + leaving uppercase code points uppercase. Each non-basic code point + is represented by a delta, which is represented by a sequence of + basic code points, the last of which provides the annotation. If it + is uppercase, it is a suggestion to map the non-basic code point to + uppercase (if possible); if it is lowercase, it is a suggestion to + map the non-basic code point to lowercase (if possible). + + These annotations do not alter the code points returned by decoders; + the annotations are returned separately, for the caller to use or + ignore. Encoders can accept annotations in addition to code points, + but the annotations do not alter the output, except to influence the + uppercase/lowercase form of ASCII letters. + + Punycode encoders and decoders need not support these annotations, + and higher layers need not use them. + +C. Disclaimer and license + + Regarding this entire document or any portion of it (including + the pseudocode and C code), the author makes no guarantees and + is not responsible for any damage resulting from its use. The + author grants irrevocable permission to anyone to use, modify, + and distribute it in any way that does not diminish the rights + of anyone else to use, modify, and distribute it, provided that + redistributed derivative works do not contain misleading author or + version information. Derivative works need not be licensed under + similar terms. + + +D. Punycode sample implementation + +/* +punycode.c from draft-ietf-idn-punycode-03 +http://www.nicemice.net/idn/ +Adam M. Costello +http://www.nicemice.net/amc/ + +This is ANSI C code (C89) implementing +Punycode (draft-ietf-idn-punycode-03). + +*/ + + +/************************************************************/ +/* Public interface (would normally go in its own .h file): */ + +#include + +enum punycode_status { + punycode_success, + punycode_bad_input, /* Input is invalid. */ + punycode_big_output, /* Output would exceed the space provided. */ + punycode_overflow /* Input needs wider integers to process. */ +}; + +#if UINT_MAX >= (1 << 26) - 1 +typedef unsigned int punycode_uint; +#else +typedef unsigned long punycode_uint; +#endif + +enum punycode_status punycode_encode( + punycode_uint input_length, + const punycode_uint input[], + const unsigned char case_flags[], + punycode_uint *output_length, + char output[] ); + + /* punycode_encode() converts Unicode to Punycode. The input */ + /* is represented as an array of Unicode code points (not code */ + /* units; surrogate pairs are not allowed), and the output */ + /* will be represented as an array of ASCII code points. The */ + /* output string is *not* null-terminated; it will contain */ + /* zeros if and only if the input contains zeros. (Of course */ + /* the caller can leave room for a terminator and add one if */ + /* needed.) The input_length is the number of code points in */ + /* the input. The output_length is an in/out argument: the */ + /* caller passes in the maximum number of code points that it */ + /* can receive, and on successful return it will contain the */ + /* number of code points actually output. The case_flags array */ + /* holds input_length boolean values, where nonzero suggests that */ + /* the corresponding Unicode character be forced to uppercase */ + /* after being decoded (if possible), and zero suggests that */ + /* it be forced to lowercase (if possible). ASCII code points */ + /* are encoded literally, except that ASCII letters are forced */ + /* to uppercase or lowercase according to the corresponding */ + /* uppercase flags. If case_flags is a null pointer then ASCII */ + /* letters are left as they are, and other code points are */ + /* treated as if their uppercase flags were zero. The return */ + /* value can be any of the punycode_status values defined above */ + /* except punycode_bad_input; if not punycode_success, then */ + /* output_size and output might contain garbage. */ + +enum punycode_status punycode_decode( + punycode_uint input_length, + const char input[], + punycode_uint *output_length, + punycode_uint output[], + unsigned char case_flags[] ); + + /* punycode_decode() converts Punycode to Unicode. The input is */ + /* represented as an array of ASCII code points, and the output */ + /* will be represented as an array of Unicode code points. The */ + /* input_length is the number of code points in the input. The */ + /* output_length is an in/out argument: the caller passes in */ + /* the maximum number of code points that it can receive, and */ + /* on successful return it will contain the actual number of */ + /* code points output. The case_flags array needs room for at */ + /* least output_length values, or it can be a null pointer if the */ + /* case information is not needed. A nonzero flag suggests that */ + /* the corresponding Unicode character be forced to uppercase */ + /* by the caller (if possible), while zero suggests that it be */ + /* forced to lowercase (if possible). ASCII code points are */ + /* output already in the proper case, but their flags will be set */ + /* appropriately so that applying the flags would be harmless. */ + /* The return value can be any of the punycode_status values */ + /* defined above; if not punycode_success, then output_length, */ + /* output, and case_flags might contain garbage. On success, the */ + /* decoder will never need to write an output_length greater than */ + /* input_length, because of how the encoding is defined. */ + +/**********************************************************/ +/* Implementation (would normally go in its own .c file): */ + +#include + +/*** Bootstring parameters for Punycode ***/ + +enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700, + initial_bias = 72, initial_n = 0x80, delimiter = 0x2D }; + +/* basic(cp) tests whether cp is a basic code point: */ +#define basic(cp) ((punycode_uint)(cp) < 0x80) + +/* delim(cp) tests whether cp is a delimiter: */ +#define delim(cp) ((cp) == delimiter) + +/* decode_digit(cp) returns the numeric value of a basic code */ +/* point (for use in representing integers) in the range 0 to */ +/* base-1, or base if cp is does not represent a value. */ + +static punycode_uint decode_digit(punycode_uint cp) +{ + return cp - 48 < 10 ? cp - 22 : cp - 65 < 26 ? cp - 65 : + cp - 97 < 26 ? cp - 97 : base; +} + +/* encode_digit(d,flag) returns the basic code point whose value */ +/* (when used for representing integers) is d, which needs to be in */ +/* the range 0 to base-1. The lowercase form is used unless flag is */ +/* nonzero, in which case the uppercase form is used. The behavior */ +/* is undefined if flag is nonzero and digit d has no uppercase form. */ + +static char encode_digit(punycode_uint d, int flag) +{ + return d + 22 + 75 * (d < 26) - ((flag != 0) << 5); + /* 0..25 map to ASCII a..z or A..Z */ + /* 26..35 map to ASCII 0..9 */ +} + +/* flagged(bcp) tests whether a basic code point is flagged */ +/* (uppercase). The behavior is undefined if bcp is not a */ +/* basic code point. */ + +#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26) + +/* encode_basic(bcp,flag) forces a basic code point to lowercase */ +/* if flag is zero, uppercase if flag is nonzero, and returns */ +/* the resulting code point. The code point is unchanged if it */ +/* is caseless. The behavior is undefined if bcp is not a basic */ +/* code point. */ + +static char encode_basic(punycode_uint bcp, int flag) +{ + bcp -= (bcp - 97 < 26) << 5; + return bcp + ((!flag && (bcp - 65 < 26)) << 5); +} + +/*** Platform-specific constants ***/ + +/* maxint is the maximum value of a punycode_uint variable: */ +static const punycode_uint maxint = -1; +/* Because maxint is unsigned, -1 becomes the maximum value. */ + +/*** Bias adaptation function ***/ + +static punycode_uint adapt( + punycode_uint delta, punycode_uint numpoints, int firsttime ) +{ + punycode_uint k; + + delta = firsttime ? delta / damp : delta >> 1; + /* delta >> 1 is a faster way of doing delta / 2 */ + delta += delta / numpoints; + + for (k = 0; delta > ((base - tmin) * tmax) / 2; k += base) { + delta /= base - tmin; + } + + return k + (base - tmin + 1) * delta / (delta + skew); +} + +/*** Main encode function ***/ + +enum punycode_status punycode_encode( + punycode_uint input_length, + const punycode_uint input[], + const unsigned char case_flags[], + punycode_uint *output_length, + char output[] ) +{ + punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t; + + /* Initialize the state: */ + + n = initial_n; + delta = out = 0; + max_out = *output_length; + bias = initial_bias; + + /* Handle the basic code points: */ + + for (j = 0; j < input_length; ++j) { + if (basic(input[j])) { + if (max_out - out < 2) return punycode_big_output; + output[out++] = + case_flags ? encode_basic(input[j], case_flags[j]) : input[j]; + } + /* else if (input[j] < n) return punycode_bad_input; */ + /* (not needed for Punycode with unsigned code points) */ + } + + h = b = out; + + /* h is the number of code points that have been handled, b is the */ + /* number of basic code points, and out is the number of characters */ + /* that have been output. */ + + if (b > 0) output[out++] = delimiter; + + /* Main encoding loop: */ + + while (h < input_length) { + /* All non-basic code points < n have been */ + /* handled already. Find the next larger one: */ + + for (m = maxint, j = 0; j < input_length; ++j) { + /* if (basic(input[j])) continue; */ + /* (not needed for Punycode) */ + if (input[j] >= n && input[j] < m) m = input[j]; + } + + /* Increase delta enough to advance the decoder's */ + /* state to , but guard against overflow: */ + + if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow; + delta += (m - n) * (h + 1); + n = m; + + for (j = 0; j < input_length; ++j) { + /* Punycode does not need to check whether input[j] is basic: */ + if (input[j] < n /* || basic(input[j]) */ ) { + if (++delta == 0) return punycode_overflow; + } + + if (input[j] == n) { + /* Represent delta as a generalized variable-length integer: */ + + for (q = delta, k = base; ; k += base) { + if (out >= max_out) return punycode_big_output; + t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ + k >= bias + tmax ? tmax : k - bias; + if (q < t) break; + output[out++] = encode_digit(t + (q - t) % (base - t), 0); + q = (q - t) / (base - t); + } + + output[out++] = encode_digit(q, case_flags && case_flags[j]); + bias = adapt(delta, h + 1, h == b); + delta = 0; + ++h; + } + } + + ++delta, ++n; + } + + *output_length = out; + return punycode_success; +} + +/*** Main decode function ***/ + +enum punycode_status punycode_decode( + punycode_uint input_length, + const char input[], + punycode_uint *output_length, + punycode_uint output[], + unsigned char case_flags[] ) +{ + punycode_uint n, out, i, max_out, bias, + b, j, in, oldi, w, k, digit, t; + + /* Initialize the state: */ + + n = initial_n; + out = i = 0; + max_out = *output_length; + bias = initial_bias; + + /* Handle the basic code points: Let b be the number of input code */ + /* points before the last delimiter, or 0 if there is none, then */ + /* copy the first b code points to the output. */ + + for (b = j = 0; j < input_length; ++j) if (delim(input[j])) b = j; + if (b > max_out) return punycode_big_output; + + for (j = 0; j < b; ++j) { + if (case_flags) case_flags[out] = flagged(input[j]); + if (!basic(input[j])) return punycode_bad_input; + output[out++] = input[j]; + } + + /* Main decoding loop: Start just after the last delimiter if any */ + /* basic code points were copied; start at the beginning otherwise. */ + + for (in = b > 0 ? b + 1 : 0; in < input_length; ++out) { + + /* in is the index of the next character to be consumed, and */ + /* out is the number of code points in the output array. */ + + /* Decode a generalized variable-length integer into delta, */ + /* which gets added to i. The overflow checking is easier */ + /* if we increase i as we go, then subtract off its starting */ + /* value at the end to obtain delta. */ + + for (oldi = i, w = 1, k = base; ; k += base) { + if (in >= input_length) return punycode_bad_input; + digit = decode_digit(input[in++]); + if (digit >= base) return punycode_bad_input; + if (digit > (maxint - i) / w) return punycode_overflow; + i += digit * w; + t = k <= bias /* + tmin */ ? tmin : /* +tmin not needed */ + k >= bias + tmax ? tmax : k - bias; + if (digit < t) break; + if (w > maxint / (base - t)) return punycode_overflow; + w *= (base - t); + } + + bias = adapt(i - oldi, out + 1, oldi == 0); + + /* i was supposed to wrap around from out+1 to 0, */ + /* incrementing n each time, so we'll fix that now: */ + + if (i / (out + 1) > maxint - n) return punycode_overflow; + n += i / (out + 1); + i %= (out + 1); + + /* Insert n at position i of the output: */ + + /* not needed for Punycode: */ + /* if (decode_digit(n) <= base) return punycode_invalid_input; */ + if (out >= max_out) return punycode_big_output; + + if (case_flags) { + memmove(case_flags + i + 1, case_flags + i, out - i); + /* Case of last character determines uppercase flag: */ + case_flags[i] = flagged(input[in - 1]); + } + + memmove(output + i + 1, output + i, (out - i) * sizeof *output); + output[i++] = n; + } + + *output_length = out; + return punycode_success; +} + + +/******************************************************************/ +/* Wrapper for testing (would normally go in a separate .c file): */ + +#include +#include +#include +#include + +/* For testing, we'll just set some compile-time limits rather than */ +/* use malloc(), and set a compile-time option rather than using a */ +/* command-line option. */ + +enum { + unicode_max_length = 256, + ace_max_length = 256 +}; + +static void usage(char **argv) +{ + fprintf(stderr, + "\n" + "%s -e reads code points and writes a Punycode string.\n" + "%s -d reads a Punycode string and writes code points.\n" + "\n" + "Input and output are plain text in the native character set.\n" + "Code points are in the form u+hex separated by whitespace.\n" + "Although the specification allows Punycode strings to contain\n" + "any characters from the ASCII repertoire, this test code\n" + "supports only the printable characters, and needs the Punycode\n" + "string to be followed by a newline.\n" + "The case of the u in u+hex is the force-to-uppercase flag.\n" + , argv[0], argv[0]); + exit(EXIT_FAILURE); +} + + +static void fail(const char *msg) +{ + fputs(msg,stderr); + exit(EXIT_FAILURE); +} + +static const char too_big[] = + "input or output is too large, recompile with larger limits\n"; +static const char invalid_input[] = "invalid input\n"; +static const char overflow[] = "arithmetic overflow\n"; +static const char io_error[] = "I/O error\n"; + + +/* The following string is used to convert printable */ +/* characters between ASCII and the native charset: */ + +static const char print_ascii[] = + "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" + "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n" + " !\"#$%&'()*+,-./" + "0123456789:;<=>?" + "@ABCDEFGHIJKLMNO" + "PQRSTUVWXYZ[\\]^_" + "`abcdefghijklmno" + "pqrstuvwxyz{|}~\n"; + + +int main(int argc, char **argv) +{ + enum punycode_status status; + int r; + unsigned int input_length, output_length, j; + unsigned char case_flags[unicode_max_length]; + + if (argc != 2) usage(argv); + if (argv[1][0] != '-') usage(argv); + if (argv[1][2] != 0) usage(argv); + + if (argv[1][1] == 'e') { + punycode_uint input[unicode_max_length]; + unsigned long codept; + char output[ace_max_length+1], uplus[3]; + int c; + + /* Read the input code points: */ + + input_length = 0; + + for (;;) { + r = scanf("%2s%lx", uplus, &codept); + if (ferror(stdin)) fail(io_error); + if (r == EOF || r == 0) break; + + if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) { + fail(invalid_input); + } + + if (input_length == unicode_max_length) fail(too_big); + + if (uplus[0] == 'u') case_flags[input_length] = 0; + else if (uplus[0] == 'U') case_flags[input_length] = 1; + else fail(invalid_input); + + input[input_length++] = codept; + } + + /* Encode: */ + + output_length = ace_max_length; + status = punycode_encode(input_length, input, case_flags, + &output_length, output); + if (status == punycode_bad_input) fail(invalid_input); + if (status == punycode_big_output) fail(too_big); + if (status == punycode_overflow) fail(overflow); + assert(status == punycode_success); + + /* Convert to native charset and output: */ + + for (j = 0; j < output_length; ++j) { + c = output[j]; + assert(c >= 0 && c <= 127); + if (print_ascii[c] == 0) fail(invalid_input); + output[j] = print_ascii[c]; + } + + output[j] = 0; + r = puts(output); + if (r == EOF) fail(io_error); + return EXIT_SUCCESS; + } + + if (argv[1][1] == 'd') { + char input[ace_max_length+2], *p, *pp; + punycode_uint output[unicode_max_length]; + + /* Read the Punycode input string and convert to ASCII: */ + + fgets(input, ace_max_length+2, stdin); + if (ferror(stdin)) fail(io_error); + if (feof(stdin)) fail(invalid_input); + input_length = strlen(input) - 1; + if (input[input_length] != '\n') fail(too_big); + input[input_length] = 0; + + for (p = input; *p != 0; ++p) { + pp = strchr(print_ascii, *p); + if (pp == 0) fail(invalid_input); + *p = pp - print_ascii; + } + + /* Decode: */ + + output_length = unicode_max_length; + status = punycode_decode(input_length, input, &output_length, + output, case_flags); + if (status == punycode_bad_input) fail(invalid_input); + if (status == punycode_big_output) fail(too_big); + if (status == punycode_overflow) fail(overflow); + assert(status == punycode_success); + + /* Output the result: */ + + for (j = 0; j < output_length; ++j) { + r = printf("%s+%04lX\n", + case_flags[j] ? "U" : "u", + (unsigned long) output[j] ); + if (r < 0) fail(io_error); + } + + return EXIT_SUCCESS; + } + + usage(argv); + return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ +} + + + + INTERNET-DRAFT expires 2003-Apr-08 diff --git a/doc/draft/draft-ietf-idn-uri-03.txt b/doc/draft/draft-ietf-idn-uri-03.txt new file mode 100644 index 0000000000..2d44967a6c --- /dev/null +++ b/doc/draft/draft-ietf-idn-uri-03.txt @@ -0,0 +1,442 @@ + + + + +Network Working Group M. Duerst +Internet-Draft W3C +Expires: May 4, 2003 November 3, 2002 + + + Internationalized Domain Names in URIs + draft-ietf-idn-uri-03 + +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. + + This Internet-Draft will expire on May 4, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document proposes to upgrade the definition of URIs (RFC 2396) + [RFC2396] to work consistently with internationalized domain names. + + + + + + + + + + + + + +Duerst Expires May 4, 2003 [Page 1] +Internet-Draft IDNs in URIs November 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. URI syntax changes . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Security considerations . . . . . . . . . . . . . . . . . . . 5 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 . 5 + 5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 . 5 + 5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 . 5 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Duerst Expires May 4, 2003 [Page 2] +Internet-Draft IDNs in URIs November 2002 + + +1. Introduction + + Internet domain names serve to identify hosts and services on the + Internet in a convenient way. The IETF IDN working group [IDNWG] has + been working on extending the character repertoire usable in domain + names beyond a subset of US-ASCII. + + One of the most important places where domain names appear are + Uniform Resource Identifiers (URIs, [RFC2396], as modified by + [RFC2732]). However, in the current definition of the generic URI + syntax, the restrictions on domain names are 'hard-coded'. In + Section 2, this document relaxes these restrictions by updating the + syntax, and defines how internationalized domain names are encoded in + URIs. + + The syntax in this document has been chosen to further increase the + uniformity of URI syntax, which is a very important principle of + URIs. + + In practice, escaped domain names should be used as rarely as + possible. Wherever possible, the actual characters in + Internationalized Domain Names should be preserved as long as + possible by using IRIs [IRI] rather than URIs, and only converting to + URIs and then to ACE-encoded [IDNA] domain names (or ideally directly + to ACE-encoding without even using URIs) when resolving the IRI. + Also, this document does not exclude the use of ACE encoding directly + in an URI domain name part. ACE encoding may be used directly in an + URI domain name part if this is considered necessary for + interoperability. + + Please note that even with the definition of URIs in [RFC2396], some + URIs can already contain host names with escaped characters. For + example, mailto:example@w%33.org is legal per [RFC2396] because the + mailto: URI scheme does not follow the generic syntax of [RFC2396]. + +2. URI syntax changes + + The syntax of URIs [RFC2396] currently contains the following rules + relevant to domain names: + + hostname = *( domainlabel "." ) toplabel [ "." ] + domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum + toplabel = alpha | alpha *( alphanum | "-" ) alphanum + + + + + + + + +Duerst Expires May 4, 2003 [Page 3] +Internet-Draft IDNs in URIs November 2002 + + + The later two rules are changed as follows: + + domainlabel = anchar | anchar *( anchar | "-" ) anchar + toplabel = achar | achar *( anchar | "-" ) anchar + + and the following rules are added: + + anchar = alphanum | escaped + achar = alpha | escaped + + Characters outside the repertoire (alphanum) are encoded by first + encoding the characters in UTF-8 [RFC 2279], resulting in a sequence + of octets, and then escaping these octets according to the rules + defined in [RFC2396]. + + Using UTF-8 assures that this encoding interoperates with IRIs [IRI]. + It is also aligned with the recommendations in [RFC2277] and + [RFC2718], and is consistent with the URN syntax [RFC2141] as well as + recent URL scheme definitions that define encodings of non-ASCII + characters based on UTF-8 (e.g., IMAP URLs [RFC2192] and POP URLs + [RFC2384]). + + The above syntax rules permit for domain names that are neither + permitted as US-ASCII only domain names nor as internationalized + domain names. However, such domain names should never be used, and + will never be resolved because no such domains will be registered. + For US-ASCII only domain names, the syntax rules in [RFC2396] are + relevant. For example, http://www.w%33.org is legal, because the + corresponding 'w3' is a legal 'domainlabel' according to [RFC2396]. + However, http://%2a.example.org is illegal because the corresponding + '*' is not a legal 'domainlabel' according to [RFC2396]. + + For domain names containing non-ASCII characters, the legal domain + names are those for which the ToASCII operation ([IDNA], [Nameprep]; + using the unescaped UTF-8 values as input), with the flags + "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The + URI resolver MUST apply any steps required as part of domain name + resolution by [IDNA], in particular the ToASCII operation, with the + above-mentioned flags set. URIs where the ToASCII operation results + in an error should be treated as unresolvable. + + For domain names containing non-ASCII characters, the Nameprep + specification ([Nameprep]) defines some mappings, which mainly + include normalization to NFKC and folding to lower case. When + encoding an internationalized domain name in an URI, these mappings + SHOULD NOT be applied. It should be assumed that the domain name is + already normalized as far as appropriate. + + + + +Duerst Expires May 4, 2003 [Page 4] +Internet-Draft IDNs in URIs November 2002 + + + For consistency in comparison operations and for interoperability + with older software, the following should be noted: 1) US-ASCII + characters in domain names should not be escaped. 2) Because of the + principle of syntax uniformity for URIs, it is always more prudent to + take into account the possibility that US-ASCII characters are + escaped. + +3. Security considerations + + The security considerations of [RFC2396] and those applying to + internationalized domain names apply. There may be an increased + potential to smuggle escaped US-ASCII-based domain names across + firewalls, although because of the uniform syntax principle for URIs, + such a potential is already existing. + +4. Acknowledgements + + Erik Nordmark + +5. Change Log + +5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 + + Clarified expectations on name checking. + +5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 + + Moved change log to back + + Changed to only change URIs; IRI syntax updated directly in IRI + draft. + + Removed syntax restriction on %hh in the US-ASCII part, but made + clear that restrictions to domain names apply. + + Made clear that escaped domain names in URIs should only be an + intermediate representation. + + Gave example of mailto: as already allowing escaped host names. + + Corrected some typos. + +5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 + + Changed requirement for URI/IRI resolvers from MUST to SHOULD + + Changed IRI syntax slightly (ichar -> idchar, based on changes in + [IRI]) + + + +Duerst Expires May 4, 2003 [Page 5] +Internet-Draft IDNs in URIs November 2002 + + + Various wording changes + +References + + [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + draft-ietf-idn-idna-14.txt (work in progress), October + 2002, . + + [IDNWG] "IETF Internationalized Domain Name (idn) Working Group". + + [IRI] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRI)", draft-duerst-iri-02.txt (work in + progress), November 2002, . + + [ISO10646] International Organization for Standardization, + "Information Technology - Universal Multiple-Octet Coded + Character Set (UCS) - Part 1: Architecture and Basic + Multilingual Plane", ISO Standard 10646-1, October 2000. + + [Nameprep] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep + Profile for Internationalized Domain Names", draft-ietf- + idn-nameprep-11.txt (work in progress), June 2002, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", BCP 18, RFC 2277, January 1998. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. + + [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, + August 1998. + + [RFC2640] Curtin, B., "Internationalization of the File Transfer + + + +Duerst Expires May 4, 2003 [Page 6] +Internet-Draft IDNs in URIs November 2002 + + + Protocol", RFC 2640, July 1999. + + [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, + "Guidelines for new URL Schemes", RFC 2718, November + 1999. + + [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for + Literal IPv6 Addresses in URL's", RFC 2732, December + 1999. + + +Author's Address + + Martin Duerst + World Wide Web Consortium + 200 Technology Square + Cambridge, MA 02139 + U.S.A. + + Phone: +1 617 253 5509 + Fax: +1 617 258 5999 + EMail: duerst@w3.org + URI: http://www.w3.org/People/D%C3%BCrst/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Duerst Expires May 4, 2003 [Page 7] +Internet-Draft IDNs in URIs November 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Duerst Expires May 4, 2003 [Page 8] diff --git a/doc/draft/draft-ietf-ipngwg-rfc2553bis-10.txt b/doc/draft/draft-ietf-ipngwg-rfc2553bis-10.txt new file mode 100644 index 0000000000..829d72593c --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-rfc2553bis-10.txt @@ -0,0 +1,2045 @@ + +IPNG Working Group R.E. Gilligan +INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-10.txt Cache Flow +Obsoletes RFC 2553 S. Thomson + Cisco + J. Bound + J. McCann + Hewlett-Packard + W. R. Stevens + December 2002 + + + Basic Socket Interface Extensions for IPv6 + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + This document is a submission by the Internet Protocol IPv6 Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ipng@sunroof.eng.sun.com mailing list. + + 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. + + +Abstract + + The de facto standard application program interface (API) for TCP/IP + applications is the "sockets" interface. Although this API was + developed for Unix in the early 1980s it has also been implemented on + a wide variety of non-Unix systems. TCP/IP applications written + using the sockets API have in the past enjoyed a high degree of + portability and we would like the same portability with IPv6 + applications. But changes are required to the sockets API to support + IPv6 and this memo describes these changes. These include a new + socket address structure to carry IPv6 addresses, new address + conversion functions, and some new socket options. These extensions + are designed to provide access to the basic IPv6 features required by + TCP and UDP applications, including multicasting, while introducing a + minimum of change into the system and providing complete + compatibility for existing IPv4 applications. Additional extensions + for advanced IPv6 features (raw sockets and access to the IPv6 + extension headers) are defined in another document [4]. + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 1] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +Table of Contents: + +1. Introduction.................................................3 +2. Design Considerations........................................3 +2.1 What Needs to be Changed....................................4 +2.2 Data Types..................................................5 +2.3 Headers.....................................................5 +2.4 Structures..................................................5 +3. Socket Interface.............................................5 +3.1 IPv6 Address Family and Protocol Family.....................6 +3.2 IPv6 Address Structure......................................6 +3.3 Socket Address Structure for 4.3BSD-Based Systems...........6 +3.4 Socket Address Structure for 4.4BSD-Based Systems...........7 +3.5 The Socket Functions........................................8 +3.6 Compatibility with IPv4 Applications........................9 +3.7 Compatibility with IPv4 Nodes...............................9 +3.8 IPv6 Wildcard Address......................................10 +3.9 IPv6 Loopback Address......................................11 +3.10 Portability Additions.....................................11 +4. Interface Identification....................................13 +4.1 Name-to-Index..............................................14 +4.2 Index-to-Name..............................................14 +4.3 Return All Interface Names and Indexes.....................14 +4.4 Free Memory................................................15 +5. Socket Options..............................................15 +5.1 Unicast Hop Limit..........................................15 +5.2 Sending and Receiving Multicast Packets....................16 +5.3 IPV6_V6ONLY option for AF_INET6 Sockets....................18 +6. Library Functions...........................................18 +6.1 Protocol-Independent Nodename and Service Name Translation.19 +6.2 Socket Address Structure to Node Name and Service Name.....23 +6.3 Address Conversion Functions...............................25 +6.4 Address Testing Macros.....................................26 +7. Summary of New Definitions..................................27 +8. Security Considerations.....................................29 +Changes from RFC 2553..........................................29 +Acknowledgments................................................29 +References.....................................................30 +Authors' Addresses.............................................31 + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 2] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +1. Introduction + +While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits long. +The socket interface makes the size of an IP address quite visible to an +application; virtually all TCP/IP applications for BSD-based systems +have knowledge of the size of an IP address. Those parts of the API +that expose the addresses must be changed to accommodate the larger IPv6 +address size. IPv6 also introduces new features (e.g., traffic class +and flowlabel), some of which must be made visible to applications via +the API. This memo defines a set of extensions to the socket interface +to support the larger address size and new features of IPv6. It defines +"basic" extensions that are of use to a broad range of applications. A +companion document, the "advanced" API [4], covers extensions that are +of use to more specialized applications, examples of which include +routing daemons, and the "ping" and "traceroute" utilities. + +The development of this API was started in 1994 in the IETF IPng working +group. The API has evolved over the years, published first in RFC 2133, +then again in RFC 2553, and reaching its final form in this document. + +As the API matured and stabilized, it was incorporated into the Open +Group's Networking Services (XNS) specification, issue 5.2, which was +subsequently incorporated into a joint Open Group/IEEE/ISO standard [3]. + +Effort has been made to ensure that this document and [3] contain the +same information with regard to the API definitions. However, the +reader should note that this document is for informational purposes +only, and that the official standard specification of the sockets API is +[3]. + +It is expected that any future standardization work on this API would be +done by the Open Group Base Working Group [6]. + +It should also be noted that this document describes only those portions +of the API needed for IPv4 and IPv6 communications. Other potential +uses of the API, for example the use of getaddrinfo() and getnameinfo() +with the AF_UNIX address family, are beyond the scope of this document. + + + +2. Design Considerations + +There are a number of important considerations in designing changes to +this well-worn API: + + - The API changes should provide both source and binary + compatibility for programs written to the original API. That + is, existing program binaries should continue to operate when + run on a system supporting the new API. In addition, existing + applications that are re-compiled and run on a system supporting + the new API should continue to operate. Simply put, the API + changes for IPv6 should not break existing programs. An additional + mechanism for implementations to verify this is to verify the new + symbols are protected by Feature Test Macros as described in [3]. + (Such Feature Test Macros are not defined by this RFC.) + + - The changes to the API should be as small as possible in order + to simplify the task of converting existing IPv4 applications to + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 3] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + IPv6. + + - Where possible, applications should be able to use this + API to interoperate with both IPv6 and IPv4 hosts. Applications + should not need to know which type of host they are + communicating with. + + - IPv6 addresses carried in data structures should be 64-bit + aligned. This is necessary in order to obtain optimum + performance on 64-bit machine architectures. + +Because of the importance of providing IPv4 compatibility in the API, +these extensions are explicitly designed to operate on machines that +provide complete support for both IPv4 and IPv6. A subset of this API +could probably be designed for operation on systems that support only +IPv6. However, this is not addressed in this memo. + + + +2.1 What Needs to be Changed + +The socket interface API consists of a few distinct components: + + - Core socket functions. + + - Address data structures. + + - Name-to-address translation functions. + + - Address conversion functions. + +The core socket functions -- those functions that deal with such things +as setting up and tearing down TCP connections, and sending and +receiving UDP packets -- were designed to be transport independent. +Where protocol addresses are passed as function arguments, they are +carried via opaque pointers. A protocol-specific address data structure +is defined for each protocol that the socket functions support. +Applications must cast pointers to these protocol-specific address +structures into pointers to the generic "sockaddr" address structure +when using the socket functions. These functions need not change for +IPv6, but a new IPv6-specific address data structure is needed. + +The "sockaddr_in" structure is the protocol-specific data structure for +IPv4. This data structure actually includes 8-octets of unused space, +and it is tempting to try to use this space to adapt the sockaddr_in +structure to IPv6. Unfortunately, the sockaddr_in structure is not +large enough to hold the 16-octet IPv6 address as well as the other +information (address family and port number) that is needed. So a new +address data structure must be defined for IPv6. + +IPv6 addresses are scoped [2] so they could be link-local, site, +organization, global, or other scopes at this time undefined. To +support applications that want to be able to identify a set of +interfaces for a specific scope, the IPv6 sockaddr_in structure must +support a field that can be used by an implementation to identify a set +of interfaces identifying the scope for an IPv6 address. + +The IPv4 name-to-address translation functions in the socket interface + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 4] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +are gethostbyname() and gethostbyaddr(). These are left as is, and new +functions are defined which support both IPv4 and IPv6. + +The IPv4 address conversion functions -- inet_ntoa() and inet_addr() -- +convert IPv4 addresses between binary and printable form. These +functions are quite specific to 32-bit IPv4 addresses. We have designed +two analogous functions that convert both IPv4 and IPv6 addresses, and +carry an address type parameter so that they can be extended to other +protocol families as well. + +Finally, a few miscellaneous features are needed to support IPv6. A new +interface is needed to support the IPv6 hop limit header field. New +socket options are needed to control the sending and receiving of IPv6 +multicast packets. + +The socket interface will be enhanced in the future to provide access to +other IPv6 features. Some of these extensions are described in [4]. + + + + +2.2 Data Types + +The data types of the structure elements given in this memo are intended +to track the relevant standards. uintN_t means an unsigned integer of +exactly N bits (e.g., uint16_t). The sa_family_t and in_port_t types +are defined in [3]. + + + +2.3 Headers + +When function prototypes and structures are shown we show the headers +that must be #included to cause that item to be defined. + + + +2.4 Structures + +When structures are described the members shown are the ones that must +appear in an implementation. Additional, nonstandard members may also +be defined by an implementation. As an additional precaution +nonstandard members could be verified by Feature Test Macros as +described in [3]. (Such Feature Test Macros are not defined by this +RFC.) + +The ordering shown for the members of a structure is the recommended +ordering, given alignment considerations of multibyte members, but an +implementation may order the members differently. + + + +3. Socket Interface + +This section specifies the socket interface changes for IPv6. + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 5] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +3.1 IPv6 Address Family and Protocol Family + +A new address family name, AF_INET6, is defined in . The +AF_INET6 definition distinguishes between the original sockaddr_in +address data structure, and the new sockaddr_in6 data structure. + +A new protocol family name, PF_INET6, is defined in . +Like most of the other protocol family names, this will usually be +defined to have the same value as the corresponding address family name: + + #define PF_INET6 AF_INET6 + +The AF_INET6 is used in the first argument to the socket() function to +indicate that an IPv6 socket is being created. + + + +3.2 IPv6 Address Structure + +A new in6_addr structure holds a single IPv6 address and is defined as a +result of including : + + struct in6_addr { + uint8_t s6_addr[16]; /* IPv6 address */ + }; + +This data structure contains an array of sixteen 8-bit elements, which +make up one 128-bit IPv6 address. The IPv6 address is stored in network +byte order. + +The structure in6_addr above is usually implemented with an embedded +union with extra fields that force the desired alignment level in a +manner similar to BSD implementations of "struct in_addr". Those +additional implementation details are omitted here for simplicity. + +An example is as follows: + +struct in6_addr { + union { + uint8_t _S6_u8[16]; + uint32_t _S6_u32[4]; + uint64_t _S6_u64[2]; + } _S6_un; +}; +#define s6_addr _S6_un._S6_u8 + + + +3.3 Socket Address Structure for 4.3BSD-Based Systems + +In the socket interface, a different protocol-specific data structure is +defined to carry the addresses for each protocol suite. Each protocol- +specific data structure is designed so it can be cast into a protocol- +independent data structure -- the "sockaddr" structure. Each has a +"family" field that overlays the "sa_family" of the sockaddr data +structure. This field identifies the type of the data structure. + +The sockaddr_in structure is the protocol-specific address data + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 6] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + +structure for IPv4. It is used to pass addresses between applications +and the system in the socket functions. The following sockaddr_in6 +structure holds IPv6 addresses and is defined as a result of including +the header: + + struct sockaddr_in6 { + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +This structure is designed to be compatible with the sockaddr data +structure used in the 4.3BSD release. + +The sin6_family field identifies this as a sockaddr_in6 structure. This +field overlays the sa_family field when the buffer is cast to a sockaddr +data structure. The value of this field must be AF_INET6. + +The sin6_port field contains the 16-bit UDP or TCP port number. This +field is used in the same way as the sin_port field of the sockaddr_in +structure. The port number is stored in network byte order. + +The sin6_flowinfo field is a 32-bit field intended to contain flow- +related information. The exact way this field is mapped to or from a +packet is not currently specified. Until such time as its use is +specified, applications should set this field to zero when constructing +a sockaddr_in6, and ignore this field in a sockaddr_in6 structure +constructed by the system. + +The sin6_addr field is a single in6_addr structure (defined in the +previous section). This field holds one 128-bit IPv6 address. The +address is stored in network byte order. + +The ordering of elements in this structure is specifically designed so +that when sin6_addr field is aligned on a 64-bit boundary, the start of +the structure will also be aligned on a 64-bit boundary. This is done +for optimum performance on 64-bit architectures. + +The sin6_scope_id field is a 32-bit integer that identifies a set of +interfaces as appropriate for the scope [2] of the address carried in +the sin6_addr field. The mapping of sin6_scope_id to an interface or +set of interfaces is left to implementation and future specifications on +the subject of scoped addresses. + +Notice that the sockaddr_in6 structure will normally be larger than the +generic sockaddr structure. On many existing implementations the +sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both +being 16 bytes. Any existing code that makes this assumption needs to +be examined carefully when converting to IPv6. + + +3.4 Socket Address Structure for 4.4BSD-Based Systems + +The 4.4BSD release includes a small, but incompatible change to the +socket interface. The "sa_family" field of the sockaddr data structure +was changed from a 16-bit value to an 8-bit value, and the space saved +used to hold a length field, named "sa_len". The sockaddr_in6 data +structure given in the previous section cannot be correctly cast into + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 7] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +the newer sockaddr data structure. For this reason, the following +alternative IPv6 address data structure is provided to be used on +systems based on 4.4BSD. It is defined as a result of including the + header. + + struct sockaddr_in6 { + uint8_t sin6_len; /* length of this struct */ + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +The only differences between this data structure and the 4.3BSD variant +are the inclusion of the length field, and the change of the family +field to a 8-bit data type. The definitions of all the other fields are +identical to the structure defined in the previous section. + +Systems that provide this version of the sockaddr_in6 data structure +must also declare SIN6_LEN as a result of including the +header. This macro allows applications to determine whether they are +being built on a system that supports the 4.3BSD or 4.4BSD variants of +the data structure. + + + +3.5 The Socket Functions + +Applications call the socket() function to create a socket descriptor +that represents a communication endpoint. The arguments to the socket() +function tell the system which protocol to use, and what format address +structure will be used in subsequent functions. For example, to create +an IPv4/TCP socket, applications make the call: + + s = socket(AF_INET, SOCK_STREAM, 0); + +To create an IPv4/UDP socket, applications make the call: + + s = socket(AF_INET, SOCK_DGRAM, 0); + +Applications may create IPv6/TCP and IPv6/UDP sockets (which may also +handle IPv4 communication as described in section 3.7) by simply using +the constant AF_INET6 instead of AF_INET in the first argument. For +example, to create an IPv6/TCP socket, applications make the call: + + s = socket(AF_INET6, SOCK_STREAM, 0); + +To create an IPv6/UDP socket, applications make the call: + + s = socket(AF_INET6, SOCK_DGRAM, 0); + +Once the application has created a AF_INET6 socket, it must use the +sockaddr_in6 address structure when passing addresses in to the system. +The functions that the application uses to pass addresses into the +system are: + + bind() + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 8] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + connect() + sendmsg() + sendto() + +The system will use the sockaddr_in6 address structure to return +addresses to applications that are using AF_INET6 sockets. The +functions that return an address from the system to an application are: + + accept() + recvfrom() + recvmsg() + getpeername() + getsockname() + +No changes to the syntax of the socket functions are needed to support +IPv6, since all of the "address carrying" functions use an opaque +address pointer, and carry an address length as a function argument. + + + +3.6 Compatibility with IPv4 Applications + +In order to support the large base of applications using the original +API, system implementations must provide complete source and binary +compatibility with the original API. This means that systems must +continue to support AF_INET sockets and the sockaddr_in address +structure. Applications must be able to create IPv4/TCP and IPv4/UDP +sockets using the AF_INET constant in the socket() function, as +described in the previous section. Applications should be able to hold +a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets +simultaneously within the same process. + +Applications using the original API should continue to operate as they +did on systems supporting only IPv4. That is, they should continue to +interoperate with IPv4 nodes. + + + +3.7 Compatibility with IPv4 Nodes + +The API also provides a different type of compatibility: the ability for +IPv6 applications to interoperate with IPv4 applications. This feature +uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing +architecture specification [2]. This address format allows the IPv4 +address of an IPv4 node to be represented as an IPv6 address. The IPv4 +address is encoded into the low-order 32 bits of the IPv6 address, and +the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- +mapped addresses are written as follows: + + ::FFFF: + +These addresses can be generated automatically by the getaddrinfo() +function, as described in Section 6.1. + +Applications may use AF_INET6 sockets to open TCP connections to IPv4 +nodes, or send UDP packets to IPv4 nodes, by simply encoding the +destination's IPv4 address as an IPv4-mapped IPv6 address, and passing +that address, within a sockaddr_in6 structure, in the connect() or + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 9] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +sendto() call. When applications use AF_INET6 sockets to accept TCP +connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the +system returns the peer's address to the application in the accept(), +recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded +this way. + +Few applications will likely need to know which type of node they are +interoperating with. However, for those applications that do need to +know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is +provided. + + + +3.8 IPv6 Wildcard Address + +While the bind() function allows applications to select the source IP +address of UDP packets and TCP connections, applications often want the +system to select the source address for them. With IPv4, one specifies +the address as the symbolic constant INADDR_ANY (called the "wildcard" +address) in the bind() call, or simply omits the bind() entirely. + +Since the IPv6 address type is a structure (struct in6_addr), a symbolic +constant can be used to initialize an IPv6 address variable, but cannot +be used in an assignment. Therefore systems provide the IPv6 wildcard +address in two forms. + +The first version is a global variable named "in6addr_any" that is an +in6_addr structure. The extern declaration for this variable is defined +in : + + extern const struct in6_addr in6addr_any; + +Applications use in6addr_any similarly to the way they use INADDR_ANY in +IPv4. For example, to bind a socket to port number 23, but let the +system select the source address, an application could use the following +code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_any; /* structure assignment */ + . . . + if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The other version is a symbolic constant named IN6ADDR_ANY_INIT and is +defined in . This constant can be used to initialize an +in6_addr structure: + + struct in6_addr anyaddr = IN6ADDR_ANY_INIT; + +Note that this constant can be used ONLY at declaration time. It can +not be used to assign a previously declared in6_addr structure. For +example, the following code will not work: + + /* This is the WRONG way to assign an unspecified address */ + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 10] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ + +Be aware that the IPv4 INADDR_xxx constants are all defined in host byte +order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx +externals are defined in network byte order. + + + +3.9 IPv6 Loopback Address + +Applications may need to send UDP packets to, or originate TCP +connections to, services residing on the local node. In IPv4, they can +do this by using the constant IPv4 address INADDR_LOOPBACK in their +connect(), sendto(), or sendmsg() call. + +IPv6 also provides a loopback address to contact local TCP and UDP +services. Like the unspecified address, the IPv6 loopback address is +provided in two forms -- a global variable and a symbolic constant. + +The global variable is an in6_addr structure named "in6addr_loopback." +The extern declaration for this variable is defined in : + + extern const struct in6_addr in6addr_loopback; + +Applications use in6addr_loopback as they would use INADDR_LOOPBACK in +IPv4 applications (but beware of the byte ordering difference mentioned +at the end of the previous section). For example, to open a TCP +connection to the local telnet server, an application could use the +following code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_loopback; /* structure assignment */ + . . . + if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in +. It can be used at declaration time ONLY; for example: + + struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; + +Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to +a previously declared IPv6 address variable. + + + +3.10 Portability Additions + +One simple addition to the sockets API that can help application writers +is the "struct sockaddr_storage". This data structure can simplify +writing code that is portable across multiple address families and +platforms. This data structure is designed with the following goals. + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 11] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + - Large enough to accommodate all supported protocol-specific address + structures. + + - Aligned at an appropriate boundary so that pointers to it can be cast + as pointers to protocol specific address structures and used to + access the fields of those structures without alignment problems. + + +The sockaddr_storage structure contains field ss_family which is of type +sa_family_t. When a sockaddr_storage structure is cast to a sockaddr +structure, the ss_family field of the sockaddr_storage structure maps +onto the sa_family field of the sockaddr structure. When a +sockaddr_storage structure is cast as a protocol specific address +structure, the ss_family field maps onto a field of that structure that +is of type sa_family_t and that identifies the protocol's address +family. + +An example implementation design of such a data structure would be as +follows. + +/* + * Desired design of maximum size and alignment + */ +#define _SS_MAXSIZE 128 /* Implementation specific max size */ +#define _SS_ALIGNSIZE (sizeof (int64_t)) + /* Implementation specific desired alignment */ +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_family */ + /* __ss_pad1, __ss_align fields is 112 */ +}; + +The above example implementation illustrates a data structure which will +align on a 64-bit boundary. An implementation-specific field +"__ss_align" along with "__ss_pad1" is used to force a 64-bit alignment +which covers proper alignment good enough for the needs of sockaddr_in6 +(IPv6), sockaddr_in (IPv4) address data structures. The size of padding +field __ss_pad1 depends on the chosen alignment boundary. The size of +padding field __ss_pad2 depends on the value of overall size chosen for +the total size of the structure. This size and alignment are represented +in the above example by implementation specific (not required) constants +_SS_MAXSIZE (chosen value 128) and _SS_ALIGNSIZE (with chosen value 8). +Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 12] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +112) are also for illustration and not required. The derived values +assume sa_family_t is 2 bytes. The implementation specific definitions +and structure field names above start with an underscore to denote +implementation private namespace. Portable code is not expected to +access or reference those fields or constants. + +On implementations where the sockaddr data structure includes a "sa_len" +field this data structure would look like this: + +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + uint8_t ss_len; /* address length */ + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_len, */ + /* __ss_family, __ss_pad1, __ss_align fields is 112 */ +}; + + + +4. Interface Identification + +This API uses an interface index (a small positive integer) to identify +the local interface on which a multicast group is joined (Section 5.3). +Additionally, the advanced API [4] uses these same interface indexes to +identify the interface on which a datagram is received, or to specify +the interface on which a datagram is to be sent. + +Interfaces are normally known by names such as "le0", "sl1", "ppp2", and +the like. On Berkeley-derived implementations, when an interface is +made known to the system, the kernel assigns a unique positive integer +value (called the interface index) to that interface. These are small +positive integers that start at 1. (Note that 0 is never used for an +interface index.) There may be gaps so that there is no current +interface for a particular positive interface index. + +This API defines two functions that map between an interface name and +index, a third function that returns all the interface names and +indexes, and a fourth function to return the dynamic memory allocated by +the previous function. How these functions are implemented is left up +to the implementation. 4.4BSD implementations can implement these +functions using the existing sysctl() function with the NET_RT_IFLIST +command. Other implementations may wish to use ioctl() for this + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 13] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +purpose. + + + +4.1 Name-to-Index + +The first function maps an interface name into its corresponding index. + + #include + + unsigned int if_nametoindex(const char *ifname); + +If ifname is the name of an interface, the if_nametoindex() function +shall return the interface index corresponding to name ifname; +otherwise, it shall return zero. No errors are defined. + + + +4.2 Index-to-Name + +The second function maps an interface index into its corresponding name. + + #include + + char *if_indextoname(unsigned int ifindex, char *ifname); + +When this function is called, the ifname argument shall point to a +buffer of at least IF_NAMESIZE bytes. The function shall place in this +buffer the name of the interface with index ifindex. (IF_NAMESIZE is +also defined in and its value includes a terminating null +byte at the end of the interface name.) If ifindex is an interface +index, then the function shall return the value supplied in ifname, +which points to a buffer now containing the interface name. Otherwise, +the function shall return a NULL pointer and set errno to indicate the +error. If there is no interface corresponding to the specified index, +errno is set to ENXIO. If there was a system error (such as running out +of memory), errno would be set to the proper value (e.g., ENOMEM). + + + +4.3 Return All Interface Names and Indexes + +The if_nameindex structure holds the information about a single +interface and is defined as a result of including the header. + + struct if_nameindex { + unsigned int if_index; /* 1, 2, ... */ + char *if_name; /* null terminated name: "le0", ... */ + }; + +The final function returns an array of if_nameindex structures, one +structure per interface. + + #include + + struct if_nameindex *if_nameindex(void); + +The end of the array of structures is indicated by a structure with an + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 14] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +if_index of 0 and an if_name of NULL. The function returns a NULL +pointer upon an error, and would set errno to the appropriate value. + +The memory used for this array of structures along with the interface +names pointed to by the if_name members is obtained dynamically. This +memory is freed by the next function. + + + +4.4 Free Memory + +The following function frees the dynamic memory that was allocated by +if_nameindex(). + + #include + + void if_freenameindex(struct if_nameindex *ptr); + +The ptr argument shall be a pointer that was returned by if_nameindex(). +After if_freenameindex() has been called, the application shall not use +the array of which ptr is the address. + + + +5. Socket Options + +A number of new socket options are defined for IPv6. All of these new +options are at the IPPROTO_IPV6 level. That is, the "level" parameter +in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using +these options. The constant name prefix IPV6_ is used in all of the new +socket options. This serves to clearly identify these options as +applying to IPv6. + +The declaration for IPPROTO_IPV6, the new IPv6 socket options, and +related constants defined in this section are obtained by including the +header . + + + +5.1 Unicast Hop Limit + +A new setsockopt() option controls the hop limit used in outgoing +unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and +it is used at the IPPROTO_IPV6 layer. The following example illustrates +how it is used: + + int hoplimit = 10; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, sizeof(hoplimit)) == -1) + perror("setsockopt IPV6_UNICAST_HOPS"); + +When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option +value given is used as the hop limit for all subsequent unicast packets +sent via that socket. If the option is not set, the system selects a +default value. The integer hop limit value (called x) is interpreted as +follows: + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 15] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + +The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine +the hop limit value that the system will use for subsequent unicast +packets sent via that socket. For example: + + int hoplimit; + socklen_t len = sizeof(hoplimit); + + if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, &len) == -1) + perror("getsockopt IPV6_UNICAST_HOPS"); + else + printf("Using %d for hop limit.\n", hoplimit); + + + +5.2 Sending and Receiving Multicast Packets + +IPv6 applications may send multicast packets by simply specifying an +IPv6 multicast address as the destination address, for example in the +destination address argument of the sendto() function. + +Three socket options at the IPPROTO_IPV6 layer control some of the +parameters for sending multicast packets. Setting these options is not +required: applications may send multicast packets without using these +options. The setsockopt() options for controlling the sending of +multicast packets are summarized below. These three options can also be +used with getsockopt(). + + IPV6_MULTICAST_IF + + Set the interface to use for outgoing multicast packets. + The argument is the index of the interface to use. + If the interface index is specified as zero, the system + selects the interface (for example, by looking up the + address in a routing table and using the resulting interface). + + Argument type: unsigned int + + IPV6_MULTICAST_HOPS + + Set the hop limit to use for outgoing multicast packets. + (Note a separate option - IPV6_UNICAST_HOPS - is + provided to set the hop limit to use for outgoing + unicast packets.) + + The interpretation of the argument is the same + as for the IPV6_UNICAST_HOPS option: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 16] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + If IPV6_MULTICAST_HOPS is not set, the default is 1 + (same as IPv4 today) + + Argument type: int + + IPV6_MULTICAST_LOOP + + If a multicast datagram is sent to a group to which the sending host + itself belongs (on the outgoing interface), a copy of the datagram is + looped back by the IP layer for local delivery if this option is set to + 1. If this option is set to 0 a copy is not looped back. Other option + values return an error of EINVAL. + + If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as + IPv4 today). + + Argument type: unsigned int + +The reception of multicast packets is controlled by the two setsockopt() +options summarized below. An error of EOPNOTSUPP is returned if these +two options are used with getsockopt(). + + IPV6_JOIN_GROUP + + Join a multicast group on a specified local interface. + If the interface index is specified as 0, + the kernel chooses the local interface. + For example, some kernels look up the multicast group + in the normal IPv6 routing table and use the resulting interface. + + Argument type: struct ipv6_mreq + + IPV6_LEAVE_GROUP + + Leave a multicast group on a specified interface. + If the interface index is specified as 0, the system + may choose a multicast group membership to drop by + matching the multicast address only. + + Argument type: struct ipv6_mreq + +The argument type of both of these options is the ipv6_mreq structure, +defined as a result of including the header; + + struct ipv6_mreq { + struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ + unsigned int ipv6mr_interface; /* interface index */ + }; + +Note that to receive multicast datagrams a process must join the +multicast group to which datagrams will be sent. UDP applications must +also bind the UDP port to which datagrams will be sent. Some processes +also bind the multicast group address to the socket, in addition to the +port, to prevent other datagrams destined to that same port from being +delivered to the socket. + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 17] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +5.3 IPV6_V6ONLY option for AF_INET6 Sockets + +This socket option restricts AF_INET6 sockets to IPv6 communications +only. As stated in section <3.7 Compatibility with IPv4 Nodes>, +AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some +applications may want to restrict their use of an AF_INET6 socket to +IPv6 communications only. For these applications the IPV6_V6ONLY socket +option is defined. When this option is turned on, the socket can be +used to send and receive IPv6 packets only. This is an IPPROTO_IPV6 +level option. This option takes an int value. This is a boolean +option. By default this option is turned off. + + Here is an example of setting this option: + + int on = 1; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, + (char *)&on, sizeof(on)) == -1) + perror("setsockopt IPV6_V6ONLY"); + else + printf("IPV6_V6ONLY set\n"); + +Note - This option has no effect on the use of IPv4 Mapped addresses +which enter a node as a valid IPv6 addresses for IPv6 communications as +defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5]. + +An example use of this option is to allow two versions of the same +server process to run on the same port, one providing service over IPv6, +the other providing the same service over IPv4. + + + + +6. Library Functions + +New library functions are needed to perform a variety of operations with +IPv6 addresses. Functions are needed to lookup IPv6 addresses in the +Domain Name System (DNS). Both forward lookup (nodename-to-address +translation) and reverse lookup (address-to-nodename translation) need +to be supported. Functions are also needed to convert IPv6 addresses +between their binary and textual form. + +We note that the two existing functions, gethostbyname() and +gethostbyaddr(), are left as-is. New functions are defined to handle +both IPv4 and IPv6 addresses. + +The commonly used function gethostbyname() is inadequate for many +applications, first because it provides no way for the caller to specify +anything about the types of addresses desired (IPv4 only, IPv6 only, +IPv4-mapped IPv6 are OK, etc.), and second because many implementations +of this function are not thread safe. RFC 2133 defined a function named +gethostbyname2() but this function was also inadequate, first because +its use required setting a global option (RES_USE_INET6) when IPv6 +addresses were required, and second because a flag argument is needed to +provide the caller with additional control over the types of addresses +required. The gethostbyname2() function was deprecated in RFC 2553 and +is no longer part of the basic API. + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 18] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +6.1 Protocol-Independent Nodename and Service Name Translation + +Nodename-to-address translation is done in a protocol-independent +fashion using the getaddrinfo() function. + + #include + #include + + + int getaddrinfo(const char *nodename, const char *servname, + const struct addrinfo *hints, struct addrinfo **res); + + void freeaddrinfo(struct addrinfo *ai); + + struct addrinfo { + int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */ + int ai_family; /* AF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + socklen_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for nodename */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ + }; + + The getaddrinfo() function translates the name of a service location + (for example, a host name) and/or a service name and returns a set of + socket addresses and associated information to be used in creating a + socket with which to address the specified service. + + The nodename and servname arguments are either null pointers or + pointers to null-terminated strings. One or both of these two + arguments must be a non-null pointer. + + The format of a valid name depends on the address family or families. + If a specific family is not given and the name could be interpreted + as valid within multiple supported families, the implementation will + attempt to resolve the name in all supported families and, in absence + of errors, one or more results shall be returned. + + If the nodename argument is not null, it can be a descriptive name or + can be an address string. If the specified address family is AF_INET, + AF_INET6, or AF_UNSPEC, valid descriptive names include host names. + If the specified address family is AF_INET or AF_UNSPEC, address + strings using Internet standard dot notation as specified in + inet_addr() are valid. If the specified address family is AF_INET6 + or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are + valid. + + If nodename is not null, the requested service location is named by + nodename; otherwise, the requested service location is local to the + caller. + + If servname is null, the call shall return network-level addresses + for the specified nodename. If servname is not null, it is a null- + terminated character string identifying the requested service. This + can be either a descriptive name or a numeric representation suitable + for use with the address family or families. If the specified address + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 19] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be + specified as a string specifying a decimal port number. + + If the argument hints is not null, it refers to a structure + containing input values that may direct the operation by providing + options and by limiting the returned information to a specific socket + type, address family and/or protocol. In this hints structure every + member other than ai_flags, ai_family, ai_socktype and ai_protocol + shall be set to zero or a null pointer. A value of AF_UNSPEC for + ai_family means that the caller shall accept any address family. A + value of zero for ai_socktype means that the caller shall accept any + socket type. A value of zero for ai_protocol means that the caller + shall accept any protocol. If hints is a null pointer, the behavior + shall be as if it referred to a structure containing the value zero + for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC + for the ai_family field. + + Note: + + 1. If the caller handles only TCP and not UDP, for example, then the + ai_protocol member of the hints structure should be set to + IPPROTO_TCP when getaddrinfo() is called. + + 2. If the caller handles only IPv4 and not IPv6, then the ai_family + member of the hints structure should be set to AF_INET when + getaddrinfo() is called. + + The ai_flags field to which hints parameter points shall be set to + zero or be the bitwise-inclusive OR of one or more of the values + AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, + AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. + + If the AI_PASSIVE flag is specified, the returned address information + shall be suitable for use in binding a socket for accepting incoming + connections for the specified service (i.e. a call to bind()). In + this case, if the nodename argument is null, then the IP address + portion of the socket address structure shall be set to INADDR_ANY + for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the + AI_PASSIVE flag is not specified, the returned address information + shall be suitable for a call to connect() (for a connection-mode + protocol) or for a call to connect(), sendto() or sendmsg() (for a + connectionless protocol). In this case, if the nodename argument is + null, then the IP address portion of the socket address structure + shall be set to the loopback address. This flag is ignored if the + nodename argument is not null. + + If the AI_CANONNAME flag is specified and the nodename argument is + not null, the function shall attempt to determine the canonical name + corresponding to nodename (for example, if nodename is an alias or + shorthand notation for a complete name). + + If the AI_NUMERICHOST flag is specified, then a non-null nodename + string supplied shall be a numeric host address string. Otherwise, an + [EAI_NONAME] error is returned. This flag shall prevent any type of + name resolution service (for example, the DNS) from being invoked. + + If the AI_NUMERICSERV flag is specified, then a non-null servname + string supplied shall be a numeric port string. Otherwise, an + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 20] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + [EAI_NONAME] error shall be returned. This flag shall prevent any + type of name resolution service (for example, NIS+) from being + invoked. + + If the AI_V4MAPPED flag is specified along with an ai_family of + AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses + on finding no matching IPv6 addresses (ai_addrlen shall be 16). + + For example, when using the DNS, if no AAAA records are found + then a query is made for A records and any found are returned as + IPv4-mapped IPv6 addresses. + + The AI_V4MAPPED flag shall be ignored unless ai_family equals + AF_INET6. + + If the AI_ALL flag is used with the AI_V4MAPPED flag, then + getaddrinfo() shall return all matching IPv6 and IPv4 addresses. + + For example, when using the DNS, queries are made for both AAAA + records and A records, and getaddrinfo() returns the combined + results of both queries. Any IPv4 addresses found are returned + as IPv4-mapped IPv6 addresses. + + The AI_ALL flag without the AI_V4MAPPED flag is ignored. + + Note: + + When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and + AI_ALL flags will only be used if AF_INET6 is supported. + + If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be + returned only if an IPv4 address is configured on the local system, + and IPv6 addresses shall be returned only if an IPv6 address is + configured on the local system. The loopback address is not + considered for this case as valid as a configured address. + + For example, when using the DNS, a query for AAAA records + should occur only if the node has at least one IPv6 address + configured (other than IPv6 loopback) and a query for A records + should occur only if the node has at least one IPv4 address + configured (other than the IPv4 loopback). + + The ai_socktype field to which argument hints points specifies the + socket type for the service, as defined for socket(). If a specific + socket type is not given (for example, a value of zero) and the + service name could be interpreted as valid with multiple supported + socket types, the implementation shall attempt to resolve the service + name for all supported socket types and, in the absence of errors, + all possible results shall be returned. A non-zero socket type value + shall limit the returned information to values with the specified + socket type. + + If the ai_family field to which hints points has the value AF_UNSPEC, + addresses shall be returned for use with any address family that can + be used with the specified nodename and/or servname. Otherwise, + addresses shall be returned for use only with the specified address + family. If ai_family is not AF_UNSPEC and ai_protocol is not zero, + then addresses are returned for use only with the specified address + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 21] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + family and protocol; the value of ai_protocol shall be interpreted as + in a call to the socket() function with the corresponding values of + ai_family and ai_protocol . + + The freeaddrinfo() function frees one or more addrinfo structures + returned by getaddrinfo(), along with any additional storage + associated with those structures (for example, storage pointed to by + the ai_canonname and ai_addr fields; an application must not + reference this storage after the associated addrinfo structure has + been freed). If the ai_next field of the structure is not null, the + entire list of structures is freed. The freeaddrinfo() function must + support the freeing of arbitrary sublists of an addrinfo list + originally returned by getaddrinfo(). + + Functions getaddrinfo() and freeaddrinfo() must be thread-safe. + + A zero return value for getaddrinfo() indicates successful + completion; a non-zero return value indicates failure. The possible + values for the failures are listed below under Error Return Values. + + Upon successful return of getaddrinfo(), the location to which res + points shall refer to a linked list of addrinfo structures, each of + which shall specify a socket address and information for use in + creating a socket with which to use that socket address. The list + shall include at least one addrinfo structure. The ai_next field of + each structure contains a pointer to the next structure on the list, + or a null pointer if it is the last structure on the list. Each + structure on the list shall include values for use with a call to the + socket() function, and a socket address for use with the connect() + function or, if the AI_PASSIVE flag was specified, for use with the + bind() function. The fields ai_family, ai_socktype, and ai_protocol + shall be usable as the arguments to the socket() function to create a + socket suitable for use with the returned address. The fields ai_addr + and ai_addrlen are usable as the arguments to the connect() or bind() + functions with such a socket, according to the AI_PASSIVE flag. + + If nodename is not null, and if requested by the AI_CANONNAME flag, + the ai_canonname field of the first returned addrinfo structure shall + point to a null-terminated string containing the canonical name + corresponding to the input nodename; if the canonical name is not + available, then ai_canonname shall refer to the nodename argument or + a string with the same contents. The contents of the ai_flags field + of the returned structures are undefined. + + All fields in socket address structures returned by getaddrinfo() + that are not filled in through an explicit argument (for example, + sin6_flowinfo) shall be set to zero. + + Note: This makes it easier to compare socket address structures. + + Error Return Values: + + The getaddrinfo() function shall fail and return the corresponding + value if: + + [EAI_AGAIN] The name could not be resolved at this time. Future + attempts may succeed. + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 22] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + [EAI_BADFLAGS] The flags parameter had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred when attempting to + resolve the name. + + [EAI_FAMILY] The address family was not recognized. + + [EAI_MEMORY] There was a memory allocation failure when trying to + allocate storage for the return value. + + [EAI_NONAME] The name does not resolve for the supplied parameters. + Neither nodename nor servname were supplied. At least one + of these must be supplied. + + [EAI_SERVICE] The service passed was not recognized for the specified + socket type. + + [EAI_SOCKTYPE] The intended socket type was not recognized. + + [EAI_SYSTEM] A system error occurred; the error code can be found in + errno. + +The gai_strerror() function provides a descriptive text string +corresponding to an EAI_xxx error value. + + + #include + + const char *gai_strerror(int ecode); + +The argument is one of the EAI_xxx values defined for the getaddrinfo() +and getnameinfo() functions. The return value points to a string +describing the error. If the argument is not one of the EAI_xxx values, +the function still returns a pointer to a string whose contents indicate +an unknown error. + + + +6.2 Socket Address Structure to Node Name and Service Name + +The getnameinfo() function is used to translate the contents of a socket +address structure to a node name and/or service name. + + #include + #include + + int getnameinfo(const struct sockaddr *sa, socklen_t salen, + char *node, socklen_t nodelen, + char *service, socklen_t servicelen, + int flags); + +The getnameinfo() function shall translate a socket address to a node +name and service location, all of which are defined as in getaddrinfo(). + +The sa argument points to a socket address structure to be translated. + +The salen argument holds the size of the socket address structure +pointed to by sa. + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 23] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +If the socket address structure contains an IPv4-mapped IPv6 address or +an IPv4-compatible IPv6 address, the implementation shall extract the +embedded IPv4 address and lookup the node name for that IPv4 address. + + Note: The IPv6 unspecified address ("::") and the IPv6 + loopback address ("::1") are not IPv4-compatible addresses. + If the address is the IPv6 unspecified address ("::"), a + lookup is not performed, and the [EAI_NONAME] error is returned. + +If the node argument is non-NULL and the nodelen argument is nonzero, +then the node argument points to a buffer able to contain up to nodelen +characters that receives the node name as a null-terminated string. If +the node argument is NULL or the nodelen argument is zero, the node name +shall not be returned. If the node's name cannot be located, the numeric +form of the node's address is returned instead of its name. + +If the service argument is non-NULL and the servicelen argument is non- +zero, then the service argument points to a buffer able to contain up to +servicelen bytes that receives the service name as a null-terminated +string. If the service argument is NULL or the servicelen argument is +zero, the service name shall not be returned. If the service's name +cannot be located, the numeric form of the service address (for example, +its port number) shall be returned instead of its name. + +The arguments node and service cannot both be NULL. + +The flags argument is a flag that changes the default actions of the +function. By default the fully-qualified domain name (FQDN) for the host +shall be returned, but: + + - If the flag bit NI_NOFQDN is set, only the node name portion of the + FQDN shall be returned for local hosts. + + - If the flag bit NI_NUMERICHOST is set, the numeric form of the + host's address shall be returned instead of its name, under all + circumstances. + + - If the flag bit NI_NAMEREQD is set, an error shall be returned if the + host's name cannot be located. + + - If the flag bit NI_NUMERICSERV is set, the numeric form of the + service address shall be returned (for example, its port number) + instead of its name, under all circumstances. + + - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the + scope identifier shall be returned (for example, interface index) + instead of its name. This flag is ignored if the sa argument is + not an IPv6 address. + + - If the flag bit NI_DGRAM is set, this indicates that the service is + a datagram service (SOCK_DGRAM). The default behavior shall assume that + the service is a stream service (SOCK_STREAM). + +Note: + + 1. The three NI_NUMERICxxx flags are required to support the "-n" + flags that many commands provide. + 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 port + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 24] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + numbers (for example, [512,514]) that represent different services + for UDP and TCP. + +The getnameinfo() function shall be thread safe. + +A zero return value for getnameinfo() indicates successful completion; a +non-zero return value indicates failure. + +Upon successful completion, getnameinfo() shall return the node and +service names, if requested, in the buffers provided. The returned names +are always null-terminated strings. + +Error Return Values: + +The getnameinfo() function shall fail and return the corresponding value +if: + + [EAI_AGAIN] The name could not be resolved at this time. + Future attempts may succeed. + + [EAI_BADFLAGS] The flags had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred. + + [EAI_FAMILY] The address family was not recognized or the address + length was invalid for the specified family. + + [EAI_MEMORY] There was a memory allocation failure. + + [EAI_NONAME] The name does not resolve for the supplied parameters. + NI_NAMEREQD is set and the host's name cannot be located, or + both nodename and servname were null. + + [EAI_OVERFLOW] An argument buffer overflowed. + + [EAI_SYSTEM] A system error occurred. The error code can be found in + errno. + + + +6.3 Address Conversion Functions + +The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4 +address between binary and text form. IPv6 applications need similar +functions. The following two functions convert both IPv6 and IPv4 +addresses: + + #include + + int inet_pton(int af, const char *src, void *dst); + + const char *inet_ntop(int af, const void *src, + char *dst, socklen_t size); + +The inet_pton() function shall convert an address in its standard text +presentation form into its numeric binary form. The af argument shall +specify the family of the address. The AF_INET and AF_INET6 address +families shall be supported. The src argument points to the string + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 25] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +being passed in. The dst argument points to a buffer into which the +function stores the numeric address; this shall be large enough to hold +the numeric address (32 bits for AF_INET, 128 bits for AF_INET6). The +inet_pton() function shall return 1 if the conversion succeeds, with the +address pointed to by dst in network byte order. It shall return 0 if +the input is not a valid IPv4 dotted-decimal string or a valid IPv6 +address string, or -1 with errno set to EAFNOSUPPORT if the af argument +is unknown. + +If the af argument of inet_pton() is AF_INET, the src string shall be in +the standard IPv4 dotted-decimal form: + + ddd.ddd.ddd.ddd + +where "ddd" is a one to three digit decimal number between 0 and 255. +The inet_pton() function does not accept other formats (such as the +octal numbers, hexadecimal numbers, and fewer than four numbers that +inet_addr() accepts). + +If the af argument of inet_pton() is AF_INET6, the src string shall be +in one of the standard IPv6 text forms defined in Section 2.2 of the +addressing architecture specification [2]. + +The inet_ntop() function shall convert a numeric address into a text +string suitable for presentation. The af argument shall specify the +family of the address. This can be AF_INET or AF_INET6. The src +argument points to a buffer holding an IPv4 address if the af argument +is AF_INET, or an IPv6 address if the af argument is AF_INET6; the +address must be in network byte order. The dst argument points to a +buffer where the function stores the resulting text string; it shall not +be NULL. The size argument specifies the size of this buffer, which +shall be large enough to hold the text string (INET_ADDRSTRLEN +characters for IPv4, INET6_ADDRSTRLEN characters for IPv6). + +In order to allow applications to easily declare buffers of the proper +size to store IPv4 and IPv6 addresses in string form, the following two +constants are defined in : + + #define INET_ADDRSTRLEN 16 + #define INET6_ADDRSTRLEN 46 + +The inet_ntop() function shall return a pointer to the buffer containing +the text string if the conversion succeeds, and NULL otherwise. Upon +failure, errno is set to EAFNOSUPPORT if the af argument is invalid or +ENOSPC if the size of the result buffer is inadequate. + + + +6.4 Address Testing Macros + +The following macros can be used to test for special IPv6 addresses. + + #include + + int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); + int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 26] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); + + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); + +The first seven macros return true if the address is of the specified +type, or false otherwise. The last five test the scope of a multicast +address and return true if the address is a multicast address of the +specified scope or false if the address is either not a multicast +address or not of the specified scope. + +Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true +only for the two types of local-use IPv6 unicast addresses (Link-Local +and Site-Local) defined in [2], and that by this definition, the +IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback address +(::1). These two macros do not return true for IPv6 multicast addresses +of either link-local scope or site-local scope. + + + +7. Summary of New Definitions + +The following list summarizes the constants, structure, and extern +definitions discussed in this memo, sorted by header. + + IF_NAMESIZE + struct if_nameindex{}; + + AI_ADDRCONFIG + AI_ALL + AI_CANONNAME + AI_NUMERICHOST + AI_NUMERICSERV + AI_PASSIVE + AI_V4MAPPED + EAI_AGAIN + EAI_BADFLAGS + EAI_FAIL + EAI_FAMILY + EAI_MEMORY + EAI_NONAME + EAI_OVERFLOW + EAI_SERVICE + EAI_SOCKTYPE + EAI_SYSTEM + NI_DGRAM + NI_NAMEREQD + NI_NOFQDN + NI_NUMERICHOST + NI_NUMERICSERV + struct addrinfo{}; + + IN6ADDR_ANY_INIT + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 27] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + + IN6ADDR_LOOPBACK_INIT + INET6_ADDRSTRLEN + INET_ADDRSTRLEN + IPPROTO_IPV6 + IPV6_JOIN_GROUP + IPV6_LEAVE_GROUP + IPV6_MULTICAST_HOPS + IPV6_MULTICAST_IF + IPV6_MULTICAST_LOOP + IPV6_UNICAST_HOPS + IPV6_V6ONLY + SIN6_LEN + extern const struct in6_addr in6addr_any; + extern const struct in6_addr in6addr_loopback; + struct in6_addr{}; + struct ipv6_mreq{}; + struct sockaddr_in6{}; + + AF_INET6 + PF_INET6 + struct sockaddr_storage; + +The following list summarizes the function and macro prototypes +discussed in this memo, sorted by header. + + int inet_pton(int, const char *, void *); + const char *inet_ntop(int, const void *, + char *, socklen_t); + + char *if_indextoname(unsigned int, char *); + unsigned int if_nametoindex(const char *); + void if_freenameindex(struct if_nameindex *); + struct if_nameindex *if_nameindex(void); + + int getaddrinfo(const char *, const char *, + const struct addrinfo *, + struct addrinfo **); + int getnameinfo(const struct sockaddr *, socklen_t, + char *, socklen_t, char *, socklen_t, int); + void freeaddrinfo(struct addrinfo *); + const char *gai_strerror(int); + + int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); + + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 28] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +8. Security Considerations + +IPv6 provides a number of new security mechanisms, many of which need to +be accessible to applications. Companion memos detailing the extensions +to the socket interfaces to support IPv6 security are being written. + + + +Changes from RFC 2553 + + 1. Add brief description of the history of this API and its + relation to the Open Group/IEEE/ISO standards. + + 2. Alignments with [3]. + + 3. Removed all references to getipnodebyname() and + getipnodebyaddr(), which are deprecated in favor + of getaddrinfo() and getnameinfo(). + + 4. Added IPV6_V6ONLY IP level socket option to permit nodes + to not process IPv4 packets as IPv4 Mapped addresses + in implementations. + + 5. Added SIIT to references and added new contributors. + + 6. In previous versions of this specification, the sin6_flowinfo + field was associated with the IPv6 traffic class and flow label, + but its usage was not completely specified. The complete + definition of the sin6_flowinfo field, including its association + with the traffic class or flow label, is now deferred to a + future specification. + + + + +Acknowledgments + +This specification's evolution and completeness were significantly +influenced by the efforts of Richard Stevens, who has passed on. +Richard's wisdom and talent made the specification what it is today. +The co-authors will long think of Richard with great respect. + +Thanks to the many people who made suggestions and provided feedback to +this document, including: + +Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew +Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis +Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, Marc +Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji +Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, +Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, Craig +Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith +Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean +D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl +Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill. + +The getaddrinfo() and getnameinfo() functions are taken from an earlier +Internet Draft by Keith Sklower. As noted in that draft, William Durst, + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 29] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +Steven Wise, Michael Karels, and Eric Allman provided many useful +discussions on the subject of protocol-independent name-to-address +translation, and reviewed early versions of Keith Sklower's original +proposal. Eric Allman implemented the first prototype of getaddrinfo(). +The observation that specifying the pair of name and service would +suffice for connecting to a service independent of protocol details was +made by Marshall Rose in a proposal to X/Open for a "Uniform Network +Interface". + +Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker +made many contributions to this document. Ramesh Govindan made a number +of contributions and co-authored an earlier version of this memo. + + + +References + + [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460 Draft Standard. + + [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998 Draft Standard. + + [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX) + + Open Group Technical Standard: Base Specifications, Issue 6 + December 2001 + + ISO 9945 (pending final approval by ISO) + + http://www.opengroup.org/austin + + [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + + [5] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)" + RFC 2765, February 2000. + + [6] The Open Group Base Working Group + http://www.opengroup.org/platform/base.html + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 30] + + +INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002 + + +Authors' Addresses + +Bob Gilligan +Cacheflow, Inc. +650 Almanor Ave. +Sunnyvale, CA 94086 +Telephone: 408-220-2084 (voice) + 408-220-2250 (fax) +Email: gilligan@cacheflow.com + +Susan Thomson +Cisco Systems +499 Thornall Street, 8th floor +Edison, NJ 08837 +Telephone: 732-635-3086 +Email: sethomso@cisco.com + +Jim Bound +Hewlett-Packard Company +110 Spitbrook Road ZKO3-3/W20 +Nashua, NH 03062 +Telephone: 603-884-0062 +Email: Jim.Bound@hp.com + +Jack McCann +Hewlett-Packard Company +110 Spitbrook Road ZKO3-3/W20 +Nashua, NH 03062 +Telephone: 603-884-2608 +Email: Jack.McCann@hp.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 31] + diff --git a/doc/draft/draft-ietf-ipv6-dns-discovery-07.txt b/doc/draft/draft-ietf-ipv6-dns-discovery-07.txt new file mode 100644 index 0000000000..7480ee60de --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-dns-discovery-07.txt @@ -0,0 +1,660 @@ +Network Working Group Alain Durand +INTERNET-DRAFT SUN Microsystems, inc. +October 25, 2002 Jun-ichiro itojun Hagino +Expires April 2002 IIJ Research Laboratory + Dave Thaler + Microsoft + + + + + Well known site local unicast addresses + to communicate with recursive DNS servers + + + + + 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 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 a "work in progress". + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + + +Abstract + + This documents specifies 3 well known addresses to configure stub + resolvers on IPv6 nodes to enable them to communicate with recursive + DNS server with minimum configuration in the network and without + running a discovery protocol on the end nodes. This method may be + used when no other information about the addresses of recursive DNS + servers is available. Implementation of stub resolvers using this as + default configuration must provide a way to override this. + + + +Copyright notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + +1. Introduction + + RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or + more IPv6 address and default routes. + + However, for a node to be fully operational on a network, many other + parameters are needed, such as the address of a name server that + offer recursive service (a.k.a. recursive DNS server), mail relays, + web proxies, etc. Except for name resolution, all the other services + are usually described using names, not addresses, such as + smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping + reasons, a node needs to be configured with the IP address (and not + the name) of a recursive DNS server. As IPv6 addresses look much + more complex than IPv4 ones, there is some incentive to make this + configuration as automatic and simple as possible. + + Although it would be desirable to have all configuration parameters + configured/discovered automatically, it is common practice in IPv4 + today to ask the user to do manual configuration for some of them by + entering server names in a configuration form. So, a solution that + will allow for automatic configuration of the recursive DNS server is + seen as an important step forward in the autoconfiguration story. + + The intended usage scenario for this proposal is a home or enterprise + network where IPv6 nodes are plugged/unplugged with minimum + management and use local resources available on the network to + autoconfigure. This proposal is also useful in cellular networks + where all mobile devices are included within the same site. + + 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 [KEYWORDS]. + + + + +2. Well known addresses vs discovery + + Some of the discussions in the past around DNS server discovery have + been trying to characterize the solution space into stateless versus + stateful or server oriented versus severless. It is not absolutely + clear how much state if any needs to be kept to perform DNS server + discovery, and, although the semantic differences between a router + and a server are well understood from a conceptual perspective, the + current implementations tend to blur the picture. In another attempt + to characterize different approaches, one can look at how much + intelligence a client needs to have in order to use the service. + + One avenue is to ask the IPv6 node to participate in a discovery + protocol, such as SLP or DHCP, learn the address of the server and + send packets to this server. Another one is to configure the IPv6 + node with well known addresses and let the local routing system + forward packets to the right place. This document explores this + later avenue of configuration using well known addresses that does + not require participation of the end node in any discovery mechanism. + + + + + +3. Reserved prefix and addresses + + The mechanism described here is: + - intended for ongoing use and not not just for bootstrapping + - intended to populate a stub resolver's list of available + recursive servers only if that list is otherwise unpopulated + - providing reliability through redundancy using three unicast + addresses. + + +3.1 Stub resolver configuration + + This memo reserved three well known IPv6 site local addresses. + + In the absence of any other information about the addresses of + recursive DNS servers, IPv6 stub-resolvers MAY use any of those three + IPv6 addresses in their list of candidate recursive DNS servers. + + +3.2 Recursive DNS servers configuration + + Within sites, one or more recursive DNS server SHOULD be configured + with any of those three addresses. It is RECOMMENDED that large sites + deploy 3 recursive DNS servers, one for each reserved address. Small + site could use only one recursive DNS server and assign the 3 + addresses to it. + + +3.3 Rationale for the choice of three addresses + + Three was chosen based on common practice in many places in the + industry. While it's true that if the first one fails, that it's + unlikely the second one will succeed (due to there really being no + DNS server at all), using multiple addresses is important so that + when ones do exist, the host can fail over to a second server more + quickly than routing converges. Three servers is a compromise between + extra reliability and increased complexity (maintaining additional + servers, having multiple entries in the routing system, additional + delays before the stub resolver returns an error,...). + + Another reason to have multiple addresses is to avoid the need to use + of anycast addresses to achieve reliability through redundancy. On + top of the classic problems (TCP sessions, ICMP messages,...) using + an anycast address would hide the real locations of the recursive DNS + servers to the stub resolver, prohibiting it to keep track of which + servers are performing correctly. For this particular matter, using + well known addresses is no different than configuring the stub + resolver with regular addresses taken from the local site. + + +3.4 Implementation considerations + + Stub resolver implementation MAY be configured by default using those + addresses. However, implementing only the mechanism described in this + memo may end up causing some interoperability problems when operating + in networks where no recursive DNS server is configured with any of + the well known addresses. Thus, stub resolvers MUST implement + mechanisms for overriding this default, for example: manual + configuration, L2 mechanisms and/or DHCPv6. + + + + +4. Routing + + A solution to enable the stub resolvers to reach the recursive DNS + servers is to inject host routes in the local routing system. + Examples of methods for injecting host routes and a brief discussion + of their fate sharing properties are presented here: + + a) Manual injection of routes by a router on the same subnet. + If the node running the recursive DNS server goes down, the router + may or may not be notified and keep announcing the route. + + b) Running a routing protocol on the same node running the DNS + resolver. + If the process running the recursive DNS server dies, the routing + protocol may or may not be notified and keep announcing the route. + + c) Running a routing protocol within the same process running the + recursive DNS server. + If the recursive DNS server and the routing protocol run in + separated threads, similar concerns as above are true. + + d) Developing an "announcement" protocol that the recursive DNS + server could use to advertize the host route to the nearby router. + Details of such a protocol are out of scope of this document, but + something similar to [MLD] is possible. However, the three first + mechanisms should cover most cases. + + An alternate solution is to configure a link with the well known + prefix and position the three recursive DNS servers on that link. + The advantage of this method is that host routes are not necessary , + the well known prefix is advertised to the routing system by the + routers on the link. However, in the event of a problem on the + physical link, all resolvers will become unreachable. + + IANA considerations for this prefix are covered in Section 6. + + + +5. Site local versus global scope considerations + + The rationales for having a site local prefix are: + + -a) Using a site local prefix will ensure that the traffic to the + recursive DNS servers stays local to the site. This will prevent + the DNS requests from accidentally leaking out of the site. + However, the local resolver can implement a policy to forward DNS + resolution of non-local addresses to an external DNS resolver. + + -b) Reverse DNS resolution of site local addresses is only + meaningful within the site. Thus, making sure that such queries + are first sent to a recursive DNS server located within the site + perimeter increase their likelihood of success. + + + + +6. Examples of use + + This section presents example scenarios showing how the mechanism + described in this memo can co-exist with other techniques, namely + manual configuration and DHCPv6 discovery. + + Note: those examples are just there to illustrate some usage + scenarios and in no way do they suggest any recommended practices. + + +6.1 Simple case, general purpose recursive DNS server + + This example shows the case of a network that manages one recursive + DNS server and a large number of nodes running DNS stub resolvers. + The recursive DNS server is performing (and caching) all the + recursive queries on behalf of the stub resolvers. The recursive DNS + server is configured with an IPv6 address taken from the prefix + delegated to the site and with the 3 well known addresses defined in + this memo. The stub resolvers are either configured with the "real" + IPv6 address of the recursive DNS server or with the well known site + local unicast addresses defined in this memo. + + -------------------------------------------- + | | + | --------------------- | + | |DNS stub resolver | | + | |configured with the| | + | |"real" address of | | + | |the recursive DNS | | + | |server | | + | --------------------- | + | ----------- | | + | |recursive| | | + | |DNS |<---------- | + | |server |<---------------- | + | ----------- | | + | ---------------------- | + | |DNS stub resolver | | + | |configured with 3 | | + | |well known addresses| | + | ---------------------- | + | | + -------------------------------------------- + + (The recursive DNS server is configured to listen both on + its IPv6 address and on the well known address) + + +6.2 Three recursive DNS servers + + This is a similar example as above, except that three recursive DNS + resolvers are configured instead of just one. + + ------------------------------------------- + | | + | --------------------- | + | |DNS stub resolver | | + | |configured with the| | + | |"real" address of | | + | |the recursive DNS | | + | |server | | + | --------------------- | + | | | + | ----------- | | + | |recursive| | | + | |DNS |<---------| | + | |server 1 |<---------|------ | + | ----------- | | | + | | | | + | ----------- | | | + | |recursive| | | | + | |DNS |<---------| | | + | |server 2 |<---------|-----| | + | ----------- | | | + | | | | + | ----------- | | | + | |recursive| | | | + | |DNS |<---------- | | + | |server 3 |<---------------| | + | ----------- | | + | ---------------------- | + | |DNS stub resolver | | + | |configured with 3 | | + | |well known addresses| | + | ---------------------- | + | | + ------------------------------------------- + + (The recursive DNS server is configured to listen both on + its IPv6 address and on the well known address) + + +6.3 DNS forwarder + + A drawback of the choice of site local scope for the reserved + addresses for recursive DNS server is that, in the case of a + home/small office network connected to an ISP, DNS traffic cannot be + sent directly to the ISP recursive DNS server without having the ISP + and all its customers share the same definition of site. + + In this scenario, the home/small office network is connected to the + ISP router (PE) via an edge router (CPE). + + ------------- + / | + -------- ----- / | + |ISP PE| |CPE| / Customer | + | |===========| |====< site | + | | | | \ | + -------- ----- \ | + \ | + ------------- + + + The customer router CPE could be configured on its internal interface + with one of the reserved site local addresses and listen for DNS + queries. It would be configured to use one (or several) of the well + known site local unicast addresses within the ISP's site to send its + own queries to. It would act as a DNS forwarder, forwarding queries + received on its internal interface to the ISP's recursive DNS server. + + ------------- + / | + ---------- -------------- / | + |ISP | | CPE| / Customer | + |DNS |===========| DNS|====< site | + |server | <------|---forwarder|-----\---- | + ---------- -------------- \ | + \ | + ------------- + + In this configuration, the CPE is acting as a multi-sited router. + + +6.4 DNS forwarder with DHCPv6 interactions + + In this variant scenario, DHCPv6 is be used between the PE and CPE to + do prefix delegation [DELEG] and recursive DNS server discovery. + + ------------- + / | + -------- -------------- / | + |ISP | |customer CPE| / Customer | + |DHCPv6|===========| DHCPv6|====< site | + |server| <------|------client| \ | + -------- -------------- \ | + \ | + ------------- + + This example will show how DHCPv6 and well known site local unicast + addresses cooperate to enable the internal nodes to access DNS. + + The customer router CPE is configured on its internal interface with + one of the reserved site local addresses and listen for DNS queries. + It would act as a DNS forwarder, as in 5.2, forwarding those queries + to the recursive DNS server pointed out by the ISP in the DHCPv6 + exchange. + + ------------- + / | + ---------- -------------- / | + |ISP | |customer CPE| / Customer | + |DNS |===========| DNS|====< site | + |resolver| <------|---forwarder|-----\---- | + ---------- -------------- \ | + \ | + ------------- + + + The same CPE router could also implement a local DHCPv6 server and + advertizes itself as DNS forwarder. + + ------------- + / | + -------- -------------- / Customer | + |ISP PE| |customer CPE| / site | + | |===========|DHCPv6 |====< | + | | |server------|-----\---> | + -------- -------------- \ | + \ | + ------------- + + + + Within the site: + + a) DHCPv6 aware clients use DHCPv6 to obtain the address of the + DNS forwarder... + + ------------- + / | + ---------- -------------- / Customer | + |ISP | |customer CPE| / site | + |DNS |===========| DNS|====< | + |resolver| <------|---forwarder|-----\----DHCPv6 | + ---------- -------------- \ client | + \ | + ------------- + (The address of the DNS forwarder is acquired via DHCPv6.) + + + b) other nodes simply send their DNS request to the reserved site + local addresses. + + ------------- + / | + ---------- -------------- / customer | + |ISP | |customer CPE| / site | + |DNS |===========| DNS|====< | + |resolver| <------|---forwarder|-----\----non DHCPv6| + ---------- -------------- \ node | + \ | + ------------- + (Internal nodes use the reserved site local unicast address.) + + + A variant of this scenario is the CPE can decide to pass the global + address of the ISP recursive DNS server in the DHCPv6 exchange with + the internal nodes. + + + +7. IANA considerations + + The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out + of the site local fec0::/10 prefix. + + The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2 + and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server + configuration. + + All other addresses within the fec0:0000:0000:ffff::/64 are reserved + for future use and are expected to be assigned only with IESG + approval. + + + + +8. Security Considerations + + Ensuring that queries reach a legitimate DNS server relies on the + security of the IPv6 routing infrastructure. The issues here are the + same as those for protecting basic IPv6 connectivity. + + IPsec/IKE can be used as the well known addresses are used as unicast + addresses. + + The payload can be protected using standard DNS security techniques. + If the client can preconfigure a well known private or public key + then TSIG [TSIG] can be used with the same packets presented for the + query. If this is not the case, then TSIG keys will have to be + negotiated using [TKEY]. After the client has the proper key then + the query can be performed. + + The use of site local addresses instead of global addresses will + ensure the DNS queries issued by host using this mechanism will not + leak out of the site. + + + + +9. References + + [KEYWORDS] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ADDRCONF] + Thomson, S., and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [MLD] + Deering, S., Fenner, W., Haberman, B., + "Multicast Listener Discovery (MLD) for IPv6", + RFC2710, October 1999. + + [TSIG] + Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC2845, May 2000. + + [TKEY] + D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)", + RFC2930, September 2000. + + [DHCPv6] + Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and + Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6 + (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress), + Februray 2002. + + [DELEG] + Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6", + draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress), + February 2002. + + + + +10. Authors' Addresses + + Alain Durand + SUN microsystems, inc. + 17 Network Circle, UMPK 17-202 + Menlo Park, CA 94025 + Email: Alain.Durand@sun.com + + Jun-ichiro itojun HAGINO + Research Laboratory, Internet Initiative Japan Inc. + Takebashi Yasuda Bldg., + 3-13 Kanda Nishiki-cho, + Chiyoda-ku, Tokyo 101-0054, JAPAN + Email: itojun@iijlab.net + + Dave Thaler + Microsoft + One Microsoft Way + Redmond, CA 98052, USA + Email: dthaler@microsoft.com + + + + +11. Full Copyright Statement + +Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-secsh-dns-04.txt b/doc/draft/draft-ietf-secsh-dns-04.txt new file mode 100644 index 0000000000..7667a5e8dd --- /dev/null +++ b/doc/draft/draft-ietf-secsh-dns-04.txt @@ -0,0 +1,616 @@ + + +Secure Shell Working Group J. Schlyter +Internet-Draft Carlstedt Research & +Expires: October 1, 2003 Technology + W. Griffin + Network Associates Laboratories + April 2, 2003 + + + Using DNS to securely publish SSH key fingerprints + draft-ietf-secsh-dns-04.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. + + This Internet-Draft will expire on October 1, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a method to verify SSH host keys using + DNSSEC. The document defines a new DNS resource record that contains + a standard SSH key fingerprint. + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 1] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 + 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 + 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 + 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 + 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4 + 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 + 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 + 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . 8 + Informational References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 2] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +1. Introduction + + The SSH [5] protocol provides secure remote login and other secure + network services over an insecure network. The security of the + connection relies on the server authenticating itself to the client. + + Server authentication is normally done by presenting the fingerprint + of an unknown public key to the user for verification. If the user + decides the fingerprint is correct and accepts the key, the key is + saved locally and used for verification for all following + connections. While some security-conscious users verify the + fingerprint out-of-band before accepting the key, many users blindly + accepts the presented key. + + The method described here can provide out-of-band verification by + looking up a fingerprint of the server public key in the DNS [1][2] + and using DNSSEC [4] to verify the lookup. + + In order to distribute the fingerprint using DNS, this document + defines a new DNS resource record to carry the fingerprint. + + Basic understanding of the DNS system [1][2] and the DNS security + extensions [4] is assumed by this document. + + 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 [3]. + +2. SSH Host Key Verification + +2.1 Method + + Upon connection to a SSH server, the SSH client MAY look up the SSHFP + resource record(s) for the host it is connecting to. If the + algorithm and fingerprint of the key received from the SSH server + matches the algorithm and fingerprint of one of the SSHFP resource + record(s) returned from DNS, the client MAY accept the identity of + the server. + +2.2 Implementation Notes + + Client implementors SHOULD provide a configurable policy used to + select the order of methods used to verify a host key. This document + defines one method: Fingerprint storage in DNS. Another method + defined in the SSH Architecture [5] uses local files to store keys + for comparison. Other methods that could be defined in the future + might include storing fingerprints in LDAP or other databases. A + configurable policy will allow administrators to determine which + + + +Schlyter & Griffin Expires October 1, 2003 [Page 3] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + methods they want to use and in what order the methods should be + prioritized. This will allow administrators to determine how much + trust they want to place in the different methods. + + One specific scenario for having a configurable policy is where + clients do not use fully qualified host names to connect to servers. + In this scenario, the implementation SHOULD verify the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + +2.3 Fingerprint Matching + + The public key and the SSHFP resource record are matched together by + comparing algorithm number and fingerprint. + + The public key algorithm and the SSHFP algorithm number MUST + match. + + A message digest of the public key, using the message digest + algorithm specified in the SSHFP fingerprint type, MUST match the + SSH FP fingerprint. + + +2.4 Authentication + + A public key verified using this method MUST only be trusted if the + SSHFP resource record (RR) used for verification was authenticated by + a trusted SIG RR. + + Clients that do not validate the DNSSEC signatures themselves MUST + use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], + between themselves and the entity performing the signature + validation. + +3. The SSHFP Resource Record + + The SSHFP resource record (RR) is used to store a fingerprint of a + SSH public host key that is associated with a Domain Name System + (DNS) name. + + The RR type code for the SSHFP RR is TBA. + +3.1 The SSHFP RDATA Format + + The RDATA for a SSHFP RR consists of an algorithm number, fingerprint + type and the fingerprint of the public host key. + + + +Schlyter & Griffin Expires October 1, 2003 [Page 4] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | fp type | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / fingerprint / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 Algorithm Number Specification + + This algorithm number octet describes the algorithm of the public + key. The following values are assigned: + + Value Algorithm name + ----- -------------- + 0 reserved + 1 RSA + 2 DSS + + Reserving other types requires IETF consensus. + +3.1.2 Fingerprint Type Specification + + The fingerprint type octet describes the message-digest algorithm + used to calculate the fingerprint of the public key. The following + values are assigned: + + Value Fingerprint type + ----- ---------------- + 0 reserved + 1 SHA-1 + + Reserving other types requires IETF consensus. For interoperability + reasons, as few fingerprint types as possible should be reserved. + The only reason to reserve additional types is to increase security. + +3.1.3 Fingerprint + + The fingerprint is calculated over the public key blob as described + in [6]. + + The message-digest algorithm is presumed to produce an opaque octet + string output which is placed as-is in the RDATA fingerprint field. + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 5] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +3.2 Presentation Format of the SSHFP RR + + The presentation format of the SSHFP resource record consists of two + numbers (algorithm and fingerprint type) followed by the fingerprint + itself presented in hex, e.g: + + host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 + + +4. Security Considerations + + Currently, the amount of trust a user can realistically place in a + server key is proportional to the amount of attention paid to + verifying that the public key presented actually corresponds to the + private key of the server. If a user accepts a key without verifying + the fingerprint with something learned through a secured channel, the + connection is vulnerable to a man-in-the-middle attack. + + The approach suggested here shifts the burden of key checking from + each user of a machine to the key checking performed by the + administrator of the DNS recursive server used to resolve the host + information. Hopefully, by reducing the number of times that keys + need to be verified by hand, each verification is performed more + completely. Furthermore, by requiring an administrator do the + checking, the result may be more reliable than placing this task in + the hands of an application user. + + The overall security of using SSHFP for SSH host key verification is + dependent on detailed aspects of how verification is done in SSH + implementations. One such aspect is in which order fingerprints are + looked up (e.g. first checking local file and then SSHFP). We note + that in addition to protecting the first-time transfer of host keys, + SSHFP can optionally be used for stronger host key protection. + + If SSHFP is checked first, new SSH host keys may be distributed by + replacing the corresponding SSHFP in DNS. + + If SSH host key verification can be configured to require SSHFP, + we can implement SSH host key revocation by removing the + corresponding SSHFP from DNS. + + As stated in Section 2.2, we recommend that SSH implementors provide + a policy mechanism to control the order of methods used for host key + verification. One specific scenario for having a configurable policy + is where clients use unqualified host names to connect to servers. In + this case, we recommend that SSH implementations check the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + + + +Schlyter & Griffin Expires October 1, 2003 [Page 6] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + a DNS search path into the local resolver and forcing the client to + connect to a different host. + + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is no + way with current DNS lookup APIs to tell whether a search path is + from a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + Another dependency is on the implementation of DNSSEC itself. As + stated in Section 2.4, we mandate the use of secure methods for + lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This + is especially important if SSHFP is to be used as a basis for host + key rollover and/or revocation, as described above. + + Since DNSSEC only protects the integrity of the host key fingerprint + after it is signed by the DNS zone administrator, the fingerprint + must be transferred securely from the SSH host administrator to the + DNS zone administrator. This could be done manually between the + administrators or automatically using secure DNS dynamic update [10] + between the SSH server and the nameserver. We note that this is no + different from other key enrollment situations, e.g. a client sending + a certificate request to a certificate authority for signing. + +5. IANA Considerations + + IANA needs to allocate a RR type code for SSHFP from the standard RR + type space (type 44 requested). + + IANA needs to open a new registry for the SSHFP RR type for public + key algorithms. Defined types are: + + 0 is reserved + 1 is RSA + 2 is DSA + + Adding new reservations requires IETF consensus. + + IANA needs to open a new registry for the SSHFP RR type for + fingerprint types. Defined types are: + + 0 is reserved + 1 is SHA-1 + + Adding new reservations requires IETF consensus. + +Normative References + + + +Schlyter & Griffin Expires October 1, 2003 [Page 7] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH + Protocol Architecture", draft-ietf-secsh-architecture-13 (work + in progress), September 2002. + + [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Transport Layer Protocol", + draft-ietf-secsh-transport-15 (work in progress), September + 2002. + +Informational References + + [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document + Roadmap", RFC 2411, November 1998. + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [9] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + +Authors' Addresses + + Jakob Schlyter + Carlstedt Research & Technology + Stora Badhusgatan 18-20 + Goteborg SE-411 21 + Sweden + + EMail: jakob@crt.se + URI: http://www.crt.se/~jakob/ + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 8] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + Wesley Griffin + Network Associates Laboratories + 15204 Omega Drive Suite 300 + Rockville, MD 20850 + USA + + EMail: wgriffin@tislabs.com + URI: http://www.nailabs.com/ + +Appendix A. Acknowledgements + + The authors gratefully acknowledges, in no particular order, the + contributions of the following persons: + + Martin Fredriksson + + Olafur Gudmundsson + + Edward Lewis + + Bill Sommerfeld + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 9] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Schlyter & Griffin Expires October 1, 2003 [Page 10] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 11] + diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt new file mode 100644 index 0000000000..3578d2a15e --- /dev/null +++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt @@ -0,0 +1,519 @@ + +Internet Draft Johan Ihren +draft-ihren-dnsext-threshold-validation-00.txt Autonomica +February 2003 +Expires in six months + + + Threshold Validation: + + A Mechanism for Improved Trust and Redundancy for DNSSEC Keys + + +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. + + +Abstract + + This memo documents a proposal for a different method of validation + for DNSSEC aware resolvers. The key change is that by changing from + a model of one Key Signing Key, KSK, at a time to multiple KSKs it + will be possible to increase the aggregated trust in the signed + keys by leveraging from the trust associated with the different + signees. + + By having multiple keys to chose from validating resolvers get the + opportunity to use local policy to reflect actual trust in + different keys. For instance, it is possible to trust a single, + particular key ultimately, while requiring multiple valid + signatures by less trusted keys for validation to succeed. + Furthermore, with multiple KSKs there are additional redundancy + benefits available since it is possible to roll over different KSKs + at different times which may make rollover scenarios easier to + manage. + +Contents + + 1. Terminology + 2. Introduction and Background + + 3. Trust in DNSSEC Keys + 3.1. Key Management, Split Keys and Trust Models + 3.2. Trust Expansion: Authentication versus Authorization + + 4. Proposed Semantics for Signing the KEY Resource Record + Set + 4.1. Packet Size Considerations + + 5. Proposed Use of Multiple "Trusted Keys" in a Validating + Resolver + 5.1. Not All Possible KSKs Need to Be Trusted + 5.2. Possible to do Threshold Validation + 5.3. Not All Trusted Keys Will Be Available + + 6. Additional Benefits from Having Multiple KSKs + 6.1. More Robust Key Rollovers + 6.2. Evaluation of Multiple Key Distribution Mechanisms + + 7. Security Considerations + 8. IANA Considerations. + 9. References + 9.1. Normative. + 9.2. Informative. + 10. Acknowledgments. + 11. Authors' Address + + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC 2119. + + The term "zone" refers to the unit of administrative control in the + Domain Name System. "Name server" denotes a DNS name server that is + authoritative (i.e. knows all there is to know) for a DNS zone, + typically the root zone. A "resolver", is a DNS "client", i.e. an + entity that sends DNS queries to authoritative nameservers and + interpret the results. A "validating resolver" is a resolver that + attempts to perform DNSSEC validation on data it retrieves by doing + DNS lookups. + + +2. Introduction and Background + + From a protocol perspective there is no real difference between + different keys in DNSSEC. They are all just keys. However, in + actual use there is lots of difference. First and foremost, most + DNSSEC keys have in-band verification. I.e. the keys are signed by + some other key, and this other key is in its turn also signed by + yet another key. This way a "chain of trust" is created. Such + chains have to end in what is referred to as a "trusted key" for + validation of DNS lookups to be possible. + + A "trusted key" is a the public part of a key that the resolver + acquired by some other means than by looking it up in DNS. The + trusted key has to be explicitly configured. + + A node in the DNS hierarchy that issues such out-of-band "trusted + keys" is called a "security apex" and the trusted key for that apex + is the ultimate source of trust for all DNS lookups within that + entire subtree. + + DNSSEC is designed to be able to work with more than on security + apex. These apexes will all share the problem of how to distribute + their "trusted keys" in a way that provides validating resolvers + confidence in the distributed keys. + + Maximizing that confidence is crucial to the usefulness of DNSSEC + and this document tries to address this issue. + + +3. Trust in DNSSEC Keys + + In the end the trust that a validating resolver will be able to put + in a key that it cannot validate within DNSSEC will have to be a + function of + + * trust in the key issuer, aka the KSK holder + + * trust in the distribution method + + * trust in extra, out-of-band verification + + The KSK holder needs to be trusted not to accidentally lose private + keys in public places. Furthermore it needs to be trusted to + perform correct identification of the ZSK holders in case they are + separate from the KSK holder itself. + + The distribution mechanism can be more or less tamper-proof. If the + key holder publishes the public key, or perhaps just a secure + fingerprint of the key in a major newspaper it may be rather + difficult to tamper with. A key acquired that way may be easier to + trust than if it had just been downloaded from a web page. + + Out-of-band verification can for instance be the key being signed + by a certificate issued by a known Certificate Authority that the + resolver has reason to trust. + +3.1. Simplicity vs Trust + + The fewer keys that are in use the simpler the key management + becomes. Therefore increasing the number of keys should only be + considered when the complexity is not the major concern. A perfect + example of this is the distinction between so called Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds + overall complexity but simplifies real life operations and was an + overall gain since operational simplification was considered to be + a more crucial issue than the added complexity. + + In the case of a security apex there are additional issues to + consider, among them + + * maximizing trust in the KSK received out-of-band + + * authenticating the legitimacy of the ZSKs used + + In some cases this will be easy, since the same entity will manage + both ZSKs and KSKs (i.e. it will authenticate itself, somewhat + similar to a self-signed certificate). In some environments it will + be possible to get the trusted key installed in the resolver end by + decree (this would seem to be a likely method within corporate and + government environments). + + In other cases, however, this will possibly not be sufficient. In + the case of the root zone this is obvious, but there may well be + other cases. + +3.2. Expanding the "Trust Base" + + For a security apex where the ZSKs and KSK are not held by the same + entity the KSK will effectively authenticate the identity of + whoever does real operational zone signing. The amount of trust + that the data signed by a ZSK will get is directly dependent on + whether the end resolver trusts the KSK or not, since the resolver + has no OOB access to the public part of the ZSKs (for practical + reasons). + + Since the KSK holder is distinct from the ZSK holder the obvious + question is whether it would then be possible to further improve + the situation by using multiple KSK holders and thereby expanding + the trust base to the union of that available to each individual + KSK holder. "Trust base" is an invented term intended to signify + the aggregate of Internet resolvers that will eventually choose to + trust a key issued by a particular KSK holder. + + A crucial issue when considering trust expansion through addition + of multiple KSK holders is that the KSK holders are only used to + authenticate the ZSKs used for signing the zone. I.e. the function + performed by the KSK is basically: + + "This is indeed the official ZSK holder for this zone, + I've verified this fact to the best of my abilitites." + + Which can be thought of as similar to the service of a public + notary. I.e. the point with adding more KSK holders is to improve + the public trust in data signed by the ZSK holders by improving the + strength of available authentication. + + Therefore adding more KSK holders, each with their own trust base, + is by definition a good thing. More authentication is not + controversial. On the contrary, when it comes to authentication, + the more the merrier. + + +4. Proposed Semantics for Signing the KEY Resource Record Set + + In DNSSEC according to RFC2535 all KEY Resource Records are used to + sign all authoritative data in the zone, including the KEY RRset + itself, since RFC2535 makes no distinction between Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] + it is possible to change this to the KEY RRset being signed with + all KSKs and ZSKs but the rest of the zone only being signed by the + ZSKs. + + This proposal changes this one step further, by recommending that + the KEY RRset is only signed by the Key Signing Keys, KSK, and + explicitly not by the Zone Signing Keys, ZSK. The reason for this + is to maximize the amount of space in the DNS response packet that + is available for additional KSKs and signatures thereof. The rest + of the authoritative zone contents are as previously signed by only + the ZSKs. + +4.1. Packet Size Considerations + + The reason for the change is to keep down the size of the aggregate + of KEY RRset plus SIG(KEY) that resolvers will need to acquire to + perform validation of data below a security apex. For DNSSEC data + to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be + set, and therefore the allowed packet size can be assumed to be at + least the EDNS0 minimum of 4000 bytes. + + When querying for KEY + SIG(KEY) for "." (the case that is assumed + to be most crucial) the size of the response packet after the + change to only sign the KEY RR with the KSKs break down into a + rather large space of possibilities. Here are a few examples for + the possible alternatives for different numbers of KSKs and ZSKs + for some different key lengths (all RSA keys, with a public + exponent that is < 254). This is all based upon the size of the + response for the particular example of querying for + + ". KEY IN" + + with a response of entire KEY + SIG(KEY) with the authority and + additional sections empty: + + ZSK/768 and KSK/1024 (real small) + Max 12 KSK + 3 ZSK at 3975 + 10 KSK + 8 ZSK at 3934 + 8 KSK + 13 ZSK at 3893 + + ZSK/768 + KSK/1280 + MAX 10 KSK + 2 ZSK at 3913 + 8 KSK + 9 ZSK at 3970 + 6 KSK + 15 ZSK at 3914 + + ZSK/768 + KSK/1536 + MAX 8 KSK + 4 ZSK at 3917 + 7 KSK + 8 ZSK at 3938 + 6 KSK + 12 ZSK at 3959 + + ZSK/768 + KSK/2048 + MAX 6 KSK + 5 ZSK at 3936 + 5 KSK + 10 ZSK at 3942 + + ZSK/1024 + KSK/1024 + MAX 12 KSK + 2 ZSK at 3943 + 11 KSK + 4 ZSK at 3930 + 10 KSK + 6 ZSK at 3917 + 8 KSK + 10 ZSK at 3891 + + ZSK/1024 + KSK/1536 + MAX 8 KSK + 3 ZSK at 3900 + 7 KSK + 6 ZSK at 3904 + 6 KSK + 9 ZSK at 3908 + + ZSK/1024 + KSK/2048 + MAX 6 KSK + 4 ZSK at 3951 + 5 KSK + 8 ZSK at 3972 + 4 KSK + 12 ZSK at 3993 + + Note that these are just examples and this document is not making + any recommendations on suitable choices of either key lengths nor + number of different keys employed at a security apex. + + This document does however, based upon the above figures, make the + recommendation that at a security apex that expects to distribute + "trusted keys" the KEY RRset should only be signed with the KSKs + and not with the ZSKs to keep the size of the response packets + down. + + +5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver + + In DNSSEC according to RFC2535[RFC2535] validation is the process + of tracing a chain of signatures (and keys) upwards through the DNS + hierarchy until a "trusted key" is reached. If there is a known + trusted key present at a security apex above the starting point + validation becomes an exercise with a binary outcome: either the + validation succeeds or it fails. No intermediate states are + possible. + + With multiple "trusted keys" (i.e. the KEY RRset for the security + apex signed by multiple KSKs) this changes into a more complicated + space of alternatives. From the perspective of complexity that may + be regarded as a change for the worse. However, from a perspective + of maximizing available trust the multiple KSKs add value to the + system. + +5.1. Possible to do Threshold Validation + + With multiple KSKs a new option that opens for the security + concious resolver is to not trust a key individually. Instead the + resolver may decide to require the validated signatures to exceed a + threshold. For instance, given M trusted keys it is possible for + the resolver to require N-of-M signatures to treat the data as + validated. + + I.e. with the following pseudo-configuration in a validating + resolver + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Note that ksk-4 is not present below + keys { ksk-1; ksk-2; ksk-3; ksk-5; }; + # 3 signatures needed with 4 possible keys, aka 75% + needed-signatures 3; + }; + }; + + we configure five trusted keys for the root zone, but require two + valid signatures for the top-most KEY for validation to + succeed. I.e. threshold validation does not force multiple + signatures on the entire signature chain, only on the top-most + signature, closest to the security apex for which the resolver has + trusted keys. + +5.2. Not All Trusted Keys Will Be Available + + With multiple KSKs held and managed by separate entities the end + resolvers will not always manage to get access to all possible + trusted keys. In the case of just a single KSK this would be fatal + to validation and necessary to avoid at whatever cost. But with + several fully trusted keys available the resolver can decide to + trust several of them individually. An example based upon more + pseudo-configuration: + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Only these two keys are trusted independently + keys { ksk-1; ksk-4; }; + # With these keys a single signature is sufficient + needed-signatures 1; + }; + }; + + Here we have the same five keys and instruct the validating + resolver to fully trust data that ends up with just one signature + from by a fully trusted key. + + The typical case where this will be useful is for the case where + there is a risk of the resolver not catching a rollover event by + one of the KSKs. By doing rollovers of different KSKs with + different schedules it is possible for a resolver to "survive" + missing a rollover without validation breaking. This improves + overall robustness from a management point of view. + +5.3. Not All Possible KSKs Need to Be Trusted + + With just one key available it simply has to be trusted, since that + is the only option available. With multiple KSKs the validating + resolver immediately get the option of implementing a local policy + of only trusting some of the possible keys. + + This local policy can be implemented either by simply not + configuring keys that are not trusted or, possibly, configure them + but specify to the resolver that certain keys are not to be + ultimately trusted alone. + + +6. Additional Benefits from Having Multiple KSKs + +6.1. More Robust Key Rollovers + + With only one KSK the rollover operation will be a delicate + operation since the new trusted key needs to reach every validating + resolver before the old key is retired. For this reason it is + expected that long periods of overlap will be needed. + + With multiple KSKs this changes into a system where different + "series" of KSKs can have different rollover schedules, thereby + changing from one "big" rollover to several "smaller" rollovers. + + If the resolver trusts several of the available keys individually + then even a failure to track a certain rollover operation within + the overlap period will not be fatal to validation since the other + available trusted keys will be sufficient. + +6.2. Evaluation of Multiple Key Distribution Mechanisms + + Distribution of the trusted keys for the DNS root zone is + recognized to be a difficult problem that ... + + With only one trusted key, from one single "source" to distribute + it will be difficult to evaluate what distribution mechanism works + best. With multiple KSKs, held by separate entitites it will be + possible to measure how large fraction of the resolver population + that is trusting what subsets of KSKs. + + +7. Security Considerations + + From a systems perspective the simplest design is arguably the + best, i.e. one single holder of both KSK and ZSKs. However, if that + is not possible in all cases a more complex scheme is needed where + additional trust is injected by using multiple KSK holders, each + contributing trust, then there are only two alternatives + available. The first is so called "split keys", where a single key + is split up among KSK holders, each contributing trust. The second + is the multiple KSK design outlined in this proposal. + + Both these alternatives provide for threshold mechanisms. However + split keys makes the threshold integral to the key generating + mechanism (i.e. it will be a property of the keys how many + signatures are needed). In the case of multiple KSKs the threshold + validation is not a property of the keys but rather local policy in + the validating resolver. A benefit from this is that it is possible + for different resolvers to use different trust policies. Some may + configure threshold validation requiring multiple signatures and + specific keys (optimizing for security) while others may choose to + accept a single signature from a larger set of keys (optimizing for + redundancy). Since the security requirements are different it would + seem to be a good idea to make this choice local policy rather than + global policy. + + Furthermore, a clear issue for validating resolvers will be how to + ensure that they track all rollover events for keys they + trust. Even with operlap during the rollover (which is clearly + needed) there is still a need to be exceedingly careful not to miss + any rollovers (or fail to acquire a new key) since without this + single key validation will fail. With multiple KSKs this operation + becomes more robust, since different KSKs may roll at different + times according to different rollover schedules and losing one key, + for whatever reason, will not be crucial unless the resolver + intentionally chooses to be completely dependent on that exact key. + +8. IANA Considerations. + + NONE. + + +9. References + +9.1. Normative. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. + March 1999. + + [RFC3090] DNS Security Extension Clarification on Zone Status. + E. Lewis. March 2001. + + +9.2. Informative. + + [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS). D. Eastlake 3rd. May 2001. + + [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. + December 2001. + + [DS] Delegation Signer Resource Record. + O. Gudmundsson. October 2002. Work In Progress. + +10. Acknowledgments. + + Bill Manning came up with the original idea of moving complexity + from the signing side down to the resolver in the form of threshold + validation. I've also had much appreciated help from (in no + particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and + Olaf Kolkman. + + +11. Authors' Address +Johan Ihren +Autonomica AB +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se diff --git a/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt new file mode 100644 index 0000000000..e49d805ed1 --- /dev/null +++ b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt @@ -0,0 +1,386 @@ + + + Individual Submission + Internet Draft + Jae-Hoon Jeong + Jung-Soo Park + Kyeong-Jin Lee + Hyoung-Jun Kim + ETRI + Expires: August 2003 February 2003 + + + The Autoconfiguration of Recursive DNS Server and the Optimization of + DNS Name Resolution in Hierarchical Mobile IPv6 + + + Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 except that the right to + produce derivative works is not granted [1]. + + 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. + + Abstract + + This document provides the mechanism for the autoconfiguration of + recursive DNS server in mobile node and the optimization of DNS name + resolution in the hierarchical mobile IPv6 networks. Whenever the + mobile node moves into a new MAP domain, the region managed by + another MAP, in the hierarchical mobile IPv6 networks, it detects the + addresses of recursive DNS servers which are placed in the region and + replaces the old ones with the new ones for DNS name resolution. This + allows the time for DNS name resolution much reduced by using the + nearest DNS recursive server which exists in the region. Therefore, + the mechanism of this document can optimize the DNS name resolution. + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 1] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + Conventions used in this document + + 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 [2]. + + Table of Contents + + 1. Terminology....................................................2 + 2. Introduction...................................................2 + 3. Overview.......................................................3 + 4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4 + 5. Neighbor Discovery extension - RDNSS option message format.....4 + 6. RDNSS selection by the Mobile Node.............................5 + 7. Detection of RDNSS failure.....................................6 + 8. Security Considerations........................................6 + 9. References.....................................................6 + 10. Author's Addresses............................................7 + + 1. Terminology + + This memo uses the terminology described in [3]. In addition, a new + term is defined below: + + Recursive DNS Server (RDNSS) A Recursive DNS Server is a name server + that offers the recursive service of + DNS name resolution. + + 2. Introduction + + RFC 2462 [4] provides a way to autoconfigure either fixed or mobile + nodes with one or more IPv6 addresses and default routes. + + For the support of the various services in the Internet, not only the + configuration of IP address in network interface, but also that of + the recursive DNS server for DNS name resolution are necessary. + + Up to now, many mechanisms to autoconfigure recursive DNS server in + nodes have been proposed [5][6]. + + This document suggests not only the autoconfiguration of recursive + DNS server in mobile node that moves within the hierarchical mobile + IPv6 networks [3], but also the optimization of the DNS name + resolution in such networks. Whenever the mobile node moves into a + new MAP (Mobility Anchor Point) domain, the region managed by another + MAP, in the hierarchical mobile IPv6 networks, it detects the + addresses of recursive DNS servers which are placed in the region and + replaces the old ones with the new ones for DNS name resolution. This + allows the time for DNS name resolution much reduced by using the + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 2] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + nearest DNS recursive server which exists in the region. Like this, + because the mobile nodes use the recursive DNS server in the same + domain instead of the fixed recursive DNS server, the DNS name + resolution of the mobile nodes can be optimized. + + 3. Overview + + +-------+ +--------+ + | HA |---| RDNSS1 | + +-------+ +--------+ + | + | +----+ + | | CN | + | +----+ + +-----+ | + | | + | +---+ + | | + +-------+ + | MAP | RCoA + +-------+ + | | + | +--------+ + | | + | | + +-----+ +-----+ +--------+ + | AR1 | | AR2 |---| RDNSS2 | + +-----+ +-----+ +--------+ + + +----+ + | MN | + +----+ ------------> + Movement + + Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain + + Whenever a mobile node enters into a new MAP domain of the visited + network, it receives the RA message including MAP option from Access + Router (AR) and performs the local binding update with the new MAP. + If the list of the addresses of the recursive DNS server (RDNSS) is + included in the RA message with the MAP option, the mobile node can + detect the new RDNSSs and select one of them for the DNS name + resolution. Like Figure 1, this scheme can reduce considerably the + time of the name resolution between the mobile node and the RDNSS. + Because the mobile node uses the nearest RDNSS in the same MAP domain, + RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the + mobile node moves into another MAP domain, it replaces the old RDNSS + with the new RDNSS for the succeeding name resolutions. + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 3] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + 4. HMIPv6 extension - Advertisement of Recursive DNS Server + + Because this document considers only router advertisement for MAP + discovery, all ARs belonging to the MAP domain MUST advertise the + MAP's IP address. + + The information of the RDNSS in the MAP domain is stored in the MAP + by the network administrator and advertised as a new option through + the RA message with MAP option. There MAY be more than one RDNSS in a + MAP domain. A MAP advertises the RA message including the list of + RDNSSs in the same domain with MAP option. The RA message with MAP + and RDNSS options is propagated from the MAP to the mobile node + through certain (configured) router interfaces within the hierarchy + of routers. This would require manual configuration of the MAP and + RDNSS options in the MAP and also the routers receiving the MAN and + RDNSS options to allow them to propagate the options on certain + interfaces. + + Finally, the mobile node listening to RA messages receives the new RA + message and checks if the MAP is new or not. If the MAP is a new one, + the mobile node perceives it has moved into another MAP domain and + performs both the local binding update with the new MAP and the + update of the list of RDNSSs in the configuration of name resolution + with the new ones. From the next name resolution, the mobile node + uses the new RDNSSs. + + + 5. Neighbor Discovery extension - RDNSS option message format + + The mechanism of this document needs a new option in Neighbor + Discovery [7]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length( = 3) | Pref | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + IPv6 Address for RDNSS + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 4] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + Fields: + + Type Message type. TBA. + + Length 8-bit unsigned integer. The length of the + option (including the type and length fields) + in units of 8 octets. The default value is 3. + The value 0 is invalid. Nodes MUST silently + discard an ND packet that contains an option with + length zero. + + Pref The preference of an RDNSS. A 4 bit unsigned + integer. A decimal value of 15 indicates the + highest preference. A decimal value of 0 + indicates that the RDNSS can not be used. + + IPv6 Address for RDNSS + The RDNSS IPv6 address. The scope of the address + can be any scope. + i.e., link-local, site-local and global. + The prefix of the address is be /64. + + When advertising more than one RDNSS, as many RDNSS options as the + number of RDNSSs are included in an RA message. + + 6. RDNSS selection by the Mobile Node + + When a mobile node perceives multiple RDNSSs through RA message, it + stores the RDNSSs in order into the configuration the resolver on the + node uses for DNS name resolution on the basis of the value of "Pref" + field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS + option. The following algorithm is simply based on the rule of + selecting the nearest possible RDNSS, providing that its preference + value did not reach the maximum value of 15. When the distances are + the same, this algorithm uses the preference value to order the + RDNSSs. The mobile node operation is shown below: + + 1) Receive and parse all RDNSS options + + 2) Arrange RDNSSs in an ascending order, starting with the nearest + RDNSS and store them in the configuration for DNS name resolution + used by resolver. (i.e., the longest prefix matching between the + "IPv6 Address for RDNSS" field and mobile node's On-link CoA + (LCoA) MAY be used to decide the distance between mobile node and + RDNSS, how far away the mobile node is from the RDNSS.) + + 3) For each RDNSS entry, check the following; + - If the value of "Pref" field is set to zero, exclude the RDNSS + entry from the list of RDNSSs of the configuration for DNS name + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 5] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + resolution. + + Whenever the resolver on the mobile node performs the name resolution, + it refers to the address(es) of RDNSS in the configuration for name + resolution according to the current rule of selecting an RDNSS, + namely from the 1st RDNSS. + + 7. Detection of RDNSS failure + + A MAP placed in a MAP domain checks periodically if the RDNSSs + registered in the MAP are alive. Whenever the MAP detects the failure + of any RDNSS, it advertises the failure down to the hierarchy with a + new RA message including an RDNSS option of which "Pref" field has + zero for the RDNSS. When a mobile node receives the RA message, it + perceives that the RDNSS is out of work or the path to the RDNSS is + broken and excludes the RDNSS from the configuration for name + resolution. + + The dynamic detection of RDNSS failure in a MAP can be done by simply + pinging the RDNSS periodically (e.g., every ten seconds). If no + response is received, the MAP MAY try to aggressively ping the RDNSS + for a short period of time (e.g., once every 5 seconds for 15 + seconds); if no response is received, an RDNSS option MAY be sent + with a preference value of zero. + + 8. Security Considerations + + In order to guarantee the secure communication between routers, the + router advertisements sent between routers SHOULD be authenticated by + AH or ESP [3]. This security is essentially related to Neighbor + Discovery protocol security [7]. + + 9. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier, + "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- + ietf-mobileip-hmipv6-07.txt, October 2002. + + [4] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC2462. + + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 6] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + [5] A. Durand, J. itojun and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002. + + [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option", + draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003. + + [7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for + IP version 6", RFC 2461. + + 10. Author's Addresses + + Jae-Hoon Jeong + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 1664 + EMail: paul@etri.re.kr + + Jung-Soo Park + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6514 + EMail: pjs@etri.re.kr + + Kyeong-Jin Lee + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6484 + EMail: leekj@etri.re.kr + + Hyoung-Jun Kim + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6576 + EMail: khj@etri.re.kr + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 7] + \ No newline at end of file diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt new file mode 100644 index 0000000000..d857cd9580 --- /dev/null +++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt @@ -0,0 +1,295 @@ + + + +Internet Engineering Task Force Akira Kato, WIDE +INTERNET-DRAFT Paul Vixie, ISC +Expires: August 24, 2003 February 24, 2003 + + + Operational Guidelines for "local" zones in the DNS + draft-kato-dnsop-local-zones-00.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.'' + +To view the list Internet-Draft Shadow Directories, see +http://www.ietf.org/shadow.html. + +Distribution of this memo is unlimited. + +The internet-draft will expire in 6 months. The date of expiration will +be August 24, 2003. + + +Abstract + +A large number of DNS queries regarding to the "local" zones are sent +over the Internet in every second. This memo describes operational +guidelines to reduce the unnecessary DNS traffic as well as the load of +the Root DNS Servers. + +1. Introduction + +While it has yet been described in a RFC, .local is used to provide a +local subspace of the DNS tree. Formal delegation process has not been +completed for this TLD. In spite of this informal status, .local has +been used in many installations regardless of the awareness of the +users. Usually, the local DNS servers are not authoritative to the +.local domain, they end up to send queries to the Root DNS Servers. + +There are several other DNS zones which describe the "local" +information. .localhost has been used to describe the localhost for +more than a couple of decades and virtually all of the DNS servers are +configured authoritative for .localhost and its reverse zone .127.in- + + +KATO Expires: August 24, 2003 [Page 1] + + +DRAFT DNS local zones February 2003 + +addr.arpa. However, there are other "local" zones currently used in the +Internet or Intranets connected to the Internet through NATs or similar +devices. + +At a DNS server of an university in Japan, half of the DNS queries sent +to one of the 13 Root DNS Servers were regarding to the .local. At +another DNS Server running in one of the Major ISPs in Japan, the 1/4 +were .local. If those "local" queries are able to direct other DNS +servers than Root, or they can be resolved locally, it contributes the +reduction of the Root DNS Servers. + +2. Rationale + +Any DNS queries regarding to "local" names should not be sent to the DNS +servers on the Internet. + +3. Operational Guidelines + +Those queries should be processed at the DNS servers internal to each +site so that the severs respond with NXDOMAIN rather than sending +queries to the DNS servers outside. + +The "local" names have common DNS suffixes which are listed below: + +3.1. Local host related zones: + +Following two zones are described in [Barr, 1996] and .localhost is also +defined in [Eastlake, 1999] . + + o .localhost + o .127.in-addr.arpa + + +Following two zones are for the loopback address in IPv6 [Hinden, 1998] +. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush, +2001] , the old TLD .int has been used for this purpose for years +[Thomson, 1995] and many implementations still use .int. So it is +suggested that both zones should be provided for each IPv6 reverse +lookup zone for a while. + + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa + + +3.2. Locally created name space + +While the use of .local has been proposed in several Internet-Drafts, it +has not been described in any Internet documents with formal status. +However, the amount of the queries for .local is much larger than +others, it is suggested to resolve the following zone locally: + + + + +KATO Expires: August 24, 2003 [Page 2] + + +DRAFT DNS local zones February 2003 + + o .local + + + +3.3. Private or site-local addresses + +The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site- +local addresses [Hinden, 1998] should be resolved locally: + + o 10.in-addr.arpa + o 16.172.in-addr.arpa + o 17.172.in-addr.arpa + o 18.172.in-addr.arpa + o 19.172.in-addr.arpa + o 20.172.in-addr.arpa + o 21.172.in-addr.arpa + o 22.172.in-addr.arpa + o 23.172.in-addr.arpa + o 24.172.in-addr.arpa + o 25.172.in-addr.arpa + o 26.172.in-addr.arpa + o 27.172.in-addr.arpa + o 28.172.in-addr.arpa + o 29.172.in-addr.arpa + o 30.172.in-addr.arpa + o 31.172.in-addr.arpa + o 168.192.in-addr.arpa + o c.e.f.ip6.int + o d.e.f.ip6.int + o e.e.f.ip6.int + o f.e.f.ip6.int + o c.e.f.ip6.arpa + o d.e.f.ip6.arpa + o e.e.f.ip6.arpa + o f.e.f.ip6.arpa + + +3.4. Link-local addresses + +The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden, +1998] should be resolved locally: + + o 254.169.in-addr.arpa + o 8.e.f.ip6.int + o 9.e.f.ip6.int + o a.e.f.ip6.int + o b.e.f.ip6.int + o 8.e.f.ip6.arpa + o 9.e.f.ip6.arpa + o a.e.f.ip6.arpa + o b.e.f.ip6.arpa + + + +KATO Expires: August 24, 2003 [Page 3] + + +DRAFT DNS local zones February 2003 + +4. Suggestions to developers + +4.1. Suggestions to DNS software implementors + +In order to avoid unnecessary traffic, it is suggested that DNS software +implementors provide configuration templates or default configurations +so that the names described in the previous section are resolved locally +rather than sent to other DNS servers in the Internet. + +4.2. Suggestions to developers of NATs or similar devices + +There are many NAT or similar devices available in the market. +Regardless of the availability of DNS Servers in those devices, it is +suggested that those devices are able to filter the DNS traffic or +respond to the DNS traffic related to "local" zones by configuration +regardless of its ability of DNS service. It is suggested that this +functionality is activated by default. + +5. IANA Consideration + +While .local TLD has yet defined officially, there are substantial +queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the +traffic sent to the Root DNS Servers are related to the .local zone. +Therefore, while it is not formally defined, it is suggested that IANA +delegates .local TLD to an organization. + +The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918 +address and the link-local address. It has several DNS server instances +around the world by using BGP Anycast [Hardie, 2002] . So the AS112 +Project is one of the candidates to host the .local TLD. + +Authors' addresses + + Akira Kato + The University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + Tel: +81 3-5841-2750 + Email: kato@wide.ad.jp + + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063, USA + Tel: +1 650-779-7001 + Email: vixie@isc.org + + + + + + + +KATO Expires: August 24, 2003 [Page 4] + + +DRAFT DNS local zones February 2003 + +References + +To be filled + +References + +Barr, 1996. +D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912 +(February 1996). + +Eastlake, 1999. +D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999). + +Hinden, 1998. +R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in +RFC2373 (July 1998). + +Bush, 2001. +R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001). + +Thomson, 1995. +S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in +RFC1886 (December 1995). + +Rekhter, 1996. +Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, +"Address Allocation for Private Internets" in RFC1918 (February 1996). + +IANA, 2002. +IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002). + +Vixie, . +P. Vixie, "AS112 Project" in AS112. http://www.as112.net/. + +Hardie, 2002. +T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast +Addresses" in RFC3258 (April 2002). + + + + + + + + + + + + + + + + + +KATO Expires: August 24, 2003 [Page 5] + diff --git a/doc/draft/draft-klensin-idn-tld-00.txt b/doc/draft/draft-klensin-idn-tld-00.txt new file mode 100644 index 0000000000..cbe2e15b31 --- /dev/null +++ b/doc/draft/draft-klensin-idn-tld-00.txt @@ -0,0 +1,437 @@ +INTERNET-DRAFT John C Klensin +21 October 2002 +Expires April 2003 + + National and Local Characters in DNS TLD Names + draft-klensin-idn-tld-00.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026 except that the + right to produce derivative works is not granted. + + 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. + 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. + + +Abstract + + In the context of work on internationalizing the Domain Name System + (DNS), there have been extensive discussions about "multilingual" or + "internationalized" top level domain names (TLDs), especially for + countries whose predominant language is not written in a Roman-based + script. This document reviews some of the motivations for such + domains and the constraints that the DNS imposes. It then suggests + an alternative, local translation, that may solve a superset of the + problem while avoiding protocol changes, serious deployment delays, + and other difficulties. + +Table of Contents + +1 Introduction +1.1 Background on the "Multilingual Name" Problem +1.2 Domain Name System Constraints +1.3 Internationalization and Localization +2. Client-side solutions +2.1 IDNA and the client +2.2 Local translation tables for TLD names +3. Advantages and disadvantages of local translation +3.1 Every TLD in the local language and character set + +3.2 Unification of country code domains +3.3 User understanding of local and global reference +3.4 Limits on TLD propagation +4. Security Considerations +5. References +6. Acknowledgements +7. Author's Address + + +1. Introduction + +1.1 Background on the "Multilingual Name" Problem + +People who share a language prefer to communicate in it, using whatever +characters are normally used to write that language, rather than in some +"foreign" one. There have been standards for using mutually-agreed +characters and languages in electronic mail message bodies and selected +headers since the introduction of MIME in 1992 [MIME] and the Web has +permitted multilingual text since its inception. However, since domain +names are exposed to users in email addresses and URLs, and +corresponding arrangements in other protocols, demand rapidly arose to +permit domain names in applications that used characters other than +those of the very restrictive, ASCII-subset, "LDH" conventions [LDH]. +The effort to do this rapidly became known as "multilingual domain +names", although that is a misnomer, since the DNS deals only with +characters and identifier strings, and not, except by accident, what +people usually think of as "names". And there has been little actual +interest in what would actually be a "multilingual name" -- i.e., a name +that contains components from more than one language -- but only the use +of strings conforming to different languages in the context of the DNS. + +1.1.1 Approaches to the requirement + +If the requirement is seen, not as "modifying the DNS", but as +"providing users with access to the DNS from a variety of languages and +character sets", three sets of proposals have emerged in the IETF and +elsewhere. They are: + + (1) Perform processing in client software that recodes a user-visible + string into an ASCII-compatible form that can safely be passed + through the DNS protocols and stored in the DNS. This is the + approach used, for example, in the IETF's "IDNA" protocol [IDNA]. + + (2) Modify the DNS to be more hospitable to non-ASCII names and + strings. There have been a variety of proposals to do this in almost + as many ways, some of which have been implemented on a proprietary + basis by various vendors. None of them have gained acceptance in the + IETF community, primarily because they would take a long time to + deploy and would leave many problems unsolved. + + (3) Move the problem out of the DNS entirely, relying instead on a + "directory" or "presentation" layer to handle internationalization. + The rationale for this approach is discussed in [DNSROLE]. + +This document proposes a fourth approach, applicable to the top level +domains (TLDs) only (see section 1.2.1 for a discussion of the special +issues that make TLDs problematic). That approach could be used as an +alternate or supplement to the strategies summarized above. + + +1.1.2 Writing the name of one's country in its own characters + +An early focus of the "multilingual domain name" efforts was expressed +in statements such as "users in my country, in which ASCII is rarely +used, should be able to write an entire domain name in their own +character set. In particular, since all top-level domain names, at +present, follow the LDH rules, the somewhat more restrictive naming +rules discussed in [STD3], and the coding conventions specified in +[RFC1591], all fully-qualified DNS names were effectively required to +contain at least one ASCII label (the TLD name), and that was considered +inappropriate. One should, instead, be able to write the name of the +ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in +Arabic, and so on. + +1.1.3 Countries with multiple languages and countries with multiple + names + +>From a user interface standpoint, writing ccTLD names in local +characters is a problem. As discussed in section 1.2.2, the DNS itself +does not easily permit a domain to be referred to by more than one name +(or spelling or translation of a name). Countries with more than one +official language would require that the country name be represented in +each of those languages. And, just as it is important that a user in +China be able to represent the name of the Chinese ccTLD in Chinese +characters, she should be able to access a Chinese-language site in +France using Chinese characters, requiring that she be able to write the +name of the French ccTLD in those characters rather than in a form based +on a Roman character set. + + +1.2 Domain Name System Constraints + +1.2.1 Administrative hierarchy + +The domain name system is designed around the idea of an "administrative +hierarchy", with the entity responsible for a given node of the +hierarchy responsible for policies applicable to its subhierarchies (Cf. +[STD13]). The model works quite well for the domain and subdomains of a +particular enterprise, where the hierarchy can be organized to match the +organizational structure, there are established ways to set policies and +there is, at least presumably, shared assumptions about overall goals +and objectives among all registrants in the domain. It is more +problematic when a domain is shared by unrelated entities which lack +common policy assumptions. It is difficult to reach agreement on rules +that should apply to all of them. That situation always prevails for +the labels registered in a TLD (second-level names) except in those TLDs +for which the second level is structural (e.g., the .CO, .AC, .GOV +conventions in many ccTLD) in which case, it exists for the labels +within that structural level. + +TLDs may, but need not, have consistent registration policies for those +second (or third) level names. Countries (or ccTLD administrators) have +often adopted rules about what entities may register in those ccTLDs, +and the forms the names may take. RFC 1591 outlined registration norms +for most of the gTLDs, even though those norms have been largely ignored +in recent years. And some recent "sponsored" domains are based on quite +specific rules about appropriate registrations. Homogeneous + +registration rules for the root are, by contrast, impossible: almost by +definition, the subdomains registered in it are diverse and no single +policy applying to all root subdomains (TLDs) is feasible. + +1.2.2 Aliases + +In an environment different from the DNS, a rational way to permit +assigning local-language names to a country code (or other) domain would +be to set up an alias for the name, or to use some sort of "see instead" +reference. But the DNS does not have quite the right facilities for +either. Instead, it supports a "CNAME" record, whose label can refer +onto to a particular label and not to a subtree. For example, if A.B.C +is a fully-qualified name, then a CNAME reference from X to A would make +X.B.C appear to have the same values as A.B.C. However, a CNAME +reference from Y to C would not make A.B.Y referenceable (or even +defined) at all. A second record type, DNAME [RFC2672], can provide an +alias for a portion of the tree. But it is problematic technically, and +its use is strongly discouraged except for transition uses from one +domain to another. + + +1.3 Internationalization and Localization + +It has often been observed that while many people talk about +"internationalization" (a term we typically use for making something +globally accessible while incorporating a broad-range "universal" +character set and conventions appropriate to all languages), they often really +mean, and want, "localization" (making things work well in a particular +locality, or well, but potentially differently, for a broad range of +localities). Anything that actually involves the DNS must be global and +hence internationalized since the DNS cannot meaningfully support +different responses based, e.g., on the location of the user making a +query. While the DNS cannot support localization internally, many of +the features discussed earlier in this section are much more easily +thought about in local terms --whether localized to a geographical area, +users of a language, or using some other criteria -- than in global ones. + +2. Client-side solutions + +Traditionally, the IETF has avoided becoming involved in standardization +for actions that take place strictly on individual hosts on the network, +assuming that it should confine itself to behavior that is observable +"on the wire", i.e., in protocols between network hosts. Exceptions to +this general principle have been made when different clients were +required to utilize data or interpret values in compatible ways to +preserve interoperability: the standards for email and web body formats, +and IDNA itself, are examples of these exceptions. Regardless of what +is required to be standardized, it is almost never required, and often +unwise, that a user interface, by default, present on-the-wire formats +to the user. However, in most cases when the presentation format and +the wire format differ, the client program must take precautions that +the wire format can be reconstructed from user input, or to keep the +wire format, while hidden, bound to the presentation mechanism so that +it can be reconstructed. And, while it is rarely a goal in itself, it +is often necessary that the user be at least vaguely aware that the wire +("real") format is different from the presentation one and that the wire +format be available for debugging. + + +2.1 IDNA and the client + +As mentioned above, IDNA itself is entirely a client-side protocol. It +works by providing labels to the DNS in a special format (so-called +"ACE"). When labels in that format are encountered, they are +transformed, by the client, back into internationalized (normally +Unicode) characters. In the context of this document, the important +obvservation about IDNA is that any application program that supports it +is already doing considerable transformation work on the client; it is +not simply presenting the on-the-wire formats to the user. + + +2.2 Local translation tables for TLD names + +We suggest that, in addition to maintaining the code and tables required +to support IDNA, clients may want to maintain a table that contains a +list of TLDs and that maps between them and locally-desirable names. +For ccTLDs, these might be the names (or locally-standard abbreviations) +by which the relevant countries are known locally (whether in ASCII +characters or others). With some care on the part of the application +designer (e.g., to ensure that local forms do not conflict with the +actual TLD names), a particular TLD name input from the user could be +either in local or standard form without special tagging or problems. +When DNS names are received by these client programs, the TLD labels +would be mapped to local form before IDNA is applied to the rest of the +name; when names are received from users, local TLD names would be +mapped to the global ones before being passed into IDNA or for other DNS +processing. + + +3. Advantages and disadvantages of local translation + +3.1 Every TLD in the local language and character set + +The notion of a top-level domain whose name matches, e.g., the name that +is used for a country in that country or the name of a language in that +language as, as mentioned above, immediately appealing. But most of the +reasons for it argue equally strongly for other TLDs being accessible +from that language. A user in Korea who can access the national ccTLD +in the Korean language and character set has every reason to expect that +both generic top level domains and and domains associated with other +countries would be similarly accessible, especially if the second-level +domains bear Korean names. A user in Spain or Portugal, or in Latin +America, would presumably have similar expectations, but would expect to +use Spanish names, not Korean ones. + +That level of local optimization is not realistic --some would argue not +possible-- with the DNS since it would ultimately require that every top +level domain be replicated for each of the world's languages. That +replication process would involve not just the top level domain itself: +in principle, all of its subtrees would need to be completely replicated +as well (or at least all of the subtrees for which a the language +associated with the a given replicant was relevant). The administrative +hierarchy characteristics of the DNS (see section 1.2.1) turn the +replication process into an administrative nightmare: every +administrator of a second-level domain in the world would be forced to +maintain dozens, probably hundreds, of similar zone files for the the +replicates of the domain. Even if only the zones relevant to a + +particular country or language were replicated, the administrative and +tracking problems to bind these to the appropriate top-level domain and +keep all of the replicas synchronized would be extremely difficulty at +best. And many administrators of third- and fourth-level domains, and +beyond, would be faced with similar problems. + +By contrast, dealing with the names of TLDs as a localization problem, +using local translation, is fairly simple. Each function represented by +a TLD -- a country, generic registrations, or purpose-specific +registrations -- could be represented in the local language and +character set as needed. And, for countries with many languages, or +users living, working, or visiting countries where their language was +not dominant, "local" could be defined in terms of the needs or wishes +of each particular user. + +3.2 Unification of country code domains + +It follows from some of the comments above that, while there appears to +be some immediate appeal from having (at least) two domains for each +country, one using the ISO 3166-1 code and another one using a name +based on the national name in the national language, such a situation +would create considerable problems for registrants in the multiple +domains. For registrants maintaining enterprise or organizational +subdomains, ease of administration in a single family of zone files will +usually make a registration in a single top-level domain preferable to +replicated sets of them, at least as long as their functional +requirements (such a local-language access) are met by the unified +structure. + +Of course, having replicated domains might be popular with registries +and registrars, since replication would almost inevitably increase the +total number of domains to be registered. + +3.3 User understanding of local and global references + +While the IDNA tables (actually Nameprep and Stringprep -- see the IDNA +specification) must be identical globally for IDNA to work reliably, the +tables for mapping between local names and TLD names could be locally +determined, and differ from one locale to another, as long as users +understood that international interchange of names required using the +standard forms. That understanding could be assisted by software. It +is likely that, at least for the foreseeable future, DNS names being +passed among users in different countries, or using different languages, +will be forced to be in ACE form to guarantee compatibility in any +event, so the marginal knowledge or effort needed to put TLD names into +standard form and transmit them that way would be very small. + +3.4 Limits on TLD propagation + +The concept of using local translation does have one side-effect, which +some portions of the Internet community might consider undesirable. +The size and complexity of translation tables, and maintaining those +tables, will be, to a considerable extent, a function of the number of +top-level domains, the frequency with which new domains are added, and +the number of domains that are added at a time. A country or other +locale that wished to maintain a few set of translations (i.e., so that +every TLD had a representation in the local language) would presumably +find setting up a table for the current collection of a few hundred + +domains to be a task that would take some days. If the number of TLDs +was relatively stable, with a relatively small number being added at +infrequent intervals, the updates could probably be dealt with on an ad +hoc basis. But, if large numbers of domains were added frequently, or +if the total number of TLDs became very large, maintaining the table +might require dedicated staff. Worse, updating the tables stored on +client machines might require update and synchronization protocols and +all of the related complexities. + +4. Security Considerations + +IDNA provides a client-based mechanism for presenting Unicode names in +applications while passing only ASCII-based names on the wire. As such, +it constitutes a major step along the path of introducing a client-based +presentation layer into the Internet. Client-based presentation layer +transformations introduce risks from variant tables that can change +meaning without external protection. For example, if a mapping table +normally maps A onto C and that table is altered by an attacker so that +A maps onto D instead, much mischief can be committed. On the other +hand, these are not the usual sort of network attacks: they may be +thought of as falling into the "users can always cause harm to +themselves" category. The local translation model outlined here does +not significantly increase the risks over those associated with IDNA, +but may provide some new avenues for exploiting them. + +Both this approach and IDNA rely on having updated programs present +information to the user in a very different form than the one in which +it is transmitted on the wire. Unless the internal (wire) form is +always used in interchange, there are possibilities for ambiguity and +confusion about references. + +5. References + +[DNSROLE] Klensin, J.C., "Role of the Domain Name System", work in + progress (draft-klensin-dns-role-04.txt). + +[IDNA] Faltstorm, F., P. Hoffman, A. M. Costello, "Internationalizing + Domain Names in Applications (IDNA)", work in progress + (draft-ietf-idn-idna-13.txt) + +[LDH] STD13 and comments + +[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail + Extensions): Mechanisms for Specifying and Describing the Format of + Internet Message Bodies", RFC 1341, June 1992. Updated and replaced + by Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC2045, November 1996. Also, Moore, K., "Representation of + Non-ASCII Text in Internet Message Headers", RFC 1342, June 1992. + Updated and replaced by Moore, K., "MIME (Multipurpose Internet + Mail Extensions) Part Three: Message Header Extensions for + Non-ASCII Text", RFC 2047, November 1996. + +[RFC1591] Postel, J., "Domain Name System Structure and Delegation", + RFC1591, March 1994. + +[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, + August 1999. + + +[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Application and + Support", RFC1123, October 1989. + +[STD13] Mockapetris, P.V., 1034 "Domain names - concepts and + facilities", RFC 1034, and "Domain names - implementation and + specification", RFC 1035, November 1987. + +6. Acknowledgements + +This document was inspired by a number of conversations in ICANN, IETF, +MINC, and private contexts about the future evolution and +internationalization of top level domains. Discussions within, and +about, the ICANN IDN Committee have been particularly helpful, although +several of the members of that committee may be surprised about where +those discussions led. + +7. Author's Address + +John C Klensin +1770 Massachusetts Ave, #322 +Cambridge, MA 02140 USA +email: john+ietf@jck.com + diff --git a/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt b/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt new file mode 100644 index 0000000000..bf5cab20d6 --- /dev/null +++ b/doc/draft/draft-lewis-dns-wildcard-clarify-00.txt @@ -0,0 +1,599 @@ + +Internet Engineering Task Force E. Lewis +Internet-Draft ARIN +February 4, 2003 Expires: August 4, 2003 + + Clarifying the Role of Wild Card Domains + in the Domain Name System + + +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. + +Abstract + +The definition of wild cards is recast from the original in RFC 1034, +in words that are more specific and in line with RFC 2119. This document +is meant to supplement the definition in RFC 1034 and to alter neither +the spirit nor intent of that definition. + +1 Introduction + +The first section of this document will give a crisp overview of what +is begin defined, as well as the motivation for what amounts to a +simple rewording of an original document. An example is included to +help orient the reader. + +Wild card domain names are defined in Section 4.3.3. of RFC 1034 as +"instructions for synthesizing RRs." [RFC1034] The meaning of this is +that a specific, special domain name is used to construct responses in +instances in which the query name is not otherwise represented in a zone. + +A wild card domain name has a specific range of influence on query names +(QNAMEs) within a given class, which is rooted at the domain name +containing the wild card label, and is limited by explicit entries, zone +cuts and empty non-terminal domains (see section 1.3 of this document). + +Note that a wild card domain name has no special impact on the search +for a query type (QTYPE). If a domain name is found that matches the +QNAME (exact or a wild card) but the QTYPE is not found at that point, +the proper response is that there is no data available. The search +does not continue on to seek other wild cards that might match the QTYPE. +To illustrate, a wild card owning an MX RR does not 'cover' other names +in the zone that own an A RR. + +Why is this document needed? Empirical evidence suggests that the +words in RFC 1034 are not clear enough. There exist a number of +implementations that have strayed from the definition. There also +exists a misconception of operators that the wild card can be used to +add a specific RR type to all names, such as the MX RR example listed +above. This document is also needed as input to efforts to extend +DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear +base specification has proven to result in extension documents that +have unpredictable consequences. (This is true in general, not just +for DNS.) + +1.1 Existence + +The notion that a domain name 'exists' will arise numerous times in this +discussion. RFC 1034 raises the issue of existence in a number of places, +usually in reference to non-existence and often in reference to processing +involving wild card domain names. RFC 1034 does contain algorithms that +describe how domain names impact the preparation of an answer and does +define wild cards as a means of synthesizing answers. + +To help clarify the topic of wild cards, a positive definition of existence +is needed. To complicate matters, though, there needs to be a recognition +that existence is relative. To an authoritative server, a domain name +exists if the domain name plays a role following the algorithms of +preparing a response. To a resolver, a domain name exists if there is +any data available corresponding to the name. The difference between the +two is the synthesis of records according to a wild card. + +For the purposes of this document, the point of view of an authoritative +server is adopted. A domain name is said to exist if it plays a role in +the execution of the algorithms in RFC 1034. + +1.2 An Example + +For example, consider this wild card domain name: *.example. Any query +name under example. is a candidate to be matched (answered) by this wild +card. Although any name is a candidate, not all queries will match. + +To further illustrate this, consider this example: + + $ORIGIN example. + @ IN SOA + NS + NS + * TXT "this is a wild card" + MX 10 mailhost.example. + host1 A 10.0.0.1 + _ssh._tcp.host1 SRV + _ssh._tcp.host2 SRV + subdel NS + +The following queries would be synthesized from the wild card: + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host.example. IN MX ..." + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will be a "host.example. IN NXT ..." + because there is no A RR set at '*' + +The following queries would not be synthesized from the wild card: + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN + because host2.example. exists (without data) + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists and is a zone cut + +To the server, the following domains are considered to exist in the zone: +*, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2, +and subdel. To a resolver, many more domains appear to exist via the +synthesis of the wild card. + +1.3 Empty Non-terminals + +Empty non-terminals are domain names that have no data but have +subdomains. This is defined in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on the +# tree corresponds to a resource set (which may be empty). The domain +# system makes no distinctions between the uses of the interior nodes and +# leaves, and this memo uses the term "node" to refer to both. + +The parenthesized "which may be empty" specifies that empty non-terminals +are explicitly recognized. According to the definition of existence in +this document, empty non-terminals do exist at the server. + +Carefully reading the above paragraph can lead to an interpretation that +all possible domains exist - up to the suggested limit of 255 octets for +a domain name [RFC 1035]. For example, www.example. may have an A RR, and +as far as is practically concerned, is a leaf of the domain tree. But the +definition can be taken to mean that sub.www.example. also exists, albeit +with no data. By extension, all possible domains exist, from the root +down. As RFC 1034 also defines "an authoritative name error indicating +that the name does not exist" in section 4.3.1, this is not the intent +of the original document. + +RFC1034's wording is to be clarified by adding the following paragraph: + + A node is considered to have an impact on the algorithms of 4.3.2 + if it is a leaf node with any resource sets or an interior node, + with or without a resource set, that has a subdomain that is a leaf + node with a resource set. A QNAME and QCLASS matching an existing + node never results in a response return code of authoritative name + error. + +As an aside, an "authoritative name error" has been called NXDOMAIN in +some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned +to such an error by at least one implementation of DNS. + +1.3 Terminology + +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 the document entitled +"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] + +Requirements are denoted by paragraphs that begin with with the following +convention: 'R'.. + +2 Defining the Wild Card Domain Name + +A wild card domain name is defined by having the initial label be: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + +This defines domain names that may play a role in being a wild card, that +is, being a source for synthesized answers. Domain names conforming to +this definition that appear in queries and RDATA sections do not have +any special role. These cases will be described in more detail in +following sections. + +R2.1 A domain name that is to be interpreted as a wild card MUST begin + with a label of '0000 0001 0010 1010' in binary. + +The first octet is the normal label type and length for a 1 octet long +label, the second octet is the ASCII representation [RFC 20] for the +'*' character. In RFC 1034, ASCII encoding is assumed to be the character +encoding. + +In the master file formats used in RFCs, a "*" is a legal representation +for the wild card label. Even if the "*" is escaped, it is still +interpreted as the wild card when it is the only character in the label. + +R2.2. A server MUST treat a wild card domain name as the basis of + synthesized answers regardless of any "escape" sequences in + the input format. + +RFC 1034 and RFC 1035 ignore the case in which a domain name might be +"the*.example.com." The interpretation is that this domain name in a +zone would only match queries for "the*.example.com" and not have any +other role. + +Note: By virtue of this definition, a wild card domain name may have a +subdomain. The subdomain (or sub-subdomain) itself may also be a wild +card. E.g., *.*.example. is a wild card, so is *.sub.*.example. +More discussion on this is given in Appendix A. + +3 Defining Existence + +As described in the Introduction, a precise definition of existence is +needed. + +R3.1 An authoritative server MUST treat a domain name as existing during + the execution of the algorithms in RFC 1034 when the domain name + conforms to the following definition. A domain name is defined + to exist if the domain name owns data and/or has a subdomain that + exists. + +Note that at a zone boundary, the domain name owns data, including the +NS RR set. At the delegating server, the NS RR set is not authoritative, +but that is of no consequence here. The domain name owns data, therefore, +it exists. + +R3.2 An authoritative server MUST treat a domain name that has neither + a resource record set nor a subdomain as nonexistent when executing + the algorithm in section 4.3.2. of RFC 1034. + +4 Impact of a Wild Card Domain In a Query Message + +When a wild card domain name appears in a question, e.g., the query name +is "*.example.", the response in no way differs from any other query. +In other words, the wild card label in a QNAME has no special meaning, +and query processing will proceed using '*' as a literal query name. + +R4.1 A wild card domain name acting as a QNAME MUST be treated as any + other QNAME, there MUST be no special processing accorded it. + +If a wild card domain name appears in the RDATA of a CNAME RR or any +other RR that has a domain name in it, the same rule applies. In the +instance of a CNAME RR, the wild card domain name is used in the same +manner of as being the original QNAME. For other RR's, rules vary +regarding what is done with the domain name(s) appearing in them, +in no case does the wild card hold special meaning. + +R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated + as any other domain name in that situation, there MUST be no special + processing accorded it. + +5 Impact of a Wild Card Domain On a Response + +The description of how wild cards impact response generation is in RFC +1034, section 4.3.2. That passage contains the algorithm followed by a +server in constructing a response. Within that algorithm step 3, part +'c' defines the behavior of the wild card. The algorithm is directly +quoted in lines that begin with a '#' sign. Commentary is interleaved. + +[Note that are no requirements specifically listed in this section. The +text here is explanatory and interpretative. There is no change to +the algorithm specified in RFC 1034.] + +The context of part 'c' is that the search is progressing label by label +through the QNAME. (Note that the data being searched is the authoritative +data in the server, the cache is searched in step 4.) Step 3's part 'a' +covers the case that the QNAME has been matched in full, regardless of the +presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting +in a referral. All that is left is to look for the wild card. + +Step 3 of the algorithm also assumes that the search is looking in the +zone closest to the answer, i.e., in the same class as QCLASS and as +close to the authority as possible on this server. If the zone is not +the authority, then a referral is given, possibly one indicating lameness. + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if a +# the "*" label exists. + +The above paragraph refers to finding the domain name that exists in the +zone and that most encloses the QNAME. Such a domain name will mark the +boundary of candidate wild card domain names that might be used to +synthesize an answer. (Remember that at this point, if the most enclosing +name is the same as the QNAME, part 'a' would have recorded an exact +match.) The existence of the enclosing name means that no wild card name +higher in the tree is a candidate to answer the query. + +Once the closest enclosing node is identified, there's the matter of what +exists below it. It may have subdomains, but none will be closer to the +QNAME. One of the subdomains just might be a wild card. If it exists, +this is the only wild card eligible to be used to synthesize an answer +for the query. Even if the closest enclosing node conforms to the syntax +rule in section 2 for being a wild card domain name, the closest enclosing +node is not eligible to be a source of a synthesized answer. + +The only wild card domain name that is a candidate to synthesize an answer +will be the "*" subdomain of the closest enclosing domain name. Three +possibilities can happen. The "*" subdomain does not exist, the "*" +subdomain does but does not have an RR set of the same type as the QTYPE, +or it exists and has the desired RR set. + +For the sake of brevity, the closest enclosing node can be referred to as +the "closest encloser." + +To illustrate, using the example in section 1.2 of this document, the +following chart shows QNAMEs and the closest enclosers. In Appendix A +there is another chart showing unusual cases. + + QNAME Closest Encloser Wild Card Source + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no wild card + _telnet._tcp.host2.example. host2.example. no wild card + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + +Note that host1.subdel.example. is in a subzone, so the search for it ends +in a referral in part 'b', thus does not enter into finding a closest +encloser. + +The fact that a closest encloser will be the only superdomain that +can have a candidate wild card will have an impact when it comes to +designing authenticated denial of existence proofs. (This concept +is not introduced until DNS Security Extensions are considered in +upcoming sections.) + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. + +The above passage says that if there is not even a wild card domain name +to match at this point (failing to find an explicit answer elsewhere), +we are to return an authoritative name error at this point. If we were +following a CNAME, the specification is unclear, but seems to imply that +a no error return code is appropriate, with just the CNAME RR (or sequence +of CNAME RRs) in the answer section. + +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + +This final paragraph covers the role of the QTYPE in the process. Note +that if no resource record set matches the QTYPE the result is that no data +is copied, but the search still ceases ("Go to step 6."). + +6 Authenticated Denial and Wild Cards + +In unsecured DNS, the only concern when there is no data to return to +a query is whether the domain name from which the answer comes exists or +not, whether or not a name error is indicated in the return code. In +either case the answer section is empty or contained just a sequence of +CNAME RR sets. + +In securing DNS, authenticated denial of existence is a service that is +provided. The chosen solution to provide this service is to generate +resource records indicating what is protected in a zone and to digitally +sign these. + +The resource records that do this, as defined in RFC 2535, are NXT RRs. + +There are three points to consider when clarifying the topic of wild card +domain names. One is the construction of the records. The second is +the inclusion of records in responses. The third is the interpretation +of the records in a response by the resolver. + +6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs + +During the creation of the authenticated denial records, the wild card +domain name plays no special role, in the same manner as the wild card +domain name playing no special role in a query. + +There is one consideration with regards to preparing non-existence +proofs. + +R6.1 Any mechanism used to provide authenticated denial MUST reveal the + closest enclosing existing domain for the query. If this is not + provided, the resolver will not be able to ascertain the identity + of an appropriate wild card domain name. + +6.2 Role of Wild Cards in Answers + +There are three cases to address. The first is synthesizing from wild card +domain name with data, the second is negatively synthesizing from an +existing wild card, and the third is denying that neither an exact match, +referral, nor wild card exist to answer the query. + +6.2.1 Synthesizing From a Wild Card + +When preparing an answer from a wild card domain name, the answer needs +to include proof that the exact match of the QNAME and QCLASS does not +exist. This is needed because synthesis of the answer replaces the "*" +label with the QNAME without securing the result. The resolver will +realize that the answer was derived from a wild card, but cannot +detect whether an exact match was maliciously omitted. + +R6.2 When synthesizing a positive answer from a wild card domain name, the + answer MUST include proof that the exact match for the QNAME and + QCLASS does not exist. + +6.2.2. Synthesizing Negatively From a Wild Card + +When synthesizing a negative answer that is derived from a wild card, +meaning that a wild card matched the QNAME (no exact match happened for +QNAME) but that there is no match for QTYPE there, two negative answers +are needed, possibly one. As in 6.2.1, a proof that the exact match +failed is needed. A second proof is needed to show that the wild card +domain name does not have the QTYPE. Depending on the method of +authenticated denial, these this could be possible with one statement. + +R6.3 When synthesizing a negative answer from a wild card domain name, + the answer MUST include proof that the exact match of the QNAME + and QCLASS does not exist and that the QTYPE matches no RR set at + the wild card. If this answer can be optimized, an implementation + SHOULD reduce the number of records included in the response. + +6.2.3. Answering With an Authoritative Name Error + +When answering with a result code of a name error, the answer needs to +provide proof that neither the exact match for QNAME and QCLASS exists +nor that a wild card domain name exists as a subdomain of the closest +enclosing domain name. + +R6.4 When preparing a reply with an authoritative name error, the answer + MUST include proof that the exact match for the QNAME and QCLASS + does not exist and that no wild card is available to provide a match. + +6.2.4. The Remaining Case + +When answering negatively because there is a match for QNAME and QCLASS +but no match for the QTYPE, only a proof for that is needed. Just as +the search does not proceed onto a search for the wild card in this +case, neither does the construction of the negative answer proof. + +R6.5 When preparing a reply in which there is an exact match of the + QNAME and QCLASS, but there is no RR set matching the QTYPE, + the reply SHOULD NOT contain any proof regarding the wild card + domain name. + +6.3 Interpreting Negative Answers Involving Wild Cards + +There are two requirements for resolvers when it comes to handling +negative answers generated as described in section 6.2. + +R6.6 A resolver MUST be able to identify negative answer data that + indicate when a match for QNAME and QCLASS does not exist. + +R6.7 From a negative answer, a resolver MUST be able to determine + the closest enclosing domain name in a negative answer and + MUST be able to process a negative answer involving the one + wild card domain name that is a candidate to provide a + synthesized answer. + +6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In + +When considering the Opt-In proposal [WIP], it is wise to not combine +a zone that adheres to both opt-in and that has a wild card domain +name. The reason is rooted in that the synthesis of an answer is done +by substituting the QNAME for the wild card domain name in the answer. +Because this is unsecured, and the is ambiguity regarding whether a +negative proof can be provided for the exact match (when it is outside +the opt-in secured area), a definitive proof of authenticated denial +is not possible. + +7 Security Considerations + +This document is refining the specifications to make it more likely that +security can be added to DNS. No functional additions are being made, +just refining what is considered proper to allow the system, security +of the system, and extending the system more predictable. + +8 References + +Normative References + +[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 +[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, + Nov-01-1987 +[RFC 1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 +[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S + Bradner, March 1997 + +Non-normative References + +[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, + Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 +[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 +[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002 + +9 Other Contributing to This Document + +Others who have directly caused text to appear in the document: Paul Vixie +and Olaf Kolkman. Many others have indirect influences on the content. + +10 Editor + +Name: Edward Lewis +Title: Research Engineer +Affiliation: ARIN +Email: edlewis@arin.net +Phone: +1-703-227-9854 + +Appendix A: Subdomains of Wild Card Domain Names + +In reading the definition of section 2 carefully, it is possible to +rationalize unusual names as legal. In the example given, *.example. +could have subdomains of *.sub.*.example. and even the more direct +*.*.example. (The implication here is that these domain names own +explicit resource records sets.) Although defining these names is not +easy to justify, it is important that implementations account for the +possibility. This section will give some further guidance on handling +these names. + +The first thing to realize is that by all definitions, subdomains of +wild card domain names are legal. In analyzing them, one realizes +that they cause no harm by their existence. Because of this, they are +allowed to exist, i.e., there are no special case rules made to disallow +them. The reason for not preventing these names is that the prevention +would just introduce more code paths to put into implementations. + +The concept of "closest enclosing" existing names is important to keep in +mind. It is also important to realize that a wild card domain name can +be a closest encloser of a query name. For example, if *.*.example. is +defined in a zone, and the query name is a.*.example., then the closest +enclosing domain name is *.example. Keep in mind that the closest +encloser is not eligible to be a source of synthesized answers, just the +subdomain of it that has the first label "*". + +To illustrate this, the following chart shows some matches. Assume that +the names *.example., *.*.example., and *.sub.*.example. are defined +in the zone. + + QNAME Closest Encloser Wild Card Source + a.example. example. *.example. + b.a.example. example. *.example. + a.*.example. *.example. *.*.example. + b.a.*.example. *.example. *.*.example. + b.a.*.*.example. *.*.example. no wild card + a.sub.*.example. sub.*.example. *.sub.*.example. + b.a.sub.*.example. sub.*.example. *.sub.*.example. + a.*.sub.*.example. *.sub.*.example. no wild card + *.a.example. example. *.example. + a.sub.b.example. example. *.example. + +Recall that the closest encloser itself cannot be the wild card. Therefore +the match for b.a.*.*.example. has no applicable wild card. + +Finally, if a query name is sub.*.example., any answer available will come +from an exact name match for sub.*.example. No wild card synthesis is +performed in this case. + +Full Copyright Statement + + Copyright (C) The Internet Society 2003. 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 + 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 + 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 + Internet organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights defined + in the Internet Standards process must be followed, or as required to + translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT + NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN + WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +-- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- +Edward Lewis +1-703-227-9854 +ARIN Research Engineer + diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt new file mode 100644 index 0000000000..f9eaf26819 --- /dev/null +++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt @@ -0,0 +1,1830 @@ + + + + INTERNET-DRAFT S. Daniel Park + Expires: October 2003 Syam Madanapalli + File: SAMSUNG Electronics + draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 + + + + + IPv6 Extensions for DNS Plug and Play + + + + 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. + + + + Abstract + + This document proposes automatic configuration of domain name (FQDN) + for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as + a part of IPv6 plug and play feature. 6DNAC allows the automatic + registration of domain name and corresponding IPv6 Addresses with + the DNS server. In order to provide 6DNAC function, Neighbor Discovery + Protocol [2461] will be used. Moreover, 6DNAC does not require any + changes to the existing DNS system. + + + Table of Contents + + 1. Introduction ............................................. 3 + 2. Terminology .............................................. 3 + 3. 6DNAC Design Principles .................................. 4 + 4. 6DNAC Overview ........................................... 4 + 5. 6DNAC Requirements ....................................... 5 + 5.1. 6DANR Client Requirements ................................ 5 + 5.2. 6DNAC Server Requirements ................................ 6 + +Park & Madanapalli Expires October 2003 [Page 1] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6. 6DNAC Messages and Option Formats ........................ 6 + 6.1. Router Advertisement (RA) Message Format ................. 6 + 6.2. Neighbor Solicitation (NS) Message Format ................ 7 + 6.3. Neighbor Advertisement (NA) Message Format ............... 8 + 6.4. Option Formats ........................................... 8 + 6.4.1. DNS Zone Suffix Information Option Format ................ 8 + 6.4.2. Domain Name (FQDN) Option Format ......................... 9 + 6.4.3. Router Alert Option for 6DNAC ............................ 10 + 7. 6DNAC Operation .......................................... 10 + 7.1. 6DNAC Network Topology ................................... 11 + 7.2. 6DNAC Operational Scenarios .............................. 12 + 7.2.1. Domain Name Registration-Success Case .................... 12 + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 + 7.2.3. Domain Name Registration-Defend Case ..................... 16 + 7.2.4. Domain Name Registration in Retry Mode ................... 19 + 7.2.5. Domain Name Registration when DAD Fails .................. 20 + 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 + 7.3.1. Sending Router Advertisement Messages .................... 22 + 7.3.2. Processing Router Advertisement Messages ................. 22 + 7.3.3. FQDN Lifetime expiry ..................................... 23 + 7.3.4. Host Naming Algorithm .................................... 23 + 7.4. Duplicate Domain Name Detection .......................... 23 + 7.4.1. DAD with All Nodes Multicast Address ..................... 24 + 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 + 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 + 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 + 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 + 7.4.1.5. Pros and Cons ............................................ 25 + 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 + 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 + 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 + 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 + 7.4.2.5. Pros and Cons ............................................ 26 + 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 + 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 + 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 + 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 + 7.4.3.5. Pros and Cons ............................................ 27 + 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 + 7.5. Domain Name Registration ................................. 27 + 8. Security Consideration ................................... 27 + 9. IANA Consideration ....................................... 28 + 10. Acknowledgement .......................................... 28 + 11. Intellectual Property .................................... 28 + 12. Copyright ................................................ 28 + 13. References ............................................... 29 + 14. Author's Addresses ....................................... 30 + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 2] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 1. Introduction + + Today, most networks use DNS[1034][1035] for convenience. In case of + IPv6, DNS is more important element because of IPv6 long addresses + which are difficult to remember. In addition, small networks like home + networks using IPv6, should be able to make network easily without + manual configuration. Also, these small networks may not have DHCP + Server, DNS Server etc. that are used to configure the network. This + document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure + for generating and registering the Domain Name and IPv6 addresses with + the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are + required to implement lightweight functions specified in this document. + 6DNAC can be applied to all defined IPv6 unicast addresses except Link + local IPv6 addresses, viz: Site-local and Global addresses. + + 6DNAC uses Neighbor Discovery Protocol [2461] with new additions + (defined in section 6) and DAD procedures for generating and + registering the Domain Name with the DNS server automatically. + + + 2. Terminology + + 6DNAC - IPv6 Domain Name Auto Configuration. It can provide + IPv6 hosts with Domain Name Generation and + Registration automatically. + + 6DNAC Client - An IPv6 node that can generate its own unique Domain + Name. Section 3 identifies the new requirements that + 6DNAC places on an IPv6 node to be a 6DNAC node. + + 6DNAC Server - An IPv6 node that can collect and registrate Domain + Name and IPv6 addresses automatically. 6DNAC server + uses the information from the DAD operation messages + with newly defined options for the registration of the + Domain Name and IPv6 Addresses. Section 3 identifies + the new requirements that 6DNAC places on an IPv6 + node to be a 6DNAC server. Also 6DNAC server can have + various other functions depending on network + environment and the network operator. For instance + 6DNAC Server can acts as a Gateway as well Home Server + in Home Networks. + + DAD - Duplicate Address Detection (is defined [2461]) + + DFQDND - Duplicate Domain Name Detection + + FQDN - Fully Qualified Domain Name - FQDN and Domain Name are + used interchangeably in this document. + + NA - Neighbor Advertisement message (is defined [2461]) + + NS - Neighbor Solicitation message (is defined [2461]) + + RA - Router Advertisement message (is defined [2461]) + + SLAAC - Stateless Address Autoconfiguration [2462]. + +Park & Madanapalli Expires October 2003 [Page 3] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 3. 6DNAC Design Principles + + This section discusses the design principles of 6DNAC mechanism. + + 1. The new procedures for plug and play DNS should not cause changes + to existing DNS system. 6DNAC requires lightweight functions to be + implemented only at the client side of the DNS system, and uses the + existing DDNS UPDATE [2136] to communicate with DNS Servers. + + 2. Introducing a new protocol will always introduce new problems. + 6DNAC uses the existing protocols NDP [2461] with minor extensions + for generating and registering the domain name automatically + without defining a new protocol + + 3. Reusing proven and well understood design principles/patterns + will always yield a robust system. 6DNAC is based on IPv6 Address + Auotoconfiguration principle, where routers advertise the prefix + and host adds the interface ID to the prefix and forms the IPv6 + address. Domain Name (FQDN) also contains two parts: host name + and DNS zone suffix. Routers can advertise the DNS zone suffix + on a particular link in Router Advertisements (RA Messages) and + hosts can prefix their preferred host name to the DNS zone suffix + and form the fully qualified domain name. Also the detection of + duplicate domain name is similar to Duplicate Address Detection + (DAD) and can be part of DAD operation itself. + + + 4. 6DNAC Overview + + 6DNAC proposes minor extensions to NDP [2461] for automatic generation + and registration of domain name with the DNS server. It introduces two + new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone + Suffix option is carried in Router Advertisement (RA) messages for + notifying IPv6 nodes about the valid DNS Zone Suffix on the link and + FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement + (NA) messages to detect duplicate domain name. 6DNAC consists of two + components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the + domain name based on DNS Zone Suffix using Host Naming Algorithm (see + section 7.3.1) and 6DNAC Server collects and registers the DNS + information with the DNS Server on behalf of 6DNAC Clients. + + The automatic configuration of domain name using 6DNAC consists of + three parts. + + - DNS Zone Suffix Discovery and FQDN Construction: + + IPv6 Nodes collect DNS Zone Suffix information from Router + Advertisements and constructs FQDN by prefixing host name to the + DNS Zone Suffix. The IPv6 Nodes are required to implement Host + Naming Algorithm for generating host part of the FQDN in the + absence of administrator. + + Generation of node's FQDN within the node itself has advantages. Nodes + can provide forward and reverse name lookups independent of the DNS + System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain + Name is some thing that is owned by the node. + +Park & Madanapalli Expires October 2003 [Page 4] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - Duplicate Domain Name Detection + + All nodes are expected to go for DAD for all new IPv6 unicast + addresses, regardless of whether they are obtained through + stateful, stateless or manual configuration. 6DNAC uses the DAD + messages with new option for carrying the Domain Name along with + the new IPv6 Address. 6DNAC Server captures this information and + updates DNS Server provided that the IPv6 Address and its domain + name are not duplicate. If the domain name is already in use, + the 6DNAC server replies to the sender with FQDN Option in NA + message indicating that the domain name is duplicate. Then the + node is expected to generate another domain name using host + naming algorithm and go for DAD. This time the DAD is only for + duplicate domain name detection (DFQDND). In order to avoid + confusion with the normal NDP processing, the target address + field of the NS message must carry the unspecified address + in retry mode. This can be repeated depending on number of + retries defined by the administrator in the host naming algorithm. + + + - Domain Name Registration + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and updates DNS + Server using existing protocol DDNS UPDATE [2136] provided that + the IPv6 Address and its domain name are not duplicate. + + If an IPv6 Address is duplicate, the IPv6 node cannot perform + stateless address autoconfiguration repeatedly. Unlike IPv6 stateless + address autoconfiguration, 6DNAC allows the automatic configuration of + domain name repeatedly if the domain name is duplicate depending on + number of retries defined by the administrator in the host naming + algorithm. + + + 5. 6DNAC Requirements + + Depending on the 6DNAC functionality, the IPv6 nodes implement, they + are called either 6DNAC Clients or 6DNAC Servers. The following + sections lists the requirements that the 6DNAC Client and 6DNAC server + must support. + + + 5.1. 6DANC Client Requirements + + - 6DNAC Client must recognize and process the following NDP + extensions + + - DNS Zone Suffix option in RA messages for generating its + domain name (FQDN). + + - Domain Name option in NS and NA messages for detecting + the duplicate domain name + + + + +Park & Madanapalli Expires October 2003 [Page 5] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - It must generate its domain name (FQDN) based on the DNS + suffix that it got from the router advertisement. And it must + have a host naming algorithm for generating the host part of + the FQDN. + + - If NA message is received with unspecified target address and + FQDN option, then the node must treat that the domain is + duplicate. + + + 5.2. 6DNAC Server Requirements + + - 6DNAC Server must recognize and process the following NDP + extensions + + - If the 6DNAC Server is a router on the link, then it + must advertise DNS Zone Suffix option in RA messages + for hosts to generate their domain name (FQDN). + + - FQDN option in NS messages for detecting new DNS + information for of nodes on the link for which it + must update the AAAA RR and PTR RR in DNS Server. + + - FQDN option in NA messages for notifying duplicate + domain name with unspecified target address. + + - 6DNAC server must update the DNS Server (both AAAA RR and + PTR RR) dynamically using DDNS UPDATE [2136]. + + - 6DNAC server must cache this (newly detected) FQDN, Link + Layer Address, and IPv6 Address information, so that it can + decide whether it really needs to update DNS Server or not, + to avoid redundant updates. This information will also be + used for notifying the duplicate domain name. + + + 6. 6DNAC Messages and Option Formats + + In order to achieve the plug and play DNS, 6DNAC proposes new + extensions to the NDP [2461]. This section specifies the new + additions to NDP messages and formats of new options. + + + 6.1. Router Advertisement (RA) Message Format + + Routers send out Router Advertisement (RA) message periodically, or + in response to a Router Solicitation. 6DNAC does not modify the format + of the RA message, but proposes new option (DNS Zone Suffix Information) + to be carried in RA messages. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 6] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cur Hop Limit |M|O| Reserved | Router Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reachable Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retrans Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | DNS Zone Suffix Information | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + 6.2. Neighbor Solicitation (NS) Message Format + + 6DNAC does not modify the format of the Neighbor Solicitation (NS) + message, but proposes new option (FQDN Option) to be carried in NS + messages. When a node is going for DAD, the node must include FQDN + option in NS message to participate in plug and play DNS. If the + node is going for Explicit Detection of Duplicate Domain Name, the + node must use FQDN option in NS message and unspecified address in + the target address field. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | Domain Name | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Park & Madanapalli Expires October 2003 [Page 7] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6.3. Neighbor Advertisement (NA) Message Format + + 6DNAC does not modify the format of the Neighbor Advertisement (NA) + message, but proposes new option (FQDN Option) to be carried in NA + messages. 6DNAC Server sends NA message with FQDN option to 6DNAC + Client that is performing duplicate domain name detection in case + the domain name found to be duplicate. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|S|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | FQDN Option | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + 6.4 Option Formats + + 6.4.1. DNS Zone Suffix Information Option Format + + IPv6 nodes require DNS Zone Suffix for constructing their FQDN. + 6DNAC introduces new option for routers to advertise the DNS Zone + Suffix Information for IPv6 nodes on the link. The suffix information + should be configured into routers manually. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / DNS Zone Suffix / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Park & Madanapalli Expires October 2003 [Page 8] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units of + 8 octets. + + Reserved This field is unused. It must be initialized to zero + by the sender and must be ignored by the receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this suffix is valid. Nodes + should treat this as the life time for their domain + name. Nodes should contact the source of this + information before expiry of this time interval. + A value of all one bits (0xFFFFFFFF) represents + infinity. + + DNS Zone Suffix The suffix part of the FQDN. The data in the DNS + Zone Suffix field should be encoded according to + DNS encoding rules specified in [1035]. + + + + 6.4.2. Domain Name (FQDN) Option Format + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + FQDN Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / Domain Name / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units + of 8 octets. It must be greater than 3. + + + +Park & Madanapalli Expires October 2003 [Page 9] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Reserved This field is unused. It must be initialized to + zero by the sender and must be ignored by the + receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this domain name is valid + 6DNAC should deregister this domain name at + the expiry of this interval. 6DNAC clients + should send updates by the expiry of this + interval. A value of all one bits (0xFFFFFFFF) + represents infinity. + + FQDN Target Address The Address for which the FQDN maps to. It + should be same as Target Address field of the + NS message in case of DAD & duplicate FQDN are + running in parallel. + + Domain Name The domain name (FQDN) of the node. The data in + the domain name should be encoded according to + DNS encoding rules specified in [1035]. + + + 6.4.3. Router Alert Option for 6DNAC + + Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop + Header for using in NDP messages. The presence of this option in NS + message informs the router that this NS message is carrying Domain + Name information and must be processed by the 6DNAC Server on the router. + 6DNAC Clients can use this option for sending DAD packets instead + of addressing the DAD packets to the all-nodes multicast address + when 6DNAC Server is implemented on router. + + The Router Alert option has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Length = 2 + + Values are registered and maintained by the IANA. For 6DNAC, the + value has to be assigned by IANA. + + Further information about this option can be obtained from + IPv6 Router Alert Option [2711]. + + + 7. 6DNAC Operation + + 6DNAC provides mechanisms for automatic generation of domain name + and registering it with the DNS Server for IPv6 nodes. 6DNAC consists + of two components: 6DNAC Client and 6DNAC Server. All nodes that want + to participate in plug and play DNS are required to implement 6DNAC + Client functionality, and one of the IPv6 nodes is required to + implement 6DNAC Server functionality. The IPv6 node that implements + the 6DNAC Server functionality must know the location of the DNS + Server and must be a trusted node to send DDNS UPDATE [2136] messages. + +Park & Madanapalli Expires October 2003 [Page 10] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.1. 6DNAC Network Topology + + This section identifies the possible locations for the 6DNAC Server. + Note that, all nodes are required to implement 6DNAC Client + functionality for constructing the domain name from the DNS Zone + Suffix Information advertised by the router. Figure 6 illustrates + IPv6 host (H4) implementing 6DNAC Server functionality. In this case + H4 can serve only one link (that it belongs to) for automatic + registration of domain name. H4 must observe the DAD packets on the + link to detect the DNS information, this requires all nodes on the + link must belong to same solicited node multicast address. In general, + this may not be the case. So the node that is going for DAD must use + all nodes multicast address for DAD packets, so that the 6DNAC Server + (H4) can observe the DAD packets, detects IPv6 address and + corresponding domain name, checks if this domain name is duplicate + and finally registers the domain name with the DNS Server. + + + 6DNAC Server + +---+ +---+ +----------+ + | H1| | H4|<--- DDNS UPDATE --->|DNS Server| + +-+-+ +-+-+ +----+-----+ + | | +----+ +---/ + | | | | / + ---+-----+-----------+-----+-----------+ R1 +-----+ + | | | | + | | +----+ + +-+-+ +-+-+ + | H2| | H3| + +---+ +---+ + + + H1, H2, H3 - 6DNAC Clients + H4 - 6DNAC Server + R1 - Router + + + + + + Figure 7 shows the 6DNAC Server implemented on a router R1. In this + case a single 6DNAC server can serve multiple links for automatic + configuration of the domain name. This topology also has flexibility + of using DAD packets with Router Alert option instead of sending DAD + packets to all nodes multicast address. The routers are required to + process all the packets with Router Alert option as per [2711]. + + In case of Home Networks, R1 is will acts as a Home Gateway (CPE) + connected to ISP. R1 delegates the prefix from the ISP edge router. + After delegating the prefix the CPE can advertise the DNS Zone suffix + along with the prefix information to the nodes on the links to which + the router is connected to. Note that the R1 must be configured with + the DNS Zone suffix Information manually. + + + + +Park & Madanapalli Expires October 2003 [Page 11] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---+ +---+ + | H3+ | H4| + +-+-+ +-+-+ + | | + | LINK2 | + +---+ ---+--------+--+-- +----------+ + | H1| | |DNS Server| + +-+-+ | +----+-----+ + | +--+-+ -------/ + | LINK 1 | | / + ---+-----+------------------+ R1 +---------+ + | | | DDNS UPDATE + | +----+ + +-+-+ 6DNAC Server + | H2| + +---+ + + + H1, H2 - 6DNAC Clients on Link1 + H3, H4 - 6DNAC Clients on Link2 + R1 - Router with 6DNAC Server, serving both Link1 and Link2 + + + + + + 7.2. 6DNAC Operational Scenarios + + This section provides message sequence charts for various 6DNAC + operational scenarios assuming that the 6DNAC Server is implemented + on a router. All the scenarios assume that the normal boot up time + stateless address autoconfiguration of Link Local address derived + from the Interface Identifier has been completed successfully. And + it is also assumed that the router is already configured with the + DNS Zone Suffix Information. + + + Legend: + + 6DNAC-A, B, C : 6DNAC Clients + 6DNAC-S : 6DNAC Server/Router + DAD : Duplicate Address Detection + DFQDND : Duplicate Domain Name Detection + DNS-S : DNS Server + + + 7.2.1. Domain Name Registration-Successful Case + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. It is Assumed that the + DupAddrDetectTransmits is set to 1. + + + + +Park & Madanapalli Expires October 2003 [Page 12] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | #6 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + + + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information along with other parameters as specified in + NDP [2461]. + + #2. 6DNAC Client processes the router advertisement and constructs + the FQDN by prefixing hostname to the DNS Zone Suffix. It also + constructs IPv6 address from the autoconfiguration prefix + information option. + + #3. 6DNAC Client starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + Note that the DAD packets must be addressed to all nodes multicast + address if Router Alert option is not used. + +Park & Madanapalli Expires October 2003 [Page 13] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry ), where C is Link Layer Address of the 6DNAC Client. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + Note that, Stateless Address Autoconfiguration DAD procedure is not + depicted in the following message sequence chart, which simultaneously + happens along with duplicate FQDN detection. + + + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. The node is configured with + DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 14] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #6 | | + | | | + | Lookup FQDN | + | Entry exists | + | |------+ | + | Ignore | #7 | + | |<-----+ | + | #8 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + + + + + Steps from #1 to #5 are same as that of scenario.7.2.1. + + #6. 6DNAC Client sends out second Neighbor Solicitation message with + FQDN option as part of duplicate FQDN detection. + +Park & Madanapalli Expires October 2003 [Page 15] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #7. 6DNAC Server receives and observes that the FQDN Cache exactly + matches with that of the NS information and ignores the NS message. + + #8. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name.. + + + 7.2.3. Domain Name Registration-Defend Case + + This scenario starts when two 6DNAC Client receive RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and both the nodes want configure their IPv6 + address (Global or Site Local) and domain name. In this scenario both + the nodes want to have same domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 16] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | RA with | RA with | | + | DNS Suffix Opt | DNS Suffix Opt | | + |<---------------|--------------->| | + | #1 | #1 | | + |---+ | |---+ | + Construct | #2 | Construct | #2 | + FQDN | | FQDN | | + |<--+ | |<--+ | + DAD/DFQDND Starts | DAD/DFQDND Starts | + | | | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->| | | + | #3 | | | + | No Entry | | + | |------+ | | + | Create FQDN | #4 | | + | | | | + | |<-----+ | | + | | | | + | | Register FQDN #5 | + | |-------------------------------->| + | | | | + | | NS with | | + | | FQDN Opt | | + | |<---------------| | + | | #6 | | + | |------+ | | + | FQDN is in use| | | + | Defend DFQDND| #7 | | + | |<-----+ | | + | | | | + | | NA with | | + | | D-flag Set | | + | |--------------->| | + | | #8 | | + |------+ | |---+ | + No Response | #9 | Enter | #10 | + DFQDND Success| | Retry Mode| | + |<-----+ | |<--+ | + | | | | + v v v v + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 17] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information. + + #2. 6DNAC Clients A&B process the router advertisement and construct + their FQDN by prefixing hostname to the DNS Zone Suffix. They + also construct IPv6 address from the autoconfiguration prefix + information option. + + When each host is trying to go for DAD, all hosts must have + random delay to avoid the traffic congestion according to [2461]. + So here it is assumed that 6DNAC Client-A starts DAD first and + 6DNAC Client-B starts DAD later. + + #3. 6DNAC Client-A starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-A as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry ), where A is Link Layer Address of the 6DNAC Client-A. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client-B starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor Solicitation + message with FQDN option. + + #7. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-B as part of duplicate FQDN detection procedure and + finds that the domain name is already in use by the 6DNAC Client-A. + Hence, concludes to defend the duplicate FQDN detection of 6DNAC + Client-B. + + #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN + option to 6DNAC Client-B to defend its duplicate FQDN detection. + + #9. 6DNAC Client-A times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + #10. 6DNAC Client-B observes that there is a NA with FQDN option + indicating that the domain name is duplicate and enters Retry + Mode. In retry mode, 6DNAC Client constructs another FQDN based + on Host Naming Algorithm. The number of retries is defined by the + administrator and must be a configurable value. + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 18] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.2.4. Domain Name Registration in Retry Mode + + Pre-Conditions: + + 1. Duplicate Address Detection has succeeded + 2. Duplicate FQDN Detection FAILED + 3. FQDN is the first FQDN one constructed and FAILED + 4. FQDN2 is the second FQDN to be constructed + 5. The Neighbor Solicitation in the 'Retry Mode' + carries unspecified address in its target field (NS*). + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + |--------+ | | + Construct | #1 | | + new FQDN2 | | | + |<-------+ | | + | | | + DFQDND Restarts | | + | | | + | | | + | NS* With | | + | FQDN Opt | | + |--------------->| | + | #2 | | + | | | + | No Entry | + | |------+ | + | Create FQDN | #3 | + | | | + | |<-----+ | + | | | + | | Register FQDN2 | + | |--------------->| + | | #4 | + | | | + |--------+ | | + No Response | #5 | | + DFQDND-Success | | | + |<-------+ | | + | | | + v V v + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 19] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, + the DNS Zone Suffix, and it is FQDN2. + #2. It then starts Duplicate Detection only for Domain Name. 6DNAC + Client sends out NS with FQDN option and unspecified target + address. + + #3. 6DNAC Server processes the Retry Mode NS message and finds that + the FQDN2 is not in use and creates Cache entry as . + + #4. It then starts registration procedures with the DNS Server. + + #5. Meanwhile, 6DNAC Client timesout and observes that there is no + defending NA for its DFQDND NS sent out and successfully + configures its domain name. + + + 7.2.5. Domain Name Registration when DAD Fails + + Duplicate domain name detection and subsequent registration starts + if and only if the DAD for IPv6 address succeeds. If the DAD for + IPv6 address fails then no actions are taken for domain name. When + DAD fails for stateless address autoconfiguration, then the domain + configuration starts only when the address has been configured using + Stateful Address Configuration methods and the node is going on DAD + for this address. + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 20] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | | | | + | RA with | | | + | DNS Suffix Opt | | | + |<---------------| | | + | #1 | | | + |-----+ | | | + Construct | | | | + FQDN& | #2 | | | + IPv6 Addr | | | | + |<----+ | | | + DAD/DFQDND Starts | | | + | | | | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->+--------------->| | + | #3 | #3 | | + | No Entry | | + | |------+ | | + | Create FQDN | | | + | | #4 | | + | |<-----+ | | + | | | | + | | |------+ | + | | My IPv6 Addr| #5 | + | | |<-----+ | + | | Defend DAD | | + | | with NA | | + |<---------------+<---------------| | + | #6 | #6 | | + | Entry | | + | |------+ | | + | Delete FQDN | #7 | | + | |<-----+ | | + | | | | + |----+ | | | + DAD Failed | #8 | | | + Stop DFQDND | | | | + |<---+ | | | + | | | | + v v v v + + + + #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. + + #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and + FQDN as per Host Naming Algorithm. + + #3. It then starts Duplicate address & FQDN Detection, for the newly + constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS + with FQDN option. + +Park & Madanapalli Expires October 2003 [Page 21] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the DAD/DFQDND NS message and finds + that there is no entry for the FQDN in its cache. And, + creates Cache entry as and starts a Registration + timer with RegistrationWaitTime seconds. + + #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is + in its unicast address list. + + #6. It then starts defending DAD by sending NA to all-nodes multicast. + + #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. + And, deletes its FQDN Cache entry . + + #8. 6DNAC Client gets defending DAD-NA and desists from DAD. + And also, stops Duplicate FQDN Detection as well. + At this point the address must be configured using stateful + methods and the domain name registration starts with the DAD + for the newly constructed IPv6 address. + + 7.3. DNS Zone Suffix Discovery and FQDN Construction + + 7.3.1. Sending Router Advertisement Messages + + Routers send out Router Advertisement message periodically, + or in response to a Router Solicitation. Router should include + the DNS Zone Suffix Option in their advertisements. If the DNS + Zone Suffix changes (similar to Site Renumbering), then it should + advertise the Old Zone Suffix with zero Valid Lifetime and New + Zone Suffix with proper non-zero Valid Lifetime. In any other + case, a router should not send this option twice in a single + router advertisement. + + 7.3.2. Processing Router Advertisement Messages + + For each DNS Zone Suffix Option in Router Advertisement, + + a. 6DNAC node stores the Zone Suffix information in its local + database. Also, constructs FQDN as per Host Naming Algorithm. + + b. If the node has not configured FQDN yet, + + 1. If the node is going to perform DAD for either Site local or + Global Address, then it should include FQDN option to perform + Duplicate FQDN Detection in parallel with DAD. + + 2. If the node has already got either Site local or Global + address, then it should send out NS with FQDN option and + unspecified target address to perform Duplicate FQDN + Detection. + + c. If the node has already configured FQDN, and if the + advertisement carries two DNS Zone Suffix Options, + First DNS Zone Suffix should match with the configured FQDN + Suffix and its Valid Lifetime must be zero. Second DNS Zone + + + +Park & Madanapalli Expires October 2003 [Page 22] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + Suffix should have non-zero Valid Lifetime. In this case, the + node constructs new FQDN based on the new DNS Zone Suffix (from + second DNS Zone Suffix option), and perform Duplicate FQDN + Detection with unspecified target address. Also, it should + overwrite the old FQDN with the newly constructed FQDN. + + + 7.3.3. FQDN Lifetime expiry + + 6DNAC Server: + It should delete the FQDN cache entry and should de-register from + the DNS Server. + + 6DNAC Client: + It should send update to 6DNAC Server by restarting the Duplicate + FQDN Detection. + + 7.3.4. Host Naming Algorithm + + A node constructs FQDN by combining DNS Zone Suffix and the hostname + as depicted in the following diagram. + + +------------------+----------------------------------+ + | Host Name | Advertised Suffix | + +------------------+----------------------------------+ + +
+ + A node can choose Host Name using any of the following methods: + + a. String form of random number generated from the Interface + Identifier. + + b. List of configured Host Names provided by the administrator. + + + The number of retries must be specified in this algorithm in + case of domain name duplication. + + + 7.4. Duplicate Domain Name Detection + + The procedure for detecting duplicated FQDNs uses Neighbor + Solicitation and Advertisement messages as described below. + + If a duplicate FQDN is detected during the procedure, the + FQDN cannot be assigned to the node. + + An FQDN on which the DFQDND Procedure is applied is said + to be tentative until the procedure has completed successfully. + A tentative FQDN is not considered "assigned to the node" in the + traditional sense. That is, the node must accept Neighbor + Advertisement message containing the tentative FQDN in the FQDN + Option. + + +Park & Madanapalli Expires October 2003 [Page 23] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + It should also be noted that DFQDN must be performed prior to + registering with DNS Server to prevent multiple nodes from using + the same FQDN simultaneously. All the Duplicate Address Detection + Neighbor Solicitation messages must carry Source Link Layer Address + Option as specified in NDP [2461]. + + The detection of duplicate FQDN can be achieved through one of the + following three types of procedures. + + 1. DAD with All Nodes Multicast Address + 2. DAD with Router Alert Option for 6DNAC. + 3. Explicit Detection of Duplicate Domain Name + + Even though three solutions are listed, authors prefer only one + procedure to be followed in future based on further analysis and + comments received from others. + + 7.4.1. DAD with All Nodes Multicast Address + + 7.4.1.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information and modifications: + + a. Include FQDN Option in the DAD Neighbor Solicitation Message + b. Destination Address is set to All Nodes Multicast Address + + There may be a case where DAD has succeeded but DFQDND is in Retry + Mode. In such case, the Neighbor Solicitation must carry unspecified + address in the ICMP target address field and new domain name in FQDN + option to re-try the registration of the domain name. + + 7.4.1.2. Processing Neighbor Solicitation Messages + + 6DNAC Clients must ignore the FQDN option found in any of the + neighbor solicitation messages. + + 6DNAC Server processes FQDN Option found in the Duplicate Address + Detection Neighbor Solicitation Messages as described below: + + Lookup FQDN Cache for the domain name in FQDN Option. + + If the entry exists and + i. Link Layer Address matches with SLLA option, this is the case, + where node has changed its IPv6 address or updating the valid + life time. 6DNAC Server updates its cache and also updates DNS + Server using DDNS-UPDATE. If there is no change in IPv6 address + or life time then no updates are sent to the DNS server. + + ii. Link Layer Address differs with SLLA option, defend the duplicate + FQDN Detection by sending Neighbor Advertisement Message as + described in $7.4.1.3$. + + + +Park & Madanapalli Expires October 2003 [Page 24] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + else, + Lookup FQDN Cache for the Link Layer Address in SLLA Option. + + If the entry exists, update the FQDN Cache and update DNS Server + using DDNS-UPDATE. This is the case, where node has changed its + domain name (similar to Site Re-numbering). + + If then entry does not exists, then it means that this is the new + registration. It must create a cache entry and start Registration + + timer with RegistrationWaitTime. At the expiry of the Registration + timer, it should update DNS Server with DDNS-UPDATE. + + 7.4.1.3. Sending Neighbor Advertisement Messages + + 6DNAC Server sends Neighbor Advertisement Messages as part + of Duplicate Address Detection SLAAC [2462] with the FQDN Option + in Neighbor Advertisement message to defend duplicate FQDN + detection. + + There may be the case where defending of duplicate address detection + is not required but defending of FQDN is required. In such instance, + the defending Neighbor Advertisement must carry FQDN and unspecified + address in the ICMP target address field. + + 7.4.1.4. Processing Neighbor Advertisement Messages + + 6DNAC Server must ignore the any FQDN option found any of + the neighbor advertisement messages. If the Neighbor Advertisement + is a DAD defending, then it must delete its FQDN Cache entry created + on the reception of DAD Neighbor Solicitation message. + + When 6DNAC Clients gets the duplicate address detection neighbor + advertisement messages with FQDN option set it means that its + duplicate FQDN detection failed and enters Retry Mode. + + 7.4.1.5. Pros and Cons + + The advantage of this procedure is that it does not need any + extension header options to be included. The disadvantage of this + procedure is that, it needs change in the existing DAD procedure. + The change is only that the DAD neighbor solicitations are to be + addressed to all nodes multicast address instead of solicited + node multicast address. The another disadvantage is that, it needs + the existence of Duplicate Address Detection Procedure to + perform duplicate FQDN detection. + + 7.4.2. DAD with Router Alert Option for 6DNAC + + 7.4.2.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information: + + +Park & Madanapalli Expires October 2003 [Page 25] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + a. Include Hop-by-Hop extension Header with Router Alert Option + for 6DNAC as described in IPv6 Router Alert Option[2711]. + + b. Include FQDN Option in the DAD Neighbor Solicitation Message + + 7.4.2.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + 7.4.2.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.2.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.2.5. Pros and Cons + + The advantage of this procedure is that it does not disturb + the existing implementation and their way of processing the + packets. The disadvantage is that, it needs the existence + of Duplicate Address Detection Procedure to perform duplicate + FQDN detection. Another disadvantage is that this procedure + requires 6DNAC Server functionality to be implemented on Router. + However, in this case 6DNAC Server can serve multiple links. + + 7.4.3. Explicit Detection of Duplicate Domain Name + + In this procedure Duplicate FQDN Detection starts after completion + of successful Site local or Global Address configuration. + + 7.4.3.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate FQDN Detection with the following information: + + a. Include FQDN Option in the Neighbor Solicitation Message + + b. Destination Address is set to All Nodes Multicast Address + or uses Router Alert Option for 6DNAC, when 6DNAC Server is + implemented on router. + + c. Target Address is set to Unspecified Address + + d. Other fields are set as per DAD SLAAC [2462]. + + 7.4.3.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + + + + + +Park & Madanapalli Expires October 2003 [Page 26] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 7.4.3.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.3.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.3.5. Pros and Cons + + The advantage of this procedure is that it does not need the + existing duplicate address detection procedure. This is introduced + as the DAD procedure is found to be redundant in when IPv6 addresses + are constructed from the interface ID [DIID]. + + Note that, if 6DNAC Clients know the address of 6DNAC Server then + they can directly send DFQDND-NS to 6DNAC Server. + + 7.4.4. Retry Mode for Re-registering Domain Name + + In retry mode, nodes construct new FQDN as per Host Naming Algorithm. + Then they restart Duplicate FQDN Detection as described in $7.4.3$. + + + 7.5. Domain Name Registration + + 6DNAC Server must be an authenticated to update the DNS Server. + 6DNAC Server must also be configured with the DNS Server + information. + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and caches the + information. It also have an associated Registration Timer with + RegistrationWaitTime to wait for the successful completion of + DFQDND and update DNS Server using existing protocol DDNS UPDATE + [2136]. + + + 8. Security Consideration + + If someone wants to hijack correct Domain Name registration, they + could send a NS message with incorrect or same Domain Name to the + 6DNAC server repeatedly and server would start the Domain Name + registration through above mechanism, which is a security hole. + As described in [2461], a host can check validity of NDP messages. + If the NDP message include an IP Authentication Header, the message + authenticates correctly. For DNS UPDATE processing, secure DNS + Dynamic Update is described in [3007]. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 27] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 9. IANA Consideration + + Values in the Router Alert Option are registered and maintained by + IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is + required to assign the Type values for DNS Zone Suffix Information + option and FADN option. + + + 10. Acknowledgement + + Special thanks are due to Badrinarayana N.S. and Christian Huitema for + many helpful suggestions and revisions. + + + 11. Intellectual Property + + The following notice is copied from RFC 2026 [Bradner, 1996], + Section 10.4, and describes the position of the IETF concerning + intellectual property claims made against this document. + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use other 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 implementers 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + 12. Copyright + + The following copyright notice is copied from RFC 2026 [Bradner, + 1996], Section 10.4, and describes the applicable copyright for this + document. + + Copyright (C) The Internet Society July 12, 2001. 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 + or assist in its implementation may be prepared, copied, published + +Park & Madanapalli Expires October 2003 [Page 28] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + 13. References + + [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [2460] Deering, S. abd R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP version 6(IPv6)", RFC 2461, December + 1998. + + [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- + Configuration", RFC 2462, December 1998. + + [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", + RFC 2711, October 1999. + + [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND + FACILITIES", RFC 1034, November 1987. + + [1035] P. Mockapetris, "Domain Names - Implementation and + Specification" RFC 1035, November 1987. + + [2136] P. Vixie et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC2136, April 1997. + + [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + +Park & Madanapalli Expires October 2003 [Page 29] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + [DIID] yokohama-dad-vs-diid.pdf + at http://playground.sun.com/ipng/presentations/July2002/ + + [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- + dnsop-ipv6-dns-issues-00.txt, work in progress. + + [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix + delegation", draft-ietf-ipv6-prefix-delegation- + requirement-01.txt, work in progress. + + [Autoreg] H. Kitamura, "Domain Name Auto-Registration for + Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- + auto-reg-00.txt, work in progress. + + [NIQ] Matt Crawford, "IPv6 Node Information Queries", , work in progress. + + + 14. Author's Addresses + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics, KOREA + Phone: +82-31-200-3728 + Email:soohong.park@samsung.com + + Syam Madanapalli + Network Systems Division, SAMSUNG India Software Operations, INDIA + Phone: +91-80-5550555 + Email:syam@samsung.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 30] diff --git a/doc/draft/draft-richardson-ipsec-rr-02.txt b/doc/draft/draft-richardson-ipsec-rr-02.txt new file mode 100644 index 0000000000..7552fffe6f --- /dev/null +++ b/doc/draft/draft-richardson-ipsec-rr-02.txt @@ -0,0 +1,616 @@ + + +Independent submission M. Richardson +Internet-Draft SSW +Expires: August 24, 2003 February 23, 2003 + + + A method for storing IPsec keying material in DNS. + draft-richardson-ipsec-rr-02.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. + + This Internet-Draft will expire on August 24, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a new resource record for DNS. This record + may be used to store public keys for use in IPsec systems. + + This record replaces the functionality of the sub-type #1 of the KEY + Resource Record, which has been proposed to be obsoleted by [1]. + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 1] + +Internet-Draft ipsecrr February 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 + 3.1 RDATA format - algo type . . . . . . . . . . . . . . . . . . . 5 + 3.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5 + 3.3 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5 + 3.4 RDATA format - DSA public key . . . . . . . . . . . . . . . . 6 + 3.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6 + 4. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 + 4.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + Normative references . . . . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 2] + +Internet-Draft ipsecrr February 2003 + + +1. Introduction + +1.1 Overview + + Overview. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 3] + +Internet-Draft ipsecrr February 2003 + + +2. Storage formats + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS) name. It + will be a public key as only public keys are stored in the DNS. This + can be the public key of a host, network, or application (in the case + of per-port keying). + + An IPSECKEY RR is, like any other RR, authenticated by a SIG RR. + + It is expected that there will often be multiple resource records of + the IPSECKEY type. This will be due to the need to rollover keys, + and due to the presence of multiple gateways. + + The type number for the IPSECKEY RR is 45 (IANA TBD). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 4] + +Internet-Draft ipsecrr February 2003 + + +3. IPSECKEY RDATA format + + The RDATA for an IPSECKEY RR consists of a precedence value, a public + key (and algorithm type), and an optional gateway address. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RESV | algo | precedence | public key length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1 RDATA format - algo type + + The algorithm type ("algo") field indicates the type of key that is + present in the public key field. Valid values are: + + 0 No key is present. + + 1 A RSA key is present, in the format defined in + + 2 A DSA key is present, in the format defined in + + +3.2 RDATA format - precedence + + This is an 8-bit precedence for this record. This is interpreted in + a similar way to the PREFERENCE field described in section 3.3.9 of + [3]. + +3.3 RDATA format - RSA public key + + If the algorithm type has the value 1, then public key portion + contains an RSA public key, encoded as described in secion 2 of [8], + and repeated here: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | pub exp length| public key exponent / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + + + +Richardson Expires August 24, 2003 [Page 5] + +Internet-Draft ipsecrr February 2003 + + + +- modulus / + | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + + RFC2065 limited the exponent and modulus to 2552 bits in length, and + RFC3110 to 4096 bits. No such limit is specified here for the + purposes of encoding and decoding. The length in octets of the + public exponent length is represented as one octet if it is in the + range of 1 to 255 and by a zero octet followed by a two octet + unsigned length if it is longer than 255 bytes. The public key + modulus field is a multiprecision unsigned integer. The length of + the modulus can be determined from the RDLENGTH and the preceding + RDATA fields including the exponent. + + Leading zero bytes are prohibited in the exponent and modulus. + +3.4 RDATA format - DSA public key + + If the algorithm type has the value 2, then public key portion + contains an DSA public key, encoded as described in [7]. + +3.5 RDATA format - gateway + + The gateway field indicates a gateway to which an IPsec tunnel may be + created in order to reach the entity holding this resource record. + The length of this field is the size of the data portion minus the + public key length, and the 4 bytes of header. The gateway field may + be absent. + + The gateway field is a string. It is most commonly a simple fully + qualified domain name (FQDN). IP version 4 and IP version 6 + addresses may be represented using names from in-addr.arpa. and + ip6.arpa. + + The gateway field may also include a @-character in it. Either in + the form @FQDN, or user@FQDN. In this context, it does not reference + a single destination, but just an identifier that will be used when + doing key negotiations. This may be used in the context where the + gateway does not have a permanent IP address, but has permanent + address space behind it, and will be initiating connections only. + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 6] + +Internet-Draft ipsecrr February 2003 + + +4. Presentation formats + +4.1 Representation of IPSECKEY RRs + + IPSECKEY RRs may appear as lines in a zone data master file. The + precedence field is mandatory. While both the gateway and public key + fields are optional, it is illegal for neither to be present. + + As the IPv4, IPv6 and FQDN references to the gateway are mutually + exclusive, they can share a position. If no gateway is to be + indicated, then the special tokens of either "-" or "none" may be + used. + + IPv4 addresses are to be represented as a dotted decimal quad, with + no leading zeroes. IPv6 addresses are to be presented as specified + in section 2.2 of [4]. + + + 38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38 + RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ + Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La + 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 + 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC + MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 + cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 + fejrfi1H ) + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 7] + +Internet-Draft ipsecrr February 2003 + + +5. IANA Considerations + + IANA is asked to assign resource record 45 to this resource record. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 8] + +Internet-Draft ipsecrr February 2003 + + +6. Acknowledgments + + People who pushed me to write this. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 9] + +Internet-Draft ipsecrr February 2003 + + +Normative references + + [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 1884, December 1995. + + [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [6] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 10] + +Internet-Draft ipsecrr February 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Richardson Expires August 24, 2003 [Page 11] + diff --git a/doc/draft/draft-ymbk-6to4-arpa-delegation-00.txt b/doc/draft/draft-ymbk-6to4-arpa-delegation-00.txt new file mode 100644 index 0000000000..52ba9f5430 --- /dev/null +++ b/doc/draft/draft-ymbk-6to4-arpa-delegation-00.txt @@ -0,0 +1,280 @@ + + +Network Working Group R. Bush +Internet-Draft IIJ +Expires: August 14, 2003 J. Damas + February 13, 2003 + + + Delegation of 2.0.0.2.ip6.arpa + draft-ymbk-6to4-arpa-delegation-00.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. + + This Internet-Draft will expire on August 14, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document discusses the need for delegation of the + 2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4 + addresses. + +1. 6to4 and DNS + + 6to4 [RFC3056] provides a mechanism for IPv6 native hosts to + communicate over IPv4 clouds without explicit tunnel setup. + + 6to4 and DNS [I-D.moore-6to4-dns] describes methods to find the + delegation path for reverse lookups of 6to4 addresses in the DNS. + Section 3.1 of the I-D describes a simple method, using established + + + +Bush & Damas Expires August 14, 2003 [Page 1] + +Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003 + + + mechanisms at the RIRs, that would enable such a mechanism to be + deployed using a minimum of additional setup. + + Under the described method, the holders of IPv4 address space can + request the delegation of a sub-zone in the 2.0.0.2.ip6.arpa DNS tree + from the party from which they obtained the corresponding IPv4 + in-addr.arpa delegation (or the holder of an even shorter IPv4 prefix + if their immediate parent is not configured for ip6.arpa), following + the mapping of IPv4 delegations. This sub-zone can then be populated + by the entity deploying the 6to4 infrastructure. + +2. IANA Considerations + + This memo requests that the IANA delegate the 2.0.0.2.IP6.ARPA domain + to the RIRs as will be described in instructions to be provided by + the IAB. Names within this zone are to be further delegated within + the regional IP registries and ISPs in accordance with the delegation + of IPv4 address space. + +3. Security Considerations + + While DNS spoofing of address to name mapping has been exploited in + IPv4, delegation of the 2.0.0.2.ip6.arpa zone creates no new threats + to the security of the internet. + +Normative References + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + +Informative References + + [I-D.moore-6to4-dns] + Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work + in progress), October 2002. + + +Authors' Addresses + + Randy Bush + IIJ + 5147 Crystal Springs + Bainbrisge Island, WA 98110 + US + + Phone: +1 206 780 0431 + EMail: randy@psg.com + URI: http://psg.com/~randy/ + + + +Bush & Damas Expires August 14, 2003 [Page 2] + +Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003 + + + Joao Damas + Amsterdam, + The Netherlands + + Phone: + EMail: joao@psg.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bush & Damas Expires August 14, 2003 [Page 3] + +Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; 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 + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Bush & Damas Expires August 14, 2003 [Page 4] + +Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bush & Damas Expires August 14, 2003 [Page 5] + diff --git a/doc/rfc/rfc1886.txt b/doc/rfc/rfc1886.txt new file mode 100644 index 0000000000..9874fddb17 --- /dev/null +++ b/doc/rfc/rfc1886.txt @@ -0,0 +1,268 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 1886 Bellcore +Category: Standards Track C. Huitema + INRIA + December 1995 + + + DNS Extensions to support IP version 6 + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +Abstract + + This document defines the changes that need to be made to the Domain + Name System to support hosts running IP version 6 (IPv6). The + changes include a new resource record type to store an IPv6 address, + a new domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + + + + + + + + + + + + + + + + + + + +Thompson & Huitema Standards Track [Page 1] + +RFC 1886 IPv6 DNS Extensions December 1995 + + +1. INTRODUCTION + + Current support for the storage of Internet addresses in the Domain + Name System (DNS)[1,2] cannot easily be extended to support IPv6 + addresses[3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses we define the following + extensions: + + o A new resource record type is defined to map a domain name to an + IPv6 address. + + o A new domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. The + existing support for IPv4 addresses is retained. Transition issues + related to the co-existence of both IPv4 and IPv6 addresses in DNS + are discussed in [4]. + + +2. NEW RESOURCE RECORD DEFINITION AND DOMAIN + + A new record type is defined to store a host's IPv6 address. A host + that has more than one IPv6 address must have more than one such + record. + + +2.1 AAAA record type + + The AAAA resource record type is a new record specific to the + Internet class that stores a single IPv6 address. + + The value of the type is 28 (decimal). + + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + + + + +Thompson & Huitema Standards Track [Page 2] + +RFC 1886 IPv6 DNS Extensions December 1995 + + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not perform additional section processing. + + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of a IPv6 address as defined in [3]. + + +2.5 IP6.INT Domain + + A special domain is defined to look up a record given an address. The + intent of this domain is to provide a way of mapping an IPv6 address + to a host name, although it may be used for other purposes as well. + The domain is rooted at IP6.INT. + + An IPv6 address is represented as a name in the IP6.INT domain by a + sequence of nibbles separated by dots with the suffix ".IP6.INT". The + sequence of nibbles is encoded in reverse order, i.e. the low-order + nibble is encoded first, followed by the next low-order nibble and so + on. Each nibble is represented by a hexadecimal digit. For example, + the inverse lookup domain name corresponding to the address + + 4321:0:1:2:3:4:567:89ab + + would be + +b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT. + + + +3. MODIFICATIONS TO EXISTING QUERY TYPES + + All existing query types that perform type A additional section + processing, i.e. name server (NS), mail exchange (MX) and mailbox + (MB) query types, must be redefined to perform both type A and type + AAAA additional section processing. These new definitions mean that a + name server must add any relevant IPv4 addresses and any relevant + + + +Thompson & Huitema Standards Track [Page 3] + +RFC 1886 IPv6 DNS Extensions December 1995 + + + IPv6 addresses available locally to the additional section of a + response when processing any one of the above queries. + + +4. SECURITY CONSIDERATIONS + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thompson & Huitema Standards Track [Page 4] + +RFC 1886 IPv6 DNS Extensions December 1995 + + +5. REFERENCES + + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and Specifica- + tion", STD 13, RFC 1035, USC/Information Sciences Institute, + November 1987. + + [3] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing + Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December + 1995. + + + [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", Work in Progress. + + +Authors' Addresses + + Susan Thomson + Bellcore + MRE 2P343 + 445 South Street + Morristown, NJ 07960 + U.S.A. + + Phone: +1 201-829-4514 + EMail: set@thumper.bellcore.com + + + Christian Huitema + INRIA, Sophia-Antipolis + 2004 Route des Lucioles + BP 109 + F-06561 Valbonne Cedex + France + + Phone: +33 93 65 77 15 + EMail: Christian.Huitema@MIRSA.INRIA.FR + + + + + + + +Thompson & Huitema Standards Track [Page 5] + diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt new file mode 100644 index 0000000000..94cefa4c6b --- /dev/null +++ b/doc/rfc/rfc3197.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group R. Austein +Request for Comments: 3197 InterNetShare +Category: Informational November 2001 + + + Applicability Statement for DNS MIB Extensions + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document explains why, after more than six years as proposed + standards, the DNS Server and Resolver MIB extensions were never + deployed, and recommends retiring these MIB extensions by moving them + to Historical status. + +1. History + + The road to the DNS MIB extensions was paved with good intentions. + + In retrospect, it's obvious that the working group never had much + agreement on what belonged in the MIB extensions, just that we should + have some. This happened during the height of the craze for MIB + extensions in virtually every protocol that the IETF was working on + at the time, so the question of why we were doing this in the first + place never got a lot of scrutiny. Very late in the development + cycle we discovered that much of the support for writing the MIB + extensions in the first place had come from people who wanted to use + SNMP SET operations to update DNS zones on the fly. Examination of + the security model involved, however, led us to conclude that this + was not a good way to do dynamic update and that a separate DNS + Dynamic Update protocol would be necessary. + + The MIB extensions started out being fairly specific to one + particular DNS implementation (BIND-4.8.3); as work progressed, the + BIND-specific portions were rewritten to be as implementation-neutral + as we knew how to make them, but somehow every revision of the MIB + extensions managed to create new counters that just happened to + closely match statistics kept by some version of BIND. As a result, + the MIB extensions ended up being much too big, which raised a number + + + +Austein Informational [Page 1] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + + of concerns with the network management directorate, but the WG + resisted every attempt to remove any of these variables. In the end, + large portions of the MIB extensions were moved into optional groups + in an attempt to get the required subset down to a manageable size. + + The DNS Server and Resolver MIB extensions were one of the first + attempts to write MIB extensions for a protocol usually considered to + be at the application layer. Fairly early on it became clear that, + while it was certainly possible to write MIB extensions for DNS, the + SMI was not really designed with this sort of thing in mind. A case + in point was the attempt to provide direct indexing into the caches + in the resolver MIB extensions: while arguably the only sane way to + do this for a large cache, this required much more complex indexing + clauses than is usual, and ended up running into known length limits + for object identifiers in some SNMP implementations. + + Furthermore, the lack of either real proxy MIB support in SNMP + managers or a standard subagent protocol meant that there was no + reasonable way to implement the MIB extensions in the dominant + implementation (BIND). When the AgentX subagent protocol was + developed a few years later, we initially hoped that this would + finally clear the way for an implementation of the DNS MIB + extensions, but by the time AgentX was a viable protocol it had + become clear that nobody really wanted to implement these MIB + extensions. + + Finally, the MIB extensions took much too long to produce. In + retrospect, this should have been a clear warning sign, particularly + when the WG had clearly become so tired of the project that the + authors found it impossible to elicit any comments whatsoever on the + documents. + +2. Lessons + + Observations based on the preceding list of mistakes, for the benefit + of anyone else who ever attempts to write DNS MIB extensions again: + + - Define a clear set of goals before writing any MIB extensions. + Know who the constituency is and make sure that what you write + solves their problem. + + - Keep the MIB extensions short, and don't add variables just + because somebody in the WG thinks they'd be a cool thing to + measure. + + - If some portion of the task seems to be very hard to do within the + SMI, that's a strong hint that SNMP is not the right tool for + whatever it is that you're trying to do. + + + +Austein Informational [Page 2] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + + - If the entire project is taking too long, perhaps that's a hint + too. + +3. Recommendation + + In view of the community's apparent total lack of interest in + deploying these MIB extensions, we recommend that RFCs 1611 and 1612 + be reclassified as Historical documents. + +4. Security Considerations + + Re-classifying an existing MIB document from Proposed Standard to + Historic should not have any negative impact on security for the + Internet. + +5. IANA Considerations + + Getting rid of the DNS MIB extensions should not impose any new work + on IANA. + +6. Acknowledgments + + The author would like to thank all the people who were involved in + this project over the years for their optimism and patience, + misguided though it may have been. + +7. References + + [DNS-SERVER-MIB] Austein, R. and J. Saperia, "DNS Server MIB + Extensions", RFC 1611, May 1994. + + [DNS-RESOLVER-MIB] Austein, R. and J. Saperia, "DNS Resolver MIB + Extensions", RFC 1612, May 1994. + + [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J. + Bound, "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC 2136, April 1997. + + [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and D. + Francisco, "Agent Extensibility (AgentX) + Protocol Version 1", RFC 2741, January 2000. + + + + + + + + + + +Austein Informational [Page 3] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + +8. Author's Address + + Rob Austein + InterNetShare, Incorporated + 325M Sharon Park Drive, Suite 308 + Menlo Park, CA 94025 + USA + + EMail: sra@hactrn.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Informational [Page 4] + +RFC 3197 Applicability Statement - DNS MIB Extensions November 2001 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Austein Informational [Page 5] + diff --git a/doc/rfc/rfc3363.txt b/doc/rfc/rfc3363.txt new file mode 100644 index 0000000000..9d7a39c208 --- /dev/null +++ b/doc/rfc/rfc3363.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group R. Bush +Request for Comments: 3363 A. Durand +Updates: 2673, 2874 B. Fink +Category: Informational O. Gudmundsson + T. Hain + Editors + August 2002 + + + Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document clarifies and updates the standards status of RFCs that + define direct and reverse map of IPv6 addresses in DNS. This + document moves the A6 and Bit label specifications to experimental + status. + +1. Introduction + + The IETF had begun the process of standardizing two different address + formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both + are at proposed standard. This had led to confusion and conflicts on + which one to deploy. It is important for deployment that any + confusion in this area be cleared up, as there is a feeling in the + community that having more than one choice will lead to delays in the + deployment of IPv6. The goal of this document is to clarify the + situation. + + This document also discusses issues relating to the usage of Binary + Labels [RFC 2673] to support the reverse mapping of IPv6 addresses. + + This document is based on extensive technical discussion on various + relevant working groups mailing lists and a joint DNSEXT and NGTRANS + meeting at the 51st IETF in August 2001. This document attempts to + capture the sense of the discussions and reflect them in this + document to represent the consensus of the community. + + + +Bush, et. al. Informational [Page 1] + +RFC 3363 Representation of IPv6 Addresses in DNS August 2002 + + + The main arguments and the issues are covered in a separate document + [RFC3364] that reflects the current understanding of the issues. + This document summarizes the outcome of these discussions. + + The issue of the root of reverse IPv6 address map is outside the + scope of this document and is covered in a different document + [RFC3152]. + +1.1 Standards Action Taken + + This document changes the status of RFCs 2673 and 2874 from Proposed + Standard to Experimental. + +2. IPv6 Addresses: AAAA RR vs A6 RR + + Working group consensus as perceived by the chairs of the DNSEXT and + NGTRANS working groups is that: + + a) AAAA records are preferable at the moment for production + deployment of IPv6, and + + b) that A6 records have interesting properties that need to be better + understood before deployment. + + c) It is not known if the benefits of A6 outweigh the costs and + risks. + +2.1 Rationale + + There are several potential issues with A6 RRs that stem directly + from the feature that makes them different from AAAA RRs: the ability + to build up addresses via chaining. + + Resolving a chain of A6 RRs involves resolving a series of what are + nearly-independent queries. Each of these sub-queries takes some + non-zero amount of time, unless the answer happens to be in the + resolver's local cache already. Other things being equal, we expect + that the time it takes to resolve an N-link chain of A6 RRs will be + roughly proportional to N. What data we have suggests that users are + already impatient with the length of time it takes to resolve A RRs + in the IPv4 Internet, which suggests that users are not likely to be + patient with significantly longer delays in the IPv6 Internet, but + terminating queries prematurely is both a waste of resources and + another source of user frustration. Thus, we are forced to conclude + that indiscriminate use of long A6 chains is likely to lead to + increased user frustration. + + + + + +Bush, et. al. Informational [Page 2] + +RFC 3363 Representation of IPv6 Addresses in DNS August 2002 + + + The probability of failure during the process of resolving an N-link + A6 chain also appears to be roughly proportional to N, since each of + the queries involved in resolving an A6 chain has roughly the same + probability of failure as a single AAAA query. + + Last, several of the most interesting potential applications for A6 + RRs involve situations where the prefix name field in the A6 RR + points to a target that is not only outside the DNS zone containing + the A6 RR, but is administered by a different organization entirely. + While pointers out of zone are not a problem per se, experience both + with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that + pointers to other organizations are often not maintained properly, + perhaps because they're less susceptible to automation than pointers + within a single organization would be. + +2.2 Recommended Standard Action + + Based on the perceived consensus, this document recommends that RFC + 1886 stay on standards track and be advanced, while moving RFC 2874 + to Experimental status. + +3. Bitlabels in the Reverse DNS Tree + + RFC 2673 defines a new DNS label type. This was the first new type + defined since RFC 1035 [RFC1035]. Since the development of 2673 it + has been learned that deployment of a new type is difficult since DNS + servers that do not support bitlabels reject queries containing bit + labels as being malformed. The community has also indicated that + this new label type is not needed for mapping reverse addresses. + +3.1 Rationale + + The hexadecimal text representation of IPv6 addresses appears to be + capable of expressing all of the delegation schemes that we expect to + be used in the DNS reverse tree. + +3.2 Recommended Standard Action + + RFC 2673 standard status is to be changed from Proposed to + Experimental. Future standardization of these documents is to be + done by the DNSEXT working group or its successor. + + + + + + + + + + +Bush, et. al. Informational [Page 3] + +RFC 3363 Representation of IPv6 Addresses in DNS August 2002 + + +4. DNAME in IPv6 Reverse Tree + + The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated. + +5. Acknowledgments + + This document is based on input from many members of the various IETF + working groups involved in this issues. Special thanks go to the + people that prepared reading material for the joint DNSEXT and + NGTRANS working group meeting at the 51st IETF in London, Rob + Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, + Christian Huitema. Number of other people have made number of + comments on mailing lists about this issue including Andrew W. + Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka + Savola, Paul Vixie. + +6. Security Considerations + + As this document specifies a course of action, there are no direct + security considerations. There is an indirect security impact of the + choice, in that the relationship between A6 and DNSSEC is not well + understood throughout the community, while the choice of AAAA does + leads to a model for use of DNSSEC in IPv6 networks which parallels + current IPv4 practice. + +7. IANA Considerations + + None. + +Normative References + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC1886] Thompson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, July + 2000. + + + +Bush, et. al. Informational [Page 4] + +RFC 3363 Representation of IPv6 Addresses in DNS August 2002 + + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152 + August 2001. + +Informative References + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + +Editors' Addresses + + Randy Bush + EMail: randy@psg.com + + + Alain Durand + EMail: alain.durand@sun.com + + + Bob Fink + EMail: fink@es.net + + + Olafur Gudmundsson + EMail: ogud@ogud.com + + + Tony Hain + EMail: hain@tndh.net + + + + + + + + + + + + + + + + + + + + + + +Bush, et. al. Informational [Page 5] + +RFC 3363 Representation of IPv6 Addresses in DNS August 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Bush, et. al. Informational [Page 6] + diff --git a/doc/rfc/rfc3364.txt b/doc/rfc/rfc3364.txt new file mode 100644 index 0000000000..189c0d2aa0 --- /dev/null +++ b/doc/rfc/rfc3364.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group R. Austein +Request for Comments: 3364 Bourgeois Dilettant +Updates: 2673, 2874 August 2002 +Category: Informational + + + Tradeoffs in Domain Name System (DNS) Support + for Internet Protocol version 6 (IPv6) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The IETF has two different proposals on the table for how to do DNS + support for IPv6, and has thus far failed to reach a clear consensus + on which approach is better. This note attempts to examine the pros + and cons of each approach, in the hope of clarifying the debate so + that we can reach closure and move on. + +Introduction + + RFC 1886 [RFC1886] specified straightforward mechanisms to support + IPv6 addresses in the DNS. These mechanisms closely resemble the + mechanisms used to support IPv4, with a minor improvement to the + reverse mapping mechanism based on experience with CIDR. RFC 1886 is + currently listed as a Proposed Standard. + + RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6 + addresses in the DNS. These mechanisms provide new features that + make it possible for an IPv6 address stored in the DNS to be broken + up into multiple DNS resource records in ways that can reflect the + network topology underlying the address, thus making it possible for + the data stored in the DNS to reflect certain kinds of network + topology changes or routing architectures that are either impossible + or more difficult to represent without these mechanisms. RFC 2874 is + also currently listed as a Proposed Standard. + + + + + + + +Austein Informational [Page 1] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + + Both of these Proposed Standards were the output of the IPNG Working + Group. Both have been implemented, although implementation of + [RFC1886] is more widespread, both because it was specified earlier + and because it's simpler to implement. + + There's little question that the mechanisms proposed in [RFC2874] are + more general than the mechanisms proposed in [RFC1886], and that + these enhanced mechanisms might be valuable if IPv6's evolution goes + in certain directions. The questions are whether we really need the + more general mechanism, what new usage problems might come along with + the enhanced mechanisms, and what effect all this will have on IPv6 + deployment. + + The one thing on which there does seem to be widespread agreement is + that we should make up our minds about all this Real Soon Now. + +Main Advantages of Going with A6 + + While the A6 RR proposed in [RFC2874] is very general and provides a + superset of the functionality provided by the AAAA RR in [RFC1886], + many of the features of A6 can also be implemented with AAAA RRs via + preprocessing during zone file generation. + + There is one specific area where A6 RRs provide something that cannot + be provided using AAAA RRs: A6 RRs can represent addresses in which a + prefix portion of the address can change without any action (or + perhaps even knowledge) by the parties controlling the DNS zone + containing the terminal portion (least significant bits) of the + address. This includes both so-called "rapid renumbering" scenarios + (where an entire network's prefix may change very quickly) and + routing architectures such as the former "GSE" proposal [GSE] (where + the "routing goop" portion of an address may be subject to change + without warning). A6 RRs do not completely remove the need to update + leaf zones during all renumbering events (for example, changing ISPs + would usually require a change to the upward delegation pointer), but + careful use of A6 RRs could keep the number of RRs that need to + change during such an event to a minimum. + + Note that constructing AAAA RRs via preprocessing during zone file + generation requires exactly the sort of information that A6 RRs store + in the DNS. This begs the question of where the hypothetical + preprocessor obtains that information if it's not getting it from the + DNS. + + Note also that the A6 RR, when restricted to its zero-length-prefix + form ("A6 0"), is semantically equivalent to an AAAA RR (with one + "wasted" octet in the wire representation), so anything that can be + done with an AAAA RR can also be done with an A6 RR. + + + +Austein Informational [Page 2] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + +Main Advantages of Going with AAAA + + The AAAA RR proposed in [RFC1886], while providing only a subset of + the functionality provided by the A6 RR proposed in [RFC2874], has + two main points to recommend it: + + - AAAA RRs are essentially identical (other than their length) to + IPv4's A RRs, so we have more than 15 years of experience to help + us predict the usage patterns, failure scenarios and so forth + associated with AAAA RRs. + + - The AAAA RR is "optimized for read", in the sense that, by storing + a complete address rather than making the resolver fetch the + address in pieces, it minimizes the effort involved in fetching + addresses from the DNS (at the expense of increasing the effort + involved in injecting new data into the DNS). + +Less Compelling Arguments in Favor of A6 + + Since the A6 RR allows a zone administrator to write zone files whose + description of addresses maps to the underlying network topology, A6 + RRs can be construed as a "better" way of representing addresses than + AAAA. This may well be a useful capability, but in and of itself + it's more of an argument for better tools for zone administrators to + use when constructing zone files than a justification for changing + the resolution protocol used on the wire. + +Less Compelling Arguments in Favor of AAAA + + Some of the pressure to go with AAAA instead of A6 appears to be + based on the wider deployment of AAAA. Since it is possible to + construct transition tools (see discussion of AAAA synthesis, later + in this note), this does not appear to be a compelling argument if A6 + provides features that we really need. + + Another argument in favor of AAAA RRs over A6 RRs appears to be that + the A6 RR's advanced capabilities increase the number of ways in + which a zone administrator could build a non-working configuration. + While operational issues are certainly important, this is more of + argument that we need better tools for zone administrators than it is + a justification for turning away from A6 if A6 provides features that + we really need. + + + + + + + + + +Austein Informational [Page 3] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + +Potential Problems with A6 + + The enhanced capabilities of the A6 RR, while interesting, are not in + themselves justification for choosing A6 if we don't really need + those capabilities. The A6 RR is "optimized for write", in the sense + that, by making it possible to store fragmented IPv6 addresses in the + DNS, it makes it possible to reduce the effort that it takes to + inject new data into the DNS (at the expense of increasing the effort + involved in fetching data from the DNS). This may be justified if we + expect the effort involved in maintaining AAAA-style DNS entries to + be prohibitive, but in general, we expect the DNS data to be read + more frequently than it is written, so we need to evaluate this + particular tradeoff very carefully. + + There are also several potential issues with A6 RRs that stem + directly from the feature that makes them different from AAAA RRs: + the ability to build up address via chaining. + + Resolving a chain of A6 RRs involves resolving a series of what are + almost independent queries, but not quite. Each of these sub-queries + takes some non-zero amount of time, unless the answer happens to be + in the resolver's local cache already. Assuming that resolving an + AAAA RR takes time T as a baseline, we can guess that, on the + average, it will take something approaching time N*T to resolve an + N-link chain of A6 RRs, although we would expect to see a fairly good + caching factor for the A6 fragments representing the more significant + bits of an address. This leaves us with two choices, neither of + which is very good: we can decrease the amount of time that the + resolver is willing to wait for each fragment, or we can increase the + amount of time that a resolver is willing to wait before returning + failure to a client. What little data we have on this subject + suggests that users are already impatient with the length of time it + takes to resolve A RRs in the IPv4 Internet, which suggests that they + are not likely to be patient with significantly longer delays in the + IPv6 Internet. At the same time, terminating queries prematurely is + both a waste of resources and another source of user frustration. + Thus, we are forced to conclude that indiscriminate use of long A6 + chains is likely to lead to problems. + + To make matters worse, the places where A6 RRs are likely to be most + critical for rapid renumbering or GSE-like routing are situations + where the prefix name field in the A6 RR points to a target that is + not only outside the DNS zone containing the A6 RR, but is + administered by a different organization (for example, in the case of + an end user's site, the prefix name will most likely point to a name + belonging to an ISP that provides connectivity for the site). While + pointers out of zone are not a problem per se, pointers to other + organizations are somewhat more difficult to maintain and less + + + +Austein Informational [Page 4] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + + susceptible to automation than pointers within a single organization + would be. Experience both with glue RRs and with PTR RRs in the IN- + ADDR.ARPA tree suggests that many zone administrators do not really + understand how to set up and maintain these pointers properly, and we + have no particular reason to believe that these zone administrators + will do a better job with A6 chains than they do today. To be fair, + however, the alternative case of building AAAA RRs via preprocessing + before loading zones has many of the same problems; at best, one can + claim that using AAAA RRs for this purpose would allow DNS clients to + get the wrong answer somewhat more efficiently than with A6 RRs. + + Finally, assuming near total ignorance of how likely a query is to + fail, the probability of failure with an N-link A6 chain would appear + to be roughly proportional to N, since each of the queries involved + in resolving an A6 chain would have the same probability of failure + as a single AAAA query. Note again that this comment applies to + failures in the the process of resolving a query, not to the data + obtained via that process. Arguably, in an ideal world, A6 RRs would + increase the probability of the answer a client (finally) gets being + right, assuming that nothing goes wrong in the query process, but we + have no real idea how to quantify that assumption at this point even + to the hand-wavey extent used elsewhere in this note. + + One potential problem that has been raised in the past regarding A6 + RRs turns out not to be a serious issue. The A6 design includes the + possibility of there being more than one A6 RR matching the prefix + name portion of a leaf A6 RR. That is, an A6 chain may not be a + simple linked list, it may in fact be a tree, where each branch + represents a possible prefix. Some critics of A6 have been concerned + that this will lead to a wild expansion of queries, but this turns + out not to be a problem if a resolver simply follows the "bounded + work per query" rule described in RFC 1034 (page 35). That rule + applies to all work resulting from attempts to process a query, + regardless of whether it's a simple query, a CNAME chain, an A6 tree, + or an infinite loop. The client may not get back a useful answer in + cases where the zone has been configured badly, but a proper + implementation should not produce a query explosion as a result of + processing even the most perverse A6 tree, chain, or loop. + +Interactions with DNSSEC + + One of the areas where AAAA and A6 RRs differ is in the precise + details of how they interact with DNSSEC. The following comments + apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are + semantically equivalent to AAAA RRs). + + + + + + +Austein Informational [Page 5] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + + Other things being equal, the time it takes to re-sign all of the + addresses in a zone after a renumbering event is longer with AAAA RRs + than with A6 RRs (because each address record has to be re-signed + rather than just signing a common prefix A6 RR and a few A6 0 RRs + associated with the zone's name servers). Note, however, that in + general this does not present a serious scaling problem, because the + re-signing is performed in the leaf zones. + + Other things being equal, there's more work involved in verifying the + signatures received back for A6 RRs, because each address fragment + has a separate associated signature. Similarly, a DNS message + containing a set of A6 address fragments and their associated + signatures will be larger than the equivalent packet with a single + AAAA (or A6 0) and a single associated signature. + + Since AAAA RRs cannot really represent rapid renumbering or GSE-style + routing scenarios very well, it should not be surprising that DNSSEC + signatures of AAAA RRs are also somewhat problematic. In cases where + the AAAA RRs would have to be changing very quickly to keep up with + prefix changes, the time required to re-sign the AAAA RRs may be + prohibitive. + + Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that + 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the + BIND-9 dnssec-signzone program under NetBSD can generate roughly 40 + 1024-bit RSA signatures per second. Extrapolating from this, + assuming one A RR, one AAAA RR, and one NXT RR per host, this + suggests that it would take this laptop a few hours to sign a zone + listing 10**5 hosts, or about a day to sign a zone listing 10**6 + hosts using AAAA RRs. + + This suggests that the additional effort of re-signing a large zone + full of AAAA RRs during a re-numbering event, while noticeable, is + only likely to be prohibitive in the rapid renumbering case where + AAAA RRs don't work well anyway. + +Interactions with Dynamic Update + + DNS dynamic update appears to work equally well for AAAA or A6 RRs, + with one minor exception: with A6 RRs, the dynamic update client + needs to know the prefix length and prefix name. At present, no + mechanism exists to inform a dynamic update client of these values, + but presumably such a mechanism could be provided via an extension to + DHCP, or some other equivalent could be devised. + + + + + + + +Austein Informational [Page 6] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + +Transition from AAAA to A6 Via AAAA Synthesis + + While AAAA is at present more widely deployed than A6, it is possible + to transition from AAAA-aware DNS software to A6-aware DNS software. + A rough plan for this was presented at IETF-50 in Minneapolis and has + been discussed on the ipng mailing list. So if the IETF concludes + that A6's enhanced capabilities are necessary, it should be possible + to transition from AAAA to A6. + + The details of this transition have been left to a separate document, + but the general idea is that the resolver that is performing + iterative resolution on behalf of a DNS client program could + synthesize AAAA RRs representing the result of performing the + equivalent A6 queries. Note that in this case it is not possible to + generate an equivalent DNSSEC signature for the AAAA RR, so clients + that care about performing DNSSEC validation for themselves would + have to issue A6 queries directly rather than relying on AAAA + synthesis. + +Bitlabels + + While the differences between AAAA and A6 RRs have generated most of + the discussion to date, there are also two proposed mechanisms for + building the reverse mapping tree (the IPv6 equivalent of IPv4's IN- + ADDR.ARPA tree). + + [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA + mechanism used for IPv4 addresses: the RR name is the hexadecimal + representation of the IPv6 address, reversed and concatenated with a + well-known suffix, broken up with a dot between each hexadecimal + digit. The resulting DNS names are somewhat tedious for humans to + type, but are very easy for programs to generate. Making each + hexadecimal digit a separate label means that delegation on arbitrary + bit boundaries will result in a maximum of 16 NS RRsets per label + level; again, the mechanism is somewhat tedious for humans, but is + very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one + place where this scheme is weak is in handling delegations in the + least significant label; however, since there appears to be no real + need to delegate the least significant four bits of an IPv6 address, + this does not appear to be a serious restriction. + + [RFC2874] proposed a radically different way of naming entries in the + reverse mapping tree: rather than using textual representations of + addresses, it proposes to use a new kind of DNS label (a "bit label") + to represent binary addresses directly in the DNS. This has the + advantage of being significantly more compact than the textual + representation, and arguably might have been a better solution for + DNS to use for this purpose if it had been designed into the protocol + + + +Austein Informational [Page 7] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + + from the outset. Unfortunately, experience to date suggests that + deploying a new DNS label type is very hard: all of the DNS name + servers that are authoritative for any portion of the name in + question must be upgraded before the new label type can be used, as + must any resolvers involved in the resolution process. Any name + server that has not been upgraded to understand the new label type + will reject the query as being malformed. + + Since the main benefit of the bit label approach appears to be an + ability that we don't really need (delegation in the least + significant four bits of an IPv6 address), and since the upgrade + problem is likely to render bit labels unusable until a significant + portion of the DNS code base has been upgraded, it is difficult to + escape the conclusion that the textual solution is good enough. + +DNAME RRs + + [RFC2874] also proposes using DNAME RRs as a way of providing the + equivalent of A6's fragmented addresses in the reverse mapping tree. + That is, by using DNAME RRs, one can write zone files for the reverse + mapping tree that have the same ability to cope with rapid + renumbering or GSE-style routing that the A6 RR offers in the main + portion of the DNS tree. Consequently, the need to use DNAME in the + reverse mapping tree appears to be closely tied to the need to use + fragmented A6 in the main tree: if one is necessary, so is the other, + and if one isn't necessary, the other isn't either. + + Other uses have also been proposed for the DNAME RR, but since they + are outside the scope of the IPv6 address discussion, they will not + be addressed here. + +Recommendation + + Distilling the above feature comparisons down to their key elements, + the important questions appear to be: + + (a) Is IPv6 going to do rapid renumbering or GSE-like routing? + + (b) Is the reverse mapping tree for IPv6 going to require delegation + in the least significant four bits of the address? + + Question (a) appears to be the key to the debate. This is really a + decision for the IPv6 community to make, not the DNS community. + + Question (b) is also for the IPv6 community to make, but it seems + fairly obvious that the answer is "no". + + + + + +Austein Informational [Page 8] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + + Recommendations based on these questions: + + (1) If the IPv6 working groups seriously intend to specify and deploy + rapid renumbering or GSE-like routing, we should transition to + using the A6 RR in the main tree and to using DNAME RRs as + necessary in the reverse tree. + + (2) Otherwise, we should keep the simpler AAAA solution in the main + tree and should not use DNAME RRs in the reverse tree. + + (3) In either case, the reverse tree should use the textual + representation described in [RFC1886] rather than the bit label + representation described in [RFC2874]. + + (4) If we do go to using A6 RRs in the main tree and to using DNAME + RRs in the reverse tree, we should write applicability statements + and implementation guidelines designed to discourage excessively + complex uses of these features; in general, any network that can + be described adequately using A6 0 RRs and without using DNAME + RRs should be described that way, and the enhanced features + should be used only when absolutely necessary, at least until we + have much more experience with them and have a better + understanding of their failure modes. + +Security Considerations + + This note compares two mechanisms with similar security + characteristics, but there are a few security implications to the + choice between these two mechanisms: + + (1) The two mechanisms have similar but not identical interactions + with DNSSEC. Please see the section entitled "Interactions with + DNSSEC" (above) for a discussion of these issues. + + (2) To the extent that operational complexity is the enemy of + security, the tradeoffs in operational complexity discussed + throughout this note have an impact on security. + + (3) To the extent that protocol complexity is the enemy of security, + the additional protocol complexity of [RFC2874] as compared to + [RFC1886] has some impact on security. + +IANA Considerations + + None, since all of these RR types have already been allocated. + + + + + + +Austein Informational [Page 9] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + +Acknowledgments + + This note is based on a number of discussions both public and private + over a period of (at least) eight years, but particular thanks go to + Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun + Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, + and Sue Thomson, none of whom are responsible for what the author did + with their ideas. + +References + + [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support + IP version 6", RFC 1886, December 1995. + + [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support + IPv6 Address Aggregation and Renumbering", RFC 2874, + July 2000. + + [Sommerfeld] Private message to the author from Bill Sommerfeld dated + 21 March 2001, summarizing the result of experiments he + performed on a copy of the MIT.EDU zone. + + [GSE] "GSE" was an evolution of the so-called "8+8" proposal + discussed by the IPng working group in 1996 and 1997. + The GSE proposal itself was written up as an Internet- + Draft, which has long since expired. Readers interested + in the details and history of GSE should review the IPng + working group's mailing list archives and minutes from + that period. + +Author's Address + + Rob Austein + + EMail: sra@hactrn.net + + + + + + + + + + + + + + + + +Austein Informational [Page 10] + +RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Austein Informational [Page 11] + diff --git a/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt new file mode 100644 index 0000000000..707cafd18a --- /dev/null +++ b/doc/rfc/rfc3425.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group D. Lawrence +Request for Comments: 3425 Nominum +Updates: 1035 November 2002 +Category: Standards Track + + + Obsoleting IQUERY + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The IQUERY method of performing inverse DNS lookups, specified in RFC + 1035, has not been generally implemented and has usually been + operationally disabled where it has been implemented. Both reflect a + general view in the community that the concept was unwise and that + the widely-used alternate approach of using pointer (PTR) queries and + reverse-mapping records is preferable. Consequently, this document + deprecates the IQUERY operation, declaring it entirely obsolete. + This document updates RFC 1035. + +1 - Introduction + + As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS + queries is used to look up the name(s) which are associated with the + given value. The value being sought is provided in the query's + answer section and the response fills in the question section with + one or more 3-tuples of type, name and class. + + As noted in [RFC1035], section 6.4.3, inverse query processing can + put quite an arduous burden on a server. A server would need to + perform either an exhaustive search of its database or maintain a + separate database that is keyed by the values of the primary + database. Both of these approaches could strain system resource use, + particularly for servers that are authoritative for millions of + names. + + + + + +Lawrence Standards Track [Page 1] + +RFC 3425 Obsoleting IQUERY November 2002 + + + Response packets from these megaservers could be exceptionally large, + and easily run into megabyte sizes. For example, using IQUERY to + find every domain that is delegated to one of the nameservers of a + large ISP could return tens of thousands of 3-tuples in the question + section. This could easily be used to launch denial of service + attacks. + + Operators of servers that do support IQUERY in some form (such as + very old BIND 4 servers) generally opt to disable it. This is + largely due to bugs in insufficiently-exercised code, or concerns + about exposure of large blocks of names in their zones by probes such + as inverse MX queries. + + IQUERY is also somewhat inherently crippled by being unable to tell a + requester where it needs to go to get the information that was + requested. The answer is very specific to the single server that was + queried. This is sometimes a handy diagnostic tool, but apparently + not enough so that server operators like to enable it, or request + implementation where it is lacking. + + No known clients use IQUERY to provide any meaningful service. The + only common reverse mapping support on the Internet, mapping address + records to names, is provided through the use of pointer (PTR) + records in the in-addr.arpa tree and has served the community well + for many years. + + Based on all of these factors, this document recommends that the + IQUERY operation for DNS servers be officially obsoleted. + +2 - Requirements + + The key word "SHOULD" in this document is to be interpreted as + described in BCP 14, RFC 2119, namely that there may exist valid + reasons to ignore a particular item, but the full implications must + be understood and carefully weighed before choosing a different + course. + +3 - Effect on RFC 1035 + + The effect of this document is to change the definition of opcode 1 + from that originally defined in section 4.1.1 of RFC 1035, and to + entirely supersede section 6.4 (including subsections) of RFC 1035. + + The definition of opcode 1 is hereby changed to: + + "1 an inverse query (IQUERY) (obsolete)" + + + + + +Lawrence Standards Track [Page 2] + +RFC 3425 Obsoleting IQUERY November 2002 + + + The text in section 6.4 of RFC 1035 is now considered obsolete. The + following is an applicability statement regarding the IQUERY opcode: + + Inverse queries using the IQUERY opcode were originally described as + the ability to look up the names that are associated with a + particular Resource Record (RR). Their implementation was optional + and never achieved widespread use. Therefore IQUERY is now obsolete, + and name servers SHOULD return a "Not Implemented" error when an + IQUERY request is received. + +4 - Security Considerations + + Since this document obsoletes an operation that was once available, + it is conceivable that someone was using it as the basis of a + security policy. However, since the most logical course for such a + policy to take in the face of a lack of positive response from a + server is to deny authentication/authorization, it is highly unlikely + that removing support for IQUERY will open any new security holes. + + Note that if IQUERY is not obsoleted, securing the responses with DNS + Security (DNSSEC) is extremely difficult without out-on-the-fly + digital signing. + +5 - IANA Considerations + + The IQUERY opcode of 1 should be permanently retired, not to be + assigned to any future opcode. + +6 - Acknowledgments + + Olafur Gudmundsson instigated this action. Matt Crawford, John + Klensin, Erik Nordmark and Keith Moore contributed some improved + wording in how to handle obsoleting functionality described by an + Internet Standard. + +7 - References + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + +Lawrence Standards Track [Page 3] + +RFC 3425 Obsoleting IQUERY November 2002 + + +8 - Author's Address + + David C Lawrence + Nominum, Inc. + 2385 Bay Rd + Redwood City CA 94063 + USA + + Phone: +1.650.779.6042 + EMail: tale@nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lawrence Standards Track [Page 4] + +RFC 3425 Obsoleting IQUERY November 2002 + + +9 - Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Lawrence Standards Track [Page 5] + diff --git a/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt new file mode 100644 index 0000000000..67f9b2d6e5 --- /dev/null +++ b/doc/rfc/rfc3445.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Massey +Request for Comments: 3445 USC/ISI +Updates: 2535 S. Rose +Category: Standards Track NIST + December 2002 + + + Limiting the Scope of the KEY Resource Record (RR) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document limits the Domain Name System (DNS) KEY Resource Record + (RR) to only keys used by the Domain Name System Security Extensions + (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC + keys and arbitrary application keys. Storing both DNSSEC and + application keys with the same record type is a mistake. This + document removes application keys from the KEY record by redefining + the Protocol Octet field in the KEY RR Data. As a result of removing + application keys, all but one of the flags in the KEY record become + unnecessary and are redefined. Three existing application key sub- + types are changed to reserved, but the format of the KEY record is + not changed. This document updates RFC 2535. + +1. Introduction + + This document limits the scope of the KEY Resource Record (RR). The + KEY RR was defined in [3] and used resource record sub-typing to hold + arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys. + This document eliminates the existing Email, IPSEC, and TLS sub-types + and prohibits the introduction of new sub-types. DNSSEC will be the + only allowable sub-type for the KEY RR (hence sub-typing is + essentially eliminated) and all but one of the KEY RR flags are also + eliminated. + + + + + + +Massey & Rose Standards Track [Page 1] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + Section 2 presents the motivation for restricting the KEY record and + Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the + changes from RFC 2535 and discuss backwards compatibility. It is + important to note that this document restricts the use of the KEY RR + and simplifies the flags, but does not change the definition or use + of DNSSEC keys. + + 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 [1]. + +2. Motivation for Restricting the KEY RR + + The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an + Algorithm type, and a Public Key. The Protocol Octet identifies the + KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a + Protocol Octet value of 3. Email, IPSEC, and TLS keys were also + stored in the KEY RR and used Protocol Octet values of 1,2, and 4 + (respectively). Protocol Octet values 5-254 were available for + assignment by IANA and values were requested (but not assigned) for + applications such as SSH. + + Any use of sub-typing has inherent limitations. A resolver can not + specify the desired sub-type in a DNS query and most DNS operations + apply only to resource records sets. For example, a resolver can not + directly request the DNSSEC subtype KEY RRs. Instead, the resolver + has to request all KEY RRs associated with a DNS name and then search + the set for the desired DNSSEC sub-type. DNSSEC signatures also + apply to the set of all KEY RRs associated with the DNS name, + regardless of sub-type. + + In the case of the KEY RR, the inherent sub-type limitations are + exacerbated since the sub-type is used to distinguish between DNSSEC + keys and application keys. DNSSEC keys and application keys differ + in virtually every respect and Section 2.1 discusses these + differences in more detail. Combining these very different types of + keys into a single sub-typed resource record adds unnecessary + complexity and increases the potential for implementation and + deployment errors. Limited experimental deployment has shown that + application keys stored in KEY RRs are problematic. + + This document addresses these issues by removing all application keys + from the KEY RR. Note that the scope of this document is strictly + limited to the KEY RR and this document does not endorse or restrict + the storage of application keys in other, yet undefined, resource + records. + + + + + +Massey & Rose Standards Track [Page 2] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +2.1 Differences Between DNSSEC and Application Keys + + DNSSEC keys are an essential part of the DNSSEC protocol and are used + by both name servers and resolvers in order to perform DNS tasks. A + DNS zone key, used to sign and authenticate RR sets, is the most + common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use + DNSSEC keys. + + Application keys such as Email keys, IPSEC keys, and TLS keys are + simply another type of data. These keys have no special meaning to a + name server or resolver. + + The following table summarizes some of the differences between DNSSEC + keys and application keys: + + 1. They serve different purposes. + + 2. They are managed by different administrators. + + 3. They are authenticated according to different rules. + + 4. Nameservers use different rules when including them in + responses. + + 5. Resolvers process them in different ways. + + 6. Faults/key compromises have different consequences. + + 1. The purpose of a DNSSEC key is to sign resource records + associated with a DNS zone (or generate DNS transaction signatures in + the case of SIG(0)/TKEY). But the purpose of an application key is + specific to the application. Application keys, such as PGP/email, + IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and + the purpose and proper use of application keys is outside the scope + of DNS. + + 2. DNSSEC keys are managed by DNS administrators, but application + keys are managed by application administrators. The DNS zone + administrator determines the key lifetime, handles any suspected key + compromises, and manages any DNSSEC key changes. Likewise, the + application administrator is responsible for the same functions for + the application keys related to the application. For example, a user + typically manages her own PGP key and a server manages its own TLS + key. Application key management tasks are outside the scope of DNS + administration. + + + + + + +Massey & Rose Standards Track [Page 3] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + 3. DNSSEC zone keys are used to authenticate application keys, but + by definition, application keys are not allowed to authenticate DNS + zone keys. A DNS zone key is either configured as a trusted key or + authenticated by constructing a chain of trust in the DNS hierarchy. + To participate in the chain of trust, a DNS zone needs to exchange + zone key information with its parent zone [3]. Application keys are + not configured as trusted keys in the DNS and are never part of any + DNS chain of trust. Application key data is not needed by the parent + and does not need to be exchanged with the parent zone for secure DNS + resolution to work. A resolver considers an application key RRset as + authenticated DNS information if it has a valid signature from the + local DNS zone keys, but applications could impose additional + security requirements before the application key is accepted as + authentic for use with the application. + + 4. It may be useful for nameservers to include DNS zone keys in the + additional section of a response, but application keys are typically + not useful unless they have been specifically requested. For + example, it could be useful to include the example.com zone key along + with a response that contains the www.example.com A record and SIG + record. A secure resolver will need the example.com zone key in + order to check the SIG and authenticate the www.example.com A record. + It is typically not useful to include the IPSEC, email, and TLS keys + along with the A record. Note that by placing application keys in + the KEY record, a resolver would need the IPSEC, email, TLS, and + other key associated with example.com if the resolver intends to + authenticate the example.com zone key (since signatures only apply to + the entire KEY RR set). Depending on the number of protocols + involved, the KEY RR set could grow unwieldy for resolvers, and DNS + administrators to manage. + + 5. DNS zone keys require special handling by resolvers, but + application keys are treated the same as any other type of DNS data. + The DNSSEC keys are of no value to end applications, unless the + applications plan to do their own DNS authentication. By definition, + secure resolvers are not allowed to use application keys as part of + the authentication process. Application keys have no unique meaning + to resolvers and are only useful to the application requesting the + key. Note that if sub-types are used to identify the application + key, then either the interface to the resolver needs to specify the + sub-type or the application needs to be able to accept all KEY RRs + and pick out the desired sub-type. + + 6. A fault or compromise of a DNS zone key can lead to invalid or + forged DNS data, but a fault or compromise of an application key + should have no impact on other DNS data. Incorrectly adding or + changing a DNS zone key can invalidate all of the DNS data in the + zone and in all of its subzones. By using a compromised key, an + + + +Massey & Rose Standards Track [Page 4] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + attacker can forge data from the effected zone and for any of its + sub-zones. A fault or compromise of an application key has + implications for that application, but it should not have an impact + on the DNS. Note that application key faults and key compromises can + have an impact on the entire DNS if the application key and DNS zone + keys are both stored in the KEY RR. + + In summary, DNSSEC keys and application keys differ in most every + respect. DNSSEC keys are an essential part of the DNS infrastructure + and require special handling by DNS administrators and DNS resolvers. + Application keys are simply another type of data and have no special + meaning to DNS administrators or resolvers. These two different + types of data do not belong in the same resource record. + +3. Definition of the KEY RR + + The KEY RR uses type 25 and is used as resource record for storing + DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol + octet, the algorithm number octet, and the public key itself. The + format is as follows: + + --------------------------------------------------------------------- + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags | protocol | algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + KEY RR Format + + --------------------------------------------------------------------- + + In the flags field, all bits except bit 7 are reserved and MUST be + zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone + key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY + are examples of DNSSEC keys that are not zone keys. + + The protocol field MUST be set to 3. + + The algorithm and public key fields are not changed. + + + + + +Massey & Rose Standards Track [Page 5] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +4. Changes from RFC 2535 KEY RR + + The KEY RDATA format is not changed. + + All flags except for the zone key flag are eliminated: + + The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0 + and MUST be ignored by the receiver. + + The extended flags bit (bit 3) is eliminated. It MUST be set to 0 + and MUST be ignored by the receiver. + + The host/user bit (bit 6) is eliminated. It MUST be set to 0 and + MUST be ignored by the receiver. + + The zone bit (bit 7) remains unchanged. + + The signatory field (bits 12-15) are eliminated by [5]. They MUST + be set to 0 and MUST be ignored by the receiver. + + Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be + set to zero and MUST be ignored by the receiver. + + Assignment of any future KEY RR Flag values requires a standards + action. + + All Protocol Octet values except DNSSEC (3) are eliminated: + + Value 1 (Email) is renamed to RESERVED. + + Value 2 (IPSEC) is renamed to RESERVED. + + Value 3 (DNSSEC) is unchanged. + + Value 4 (TLS) is renamed to RESERVED. + + Value 5-254 remains unchanged (reserved). + + Value 255 (ANY) is renamed to RESERVED. + + The authoritative data for a zone MUST NOT include any KEY records + with a protocol octet other than 3. The registry maintained by IANA + for protocol values is closed for new assignments. + + Name servers and resolvers SHOULD accept KEY RR sets that contain KEY + RRs with a value other than 3. If out of date DNS zones contain + deprecated KEY RRs with a protocol octet value other than 3, then + simply dropping the deprecated KEY RRs from the KEY RR set would + + + +Massey & Rose Standards Track [Page 6] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + invalidate any associated SIG record(s) and could create caching + consistency problems. Note that KEY RRs with a protocol octet value + other than 3 MUST NOT be used to authenticate DNS data. + + The algorithm and public key fields are not changed. + +5. Backward Compatibility + + DNSSEC zone KEY RRs are not changed and remain backwards compatible. + A properly formatted RFC 2535 zone KEY would have all flag bits, + other than the Zone Bit (Bit 7), set to 0 and would have the Protocol + Octet set to 3. This remains true under the restricted KEY. + + DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible, + but the distinction between host and user keys (flag bit 6) is lost. + + No backwards compatibility is provided for application keys. Any + Email, IPSEC, or TLS keys are now deprecated. Storing application + keys in the KEY RR created problems such as keys at the apex and + large RR sets and some change in the definition and/or usage of the + KEY RR would have been required even if the approach described here + were not adopted. + + Overall, existing nameservers and resolvers will continue to + correctly process KEY RRs with a sub-type of DNSSEC keys. + +6. Storing Application Keys in the DNS + + The scope of this document is strictly limited to the KEY record. + This document prohibits storing application keys in the KEY record, + but it does not endorse or restrict the storing application keys in + other record types. Other documents can describe how DNS handles + application keys. + +7. IANA Considerations + + RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet + values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and + values 5-254 were made available for assignment by IANA. This + document makes two sets of changes to this registry. + + First, this document re-assigns DNS KEY RR Protocol Octet values 1, + 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3 + remains unchanged as "DNSSEC". + + + + + + + +Massey & Rose Standards Track [Page 7] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + + Second, new values are no longer available for assignment by IANA and + this document closes the IANA registry for DNS KEY RR Protocol Octet + Values. Assignment of any future KEY RR Protocol Octet values + requires a standards action. + +8. Security Considerations + + This document eliminates potential security problems that could arise + due to the coupling of DNS zone keys and application keys. Prior to + the change described in this document, a correctly authenticated KEY + set could include both application keys and DNSSEC keys. This + document restricts the KEY RR to DNS security usage only. This is an + attempt to simplify the security model and make it less user-error + prone. If one of the application keys is compromised, it could be + used as a false zone key to create false DNS signatures (SIG + records). Resolvers that do not carefully check the KEY sub-type + could believe these false signatures and incorrectly authenticate DNS + data. With this change, application keys cannot appear in an + authenticated KEY set and this vulnerability is eliminated. + + The format and correct usage of DNSSEC keys is not changed by this + document and no new security considerations are introduced. + +9. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC + 2930, September 2000. + + [4] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + + + + + + + +Massey & Rose Standards Track [Page 8] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +10. Authors' Addresses + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-3460 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Massey & Rose Standards Track [Page 9] + +RFC 3445 Limiting the KEY Resource Record (RR) December 2002 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Massey & Rose Standards Track [Page 10] + diff --git a/doc/rfc/rfc3493.txt b/doc/rfc/rfc3493.txt new file mode 100644 index 0000000000..5fea6c19ec --- /dev/null +++ b/doc/rfc/rfc3493.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group R. Gilligan +Request for Comments: 3493 Intransa, Inc. +Obsoletes: 2553 S. Thomson +Category: Informational Cisco + J. Bound + J. McCann + Hewlett-Packard + W. Stevens + February 2003 + + + Basic Socket Interface Extensions for IPv6 + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The de facto standard Application Program Interface (API) for TCP/IP + applications is the "sockets" interface. Although this API was + developed for Unix in the early 1980s it has also been implemented on + a wide variety of non-Unix systems. TCP/IP applications written + using the sockets API have in the past enjoyed a high degree of + portability and we would like the same portability with IPv6 + applications. But changes are required to the sockets API to support + IPv6 and this memo describes these changes. These include a new + socket address structure to carry IPv6 addresses, new address + conversion functions, and some new socket options. These extensions + are designed to provide access to the basic IPv6 features required by + TCP and UDP applications, including multicasting, while introducing a + minimum of change into the system and providing complete + compatibility for existing IPv4 applications. Additional extensions + for advanced IPv6 features (raw sockets and access to the IPv6 + extension headers) are defined in another document. + + + + + + + + + + +Gilligan, et al. Informational [Page 1] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +Table of Contents + + 1. Introduction................................................3 + 2. Design Considerations.......................................4 + 2.1 What Needs to be Changed...............................4 + 2.2 Data Types.............................................6 + 2.3 Headers................................................6 + 2.4 Structures.............................................6 + 3. Socket Interface............................................6 + 3.1 IPv6 Address Family and Protocol Family................6 + 3.2 IPv6 Address Structure.................................7 + 3.3 Socket Address Structure for 4.3BSD-Based Systems......7 + 3.4 Socket Address Structure for 4.4BSD-Based Systems......9 + 3.5 The Socket Functions...................................9 + 3.6 Compatibility with IPv4 Applications..................10 + 3.7 Compatibility with IPv4 Nodes.........................11 + 3.8 IPv6 Wildcard Address.................................11 + 3.9 IPv6 Loopback Address.................................13 + 3.10 Portability Additions.................................14 + 4. Interface Identification...................................16 + 4.1 Name-to-Index.........................................17 + 4.2 Index-to-Name.........................................17 + 4.3 Return All Interface Names and Indexes................18 + 4.4 Free Memory...........................................18 + 5. Socket Options.............................................18 + 5.1 Unicast Hop Limit.....................................19 + 5.2 Sending and Receiving Multicast Packets...............19 + 5.3 IPV6_V6ONLY option for AF_INET6 Sockets...............22 + 6. Library Functions..........................................22 + 6.1 Protocol-Independent Nodename and + Service Name Translation..............................23 + 6.2 Socket Address Structure to Node Name + and Service Name......................................28 + 6.3 Address Conversion Functions..........................31 + 6.4 Address Testing Macros................................33 + 7. Summary of New Definitions.................................33 + 8. Security Considerations....................................35 + 9. Changes from RFC 2553......................................35 + 10. Acknowledgments............................................36 + 11. References.................................................37 + 12. Authors' Addresses.........................................38 + 13. Full Copyright Statement...................................39 + + + + + + + + + +Gilligan, et al. Informational [Page 2] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +1. Introduction + + While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits + long. The socket interface makes the size of an IP address quite + visible to an application; virtually all TCP/IP applications for + BSD-based systems have knowledge of the size of an IP address. Those + parts of the API that expose the addresses must be changed to + accommodate the larger IPv6 address size. IPv6 also introduces new + features, some of which must be made visible to applications via the + API. This memo defines a set of extensions to the socket interface + to support the larger address size and new features of IPv6. It + defines "basic" extensions that are of use to a broad range of + applications. A companion document, the "advanced" API [4], covers + extensions that are of use to more specialized applications, examples + of which include routing daemons, and the "ping" and "traceroute" + utilities. + + The development of this API was started in 1994 in the IETF IPng + working group. The API has evolved over the years, published first + in RFC 2133, then again in RFC 2553, and reaching its final form in + this document. + + As the API matured and stabilized, it was incorporated into the Open + Group's Networking Services (XNS) specification, issue 5.2, which was + subsequently incorporated into a joint Open Group/IEEE/ISO standard + [3]. + + Effort has been made to ensure that this document and [3] contain the + same information with regard to the API definitions. However, the + reader should note that this document is for informational purposes + only, and that the official standard specification of the sockets API + is [3]. + + It is expected that any future standardization work on this API would + be done by the Open Group Base Working Group [6]. + + It should also be noted that this document describes only those + portions of the API needed for IPv4 and IPv6 communications. Other + potential uses of the API, for example the use of getaddrinfo() and + getnameinfo() with the AF_UNIX address family, are beyond the scope + of this document. + + + + + + + + + + +Gilligan, et al. Informational [Page 3] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +2. Design Considerations + + There are a number of important considerations in designing changes + to this well-worn API: + + - The API changes should provide both source and binary + compatibility for programs written to the original API. That is, + existing program binaries should continue to operate when run on a + system supporting the new API. In addition, existing applications + that are re-compiled and run on a system supporting the new API + should continue to operate. Simply put, the API changes for IPv6 + should not break existing programs. An additional mechanism for + implementations to verify this is to verify the new symbols are + protected by Feature Test Macros as described in [3]. (Such + Feature Test Macros are not defined by this RFC.) + + - The changes to the API should be as small as possible in order to + simplify the task of converting existing IPv4 applications to + IPv6. + + - Where possible, applications should be able to use this API to + interoperate with both IPv6 and IPv4 hosts. Applications should + not need to know which type of host they are communicating with. + + - IPv6 addresses carried in data structures should be 64-bit + aligned. This is necessary in order to obtain optimum performance + on 64-bit machine architectures. + + Because of the importance of providing IPv4 compatibility in the API, + these extensions are explicitly designed to operate on machines that + provide complete support for both IPv4 and IPv6. A subset of this + API could probably be designed for operation on systems that support + only IPv6. However, this is not addressed in this memo. + +2.1 What Needs to be Changed + + The socket interface API consists of a few distinct components: + + - Core socket functions. + + - Address data structures. + + - Name-to-address translation functions. + + - Address conversion functions. + + + + + + +Gilligan, et al. Informational [Page 4] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + The core socket functions -- those functions that deal with such + things as setting up and tearing down TCP connections, and sending + and receiving UDP packets -- were designed to be transport + independent. Where protocol addresses are passed as function + arguments, they are carried via opaque pointers. A protocol-specific + address data structure is defined for each protocol that the socket + functions support. Applications must cast pointers to these + protocol-specific address structures into pointers to the generic + "sockaddr" address structure when using the socket functions. These + functions need not change for IPv6, but a new IPv6-specific address + data structure is needed. + + The "sockaddr_in" structure is the protocol-specific data structure + for IPv4. This data structure actually includes 8-octets of unused + space, and it is tempting to try to use this space to adapt the + sockaddr_in structure to IPv6. Unfortunately, the sockaddr_in + structure is not large enough to hold the 16-octet IPv6 address as + well as the other information (address family and port number) that + is needed. So a new address data structure must be defined for IPv6. + + IPv6 addresses are scoped [2] so they could be link-local, site, + organization, global, or other scopes at this time undefined. To + support applications that want to be able to identify a set of + interfaces for a specific scope, the IPv6 sockaddr_in structure must + support a field that can be used by an implementation to identify a + set of interfaces identifying the scope for an IPv6 address. + + The IPv4 name-to-address translation functions in the socket + interface are gethostbyname() and gethostbyaddr(). These are left as + is, and new functions are defined which support both IPv4 and IPv6. + + The IPv4 address conversion functions -- inet_ntoa() and inet_addr() + -- convert IPv4 addresses between binary and printable form. These + functions are quite specific to 32-bit IPv4 addresses. We have + designed two analogous functions that convert both IPv4 and IPv6 + addresses, and carry an address type parameter so that they can be + extended to other protocol families as well. + + Finally, a few miscellaneous features are needed to support IPv6. A + new interface is needed to support the IPv6 hop limit header field. + New socket options are needed to control the sending and receiving of + IPv6 multicast packets. + + The socket interface will be enhanced in the future to provide access + to other IPv6 features. Some of these extensions are described in + [4]. + + + + + +Gilligan, et al. Informational [Page 5] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +2.2 Data Types + + The data types of the structure elements given in this memo are + intended to track the relevant standards. uintN_t means an unsigned + integer of exactly N bits (e.g., uint16_t). The sa_family_t and + in_port_t types are defined in [3]. + +2.3 Headers + + When function prototypes and structures are shown we show the headers + that must be #included to cause that item to be defined. + +2.4 Structures + + When structures are described the members shown are the ones that + must appear in an implementation. Additional, nonstandard members + may also be defined by an implementation. As an additional + precaution nonstandard members could be verified by Feature Test + Macros as described in [3]. (Such Feature Test Macros are not + defined by this RFC.) + + The ordering shown for the members of a structure is the recommended + ordering, given alignment considerations of multibyte members, but an + implementation may order the members differently. + +3. Socket Interface + + This section specifies the socket interface changes for IPv6. + +3.1 IPv6 Address Family and Protocol Family + + A new address family name, AF_INET6, is defined in . + The AF_INET6 definition distinguishes between the original + sockaddr_in address data structure, and the new sockaddr_in6 data + structure. + + A new protocol family name, PF_INET6, is defined in . + Like most of the other protocol family names, this will usually be + defined to have the same value as the corresponding address family + name: + + #define PF_INET6 AF_INET6 + + The AF_INET6 is used in the first argument to the socket() function + to indicate that an IPv6 socket is being created. + + + + + + +Gilligan, et al. Informational [Page 6] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +3.2 IPv6 Address Structure + + A new in6_addr structure holds a single IPv6 address and is defined + as a result of including : + + struct in6_addr { + uint8_t s6_addr[16]; /* IPv6 address */ + }; + + This data structure contains an array of sixteen 8-bit elements, + which make up one 128-bit IPv6 address. The IPv6 address is stored + in network byte order. + + The structure in6_addr above is usually implemented with an embedded + union with extra fields that force the desired alignment level in a + manner similar to BSD implementations of "struct in_addr". Those + additional implementation details are omitted here for simplicity. + + An example is as follows: + + struct in6_addr { + union { + uint8_t _S6_u8[16]; + uint32_t _S6_u32[4]; + uint64_t _S6_u64[2]; + } _S6_un; + }; + #define s6_addr _S6_un._S6_u8 + +3.3 Socket Address Structure for 4.3BSD-Based Systems + + In the socket interface, a different protocol-specific data structure + is defined to carry the addresses for each protocol suite. Each + protocol-specific data structure is designed so it can be cast into a + protocol-independent data structure -- the "sockaddr" structure. + Each has a "family" field that overlays the "sa_family" of the + sockaddr data structure. This field identifies the type of the data + structure. + + The sockaddr_in structure is the protocol-specific address data + structure for IPv4. It is used to pass addresses between + applications and the system in the socket functions. The following + sockaddr_in6 structure holds IPv6 addresses and is defined as a + result of including the header: + + + + + + + +Gilligan, et al. Informational [Page 7] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +struct sockaddr_in6 { + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ +}; + + This structure is designed to be compatible with the sockaddr data + structure used in the 4.3BSD release. + + The sin6_family field identifies this as a sockaddr_in6 structure. + This field overlays the sa_family field when the buffer is cast to a + sockaddr data structure. The value of this field must be AF_INET6. + + The sin6_port field contains the 16-bit UDP or TCP port number. This + field is used in the same way as the sin_port field of the + sockaddr_in structure. The port number is stored in network byte + order. + + The sin6_flowinfo field is a 32-bit field intended to contain flow- + related information. The exact way this field is mapped to or from a + packet is not currently specified. Until such time as its use is + specified, applications should set this field to zero when + constructing a sockaddr_in6, and ignore this field in a sockaddr_in6 + structure constructed by the system. + + The sin6_addr field is a single in6_addr structure (defined in the + previous section). This field holds one 128-bit IPv6 address. The + address is stored in network byte order. + + The ordering of elements in this structure is specifically designed + so that when sin6_addr field is aligned on a 64-bit boundary, the + start of the structure will also be aligned on a 64-bit boundary. + This is done for optimum performance on 64-bit architectures. + + The sin6_scope_id field is a 32-bit integer that identifies a set of + interfaces as appropriate for the scope [2] of the address carried in + the sin6_addr field. The mapping of sin6_scope_id to an interface or + set of interfaces is left to implementation and future specifications + on the subject of scoped addresses. + + Notice that the sockaddr_in6 structure will normally be larger than + the generic sockaddr structure. On many existing implementations the + sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both + being 16 bytes. Any existing code that makes this assumption needs + to be examined carefully when converting to IPv6. + + + + +Gilligan, et al. Informational [Page 8] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +3.4 Socket Address Structure for 4.4BSD-Based Systems + + The 4.4BSD release includes a small, but incompatible change to the + socket interface. The "sa_family" field of the sockaddr data + structure was changed from a 16-bit value to an 8-bit value, and the + space saved used to hold a length field, named "sa_len". The + sockaddr_in6 data structure given in the previous section cannot be + correctly cast into the newer sockaddr data structure. For this + reason, the following alternative IPv6 address data structure is + provided to be used on systems based on 4.4BSD. It is defined as a + result of including the header. + +struct sockaddr_in6 { + uint8_t sin6_len; /* length of this struct */ + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ +}; + + The only differences between this data structure and the 4.3BSD + variant are the inclusion of the length field, and the change of the + family field to a 8-bit data type. The definitions of all the other + fields are identical to the structure defined in the previous + section. + + Systems that provide this version of the sockaddr_in6 data structure + must also declare SIN6_LEN as a result of including the + header. This macro allows applications to determine + whether they are being built on a system that supports the 4.3BSD or + 4.4BSD variants of the data structure. + +3.5 The Socket Functions + + Applications call the socket() function to create a socket descriptor + that represents a communication endpoint. The arguments to the + socket() function tell the system which protocol to use, and what + format address structure will be used in subsequent functions. For + example, to create an IPv4/TCP socket, applications make the call: + + s = socket(AF_INET, SOCK_STREAM, 0); + + To create an IPv4/UDP socket, applications make the call: + + s = socket(AF_INET, SOCK_DGRAM, 0); + + + + + +Gilligan, et al. Informational [Page 9] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + Applications may create IPv6/TCP and IPv6/UDP sockets (which may also + handle IPv4 communication as described in section 3.7) by simply + using the constant AF_INET6 instead of AF_INET in the first argument. + For example, to create an IPv6/TCP socket, applications make the + call: + + s = socket(AF_INET6, SOCK_STREAM, 0); + + To create an IPv6/UDP socket, applications make the call: + + s = socket(AF_INET6, SOCK_DGRAM, 0); + + Once the application has created a AF_INET6 socket, it must use the + sockaddr_in6 address structure when passing addresses in to the + system. The functions that the application uses to pass addresses + into the system are: + + bind() + connect() + sendmsg() + sendto() + + The system will use the sockaddr_in6 address structure to return + addresses to applications that are using AF_INET6 sockets. The + functions that return an address from the system to an application + are: + + accept() + recvfrom() + recvmsg() + getpeername() + getsockname() + + No changes to the syntax of the socket functions are needed to + support IPv6, since all of the "address carrying" functions use an + opaque address pointer, and carry an address length as a function + argument. + +3.6 Compatibility with IPv4 Applications + + In order to support the large base of applications using the original + API, system implementations must provide complete source and binary + compatibility with the original API. This means that systems must + continue to support AF_INET sockets and the sockaddr_in address + structure. Applications must be able to create IPv4/TCP and IPv4/UDP + sockets using the AF_INET constant in the socket() function, as + + + + + +Gilligan, et al. Informational [Page 10] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + described in the previous section. Applications should be able to + hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP + sockets simultaneously within the same process. + + Applications using the original API should continue to operate as + they did on systems supporting only IPv4. That is, they should + continue to interoperate with IPv4 nodes. + +3.7 Compatibility with IPv4 Nodes + + The API also provides a different type of compatibility: the ability + for IPv6 applications to interoperate with IPv4 applications. This + feature uses the IPv4-mapped IPv6 address format defined in the IPv6 + addressing architecture specification [2]. This address format + allows the IPv4 address of an IPv4 node to be represented as an IPv6 + address. The IPv4 address is encoded into the low-order 32 bits of + the IPv6 address, and the high-order 96 bits hold the fixed prefix + 0:0:0:0:0:FFFF. IPv4-mapped addresses are written as follows: + + ::FFFF: + + These addresses can be generated automatically by the getaddrinfo() + function, as described in Section 6.1. + + Applications may use AF_INET6 sockets to open TCP connections to IPv4 + nodes, or send UDP packets to IPv4 nodes, by simply encoding the + destination's IPv4 address as an IPv4-mapped IPv6 address, and + passing that address, within a sockaddr_in6 structure, in the + connect() or sendto() call. When applications use AF_INET6 sockets + to accept TCP connections from IPv4 nodes, or receive UDP packets + from IPv4 nodes, the system returns the peer's address to the + application in the accept(), recvfrom(), or getpeername() call using + a sockaddr_in6 structure encoded this way. + + Few applications will likely need to know which type of node they are + interoperating with. However, for those applications that do need to + know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is + provided. + +3.8 IPv6 Wildcard Address + + While the bind() function allows applications to select the source IP + address of UDP packets and TCP connections, applications often want + the system to select the source address for them. With IPv4, one + specifies the address as the symbolic constant INADDR_ANY (called the + "wildcard" address) in the bind() call, or simply omits the bind() + entirely. + + + + +Gilligan, et al. Informational [Page 11] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + Since the IPv6 address type is a structure (struct in6_addr), a + symbolic constant can be used to initialize an IPv6 address variable, + but cannot be used in an assignment. Therefore systems provide the + IPv6 wildcard address in two forms. + + The first version is a global variable named "in6addr_any" that is an + in6_addr structure. The extern declaration for this variable is + defined in : + + extern const struct in6_addr in6addr_any; + + Applications use in6addr_any similarly to the way they use INADDR_ANY + in IPv4. For example, to bind a socket to port number 23, but let + the system select the source address, an application could use the + following code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_any; /* structure assignment */ + . . . + if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + + The other version is a symbolic constant named IN6ADDR_ANY_INIT and + is defined in . This constant can be used to + initialize an in6_addr structure: + + struct in6_addr anyaddr = IN6ADDR_ANY_INIT; + + Note that this constant can be used ONLY at declaration time. It can + not be used to assign a previously declared in6_addr structure. For + example, the following code will not work: + + /* This is the WRONG way to assign an unspecified address */ + struct sockaddr_in6 sin6; + . . . + sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ + + Be aware that the IPv4 INADDR_xxx constants are all defined in host + byte order but the IPv6 IN6ADDR_xxx constants and the IPv6 + in6addr_xxx externals are defined in network byte order. + + + + + + + +Gilligan, et al. Informational [Page 12] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +3.9 IPv6 Loopback Address + + Applications may need to send UDP packets to, or originate TCP + connections to, services residing on the local node. In IPv4, they + can do this by using the constant IPv4 address INADDR_LOOPBACK in + their connect(), sendto(), or sendmsg() call. + + IPv6 also provides a loopback address to contact local TCP and UDP + services. Like the unspecified address, the IPv6 loopback address is + provided in two forms -- a global variable and a symbolic constant. + + The global variable is an in6_addr structure named + "in6addr_loopback." The extern declaration for this variable is + defined in : + + extern const struct in6_addr in6addr_loopback; + + Applications use in6addr_loopback as they would use INADDR_LOOPBACK + in IPv4 applications (but beware of the byte ordering difference + mentioned at the end of the previous section). For example, to open + a TCP connection to the local telnet server, an application could use + the following code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_loopback; /* structure assignment */ + . . . + if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + + The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined + in . It can be used at declaration time ONLY; for + example: + + struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; + + Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment + to a previously declared IPv6 address variable. + + + + + + + + + + +Gilligan, et al. Informational [Page 13] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +3.10 Portability Additions + + One simple addition to the sockets API that can help application + writers is the "struct sockaddr_storage". This data structure can + simplify writing code that is portable across multiple address + families and platforms. This data structure is designed with the + following goals. + + - Large enough to accommodate all supported protocol-specific address + structures. + + - Aligned at an appropriate boundary so that pointers to it can be + cast as pointers to protocol specific address structures and used + to access the fields of those structures without alignment + problems. + + The sockaddr_storage structure contains field ss_family which is of + type sa_family_t. When a sockaddr_storage structure is cast to a + sockaddr structure, the ss_family field of the sockaddr_storage + structure maps onto the sa_family field of the sockaddr structure. + When a sockaddr_storage structure is cast as a protocol specific + address structure, the ss_family field maps onto a field of that + structure that is of type sa_family_t and that identifies the + protocol's address family. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gilligan, et al. Informational [Page 14] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + An example implementation design of such a data structure would be as + follows. + +/* + * Desired design of maximum size and alignment + */ +#define _SS_MAXSIZE 128 /* Implementation specific max size */ +#define _SS_ALIGNSIZE (sizeof (int64_t)) + /* Implementation specific desired alignment */ +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_family */ + /* __ss_pad1, __ss_align fields is 112 */ +}; + + The above example implementation illustrates a data structure which + will align on a 64-bit boundary. An implementation-specific field + "__ss_align" along with "__ss_pad1" is used to force a 64-bit + alignment which covers proper alignment good enough for the needs of + sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures. The + size of padding field __ss_pad1 depends on the chosen alignment + boundary. The size of padding field __ss_pad2 depends on the value + of overall size chosen for the total size of the structure. This + size and alignment are represented in the above example by + implementation specific (not required) constants _SS_MAXSIZE (chosen + value 128) and _SS_ALIGNSIZE (with chosen value 8). Constants + _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112) + are also for illustration and not required. The derived values + assume sa_family_t is 2 bytes. The implementation specific + definitions and structure field names above start with an underscore + to denote implementation private namespace. Portable code is not + expected to access or reference those fields or constants. + + + + +Gilligan, et al. Informational [Page 15] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + On implementations where the sockaddr data structure includes a + "sa_len" field this data structure would look like this: + +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t) + + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + uint8_t ss_len; /* address length */ + sa_family_t ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_len, */ + /* __ss_family, __ss_pad1, __ss_align fields is 112 */ +}; + +4. Interface Identification + + This API uses an interface index (a small positive integer) to + identify the local interface on which a multicast group is joined + (Section 5.2). Additionally, the advanced API [4] uses these same + interface indexes to identify the interface on which a datagram is + received, or to specify the interface on which a datagram is to be + sent. + + Interfaces are normally known by names such as "le0", "sl1", "ppp2", + and the like. On Berkeley-derived implementations, when an interface + is made known to the system, the kernel assigns a unique positive + integer value (called the interface index) to that interface. These + are small positive integers that start at 1. (Note that 0 is never + used for an interface index.) There may be gaps so that there is no + current interface for a particular positive interface index. + + This API defines two functions that map between an interface name and + index, a third function that returns all the interface names and + indexes, and a fourth function to return the dynamic memory allocated + by the previous function. How these functions are implemented is + + + +Gilligan, et al. Informational [Page 16] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + left up to the implementation. 4.4BSD implementations can implement + these functions using the existing sysctl() function with the + NET_RT_IFLIST command. Other implementations may wish to use ioctl() + for this purpose. + +4.1 Name-to-Index + + The first function maps an interface name into its corresponding + index. + + #include + + unsigned int if_nametoindex(const char *ifname); + + If ifname is the name of an interface, the if_nametoindex() function + shall return the interface index corresponding to name ifname; + otherwise, it shall return zero. No errors are defined. + +4.2 Index-to-Name + + The second function maps an interface index into its corresponding + name. + + #include + + char *if_indextoname(unsigned int ifindex, char *ifname); + + When this function is called, the ifname argument shall point to a + buffer of at least IF_NAMESIZE bytes. The function shall place in + this buffer the name of the interface with index ifindex. + (IF_NAMESIZE is also defined in and its value includes a + terminating null byte at the end of the interface name.) If ifindex + is an interface index, then the function shall return the value + supplied in ifname, which points to a buffer now containing the + interface name. Otherwise, the function shall return a NULL pointer + and set errno to indicate the error. If there is no interface + corresponding to the specified index, errno is set to ENXIO. If + there was a system error (such as running out of memory), errno would + be set to the proper value (e.g., ENOMEM). + + + + + + + + + + + + +Gilligan, et al. Informational [Page 17] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +4.3 Return All Interface Names and Indexes + + The if_nameindex structure holds the information about a single + interface and is defined as a result of including the + header. + + struct if_nameindex { + unsigned int if_index; /* 1, 2, ... */ + char *if_name; /* null terminated name: "le0", ... */ + }; + + The final function returns an array of if_nameindex structures, one + structure per interface. + + #include + + struct if_nameindex *if_nameindex(void); + + The end of the array of structures is indicated by a structure with + an if_index of 0 and an if_name of NULL. The function returns a NULL + pointer upon an error, and would set errno to the appropriate value. + + The memory used for this array of structures along with the interface + names pointed to by the if_name members is obtained dynamically. + This memory is freed by the next function. + +4.4 Free Memory + + The following function frees the dynamic memory that was allocated by + if_nameindex(). + + #include + + void if_freenameindex(struct if_nameindex *ptr); + + The ptr argument shall be a pointer that was returned by + if_nameindex(). After if_freenameindex() has been called, the + application shall not use the array of which ptr is the address. + +5. Socket Options + + A number of new socket options are defined for IPv6. All of these + new options are at the IPPROTO_IPV6 level. That is, the "level" + parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 + when using these options. The constant name prefix IPV6_ is used in + all of the new socket options. This serves to clearly identify these + options as applying to IPv6. + + + + +Gilligan, et al. Informational [Page 18] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + The declaration for IPPROTO_IPV6, the new IPv6 socket options, and + related constants defined in this section are obtained by including + the header . + +5.1 Unicast Hop Limit + + A new setsockopt() option controls the hop limit used in outgoing + unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, + and it is used at the IPPROTO_IPV6 layer. The following example + illustrates how it is used: + + int hoplimit = 10; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, sizeof(hoplimit)) == -1) + perror("setsockopt IPV6_UNICAST_HOPS"); + + When the IPV6_UNICAST_HOPS option is set with setsockopt(), the + option value given is used as the hop limit for all subsequent + unicast packets sent via that socket. If the option is not set, the + system selects a default value. The integer hop limit value (called + x) is interpreted as follows: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + The IPV6_UNICAST_HOPS option may be used with getsockopt() to + determine the hop limit value that the system will use for subsequent + unicast packets sent via that socket. For example: + + int hoplimit; + socklen_t len = sizeof(hoplimit); + + if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, &len) == -1) + perror("getsockopt IPV6_UNICAST_HOPS"); + else + printf("Using %d for hop limit.\n", hoplimit); + +5.2 Sending and Receiving Multicast Packets + + IPv6 applications may send multicast packets by simply specifying an + IPv6 multicast address as the destination address, for example in the + destination address argument of the sendto() function. + + + + + +Gilligan, et al. Informational [Page 19] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + Three socket options at the IPPROTO_IPV6 layer control some of the + parameters for sending multicast packets. Setting these options is + not required: applications may send multicast packets without using + these options. The setsockopt() options for controlling the sending + of multicast packets are summarized below. These three options can + also be used with getsockopt(). + + IPV6_MULTICAST_IF + + Set the interface to use for outgoing multicast packets. The + argument is the index of the interface to use. If the + interface index is specified as zero, the system selects the + interface (for example, by looking up the address in a routing + table and using the resulting interface). + + Argument type: unsigned int + + IPV6_MULTICAST_HOPS + + Set the hop limit to use for outgoing multicast packets. (Note + a separate option - IPV6_UNICAST_HOPS - is provided to set the + hop limit to use for outgoing unicast packets.) + + The interpretation of the argument is the same as for the + IPV6_UNICAST_HOPS option: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + If IPV6_MULTICAST_HOPS is not set, the default is 1 + (same as IPv4 today) + + Argument type: int + + IPV6_MULTICAST_LOOP + + If a multicast datagram is sent to a group to which the sending + host itself belongs (on the outgoing interface), a copy of the + datagram is looped back by the IP layer for local delivery if + this option is set to 1. If this option is set to 0 a copy is + not looped back. Other option values return an error of + EINVAL. + + + + + + + +Gilligan, et al. Informational [Page 20] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; + same as IPv4 today). + + Argument type: unsigned int + + The reception of multicast packets is controlled by the two + setsockopt() options summarized below. An error of EOPNOTSUPP is + returned if these two options are used with getsockopt(). + + IPV6_JOIN_GROUP + + Join a multicast group on a specified local interface. + If the interface index is specified as 0, + the kernel chooses the local interface. + For example, some kernels look up the multicast group + in the normal IPv6 routing table and use the resulting + interface. + + Argument type: struct ipv6_mreq + + IPV6_LEAVE_GROUP + + Leave a multicast group on a specified interface. + If the interface index is specified as 0, the system + may choose a multicast group membership to drop by + matching the multicast address only. + + Argument type: struct ipv6_mreq + + The argument type of both of these options is the ipv6_mreq + structure, defined as a result of including the + header; + + struct ipv6_mreq { + struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ + unsigned int ipv6mr_interface; /* interface index */ + }; + + Note that to receive multicast datagrams a process must join the + multicast group to which datagrams will be sent. UDP applications + must also bind the UDP port to which datagrams will be sent. Some + processes also bind the multicast group address to the socket, in + addition to the port, to prevent other datagrams destined to that + same port from being delivered to the socket. + + + + + + + +Gilligan, et al. Informational [Page 21] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +5.3 IPV6_V6ONLY option for AF_INET6 Sockets + + This socket option restricts AF_INET6 sockets to IPv6 communications + only. As stated in section <3.7 Compatibility with IPv4 Nodes>, + AF_INET6 sockets may be used for both IPv4 and IPv6 communications. + Some applications may want to restrict their use of an AF_INET6 + socket to IPv6 communications only. For these applications the + IPV6_V6ONLY socket option is defined. When this option is turned on, + the socket can be used to send and receive IPv6 packets only. This + is an IPPROTO_IPV6 level option. This option takes an int value. + This is a boolean option. By default this option is turned off. + + Here is an example of setting this option: + + int on = 1; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, + (char *)&on, sizeof(on)) == -1) + perror("setsockopt IPV6_V6ONLY"); + else + printf("IPV6_V6ONLY set\n"); + + Note - This option has no effect on the use of IPv4 Mapped addresses + which enter a node as a valid IPv6 addresses for IPv6 communications + as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5]. + + An example use of this option is to allow two versions of the same + server process to run on the same port, one providing service over + IPv6, the other providing the same service over IPv4. + +6. Library Functions + + New library functions are needed to perform a variety of operations + with IPv6 addresses. Functions are needed to lookup IPv6 addresses + in the Domain Name System (DNS). Both forward lookup (nodename-to- + address translation) and reverse lookup (address-to-nodename + translation) need to be supported. Functions are also needed to + convert IPv6 addresses between their binary and textual form. + + We note that the two existing functions, gethostbyname() and + gethostbyaddr(), are left as-is. New functions are defined to handle + both IPv4 and IPv6 addresses. + + The commonly used function gethostbyname() is inadequate for many + applications, first because it provides no way for the caller to + specify anything about the types of addresses desired (IPv4 only, + IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many + implementations of this function are not thread safe. RFC 2133 + + + +Gilligan, et al. Informational [Page 22] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + defined a function named gethostbyname2() but this function was also + inadequate, first because its use required setting a global option + (RES_USE_INET6) when IPv6 addresses were required, and second because + a flag argument is needed to provide the caller with additional + control over the types of addresses required. The gethostbyname2() + function was deprecated in RFC 2553 and is no longer part of the + basic API. + +6.1 Protocol-Independent Nodename and Service Name Translation + + Nodename-to-address translation is done in a protocol-independent + fashion using the getaddrinfo() function. + +#include +#include + + +int getaddrinfo(const char *nodename, const char *servname, + const struct addrinfo *hints, struct addrinfo **res); + +void freeaddrinfo(struct addrinfo *ai); + +struct addrinfo { + int ai_flags; /* AI_PASSIVE, AI_CANONNAME, + AI_NUMERICHOST, .. */ + int ai_family; /* AF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + socklen_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for nodename */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ +}; + + The getaddrinfo() function translates the name of a service location + (for example, a host name) and/or a service name and returns a set of + socket addresses and associated information to be used in creating a + socket with which to address the specified service. + + The nodename and servname arguments are either null pointers or + pointers to null-terminated strings. One or both of these two + arguments must be a non-null pointer. + + The format of a valid name depends on the address family or families. + If a specific family is not given and the name could be interpreted + as valid within multiple supported families, the implementation will + attempt to resolve the name in all supported families and, in absence + of errors, one or more results shall be returned. + + + +Gilligan, et al. Informational [Page 23] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + If the nodename argument is not null, it can be a descriptive name or + can be an address string. If the specified address family is + AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host + names. If the specified address family is AF_INET or AF_UNSPEC, + address strings using Internet standard dot notation as specified in + inet_addr() are valid. If the specified address family is AF_INET6 + or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are + valid. + + If nodename is not null, the requested service location is named by + nodename; otherwise, the requested service location is local to the + caller. + + If servname is null, the call shall return network-level addresses + for the specified nodename. If servname is not null, it is a null- + terminated character string identifying the requested service. This + can be either a descriptive name or a numeric representation suitable + for use with the address family or families. If the specified + address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be + specified as a string specifying a decimal port number. + + If the argument hints is not null, it refers to a structure + containing input values that may direct the operation by providing + options and by limiting the returned information to a specific socket + type, address family and/or protocol. In this hints structure every + member other than ai_flags, ai_family, ai_socktype and ai_protocol + shall be set to zero or a null pointer. A value of AF_UNSPEC for + ai_family means that the caller shall accept any address family. A + value of zero for ai_socktype means that the caller shall accept any + socket type. A value of zero for ai_protocol means that the caller + shall accept any protocol. If hints is a null pointer, the behavior + shall be as if it referred to a structure containing the value zero + for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC + for the ai_family field. + + Note: + + 1. If the caller handles only TCP and not UDP, for example, then the + ai_protocol member of the hints structure should be set to + IPPROTO_TCP when getaddrinfo() is called. + + 2. If the caller handles only IPv4 and not IPv6, then the ai_family + member of the hints structure should be set to AF_INET when + getaddrinfo() is called. + + + + + + + +Gilligan, et al. Informational [Page 24] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + The ai_flags field to which hints parameter points shall be set to + zero or be the bitwise-inclusive OR of one or more of the values + AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, + AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. + + If the AI_PASSIVE flag is specified, the returned address information + shall be suitable for use in binding a socket for accepting incoming + connections for the specified service (i.e., a call to bind()). In + this case, if the nodename argument is null, then the IP address + portion of the socket address structure shall be set to INADDR_ANY + for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the + AI_PASSIVE flag is not specified, the returned address information + shall be suitable for a call to connect() (for a connection-mode + protocol) or for a call to connect(), sendto() or sendmsg() (for a + connectionless protocol). In this case, if the nodename argument is + null, then the IP address portion of the socket address structure + shall be set to the loopback address. This flag is ignored if the + nodename argument is not null. + + If the AI_CANONNAME flag is specified and the nodename argument is + not null, the function shall attempt to determine the canonical name + corresponding to nodename (for example, if nodename is an alias or + shorthand notation for a complete name). + + If the AI_NUMERICHOST flag is specified, then a non-null nodename + string supplied shall be a numeric host address string. Otherwise, + an [EAI_NONAME] error is returned. This flag shall prevent any type + of name resolution service (for example, the DNS) from being invoked. + + If the AI_NUMERICSERV flag is specified, then a non-null servname + string supplied shall be a numeric port string. Otherwise, an + [EAI_NONAME] error shall be returned. This flag shall prevent any + type of name resolution service (for example, NIS+) from being + invoked. + + If the AI_V4MAPPED flag is specified along with an ai_family of + AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses + on finding no matching IPv6 addresses (ai_addrlen shall be 16). + + For example, when using the DNS, if no AAAA records are found then + a query is made for A records and any found are returned as IPv4- + mapped IPv6 addresses. + + The AI_V4MAPPED flag shall be ignored unless ai_family equals + AF_INET6. + + If the AI_ALL flag is used with the AI_V4MAPPED flag, then + getaddrinfo() shall return all matching IPv6 and IPv4 addresses. + + + +Gilligan, et al. Informational [Page 25] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + For example, when using the DNS, queries are made for both AAAA + records and A records, and getaddrinfo() returns the combined + results of both queries. Any IPv4 addresses found are returned as + IPv4-mapped IPv6 addresses. + + The AI_ALL flag without the AI_V4MAPPED flag is ignored. + + Note: + + When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and + AI_ALL flags will only be used if AF_INET6 is supported. + + If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be + returned only if an IPv4 address is configured on the local system, + and IPv6 addresses shall be returned only if an IPv6 address is + configured on the local system. The loopback address is not + considered for this case as valid as a configured address. + + For example, when using the DNS, a query for AAAA records should + occur only if the node has at least one IPv6 address configured + (other than IPv6 loopback) and a query for A records should occur + only if the node has at least one IPv4 address configured (other + than the IPv4 loopback). + + The ai_socktype field to which argument hints points specifies the + socket type for the service, as defined for socket(). If a specific + socket type is not given (for example, a value of zero) and the + service name could be interpreted as valid with multiple supported + socket types, the implementation shall attempt to resolve the service + name for all supported socket types and, in the absence of errors, + all possible results shall be returned. A non-zero socket type value + shall limit the returned information to values with the specified + socket type. + + If the ai_family field to which hints points has the value AF_UNSPEC, + addresses shall be returned for use with any address family that can + be used with the specified nodename and/or servname. Otherwise, + addresses shall be returned for use only with the specified address + family. If ai_family is not AF_UNSPEC and ai_protocol is not zero, + then addresses are returned for use only with the specified address + family and protocol; the value of ai_protocol shall be interpreted as + in a call to the socket() function with the corresponding values of + ai_family and ai_protocol. + + The freeaddrinfo() function frees one or more addrinfo structures + returned by getaddrinfo(), along with any additional storage + associated with those structures (for example, storage pointed to by + the ai_canonname and ai_addr fields; an application must not + + + +Gilligan, et al. Informational [Page 26] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + reference this storage after the associated addrinfo structure has + been freed). If the ai_next field of the structure is not null, the + entire list of structures is freed. The freeaddrinfo() function must + support the freeing of arbitrary sublists of an addrinfo list + originally returned by getaddrinfo(). + + Functions getaddrinfo() and freeaddrinfo() must be thread-safe. + + A zero return value for getaddrinfo() indicates successful + completion; a non-zero return value indicates failure. The possible + values for the failures are listed below under Error Return Values. + + Upon successful return of getaddrinfo(), the location to which res + points shall refer to a linked list of addrinfo structures, each of + which shall specify a socket address and information for use in + creating a socket with which to use that socket address. The list + shall include at least one addrinfo structure. The ai_next field of + each structure contains a pointer to the next structure on the list, + or a null pointer if it is the last structure on the list. Each + structure on the list shall include values for use with a call to the + socket() function, and a socket address for use with the connect() + function or, if the AI_PASSIVE flag was specified, for use with the + bind() function. The fields ai_family, ai_socktype, and ai_protocol + shall be usable as the arguments to the socket() function to create a + socket suitable for use with the returned address. The fields + ai_addr and ai_addrlen are usable as the arguments to the connect() + or bind() functions with such a socket, according to the AI_PASSIVE + flag. + + If nodename is not null, and if requested by the AI_CANONNAME flag, + the ai_canonname field of the first returned addrinfo structure shall + point to a null-terminated string containing the canonical name + corresponding to the input nodename; if the canonical name is not + available, then ai_canonname shall refer to the nodename argument or + a string with the same contents. The contents of the ai_flags field + of the returned structures are undefined. + + All fields in socket address structures returned by getaddrinfo() + that are not filled in through an explicit argument (for example, + sin6_flowinfo) shall be set to zero. + + Note: This makes it easier to compare socket address structures. + + + + + + + + + +Gilligan, et al. Informational [Page 27] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + Error Return Values: + + The getaddrinfo() function shall fail and return the corresponding + value if: + + [EAI_AGAIN] The name could not be resolved at this time. Future + attempts may succeed. + + [EAI_BADFLAGS] The flags parameter had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred when attempting to + resolve the name. + + [EAI_FAMILY] The address family was not recognized. + + [EAI_MEMORY] There was a memory allocation failure when trying to + allocate storage for the return value. + + [EAI_NONAME] The name does not resolve for the supplied + parameters. Neither nodename nor servname were + supplied. At least one of these must be supplied. + + [EAI_SERVICE] The service passed was not recognized for the + specified socket type. + + [EAI_SOCKTYPE] The intended socket type was not recognized. + + [EAI_SYSTEM] A system error occurred; the error code can be found + in errno. + + The gai_strerror() function provides a descriptive text string + corresponding to an EAI_xxx error value. + + #include + + const char *gai_strerror(int ecode); + + The argument is one of the EAI_xxx values defined for the + getaddrinfo() and getnameinfo() functions. The return value points + to a string describing the error. If the argument is not one of the + EAI_xxx values, the function still returns a pointer to a string + whose contents indicate an unknown error. + +6.2 Socket Address Structure to Node Name and Service Name + + The getnameinfo() function is used to translate the contents of a + socket address structure to a node name and/or service name. + + + + +Gilligan, et al. Informational [Page 28] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + #include + #include + + int getnameinfo(const struct sockaddr *sa, socklen_t salen, + char *node, socklen_t nodelen, + char *service, socklen_t servicelen, + int flags); + + The getnameinfo() function shall translate a socket address to a node + name and service location, all of which are defined as in + getaddrinfo(). + + The sa argument points to a socket address structure to be + translated. + + The salen argument holds the size of the socket address structure + pointed to by sa. + + If the socket address structure contains an IPv4-mapped IPv6 address + or an IPv4-compatible IPv6 address, the implementation shall extract + the embedded IPv4 address and lookup the node name for that IPv4 + address. + + Note: The IPv6 unspecified address ("::") and the IPv6 loopback + address ("::1") are not IPv4-compatible addresses. If the address + is the IPv6 unspecified address ("::"), a lookup is not performed, + and the [EAI_NONAME] error is returned. + + If the node argument is non-NULL and the nodelen argument is nonzero, + then the node argument points to a buffer able to contain up to + nodelen characters that receives the node name as a null-terminated + string. If the node argument is NULL or the nodelen argument is + zero, the node name shall not be returned. If the node's name cannot + be located, the numeric form of the node's address is returned + instead of its name. + + If the service argument is non-NULL and the servicelen argument is + non-zero, then the service argument points to a buffer able to + contain up to servicelen bytes that receives the service name as a + null-terminated string. If the service argument is NULL or the + servicelen argument is zero, the service name shall not be returned. + If the service's name cannot be located, the numeric form of the + service address (for example, its port number) shall be returned + instead of its name. + + The arguments node and service cannot both be NULL. + + + + + +Gilligan, et al. Informational [Page 29] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + The flags argument is a flag that changes the default actions of the + function. By default the fully-qualified domain name (FQDN) for the + host shall be returned, but: + + - If the flag bit NI_NOFQDN is set, only the node name portion of + the FQDN shall be returned for local hosts. + + - If the flag bit NI_NUMERICHOST is set, the numeric form of the + host's address shall be returned instead of its name, under all + circumstances. + + - If the flag bit NI_NAMEREQD is set, an error shall be returned if + the host's name cannot be located. + + - If the flag bit NI_NUMERICSERV is set, the numeric form of the + service address shall be returned (for example, its port number) + instead of its name, under all circumstances. + + - If the flag bit NI_DGRAM is set, this indicates that the service + is a datagram service (SOCK_DGRAM). The default behavior shall + assume that the service is a stream service (SOCK_STREAM). + + Note: + + 1. The NI_NUMERICxxx flags are required to support the "-n" flags + that many commands provide. + + 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 + port numbers (for example, [512,514]) that represent different + services for UDP and TCP. + + The getnameinfo() function shall be thread safe. + + A zero return value for getnameinfo() indicates successful + completion; a non-zero return value indicates failure. + + Upon successful completion, getnameinfo() shall return the node and + service names, if requested, in the buffers provided. The returned + names are always null-terminated strings. + + + + + + + + + + + + +Gilligan, et al. Informational [Page 30] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + Error Return Values: + + The getnameinfo() function shall fail and return the corresponding + value if: + + [EAI_AGAIN] The name could not be resolved at this time. + Future attempts may succeed. + + [EAI_BADFLAGS] The flags had an invalid value. + + [EAI_FAIL] A non-recoverable error occurred. + + [EAI_FAMILY] The address family was not recognized or the address + length was invalid for the specified family. + + [EAI_MEMORY] There was a memory allocation failure. + + [EAI_NONAME] The name does not resolve for the supplied parameters. + NI_NAMEREQD is set and the host's name cannot be + located, or both nodename and servname were null. + + [EAI_OVERFLOW] An argument buffer overflowed. + + [EAI_SYSTEM] A system error occurred. The error code can be found + in errno. + +6.3 Address Conversion Functions + + The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4 + address between binary and text form. IPv6 applications need similar + functions. The following two functions convert both IPv6 and IPv4 + addresses: + + #include + + int inet_pton(int af, const char *src, void *dst); + + const char *inet_ntop(int af, const void *src, + char *dst, socklen_t size); + + The inet_pton() function shall convert an address in its standard + text presentation form into its numeric binary form. The af argument + shall specify the family of the address. The AF_INET and AF_INET6 + address families shall be supported. The src argument points to the + string being passed in. The dst argument points to a buffer into + which the function stores the numeric address; this shall be large + enough to hold the numeric address (32 bits for AF_INET, 128 bits for + AF_INET6). The inet_pton() function shall return 1 if the conversion + + + +Gilligan, et al. Informational [Page 31] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + succeeds, with the address pointed to by dst in network byte order. + It shall return 0 if the input is not a valid IPv4 dotted-decimal + string or a valid IPv6 address string, or -1 with errno set to + EAFNOSUPPORT if the af argument is unknown. + + If the af argument of inet_pton() is AF_INET, the src string shall be + in the standard IPv4 dotted-decimal form: + + ddd.ddd.ddd.ddd + + where "ddd" is a one to three digit decimal number between 0 and 255. + The inet_pton() function does not accept other formats (such as the + octal numbers, hexadecimal numbers, and fewer than four numbers that + inet_addr() accepts). + + If the af argument of inet_pton() is AF_INET6, the src string shall + be in one of the standard IPv6 text forms defined in Section 2.2 of + the addressing architecture specification [2]. + + The inet_ntop() function shall convert a numeric address into a text + string suitable for presentation. The af argument shall specify the + family of the address. This can be AF_INET or AF_INET6. The src + argument points to a buffer holding an IPv4 address if the af + argument is AF_INET, or an IPv6 address if the af argument is + AF_INET6; the address must be in network byte order. The dst + argument points to a buffer where the function stores the resulting + text string; it shall not be NULL. The size argument specifies the + size of this buffer, which shall be large enough to hold the text + string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN + characters for IPv6). + + In order to allow applications to easily declare buffers of the + proper size to store IPv4 and IPv6 addresses in string form, the + following two constants are defined in : + + #define INET_ADDRSTRLEN 16 + #define INET6_ADDRSTRLEN 46 + + The inet_ntop() function shall return a pointer to the buffer + containing the text string if the conversion succeeds, and NULL + otherwise. Upon failure, errno is set to EAFNOSUPPORT if the af + argument is invalid or ENOSPC if the size of the result buffer is + inadequate. + + + + + + + + +Gilligan, et al. Informational [Page 32] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +6.4 Address Testing Macros + + The following macros can be used to test for special IPv6 addresses. + + #include + + int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); + int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); + + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); + + The first seven macros return true if the address is of the specified + type, or false otherwise. The last five test the scope of a + multicast address and return true if the address is a multicast + address of the specified scope or false if the address is either not + a multicast address or not of the specified scope. + + Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true + only for the two types of local-use IPv6 unicast addresses (Link- + Local and Site-Local) defined in [2], and that by this definition, + the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback + address (::1). These two macros do not return true for IPv6 + multicast addresses of either link-local scope or site-local scope. + +7. Summary of New Definitions + + The following list summarizes the constants, structure, and extern + definitions discussed in this memo, sorted by header. + + IF_NAMESIZE + struct if_nameindex{}; + + AI_ADDRCONFIG + AI_ALL + AI_CANONNAME + AI_NUMERICHOST + AI_NUMERICSERV + AI_PASSIVE + AI_V4MAPPED + + + +Gilligan, et al. Informational [Page 33] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + EAI_AGAIN + EAI_BADFLAGS + EAI_FAIL + EAI_FAMILY + EAI_MEMORY + EAI_NONAME + EAI_OVERFLOW + EAI_SERVICE + EAI_SOCKTYPE + EAI_SYSTEM + NI_DGRAM + NI_NAMEREQD + NI_NOFQDN + NI_NUMERICHOST + NI_NUMERICSERV + struct addrinfo{}; + + IN6ADDR_ANY_INIT + IN6ADDR_LOOPBACK_INIT + INET6_ADDRSTRLEN + INET_ADDRSTRLEN + IPPROTO_IPV6 + IPV6_JOIN_GROUP + IPV6_LEAVE_GROUP + IPV6_MULTICAST_HOPS + IPV6_MULTICAST_IF + IPV6_MULTICAST_LOOP + IPV6_UNICAST_HOPS + IPV6_V6ONLY + SIN6_LEN + extern const struct in6_addr in6addr_any; + extern const struct in6_addr in6addr_loopback; + struct in6_addr{}; + struct ipv6_mreq{}; + struct sockaddr_in6{}; + + AF_INET6 + PF_INET6 + struct sockaddr_storage; + + The following list summarizes the function and macro prototypes + discussed in this memo, sorted by header. + + int inet_pton(int, const char *, void *); + const char *inet_ntop(int, const void *, + char *, socklen_t); + + + + + +Gilligan, et al. Informational [Page 34] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + char *if_indextoname(unsigned int, char *); + unsigned int if_nametoindex(const char *); + void if_freenameindex(struct if_nameindex *); + struct if_nameindex *if_nameindex(void); + + int getaddrinfo(const char *, const char *, + const struct addrinfo *, + struct addrinfo **); + int getnameinfo(const struct sockaddr *, socklen_t, + char *, socklen_t, char *, socklen_t, int); + void freeaddrinfo(struct addrinfo *); + const char *gai_strerror(int); + + int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); + +8. Security Considerations + + IPv6 provides a number of new security mechanisms, many of which need + to be accessible to applications. Companion memos detailing the + extensions to the socket interfaces to support IPv6 security are + being written. + +9. Changes from RFC 2553 + + 1. Add brief description of the history of this API and its relation + to the Open Group/IEEE/ISO standards. + + 2. Alignments with [3]. + + 3. Removed all references to getipnodebyname() and getipnodebyaddr(), + which are deprecated in favor of getaddrinfo() and getnameinfo(). + + 4. Added IPV6_V6ONLY IP level socket option to permit nodes to not + process IPv4 packets as IPv4 Mapped addresses in implementations. + + 5. Added SIIT to references and added new contributors. + + + + +Gilligan, et al. Informational [Page 35] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + + 6. In previous versions of this specification, the sin6_flowinfo + field was associated with the IPv6 traffic class and flow label, + but its usage was not completely specified. The complete + definition of the sin6_flowinfo field, including its association + with the traffic class or flow label, is now deferred to a future + specification. + +10. Acknowledgments + + This specification's evolution and completeness were significantly + influenced by the efforts of Richard Stevens, who has passed on. + Richard's wisdom and talent made the specification what it is today. + The co-authors will long think of Richard with great respect. + + Thanks to the many people who made suggestions and provided feedback + to this document, including: + + Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew + Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, + Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, + Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, + Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan + McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, + Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, + Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey + Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, + David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig + Venaas, and Brian Zill. + + The getaddrinfo() and getnameinfo() functions are taken from an + earlier document by Keith Sklower. As noted in that document, + William Durst, Steven Wise, Michael Karels, and Eric Allman provided + many useful discussions on the subject of protocol-independent name- + to-address translation, and reviewed early versions of Keith + Sklower's original proposal. Eric Allman implemented the first + prototype of getaddrinfo(). The observation that specifying the pair + of name and service would suffice for connecting to a service + independent of protocol details was made by Marshall Rose in a + proposal to X/Open for a "Uniform Network Interface". + + Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh + Kacker made many contributions to this document. Ramesh Govindan + made a number of contributions and co-authored an earlier version of + this memo. + + + + + + + +Gilligan, et al. Informational [Page 36] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +11. References + + [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [2] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December 2001. + ISO/IEC 9945:2002. http://www.opengroup.org/austin + + [4] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC + 2292, February 1998. + + [5] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", + RFC 2765, February 2000. + + [6] The Open Group Base Working Group + http://www.opengroup.org/platform/base.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gilligan, et al. Informational [Page 37] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +12. Authors' Addresses + + Bob Gilligan + Intransa, Inc. + 2870 Zanker Rd. + San Jose, CA 95134 + + Phone: 408-678-8647 + EMail: gilligan@intransa.com + + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + + Phone: 732-635-3086 + EMail: sethomso@cisco.com + + + Jim Bound + Hewlett-Packard Company + 110 Spitbrook Road ZKO3-3/W20 + Nashua, NH 03062 + + Phone: 603-884-0062 + EMail: Jim.Bound@hp.com + + + Jack McCann + Hewlett-Packard Company + 110 Spitbrook Road ZKO3-3/W20 + Nashua, NH 03062 + + Phone: 603-884-2608 + EMail: Jack.McCann@hp.com + + + + + + + + + + + + + + + +Gilligan, et al. Informational [Page 38] + +RFC 3493 Basic Socket Interface Extensions for IPv6 February 2003 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 + 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 + 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 + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Gilligan, et al. Informational [Page 39] + diff --git a/lib/bind/port/cygwin/include/asm/socket.h b/lib/bind/port/cygwin/include/asm/socket.h new file mode 100644 index 0000000000..4d4c8a2009 --- /dev/null +++ b/lib/bind/port/cygwin/include/asm/socket.h @@ -0,0 +1,12 @@ +#ifndef _cygwin_asm_socket_h +#define _cygwin_asm_socket_h + +#include_next + +/* This is a lame cop-out, but cygwin's SIOCGIFCONF doesn't define + IFF_POINTOPOINT, so this should never happen anyway. */ +#ifndef SIOCGIFDSTADDR +# define SIOCGIFDSTADDR SIOCGIFADDR +#endif + +#endif diff --git a/lib/bind/port/cygwin/include/assert.h b/lib/bind/port/cygwin/include/assert.h new file mode 100644 index 0000000000..4b881ee6ad --- /dev/null +++ b/lib/bind/port/cygwin/include/assert.h @@ -0,0 +1,2 @@ +#include +#include_next diff --git a/lib/bind/port/cygwin/include/paths.h b/lib/bind/port/cygwin/include/paths.h new file mode 100644 index 0000000000..7ec03327e1 --- /dev/null +++ b/lib/bind/port/cygwin/include/paths.h @@ -0,0 +1,2 @@ +#define _PATH_DEVNULL "/dev/null" + diff --git a/lib/bind/port/cygwin/include/sys/cdefs.h b/lib/bind/port/cygwin/include/sys/cdefs.h new file mode 100644 index 0000000000..a2c123b883 --- /dev/null +++ b/lib/bind/port/cygwin/include/sys/cdefs.h @@ -0,0 +1,144 @@ +/* + * ++Copyright++ 1991, 1993 + * - + * Copyright (c) 1991, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * - + * Portions Copyright (c) 1993 by Digital Equipment Corporation. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies, and that + * the name of Digital Equipment Corporation not be used in advertising or + * publicity pertaining to distribution of the document or software without + * specific, written prior permission. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL + * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT + * CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL + * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR + * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS + * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS + * SOFTWARE. + * - + * --Copyright-- + */ + +/* + * @(#)cdefs.h 8.1 (Berkeley) 6/2/93 + * $Id: cdefs.h,v 1.1 2002/12/27 03:13:51 marka Exp $ + */ + +#ifndef _CDEFS_H_ +#define _CDEFS_H_ + +#if defined(__cplusplus) +#define __BEGIN_DECLS extern "C" { +#define __END_DECLS }; +#else +#define __BEGIN_DECLS +#define __END_DECLS +#endif + +/* + * The __CONCAT macro is used to concatenate parts of symbol names, e.g. + * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo. + * The __CONCAT macro is a bit tricky -- make sure you don't put spaces + * in between its arguments. __CONCAT can also concatenate double-quoted + * strings produced by the __STRING macro, but this only works with ANSI C. + */ +#if defined(__STDC__) || defined(__cplusplus) +#define __P(protos) protos /* full-blown ANSI C */ +#define __CONCAT(x,y) x ## y +#define __STRING(x) #x + +#define __const const /* define reserved names to standard */ +#define __signed signed +#define __volatile volatile +#if defined(__cplusplus) +#define __inline inline /* convert to C++ keyword */ +#else +#ifndef __GNUC__ +#define __inline /* delete GCC keyword */ +#endif /* !__GNUC__ */ +#endif /* !__cplusplus */ + +#else /* !(__STDC__ || __cplusplus) */ +#define __P(protos) () /* traditional C preprocessor */ +#define __CONCAT(x,y) x/**/y +#define __STRING(x) "x" + +#ifndef __GNUC__ +#define __const /* delete pseudo-ANSI C keywords */ +#define __inline +#define __signed +#define __volatile +/* + * In non-ANSI C environments, new programs will want ANSI-only C keywords + * deleted from the program and old programs will want them left alone. + * When using a compiler other than gcc, programs using the ANSI C keywords + * const, inline etc. as normal identifiers should define -DNO_ANSI_KEYWORDS. + * When using "gcc -traditional", we assume that this is the intent; if + * __GNUC__ is defined but __STDC__ is not, we leave the new keywords alone. + */ +#ifndef NO_ANSI_KEYWORDS +#define const /* delete ANSI C keywords */ +#define inline +#define signed +#define volatile +#endif +#endif /* !__GNUC__ */ +#endif /* !(__STDC__ || __cplusplus) */ + +/* + * GCC1 and some versions of GCC2 declare dead (non-returning) and + * pure (no side effects) functions using "volatile" and "const"; + * unfortunately, these then cause warnings under "-ansi -pedantic". + * GCC2 uses a new, peculiar __attribute__((attrs)) style. All of + * these work for GNU C++ (modulo a slight glitch in the C++ grammar + * in the distribution version of 2.5.5). + */ +#if !defined(__GNUC__) || __GNUC__ < 2 || __GNUC_MINOR__ < 5 +#define __attribute__(x) /* delete __attribute__ if non-gcc or gcc1 */ +#if defined(__GNUC__) && !defined(__STRICT_ANSI__) +#define __dead __volatile +#define __pure __const +#endif +#endif + +/* Delete pseudo-keywords wherever they are not available or needed. */ +#ifndef __dead +#define __dead +#define __pure +#endif + +#endif /* !_CDEFS_H_ */ diff --git a/lib/bind/port/cygwin/include/sys/socket.h b/lib/bind/port/cygwin/include/sys/socket.h new file mode 100644 index 0000000000..bf5688ca3e --- /dev/null +++ b/lib/bind/port/cygwin/include/sys/socket.h @@ -0,0 +1,10 @@ +#ifndef _cygwin_sys_socket_h +#define _cygwin_sys_socket_h + +#include_next + +#ifndef IFF_POINTOPOINT +# define IFF_POINTOPOINT 0x10 +#endif + +#endif diff --git a/lib/bind/port/cygwin/include/sys/wait.h b/lib/bind/port/cygwin/include/sys/wait.h new file mode 100644 index 0000000000..7bfa19e7e1 --- /dev/null +++ b/lib/bind/port/cygwin/include/sys/wait.h @@ -0,0 +1,9 @@ +#ifndef _cygwin_sys_wait_h + +#include_next + +#if !defined (WCOREDUMP) +# define WCOREDUMP(x) (((x) & 0x80) == 0x80) +#endif + +#endif diff --git a/lib/isc/win32/include/isc/win32os.h b/lib/isc/win32/include/isc/win32os.h new file mode 100644 index 0000000000..63794565b9 --- /dev/null +++ b/lib/isc/win32/include/isc/win32os.h @@ -0,0 +1,71 @@ +/* + * Copyright (C) 2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM + * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL + * INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING + * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION + * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: win32os.h,v 1.2 2002/08/03 01:36:24 mayer Exp $ */ + +#ifndef ISC_WIN32OS_H +#define ISC_WIN32OS_H 1 + +#include + +ISC_LANG_BEGINDECLS + +/* + * Return the number of CPUs available on the system, or 1 if this cannot + * be determined. + */ + +unsigned int +isc_win32os_majorversion(void); +/* + * Major Version of the O/S. + */ + +unsigned int +isc_win32os_minorversion(void); +/* + * Minor Version of the O/S. + */ + +unsigned int +isc_win32os_servicepackmajor(void); +/* + * Major Version of the Service Pack for O/S. + */ + +unsigned int +isc_win32os_servicepackminor(void); +/* + * Minor Version of the Service Pack for O/S. + */ + +int +isc_win32os_versioncheck(unsigned int major, unsigned int minor, + unsigned int updatemajor, unsigned int updateminor); + +/* + * Checks the current version of the operating system with the + * supplied version information. + * Returns: + * -1 if less than the version information supplied + * 0 if equal to all of the version information supplied + * +1 if greater than the version information supplied + */ + +ISC_LANG_ENDDECLS + +#endif /* ISC_OS_H */ diff --git a/lib/isc/win32/strerror.c b/lib/isc/win32/strerror.c new file mode 100644 index 0000000000..f092ddd514 --- /dev/null +++ b/lib/isc/win32/strerror.c @@ -0,0 +1,459 @@ +/* + * Copyright (C) 2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM + * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL + * INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING + * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION + * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: strerror.c,v 1.5 2002/08/01 03:52:14 mayer Exp $ */ + +#include + +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * Forward declarations + */ + +char * +FormatError(int error); + +char * +GetWSAErrorMessage(int errval); + +char * +NTstrerror(int err, BOOL *bfreebuf); + +/* + * We need to do this this way for profiled locks. + */ + +static isc_mutex_t isc_strerror_lock; +static void init_lock(void) { + RUNTIME_CHECK(isc_mutex_init(&isc_strerror_lock) == ISC_R_SUCCESS); +} + +/* + * This routine needs to free up any buffer allocated by FormatMessage + * if that routine gets used. + */ + +void +isc__strerror(int num, char *buf, size_t size) { + char *msg; + BOOL freebuf; + unsigned int unum = num; + static isc_once_t once = ISC_ONCE_INIT; + + REQUIRE(buf != NULL); + + RUNTIME_CHECK(isc_once_do(&once, init_lock) == ISC_R_SUCCESS); + + LOCK(&isc_strerror_lock); + freebuf = FALSE; + msg = NTstrerror(num, &freebuf); + if (msg != NULL) + snprintf(buf, size, "%s", msg); + else + snprintf(buf, size, "Unknown error: %u", unum); + if(freebuf && msg != NULL) { + LocalFree(msg); + } + UNLOCK(&isc_strerror_lock); +} + +/* + * Note this will cause a memory leak unless the memory allocated here + * is freed by calling LocalFree. isc__strerror does this before unlocking. + * This only gets called if there is a system type of error and will likely + * be an unusual event. + */ +char * +FormatError(int error) { + LPVOID lpMsgBuf = NULL; + FormatMessage( + FORMAT_MESSAGE_ALLOCATE_BUFFER | + FORMAT_MESSAGE_FROM_SYSTEM | + FORMAT_MESSAGE_IGNORE_INSERTS, + NULL, + error, + /* Default language */ + MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), + (LPTSTR) &lpMsgBuf, + 0, + NULL); + + return (lpMsgBuf); +} + +/* + * This routine checks the error value and calls the WSA Windows Sockets + * Error message function GetWSAErrorMessage below if it's within that range + * since those messages are not available in the system error messages. + */ +char * +NTstrerror(int err, BOOL *bfreebuf) { + char *retmsg = NULL; + + /* Copy the error value first in case of other errors */ + DWORD errval = err; + + *bfreebuf = FALSE; + + /* Get the Winsock2 error messages */ + if (errval >= WSABASEERR && errval <= (WSABASEERR + 1015)) { + retmsg = GetWSAErrorMessage(errval); + if (retmsg != NULL) + return (retmsg); + } + /* + * If it's not one of the standard Unix error codes, + * try a system error message + */ + if (errval > (DWORD) _sys_nerr) { + *bfreebuf = TRUE; + return (FormatError(errval)); + } else { + return (strerror(errval)); + } +} + +/* + * This is a replacement for perror + */ +void __cdecl +NTperror(char *errmsg) { + /* Copy the error value first in case of other errors */ + int errval = errno; + BOOL bfreebuf = FALSE; + char *msg; + + msg = NTstrerror(errval, &bfreebuf); + fprintf(stderr, "%s: %s\n", errmsg, msg); + if(bfreebuf == TRUE) { + LocalFree(msg); + } + +} + +/* + * Return the error string related to Winsock2 errors. + * This function is necessary since FormatMessage knows nothing about them + * and there is no function to get them. + */ +char * +GetWSAErrorMessage(int errval) { + char *msg; + + switch (errval) { + + case WSAEINTR: + msg = "Interrupted system call"; + break; + + case WSAEBADF: + msg = "Bad file number"; + break; + + case WSAEACCES: + msg = "Permission denied"; + break; + + case WSAEFAULT: + msg = "Bad address"; + break; + + case WSAEINVAL: + msg = "Invalid argument"; + break; + + case WSAEMFILE: + msg = "Too many open sockets"; + break; + + case WSAEWOULDBLOCK: + msg = "Operation would block"; + break; + + case WSAEINPROGRESS: + msg = "Operation now in progress"; + break; + + case WSAEALREADY: + msg = "Operation already in progress"; + break; + + case WSAENOTSOCK: + msg = "Socket operation on non-socket"; + break; + + case WSAEDESTADDRREQ: + msg = "Destination address required"; + break; + + case WSAEMSGSIZE: + msg = "Message too long"; + break; + + case WSAEPROTOTYPE: + msg = "Protocol wrong type for socket"; + break; + + case WSAENOPROTOOPT: + msg = "Bad protocol option"; + break; + + case WSAEPROTONOSUPPORT: + msg = "Protocol not supported"; + break; + + case WSAESOCKTNOSUPPORT: + msg = "Socket type not supported"; + break; + + case WSAEOPNOTSUPP: + msg = "Operation not supported on socket"; + break; + + case WSAEPFNOSUPPORT: + msg = "Protocol family not supported"; + break; + + case WSAEAFNOSUPPORT: + msg = "Address family not supported"; + break; + + case WSAEADDRINUSE: + msg = "Address already in use"; + break; + + case WSAEADDRNOTAVAIL: + msg = "Can't assign requested address"; + break; + + case WSAENETDOWN: + msg = "Network is down"; + break; + + case WSAENETUNREACH: + msg = "Network is unreachable"; + break; + + case WSAENETRESET: + msg = "Net connection reset"; + break; + + case WSAECONNABORTED: + msg = "Software caused connection abort"; + break; + + case WSAECONNRESET: + msg = "Connection reset by peer"; + break; + + case WSAENOBUFS: + msg = "No buffer space available"; + break; + + case WSAEISCONN: + msg = "Socket is already connected"; + break; + + case WSAENOTCONN: + msg = "Socket is not connected"; + break; + + case WSAESHUTDOWN: + msg = "Can't send after socket shutdown"; + break; + + case WSAETOOMANYREFS: + msg = "Too many references: can't splice"; + break; + + case WSAETIMEDOUT: + msg = "Connection timed out"; + break; + + case WSAECONNREFUSED: + msg = "Connection refused"; + break; + + case WSAELOOP: + msg = "Too many levels of symbolic links"; + break; + + case WSAENAMETOOLONG: + msg = "File name too long"; + break; + + case WSAEHOSTDOWN: + msg = "Host is down"; + break; + + case WSAEHOSTUNREACH: + msg = "No route to host"; + break; + + case WSAENOTEMPTY: + msg = "Directory not empty"; + break; + + case WSAEPROCLIM: + msg = "Too many processes"; + break; + + case WSAEUSERS: + msg = "Too many users"; + break; + + case WSAEDQUOT: + msg = "Disc quota exceeded"; + break; + + case WSAESTALE: + msg = "Stale NFS file handle"; + break; + + case WSAEREMOTE: + msg = "Too many levels of remote in path"; + break; + + case WSASYSNOTREADY: + msg = "Network system is unavailable"; + break; + + case WSAVERNOTSUPPORTED: + msg = "Winsock version out of range"; + break; + + case WSANOTINITIALISED: + msg = "WSAStartup not yet called"; + break; + + case WSAEDISCON: + msg = "Graceful shutdown in progress"; + break; +/* + case WSAHOST_NOT_FOUND: + msg = "Host not found"; + break; + + case WSANO_DATA: + msg = "No host data of that type was found"; + break; +*/ + default: + msg = NULL; + break; + } + return (msg); +} + +/* + * These error messages are more informative about CryptAPI Errors than the + * standard error messages + */ + +char * +GetCryptErrorMessage(int errval) { + char *msg; + + switch (errval) { + + case NTE_BAD_FLAGS: + msg = "The dwFlags parameter has an illegal value."; + break; + case NTE_BAD_KEYSET: + msg = "The Registry entry for the key container " + "could not be opened and may not exist."; + break; + case NTE_BAD_KEYSET_PARAM: + msg = "The pszContainer or pszProvider parameter " + "is set to an illegal value."; + break; + case NTE_BAD_PROV_TYPE: + msg = "The value of the dwProvType parameter is out " + "of range. All provider types must be from " + "1 to 999, inclusive."; + break; + case NTE_BAD_SIGNATURE: + msg = "The provider DLL signature did not verify " + "correctly. Either the DLL or the digital " + "signature has been tampered with."; + break; + case NTE_EXISTS: + msg = "The dwFlags parameter is CRYPT_NEWKEYSET, but the key" + " container already exists."; + break; + case NTE_KEYSET_ENTRY_BAD: + msg = "The Registry entry for the pszContainer key container " + "was found (in the HKEY_CURRENT_USER window), but is " + "corrupt. See the section System Administration for " + " etails about CryptoAPI's Registry usage."; + break; + case NTE_KEYSET_NOT_DEF: + msg = "No Registry entry exists in the HKEY_CURRENT_USER " + "window for the key container specified by " + "pszContainer."; + break; + case NTE_NO_MEMORY: + msg = "The CSP ran out of memory during the operation."; + break; + case NTE_PROV_DLL_NOT_FOUND: + msg = "The provider DLL file does not exist or is not on the " + "current path."; + break; + case NTE_PROV_TYPE_ENTRY_BAD: + msg = "The Registry entry for the provider type specified by " + "dwProvType is corrupt. This error may relate to " + "either the user default CSP list or the machine " + "default CSP list. See the section System " + "Administration for details about CryptoAPI's " + "Registry usage."; + break; + case NTE_PROV_TYPE_NO_MATCH: + msg = "The provider type specified by dwProvType does not " + "match the provider type found in the Registry. Note " + "that this error can only occur when pszProvider " + "specifies an actual CSP name."; + break; + case NTE_PROV_TYPE_NOT_DEF: + msg = "No Registry entry exists for the provider type " + "specified by dwProvType."; + break; + case NTE_PROVIDER_DLL_FAIL: + msg = "The provider DLL file could not be loaded, and " + "may not exist. If it exists, then the file is " + "not a valid DLL."; + break; + case NTE_SIGNATURE_FILE_BAD: + msg = "An error occurred while loading the DLL file image, " + "prior to verifying its signature."; + break; + + default: + msg = NULL; + break; + } + return msg; +} + diff --git a/lib/isc/win32/win32os.c b/lib/isc/win32/win32os.c new file mode 100644 index 0000000000..05ca09e354 --- /dev/null +++ b/lib/isc/win32/win32os.c @@ -0,0 +1,101 @@ +/* + * Copyright (C) 2002 Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM + * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL + * INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, + * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING + * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION + * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +/* $Id: win32os.c,v 1.2 2002/08/03 01:36:24 mayer Exp $ */ + +#include + +#include + +static BOOL bInit = FALSE; +static OSVERSIONINFOEX osVer; + +static void +initialize_action(void) { + BOOL bSuccess; + + if (bInit) + return; + /* + * NOTE: VC++ 6.0 gets this function declaration wrong + * so we compensate by casting the argument + */ + osVer.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX); + bSuccess = GetVersionEx((OSVERSIONINFO *) &osVer); + + /* + * Versions of NT before NT4.0 SP6 did not return the + * extra info that the EX structure provides and returns + * a failure so we need to retry with the old structure. + */ + if(!bSuccess) { + osVer.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); + bSuccess = GetVersionEx((OSVERSIONINFO *) &osVer); + } + bInit = TRUE; +} + +unsigned int +isc_win32os_majorversion(void) { + initialize_action(); + return ((unsigned int)osVer.dwMajorVersion); +} + +unsigned int +isc_win32os_minorversion(void) { + initialize_action(); + return ((unsigned int)osVer.dwMinorVersion); +} + +unsigned int +isc_win32os_servicepackmajor(void) { + initialize_action(); + return ((unsigned int)osVer.wServicePackMajor); +} + +unsigned int +isc_win32os_servicepackminor(void) { + initialize_action(); + return ((unsigned int)osVer.wServicePackMinor); +} + +int +isc_win32os_versioncheck(unsigned int major, unsigned int minor, + unsigned int spmajor, unsigned int spminor) { + + initialize_action(); + + if (major < isc_win32os_majorversion()) + return (1); + if (major > isc_win32os_majorversion()) + return (-1); + if (minor < isc_win32os_minorversion()) + return (1); + if (minor > isc_win32os_minorversion()) + return (-1); + if (spmajor < isc_win32os_servicepackmajor()) + return (1); + if (spmajor > isc_win32os_servicepackmajor()) + return (-1); + if (spminor < isc_win32os_servicepackminor()) + return (1); + if (spminor > isc_win32os_servicepackminor()) + return (-1); + + /* Exact */ + return (0); +} \ No newline at end of file