idnits 2.17.1 draft-ymbk-rpki-grandparenting-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 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 (June 6, 2012) is 4340 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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-16 Summary: 0 errors (**), 0 flaws (~~), 5 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: BCP June 6, 2012 5 Expires: December 8, 2012 7 Responsible Grandparenting in the RPKI 8 draft-ymbk-rpki-grandparenting-00 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 to their grandparent who is willing to 16 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. This document may not be modified, 23 and derivative works of it may not be created, and it may not be 24 published except as an Internet-Draft. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 8, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Informative References . . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 to their grandparent who is willing to 69 aid the grandchild. This document describes simple procedures for 70 doing so. 72 One example would 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 Other examples occur in administrative hierarchies, such as large 77 organizations or military and other government hierarchies, when A's 78 child C wishes to manage their own data but does not wish the 79 technical or administrative burden of managing their children's, Gs', 80 data. 82 2. Suggested Reading 84 It is assumed that the reader understands the RPKI, see [RFC6480], 85 ROAs, see [RFC6482], BGPSEC Router Certificates, see 86 [I-D.ietf-sidr-bgpsec-pki-profiles], and the operational guidance for 87 origin validation, [I-D.ietf-sidr-origin-ops]. 89 3. What to Do 91 A hypothetical example might be that A has the rights to 10.0.0.0/8, 92 has delegated 10.42.0.0/16 to their child C, who delegated 93 10.42.2.0/23 to their child G. C has changed providers and kept, with 94 A's consent, 10.42.0.0/16, but G wishes to stay with A and keep 95 10.42.2.0/23. 97 Perhaps there are also AS resources involved, and G wishes to issue 98 Router Certificates for their AS(s). 100 Managing RPKI data in such relationships is simple, but should be 101 done carefully. 103 First, using whatever administrative and/or contractual procedures 104 are appropriate in the local hierarchy, the grandparent, A, should 105 ensure their relationship to the grandchild, G, and that G has the 106 right to the resources which they wish to have registered. These are 107 local matters between A and G. 109 Although A has the rights over their child's, C's, resources, it 110 would be prudent and polite to ensure that C agrees to A forming a 111 relationship to G. Again, these are local matters between A, C, and 112 G. 114 Then, it is trivial within the RPKI for A to certify G's data, even 115 though it is a subset of the resources A delegated to C. A may 116 certify G's resources, or issue one or more EE certificates and ROAs 117 for G's resources. Which is done is a local matter between A and G. 119 4. Security Considerations 121 This operational practice presents no technical security threats 122 beyond those of the relevant RPKI specifications. 124 There are threats of social engineering by G, lying to A about their 125 relationship to and rights gained from C. 127 There are also threats of social engineering by C, attempting to 128 prevent A from giving rights to G which G legitimately deserves. 130 5. IANA Considerations 132 This document has no IANA Considerations. 134 6. Informative References 136 [I-D.ietf-sidr-bgpsec-pki-profiles] 137 Reynolds, M., Turner, S., and S. Kent, "A Profile for 138 BGPSEC Router Certificates, Certificate Revocation Lists, 139 and Certification Requests", 140 draft-ietf-sidr-bgpsec-pki-profiles-03 (work in progress), 141 April 2012. 143 [I-D.ietf-sidr-origin-ops] 144 Bush, R., "RPKI-Based Origin Validation Operation", 145 draft-ietf-sidr-origin-ops-16 (work in progress), 146 May 2012. 148 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 149 Secure Internet Routing", RFC 6480, February 2012. 151 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 152 Origin Authorizations (ROAs)", RFC 6482, February 2012. 154 Author's Address 156 Randy Bush 157 Internet Initiative Japan 158 5147 Crystal Springs 159 Bainbridge Island, Washington 98110 160 US 162 Phone: +1 206 780 0431 x1 163 Email: randy@psg.com