idnits 2.17.1 draft-ietf-dnssec-as-map-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnssec-as-map-05.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnssec-as-map-05.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnssec-as-map-05.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnssec-as-map-05.txt,', but the file name used is 'draft-ietf-dnssec-as-map-05' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2065]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 176: '...pe A or AAAA RRs SHOULD NOT be placed ...' RFC 2119 keyword, line 198: '...sponds to the AS SHOULD be indicated b...' RFC 2119 keyword, line 202: '...nsible Person RR SHOULD appear under e...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (January 1998) is 9569 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 1034' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'RFC 1035' is defined on line 230, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 14 errors (**), 1 flaw (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mapping AS Number into the DNS 2 Expires January 1998 4 Mapping Autonomous Systems Number into the Domain Name System 5 ------- ---------- ------- ------ ---- --- ------ ---- ------ 7 Donald E. Eastlake 3rd 9 Status of This Document 11 This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to 12 be become a Best Current Practice RFC concerning utilization of the 13 Domain Name System (DNS) to support routing security. Distribution of 14 this document is unlimited. Comments should be sent to the DNS 15 Security Working Group mailing list or to the 16 author. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 32 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 33 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 35 Abstract 37 One requirement of secure routing is that independent routing 38 entities, such as those identified by Internet Autonomous System 39 Numbers, be able to authenticate messages to each other. Additions 40 have developed to the Domain Name System to enable it to be used for 41 authenticated public key distribution [RFC 2065]. This draft maps 42 all Autonomous System numbers into DNS Domain Names so that the DNS 43 security can be used to distribute their public keys. 45 [Changes from previous version are to accommodate AS numbers larger 46 than 16 bits and to delegate on decimal boundaries rather than binary 47 boundaries.] 49 Acknowledgements 51 The contributions of the following persons, listed in alphabetic 52 order, to this draft are gratefully acknowledged: 54 Ran Atkinson 56 Christian Huitema 58 Tony Li 60 Michael A. Patton. 62 Table of Contents 64 Status of This Document....................................1 66 Abstract...................................................2 67 Acknowledgements...........................................2 69 Table of Contents..........................................3 71 1. Introduction............................................4 73 2. Autonomous System Number Mapping........................5 75 3. Meaning of RRs..........................................6 77 4. Security Considerations.................................8 78 References.................................................8 79 Author's Address...........................................8 80 Expiration and File Name...................................9 82 1. Introduction 84 There are a number of elements required to secure routing in the 85 Internet. One of these is a way that independently operated routing 86 domains be able to authenticate messages to each other. 88 Sharing a private symmetric key between each pair of such domains is 89 impractical. Assuming 2**16 Autonomous System routing entities, 90 which is what is allowed in current versions of BGP, [RFC 1771], this 91 would imply approximately 2**31 pairs, an impractical number of keys 92 to securely generate, install, and periodically replace. 94 The solution is to use public key technology whereby each routing 95 domain has a private key it can use to sign messages. Other domains 96 that know the corresponding public key can then authenticate these 97 messages. Such authenticated messages can be used to set up and 98 maintain efficient symmetric keys on an as needed basis. 100 But how do the domains securely obtain the Autonomous System number 101 to public key mapping? 103 Extensions have been developed for the Domain Name System that enable 104 it to be conveniently used for authenticated public key distribution 105 [RFC 2065]. A variety of key types can be supported. All that is 106 required is a mapping of Autonomous System numbers into domain names, 107 which is provided by this draft. 109 It should be noted that the public keys retrieved from DNS will 110 likely be used primarily to authenticate initial connection set up 111 messages. Autonomous Systems that need to converse with any 112 frequency will probably negotiate more efficient symmetric session 113 keys. 115 2. Autonomous System Number Mapping 117 Autonomous System (AS) numbers are usually written as decimal number 118 and when blocks of AS numbers are delegated to a registry, it is 119 normally on decimal boundaries. Their current use in BGP is limited 120 to 16 bits providing a maximum value of 65,535. For example, ANS is 121 autonomous system 690. However, there is no inherent size limit in 122 the AS concept. AS numbers are mapped into a domain name as 123 described below. 125 Write the AS number, as usual, as a decimal number without any 126 "thousands" punctuation. If it is less than 5 digits, add leading 127 zeros to bring it up to five digits. Then simply reverse the order 128 of the digits, put a period between them, and append ".length.in- 129 as.arpa" where "length" is the number of AS digits. This mapping is 130 analogous to the IPv4 address mapping into the in-addr.arpa DNS 131 domain. 133 Thus the domain name correspond to Autonomous System 690 (decimal) is 135 0.9.6.0.0.5.in-as.arpa. 137 the domain corresponding to the largest possible AS number in BGP is 139 5.3.5.5.6.5.in-as.arpa. 141 the domain corresponding to AS number 65,000 is 143 0.0.0.5.6.5.in-as.arpa. 145 and the domain correspond to a hypothetical future greater than 16 146 bit AS number 1,234,567 is 148 7.6.5.4.3.2.1.7.in-as.arpa. 150 3. Meaning of RRs 152 The following guidance is given for some resource record (RR) types 153 that could be stored under the names mapped from AS numbers. The KEY 154 RR is given first, followed by the SIG RR, the NXT RR, and then some 155 additional RR types in alphabetic order. 157 KEY: This type of RR associates a public key with the owner name 158 which, in this case, corresponds to an Autonomous System (AS). Under 159 DNS security as proposed in RFC 2065 the KEY RR can be used to store 160 a variety of digital keys. A KEY for use in securing routing 161 communications between ASs will have the end entity flag bit on, the 162 authentication use prohibited flag bit off, and a protocol byte or 163 flag bit indicating routing communications use. Such a public key can 164 be used to authenticate communications with or between ASs. The 165 existence of such KEY RRs in the primary reason for mapping AS names 166 into the DNS. 168 SIG: The SIG signature resource record authenticates the RRs 169 that it signs as described in RFC 2065. Assuming the signer who 170 generated the SIG is trustworthy, such as the in-as.arpa zone owner, 171 then the signed RRs can be trusted. 173 NXT: An NXT RR is used in DNS security to provide authenticated 174 denial of the existence of types and names as described in RFC 2065. 176 A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes. 177 AS domain names are reserved for Autonomous Systems only and should 178 NOT be used for a host or any type of end entity other than an 179 Autonomous System. 181 CNAME: This type of RR is an alias pointing to another domain 182 name. An AS could have a CNAME pointing to a different AS but this 183 is not likely to be very useful as AS RRs will normally be looked up 184 when the AS number is actually encountered in use. 186 MX: There is no special use for an MX RR for an AS name. It 187 could point to a host that would accept mail related to that AS. 189 NS: The presence of NS records under an AS name means that it 190 has been carved out as a subzone. This gives the AS complete control 191 over the zone refresh parameters and control over the creation of 192 inferior names. No special meaning is currently assigned to such 193 inferior names so, although this is not advised, they could be used 194 for hosts or whatever. In this case, the will also be a zone KEY at 195 the AS name, indicated by having the zone flag bit on. 197 PTR: The part of the forward domain tree that administratively 198 corresponds to the AS SHOULD be indicated by a PTR RR. If some 199 entity, say example.xx, has several ASs, there would be PTRs to 200 example.xx from several names in the in-as.arpa hierarchy. 202 RP: A Responsible Person RR SHOULD appear under each AS name 203 telling you who you should contact in the case of problems with that 204 AS 206 TXT: Text RRs can be used for comments, postal address, or 207 similar notes under an AS name. 209 4. Security Considerations 211 This document concerns a means to map Internet Autonomous System 212 numbers into the Domain Name System (DNS) so that DNS can be used to 213 provide secure distribution of Autonomous System's public keys. The 214 security of the resulting AS to key mapping is dependent on the 215 security of the DNS security extensions and of the DNS zone where the 216 key is stored. 218 The most obvious way of using the AS keys retrieved from DNS is to 219 authenticate communications with a directly connected AS. However, 220 this does not prove that any routing information exchanged is 221 actually correct and note that routing information communicated over 222 this secured path may be indirectly forwarded from or to yet other 223 ASs. 225 References 227 [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, 228 November 1987 230 [RFC 1035] - Domain Names - Implementation and Specifications, P. 231 Mockapetris, November 1987. 233 [RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP- 234 4)", 03/21/1995. 236 [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. 237 Kaufman, January 1997. 239 Author's Address 241 Donald E. Eastlake 3rd 242 CyberCash, Inc. 243 318 Acton Street 244 Carlisle, MA 01741 USA 246 Telephone: +1 508 287 4877 247 +1 703 620-4200 (main office, Reston, VA) 248 FAX: +1 508 371 7148 249 EMail: dee@cybercash.com 251 Expiration and File Name 253 This draft expires January 1998. 255 Its file name is draft-ietf-dnssec-as-map-05.txt.