idnits 2.17.1 draft-ietf-rps-icann-00.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: ---------------------------------------------------------------------------- ** 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 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 == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 119 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. ** There are 39 instances of too long lines in the document, the longest one being 8 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 (June 25, 1999) is 9043 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) ** Obsolete normative reference: RFC 2280 (ref. '1') (Obsoleted by RFC 2622) == Outdated reference: A later version (-04) exists of draft-ietf-rps-auth-03 == Outdated reference: A later version (-06) exists of draft-ietf-rps-dist-01 Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Cengiz Alaettinoglu 2 Expires December 25, 1999 USC/ISI 3 draft-ietf-rps-icann-00 Curtis Villamizar 4 Avici Systems 5 Ramesh Govindan 6 USC/ISI 7 June 25, 1999 9 RPS ICANN 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 ICANN. This paper 42 presents these seed objects and lists operations required from ICANN. 44 1 Initial Seed 46 A public key of ICANN 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. They are: 50 mntner: mnt-icann 51 descr: icann's maintainer 52 admin-c: . . . 53 tech-c: . . . 54 upd-to: . . . 55 mnt-nfy: . . . 56 auth: pgpkey-12345 57 mnt-by: mnt-icann 58 referral-by: mnt-icann 59 source: ICANN 61 key-cert: pgpkey-12345 62 method: pgp 63 owner: . . . 64 fingerpr: . . . 65 certif: # this key is for illustration only 66 + -----BEGIN PGP PUBLIC KEY BLOCK----- 67 + Version: PGP for Personal Privacy 5.0 68 + 69 + mQFCBDZDU98RAwDUmo45DdsS5W8zjTT0wrOMGIxhpdgGEajiwcjUF2EJm/7w7rEt 70 + 2WOqXqPupF2lrbb8D3keBnIPW8oyvn0tl471yerBeuBsR50U+D039/yFbpcG0O4F 71 + IhYB5TBOrPuUUl8AoP+bUmGP6DudkE+wDgNlcY5UnEBnAwDIB9umMEKK0kDcFy/Q 72 + 34gLNplxARbNjyIFLDOg/W2qfBb9/RfQLNGfgPWqYz47tIN1rYhErDWDJjjhWkNd 73 + Fb7sARhqCotnkJrJ/0EsnSugU+HZZrp/49XMyvdITyq3Q3QC/RDh2dIWD0VyXvz8 74 + uDo6jvN9cx9rmejOsle/TXWYeLlNZrv5zQ8zLr/ZHWzOQAV45GdSgRREHKfHM9lj 75 + iOqMagiTdk0df+/g78v8tQaefScj5JNbXqDive5HStdeogFMR7QkQ2VuZ2l6IEFs 76 + YWV0dGlub2dsdSA8Y2VuZ2l6QGlzaS5lZHU+iQBLBBARAgALBQI2Q1PfBAsDAQIA 77 + CgkQjZRGkY5cjCfDMgCgx8SYpbmMwCC3QoFaJdhBeHPtjCoAn3MZ75AODmWlTjgI 78 + akrLUaw3v5CGuQDNBDZDU+UQAwDUtvp8wrXXKqvhGMGBDLYYPWlgGhBAr2eoyS2r 79 + n+JZPbDJpOKVygVfdkrWjqQpParzRRUHerhgGNnaiGZBB+XtDa7OTy8mKWGLyY3f 80 + svtySSmVSDIjOCTIoMwhR+c3oBcAAgIC/2FVAllFaZWeuEpyjT5p4rOzgzpLSNTf 81 + LV9Mav5hyuZJZYHlpibqt1uF5YiYGaE/Zaf0P5pHvF89mOUZ0y8Cj9rKc2AkoRWm 82 + 8XhDVL68MXjBUcMimNHkweOnn16iSNttm4kAPwMFGDZDU+WNlEaRjlyMJxECThwA 83 + oOpfVLhHM1tqnq09SFptSoiEfxGQAKDF0b1pN8iuZslgttr7AcfAnImCYA== 84 + =X+wc 85 + -----END PGP PUBLIC KEY BLOCK----- 86 mnt-by: mnt-icann 87 source: ICANN 88 as-block: AS0 - AS65535 89 descr: as number space 90 country: us 91 admin-c: . . . 92 tech-c: . . . 93 status: UNALLOCATED 94 source: ICANN 95 mnt-by: mnt-icann 96 mnt-lower: mnt-icann 98 inetnum: 0.0.0.0 - 255.255.255.255 99 netname: Internet 100 descr: ip number space 101 country: us 102 admin-c: . . . 103 tech-c: . . . 104 status: UNALLOCATED 105 source: ICANN 106 mnt-by: mnt-icann 107 mnt-lower: mnt-icann 109 Here, we assume that ICANN runs its own repository. However this is not a 110 requirement. Instead, it may publish its objects with one of the existing 111 routing registries. 113 This set of seed objects needs to be signed with the hard coded ICANN key. 114 Later, ICANN objects can be signed with the key in the ICANN key-cert 115 object. 117 2 ICANN Assignments 119 Each time ICANN makes an assignment, it needs to create inetnum and as-block 120 objects as appropriate and digitally sign them using the key in its key-cert 121 object. For example: 123 as-block: AS0 - AS500 124 descr: arin's space 125 country: us 126 status: ALLOCATED 127 source: icann 128 delegated: arin 129 mnt-by: mnt-icann 131 inetnum: 128.0.0.0 - 128.255.255.255 132 netname: Internet portion 133 descr: ip number space 134 country: us 135 status: ALLOCATED 136 source: icann 137 delegated: arin 138 mnt-by: mnt-icann 140 3 Creating Routing Repositories 142 To enable a new routing repository, a repository object, a maintainer object 143 and a key-cert object (if the maintainer object uses it) needs to be created 144 and digitally signed by ICANN. For example: 146 mntner: mnt-ripe 147 descr: RIPE's maintainer 148 auth: 149 mnt-by: mnt-ripe 150 referral-by: mnt-icann 151 admin-c: . . . 152 tech-c: . . . 153 upd-to: . . . 154 mnt-nfy: . . . 155 source: RIPE 157 key-cert: pgpkey-979979 158 method: pgp 159 owner: . . . 160 fingerpr: . . . 161 certif: # this key is for illustration only 162 + -----BEGIN PGP PUBLIC KEY BLOCK----- 163 + Version: PGP for Personal Privacy 5.0 164 + 165 + . . . 166 + -----END PGP PUBLIC KEY BLOCK----- 167 mnt-by: mnt-ripe 168 source: RIPE 170 repository: RIPE 171 query-address: whois.ripe.net 43 172 response-auth-type: rsa-pubkey some-incredibly-long-public-key 173 response-auth-type: none 174 remarks: you can request rsa signature on queries 175 remarks: PGP required on submissions 176 submit-address: mailto://auto-dbm@ripe.net 177 submit-address: rps-query://whois.ripe.net:43 178 submit-auth-type: pgp-key crypt-pw mail-from 179 remarks: these are the authentication types supported 180 mnt-by: maint-ripe 181 expire: 0000 04:00:00 182 heartbeat-rate: 0000 01:00:00 183 ... 184 remarks: admin and technical contact, etc 185 source: RIPE 187 This very first transaction of a new repository is placed in the new 188 repository, not in the ICANN repository. 190 4 Security Consideration 192 This document describes ICANN procedures and initial RPSL seed objects. It 193 does not define protocols or standards that need to be secured. 195 References 197 [1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. 198 Terpstra, and C. Villamizar: Routing Policy Specification Language 199 (RPSL), RFC 2280. 201 [2] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy, and C. Orange. 202 Routing policy system security. Internet Draft draft-ietf-rps-auth-03, 203 Network Information Center, April 1999. 205 [3] C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. Distributed 206 Routing Policy System. Internet Draft draft-ietf-rps-dist-01, Network 207 Information Center, February 1999. 209 5 Authors' Addresses 211 Cengiz Alaettinoglu 212 USC Information Sciences Institute 213 email: cengiz@isi.edu 215 Curtis Villamizar 216 Avici Systems 217 email: curtis@avici.com 219 Ramesh Govindan 220 USC Information Sciences Institute 221 email: govindan@isi.edu