idnits 2.17.1 draft-ietf-sidr-rpki-grandparenting-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2013) is 4032 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-04 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-20 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Bush 3 Internet-Draft Internet Initiative Japan 4 Intended status: Informational April 10, 2013 5 Expires: October 12, 2013 7 Responsible Grandparenting in the RPKI 8 draft-ietf-sidr-rpki-grandparenting-01 10 Abstract 12 There are circumstances in RPKI operation where a resource holder's 13 parent may not be able to, or may not choose to, facilitate full and 14 proper registration of the holder's data. As in real life, the 15 holder may form a relationship with their grandparent who is willing 16 to aid the grandchild. This document describes simple procedures for 17 doing so. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 12, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 55 3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Informative References . . . . . . . . . . . . . . . . . . . 4 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 There are circumstances in RPKI operation where a resource holder's 64 parent may not be able to, or may not choose to, facilitate full and 65 proper registration of the holder's data. As in real life, the 66 holder may form a relationship with their grandparent who is willing 67 to aid the grandchild. This document describes simple procedures for 68 doing so. 70 An example might be when provider A allowed a child, C, to move to 71 other provider(s) and keep their address space, either temporarily or 72 permanently, and C's child, G, wished to stay with provider A. 74 Or a child, C, in the process of going out of business might place 75 their grandchildren in precarious circumstances until they can re- 76 home. The grandparent, without disturbing the child's data, could 77 simply issue ROAs for the grandchildren, or issue certificates for 78 those willing to manage their own rpki data. 80 Or, in the process of a transfer, the swing point (the CA in the 81 hierarchy where the buyer and seller meet) may be multiple CAs up 82 from the seller or buyer, and need to manage the resource during a 83 time where intermediate CAs are not prepared to act in the time 84 required by the business process. 86 Certification Authorities with a large number of children, e.g. very 87 large ISPs or RIRs, might offer documented grandparenting processes 88 and/or agreements. This might reassure grandchildren with worries 89 about irresponsible parents. 91 Other examples occur in administrative hierarchies, such as large 92 organizations or military and other government hierarchies, when A's 93 child C wishes to manage their own data but does not wish the 94 technical or administrative burden of managing their children's, Gs', 95 data. 97 2. Suggested Reading 99 It is assumed that the reader understands the RPKI, see [RFC6480], 100 ROAs, see [RFC6482], BGPSEC Router Certificates, see 101 [I-D.ietf-sidr-bgpsec-pki-profiles], and operational guidance for 102 origin validation, [I-D.ietf-sidr-origin-ops]. 104 3. What to Do 106 A hypothetical example might be that A has the rights to 10.0.0.0/8, 107 has delegated 10.42.0.0/16 to their child C, who delegated 10.42.2.0/ 108 23 to their child G. C has changed providers and kept, with A's 109 consent, 10.42.0.0/16, but G wishes to stay with A and keep 10.42.2.0 110 /23. 112 Perhaps there are also AS resources involved, and G wishes to issue 113 Router Certificates for their AS(s). 115 Managing RPKI data in such relationships is simple, but should be 116 done carefully. 118 First, using whatever administrative and/or contractual procedures 119 are appropriate in the local hierarchy, the grandparent, A, should 120 ensure their relationship to the grandchild, G, and that G has the 121 right to the resources which they wish to have registered. These are 122 local matters between A and G. 124 Although A has the rights over their child's, C's, resources, it 125 would be prudent and polite to ensure that C agrees to A forming a 126 relationship to G. Again, these are local matters between A, C, and 127 G. Often, no one outside of one of these bi-lateral relationships 128 actually knows the agreement between the parties. 130 Then, it is trivial within the RPKI for A to certify G's data, even 131 though it is a subset of the resources A delegated to C. A may 132 certify G's resources, or issue one or more EE certificates and ROAs 133 for G's resources. Which is done is a local matter between A and G. 135 4. Security Considerations 137 This operational practice presents no technical security threats 138 beyond those of the relevant RPKI specifications. 140 There are threats of social engineering by G, lying to A about their 141 relationship to and rights gained from C. 143 There are also threats of social engineering by C, attempting to 144 prevent A from giving rights to G which G legitimately deserves. 146 5. IANA Considerations 148 This document has no IANA Considerations. 150 6. Informative References 152 [I-D.ietf-sidr-bgpsec-pki-profiles] 153 Reynolds, M., Turner, S., and S. Kent, "A Profile for 154 BGPSEC Router Certificates, Certificate Revocation Lists, 155 and Certification Requests", draft-ietf-sidr-bgpsec-pki- 156 profiles-04 (work in progress), October 2012. 158 [I-D.ietf-sidr-origin-ops] 159 Bush, R., "RPKI-Based Origin Validation Operation", draft- 160 ietf-sidr-origin-ops-20 (work in progress), February 2013. 162 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 163 Secure Internet Routing", RFC 6480, February 2012. 165 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 166 Origin Authorizations (ROAs)", RFC 6482, February 2012. 168 Author's Address 170 Randy Bush 171 Internet Initiative Japan 172 5147 Crystal Springs 173 Bainbridge Island, Washington 98110 174 US 176 Email: randy@psg.com