idnits 2.17.1 draft-ietf-rps-iana-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 44 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 1999) is 8959 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-06) exists of draft-ietf-rps-dist-02 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Cengiz Alaettinoglu 2 Expires April 15, 2000 USC/ISI 3 draft-ietf-rps-iana-02.txt Curtis Villamizar 4 Avici Systems 5 Ramesh Govindan 6 USC/ISI 7 October 15, 1999 9 RPS IANA Issues 11 Status of this Memo: 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Copyright (C) The Internet Society (1998). All Rights Reserved. 18 Internet-Drafts are working documents of the Internet Engineering Task Force 19 (IETF), its areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months and 23 may be updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet-Drafts as reference material or to cite 25 them other than as 'work in progress.' 27 The list of current Internet-Drafts can be accessed at 28 30 The list of Internet-Draft Shadow Directories can be accessed at 31 . 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119. 37 Abstract 39 RPS Security [2] requires certain RPSL [1] objects in the IRR to be 40 hierarchically delegated. The set of objects that are at the root of this 41 hierarchy needs to be created and digitally signed by IANA. This paper 42 presents these seed objects and lists operations required from IANA. 44 1 Initial Seed 46 A public key of IANA needs to be distributed with the software 47 implementations of Distributed Routing Policy System [3]. An initial set of 48 seed objects are needed to be signed with this key. The following 49 transaction (the transaction format is defined in [3]) contains these 50 objects and is signed by this key: 52 mntner: mnt-iana 53 descr: iana's maintainer 54 admin-c: JKR1 55 tech-c: JKR1 56 upd-to: JKRey@ISI.EDU 57 mnt-nfy: JKRey@ISI.EDU 58 auth: pgpkey-7F6AA1B9 59 mnt-by: mnt-iana 60 referral-by: mnt-iana 61 source: IANA 63 key-cert: pgpkey-7F6AA1B9 64 method: pgp 65 owner: iana-root (est. Nov 98) 66 fingerpr: 71 09 2E 37 71 B8 0A 9C 3B 28 98 B4 F1 21 13 BB 67 certif: # this is the real IANA key 68 + -----BEGIN PGP PUBLIC KEY BLOCK----- 69 + Version: 2.6.2 70 + 71 + mQCNAzZJ52sAAAEEAJ//C01YnlaGuXyrC16V7FphkRvBmcNU22TPOzrKnKjnWjH5 72 + sJ5UQnGOpyhDc796gqBjY+lTLvPB9sFGJPWgxfNk2JQaxxLTD+tfqSsiURc/srpp 73 + XohFAVR/fez8MOecISwvNpFh5VADuFuoNi7ZLuOwVTC4tM5RU0NJa8l/aqG5AAUR 74 + tCdpYW5hLXJvb3QgKGVzdC4gTm92IDk4KSA8aWFuYUBpYW5hLm9yZz4= 75 + =sF4q 76 + -----END PGP PUBLIC KEY BLOCK----- 77 mnt-by: mnt-iana 78 source: IANA 80 repository: IANA 81 repository-cert: PGPKEY-88BAC849 82 query-address: http://www.iana.org 83 response-auth-type: none 84 submit-address: http://www.iana.org 85 submit-auth-type: none 86 expire: 0000 04:00:00 87 heartbeat-interval: 0000 01:00:00 88 admin-c: JKR1 89 tech-c: JKR1 90 mnt-by: mnt-iana 91 source: IANA 93 as-block: AS0 - AS65535 94 descr: as number space 95 country: us 96 admin-c: JKR1 97 tech-c: JKR1 98 status: UNALLOCATED 99 source: IANA 100 mnt-by: mnt-iana 101 mnt-lower: mnt-iana 103 inetnum: 0.0.0.0 - 255.255.255.255 104 netname: Internet 105 descr: ip number space 106 country: us 107 admin-c: JKR1 108 tech-c: JKR1 109 status: UNALLOCATED 110 source: IANA 111 mnt-by: mnt-iana 112 mnt-lower: mnt-iana 114 timestamp: 19991001 01:00:00 +00:00 116 signature: 117 + -----BEGIN PGP SIGNATURE----- 118 + Version: 2.6.2 119 + 120 + iQCVAwUBOAd3YENJa8l/aqG5AQFVdAP9Ho2TSLGXiDi6v1McsKY4obO32EtP44Jv 121 + tpNWiRRz47WIpMBmzUrQajBDNNXzwq9r9mGC75Pg0MMwTDfvA47o6mnIGdT9XyZz 122 + s9HlDGOqhklIjHOxXFDrBiz3u7eWEf3vmDCXt6UYg9lUtRKefkWtR5wD1Q1zDMSc 123 + 7Ya7PE6X8SU= 124 + =sAft 125 + -----END PGP SIGNATURE----- 127 The above text has no extra white space characters at the end of each line, 128 and contains no tab characters. All blank line sequences contain only a 129 single blank line. 131 In this case, we assumed that IANA runs its own repository. However this is 132 not a requirement. Instead, it may publish this transaction with an 133 existing routing registry. 135 2 IANA Assignments 137 Each time IANA makes an assignment, it needs to create inetnum and as-block 138 objects as appropriate and digitally sign them using the key in its key-cert 139 object. For example: 141 as-block: AS0 - AS500 142 descr: arin's space 143 country: us 144 status: ALLOCATED 145 source: iana 146 delegated: arin 147 mnt-by: mnt-iana 149 inetnum: 128.0.0.0 - 128.255.255.255 150 netname: Internet portion 151 descr: ip number space 152 country: us 153 status: ALLOCATED 154 source: iana 155 delegated: arin 156 mnt-by: mnt-iana 158 3 Creating Routing Repositories 160 To enable a new routing repository, a repository object, a maintainer object 161 and a key-cert object need to be created and digitally signed by IANA. For 162 example: 164 mntner: mnt-ripe 165 descr: RIPE's maintainer 166 auth: 167 mnt-by: mnt-ripe 168 referral-by: mnt-iana 169 admin-c: . . . 170 tech-c: . . . 171 upd-to: . . . 172 mnt-nfy: . . . 173 source: RIPE 175 key-cert: pgpkey-979979 176 method: pgp 177 owner: . . . 178 fingerpr: . . . 179 certif: # this key is for illustration only 180 + -----BEGIN PGP PUBLIC KEY BLOCK----- 181 + Version: PGP for Personal Privacy 5.0 182 + 183 + . . . 184 + -----END PGP PUBLIC KEY BLOCK----- 185 mnt-by: mnt-ripe 186 source: RIPE 188 repository: RIPE 189 query-address: whois://whois.ripe.net 190 response-auth-type: PGPKEY-23F5CE35 # pointer to key-cert object 191 response-auth-type: none 192 remarks: you can request rsa signature on queries 193 remarks: PGP required on submissions 194 submit-address: mailto://auto-dbm@ripe.net 195 submit-address: rps-query://whois.ripe.net:43 196 submit-auth-type: pgp-key, crypt-pw, mail-from 197 remarks: these are the authentication types supported 198 mnt-by: maint-ripe-db 199 expire: 0000 04:00:00 200 heartbeat-interval: 0000 01:00:00 201 ... 202 remarks: admin and technical contact, etc 203 source: RIPE 205 This very first transaction of a new repository is placed in the new 206 repository, not in the IANA repository. 208 4 Security Considerations 210 Routing policy system security document [2] defines an hierarchical 211 authorization model for objects stored in the routing registries. This 212 document specifies the seed objects and the actions need to be taken by IANA 213 to maintain the root of that authorization hierarchy. 215 5 IANA Considerations 217 This whole document is for detailed consideration by IANA. 219 References 221 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 223 Terpstra, and C. Villamizar: Routing Policy Specification Language 224 (RPSL), RFC 2622. 226 [2] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. 227 Routing policy system security. Internet Draft draft-ietf-rps-auth-04, 228 Network Information Center, April 1999. 230 [3] C. Villamizar, C. Alaettinouglu, R. Govindan, D. Meyer. Distributed 231 Routing Policy System. Internet Draft draft-ietf-rps-dist-02, Network 232 Information Center, February 1999. 234 6 Authors' Addresses 236 Cengiz Alaettinoglu 237 USC Information Sciences Institute 238 email: cengiz@isi.edu 240 Curtis Villamizar 241 Avici Systems 242 email: curtis@avici.com 244 Ramesh Govindan 245 USC Information Sciences Institute 246 email: govindan@isi.edu 248 Full Copyright Statement 250 Copyright (C) The Internet Society (October 15, 1999). All Rights Reserved. 252 This document and translations of it may be copied and furnished to others, 253 and derivative works that comment on or otherwise explain it or assist in 254 its implmentation may be prepared, copied, published and distributed, in 255 whole or in part, without restriction of any kind, provided that the above 256 copyright notice and this paragraph are included on all such copies and 257 derivative works. However, this document itself may not be modified in any 258 way, such as by removing the copyright notice or references to the Internet 259 Society or other Internet organizations, except as needed for the purpose of 260 developing Internet standards in which case the procedures for copyrights 261 defined in the Internet Standards process must be followed, or as required 262 to translate it into languages other than English. 264 The limited permissions granted above are perpetual and will not be revoked 265 by the Internet Society or its successors or assigns. 267 This document and the information contained herein is provided on an ``AS 268 IS'' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 269 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 270 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 271 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 272 PARTICULAR PURPOSE. 274 Notices 276 The IETF takes no position regarding the validity or scope of any 277 intellectual property or other rights that might be claimed to pertain to 278 the implementation or use of the technology described in this document or 279 the extent to which any license under such rights might or might not be 280 available; neither does it represent that it has made any effort to identify 281 any such rights. Information on the IETF's procedures with respect to 282 rights in standards-track and standards-related documentation can be found 283 in BCP-11. Copies of claims of rights made available for publication and 284 any assurances of licenses to be made available, or the result of an attempt 285 made to obtain a general license or permission for the use of such 286 proprietary rights by implementors or users of this specification can be 287 obtained from the IETF Secretariat. 289 The IETF invites any interested party to bring to its attention any 290 copyrights, patents or patent applications, or other proprietary rights 291 which may cover technology that may be required to practice this standard. 292 Please address the information to the IETF Executive Director.