draft-ymbk-rpki-grandparenting-00.txt   draft-ymbk-rpki-grandparenting-01.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: BCP June 6, 2012 Intended status: Informational June 2012
Expires: December 8, 2012 Expires: December 01, 2012
Responsible Grandparenting in the RPKI Responsible Grandparenting in the RPKI
draft-ymbk-rpki-grandparenting-00 draft-ymbk-rpki-grandparenting-01
Abstract Abstract
There are circumstances in RPKI operations where a resource holder's There are circumstances in RPKI operations where a resource holder's
parent may not be able to, or may not choose to, facilitate full and parent may not be able to, or may not choose to, facilitate full and
proper registration of the holder's data. As in real life, the proper registration of the holder's data. As in real life, the
holder may form a relationship to their grandparent who is willing to holder may form a relationship with their grandparent who is willing
aid the grandchild. This document describes simple procedures for to aid the grandchild. This document describes simple procedures for
doing so. doing so.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, provisions of BCP 78 and BCP 79.
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 8, 2012. This Internet-Draft will expire on December 01, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (http://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
6. Informative References . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction 1. Introduction
There are circumstances in RPKI operations where a resource holder's There are circumstances in RPKI operations where a resource holder's
parent may not be able to, or may not choose to, facilitate full and parent may not be able to, or may not choose to, facilitate full and
proper registration of the holder's data. As in real life, the proper registration of the holder's data. As in real life, the
holder may form a relationship to their grandparent who is willing to holder may form a relationship with their grandparent who is willing
aid the grandchild. This document describes simple procedures for to aid the grandchild. This document describes simple procedures for
doing so. doing so.
One example would be when provider A allowed a child, C, to move to An example might be when provider A allowed a child, C, to move to
other provider(s) and keep their address space, either temporarily or other provider(s) and keep their address space, either temporarily or
permanently, and C's child, G, wished to stay with provider A. permanently, and C's child, G, wished to stay with provider A.
Certification Authorities with a large number of children, e.g.
RIRs, might offer documented grandparenting processes and/or
agreements. This might reassure grandchildren with worries about
irresponsible parents.
Other examples occur in administrative hierarchies, such as large Other examples occur in administrative hierarchies, such as large
organizations or military and other government hierarchies, when A's organizations or military and other government hierarchies, when A's
child C wishes to manage their own data but does not wish the child C wishes to manage their own data but does not wish the
technical or administrative burden of managing their children's, Gs', technical or administrative burden of managing their children's, Gs',
data. data.
2. Suggested Reading 2. Suggested Reading
It is assumed that the reader understands the RPKI, see [RFC6480], It is assumed that the reader understands the RPKI, see [RFC6480],
ROAs, see [RFC6482], BGPSEC Router Certificates, see ROAs, see [RFC6482], BGPSEC Router Certificates, see [I-D.ietf-sidr-
[I-D.ietf-sidr-bgpsec-pki-profiles], and the operational guidance for bgpsec-pki-profiles], and the operational guidance for origin
origin validation, [I-D.ietf-sidr-origin-ops]. validation, [I-D.ietf-sidr-origin-ops].
3. What to Do 3. What to Do
A hypothetical example might be that A has the rights to 10.0.0.0/8, A hypothetical example might be that A has the rights to 10.0.0.0/8,
has delegated 10.42.0.0/16 to their child C, who delegated has delegated 10.42.0.0/16 to their child C, who delegated 10.42.2.0/
10.42.2.0/23 to their child G. C has changed providers and kept, with 23 to their child G. C has changed providers and kept, with A's
A's consent, 10.42.0.0/16, but G wishes to stay with A and keep consent, 10.42.0.0/16, but G wishes to stay with A and keep 10.42.2.0
10.42.2.0/23. /23.
Perhaps there are also AS resources involved, and G wishes to issue Perhaps there are also AS resources involved, and G wishes to issue
Router Certificates for their AS(s). Router Certificates for their AS(s).
Managing RPKI data in such relationships is simple, but should be Managing RPKI data in such relationships is simple, but should be
done carefully. done carefully.
First, using whatever administrative and/or contractual procedures First, using whatever administrative and/or contractual procedures
are appropriate in the local hierarchy, the grandparent, A, should are appropriate in the local hierarchy, the grandparent, A, should
ensure their relationship to the grandchild, G, and that G has the ensure their relationship to the grandchild, G, and that G has the
right to the resources which they wish to have registered. These are right to the resources which they wish to have registered. These are
local matters between A and G. local matters between A and G.
Although A has the rights over their child's, C's, resources, it Although A has the rights over their child's, C's, resources, it
would be prudent and polite to ensure that C agrees to A forming a would be prudent and polite to ensure that C agrees to A forming a
relationship to G. Again, these are local matters between A, C, and relationship to G. Again, these are local matters between A, C, and
G. G. Often, no one outside of one of these bi-lateral relationships
actually knows the agreement between the parties.
Then, it is trivial within the RPKI for A to certify G's data, even Then, it is trivial within the RPKI for A to certify G's data, even
though it is a subset of the resources A delegated to C. A may though it is a subset of the resources A delegated to C. A may
certify G's resources, or issue one or more EE certificates and ROAs certify G's resources, or issue one or more EE certificates and ROAs
for G's resources. Which is done is a local matter between A and G. for G's resources. Which is done is a local matter between A and G.
4. Security Considerations 4. Security Considerations
This operational practice presents no technical security threats This operational practice presents no technical security threats
beyond those of the relevant RPKI specifications. beyond those of the relevant RPKI specifications.
There are threats of social engineering by G, lying to A about their There are threats of social engineering by G, lying to A about their
relationship to and rights gained from C. relationship to and rights gained from C.
There are also threats of social engineering by C, attempting to There are also threats of social engineering by C, attempting to
prevent A from giving rights to G which G legitimately deserves. prevent A from giving rights to G which G legitimately deserves.
5. IANA Considerations 5. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
6. Informative References 6. References
[I-D.ietf-sidr-bgpsec-pki-profiles] [I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for Reynolds, M., Turner, S. and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists, BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", and Certification Requests", Internet-Draft draft-ietf-
draft-ietf-sidr-bgpsec-pki-profiles-03 (work in progress), sidr-bgpsec-pki-profiles-03, April 2012.
April 2012.
[I-D.ietf-sidr-origin-ops] [I-D.ietf-sidr-origin-ops]
Bush, R., "RPKI-Based Origin Validation Operation", Bush, R., "RPKI-Based Origin Validation Operation",
draft-ietf-sidr-origin-ops-16 (work in progress), Internet-Draft draft-ietf-sidr-origin-ops-16, May 2012.
May 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S. and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
Author's Address Author's Address
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
 End of changes. 22 change blocks. 
48 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/