idnits 2.17.1 draft-ymbk-rpki-grandparenting-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 (July 2012) is 4302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sidr-bgpsec-pki-profiles' is defined on line 148, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-sidr-bgpsec-pki-profiles-03 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-17 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 July 2012 5 Expires: December 31, 2012 7 Responsible Grandparenting in the RPKI 8 draft-ymbk-rpki-grandparenting-02 10 Abstract 12 There are circumstances in RPKI operations 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 December 31, 2012. 36 Copyright Notice 38 Copyright (c) 2012 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 (http://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 This document may not be modified, and derivative works of it may not 51 be created, and it may not be published except as an Internet-Draft. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2 57 3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 There are circumstances in RPKI operations where a resource holder's 66 parent may not be able to, or may not choose to, facilitate full and 67 proper registration of the holder's data. As in real life, the 68 holder may form a relationship with their grandparent who is willing 69 to aid the grandchild. This document describes simple procedures for 70 doing so. 72 An example might be when provider A allowed a child, C, to move to 73 other provider(s) and keep their address space, either temporarily or 74 permanently, and C's child, G, wished to stay with provider A. 76 Or a child, C, in the process of going out of business might place 77 their grandchildren in precarious circumstances until they can re- 78 home. The grandparent, without disturbing the child's data, could 79 simply issue ROAs for the grandchildren, or issue certificates for 80 those willing to manage their own rpki data. 82 Certification Authorities with a large number of children, e.g. very 83 large ISPs or RIRs, might offer documented grandparenting processes 84 and/or agreements. This might reassure grandchildren with worries 85 about irresponsible parents. 87 Other examples occur in administrative hierarchies, such as large 88 organizations or military and other government hierarchies, when A's 89 child C wishes to manage their own data but does not wish the 90 technical or administrative burden of managing their children's, Gs', 91 data. 93 2. Suggested Reading 95 It is assumed that the reader understands the RPKI, see [RFC6480], 96 ROAs, see [RFC6482], BGPSEC Router Certificates, see [I-D.ietf-sidr- 97 bgpsec-pki-profiles], and the operational guidance for origin 98 validation, [I-D.ietf-sidr-origin-ops]. 100 3. What to Do 102 A hypothetical example might be that A has the rights to 10.0.0.0/8, 103 has delegated 10.42.0.0/16 to their child C, who delegated 10.42.2.0/ 104 23 to their child G. C has changed providers and kept, with A's 105 consent, 10.42.0.0/16, but G wishes to stay with A and keep 10.42.2.0 106 /23. 108 Perhaps there are also AS resources involved, and G wishes to issue 109 Router Certificates for their AS(s). 111 Managing RPKI data in such relationships is simple, but should be 112 done carefully. 114 First, using whatever administrative and/or contractual procedures 115 are appropriate in the local hierarchy, the grandparent, A, should 116 ensure their relationship to the grandchild, G, and that G has the 117 right to the resources which they wish to have registered. These are 118 local matters between A and G. 120 Although A has the rights over their child's, C's, resources, it 121 would be prudent and polite to ensure that C agrees to A forming a 122 relationship to G. Again, these are local matters between A, C, and 123 G. Often, no one outside of one of these bi-lateral relationships 124 actually knows the agreement between the parties. 126 Then, it is trivial within the RPKI for A to certify G's data, even 127 though it is a subset of the resources A delegated to C. A may 128 certify G's resources, or issue one or more EE certificates and ROAs 129 for G's resources. Which is done is a local matter between A and G. 131 4. Security Considerations 133 This operational practice presents no technical security threats 134 beyond those of the relevant RPKI specifications. 136 There are threats of social engineering by G, lying to A about their 137 relationship to and rights gained from C. 139 There are also threats of social engineering by C, attempting to 140 prevent A from giving rights to G which G legitimately deserves. 142 5. IANA Considerations 144 This document has no IANA Considerations. 146 6. References 148 [I-D.ietf-sidr-bgpsec-pki-profiles] 149 Reynolds, M., Turner, S. and S. Kent, "A Profile for 150 BGPSEC Router Certificates, Certificate Revocation Lists, 151 and Certification Requests", Internet-Draft draft-ietf- 152 sidr-bgpsec-pki-profiles-03, April 2012. 154 [I-D.ietf-sidr-origin-ops] 155 Bush, R., "RPKI-Based Origin Validation Operation", 156 Internet-Draft draft-ietf-sidr-origin-ops-17, June 2012. 158 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 159 Secure Internet Routing", RFC 6480, February 2012. 161 [RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route 162 Origin Authorizations (ROAs)", RFC 6482, February 2012. 164 Author's Address 166 Randy Bush 167 Internet Initiative Japan 168 5147 Crystal Springs 169 Bainbridge Island, Washington 98110 170 US 172 Email: randy@psg.com