Network Working Group R. Bush
Internet-Draft Internet Initiative Japan
Intended status: Informational April 10, 2013
Expires: October 12, 2013
Responsible Grandparenting in the RPKI
draft-ietf-sidr-rpki-grandparenting-01
Abstract
There are circumstances in RPKI operation where a resource holder's
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
holder may form a relationship with their grandparent who is willing
to aid the grandchild. This document describes simple procedures for
doing so.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 12, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bush Expires October 12, 2013 [Page 1]
Internet-Draft Responsible Grandparenting in the RPKI April 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. What to Do . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
There are circumstances in RPKI operation where a resource holder's
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
holder may form a relationship with their grandparent who is willing
to aid the grandchild. This document describes simple procedures for
doing so.
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
permanently, and C's child, G, wished to stay with provider A.
Or a child, C, in the process of going out of business might place
their grandchildren in precarious circumstances until they can re-
home. The grandparent, without disturbing the child's data, could
simply issue ROAs for the grandchildren, or issue certificates for
those willing to manage their own rpki data.
Or, in the process of a transfer, the swing point (the CA in the
hierarchy where the buyer and seller meet) may be multiple CAs up
from the seller or buyer, and need to manage the resource during a
time where intermediate CAs are not prepared to act in the time
required by the business process.
Bush Expires October 12, 2013 [Page 2]
Internet-Draft Responsible Grandparenting in the RPKI April 2013
Certification Authorities with a large number of children, e.g. very
large ISPs or 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
organizations or military and other government hierarchies, when A's
child C wishes to manage their own data but does not wish the
technical or administrative burden of managing their children's, Gs',
data.
2. Suggested Reading
It is assumed that the reader understands the RPKI, see [RFC6480],
ROAs, see [RFC6482], BGPSEC Router Certificates, see
[I-D.ietf-sidr-bgpsec-pki-profiles], and operational guidance for
origin validation, [I-D.ietf-sidr-origin-ops].
3. What to Do
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 10.42.2.0/
23 to their child G. C has changed providers and kept, with A's
consent, 10.42.0.0/16, but G wishes to stay with A and keep 10.42.2.0
/23.
Perhaps there are also AS resources involved, and G wishes to issue
Router Certificates for their AS(s).
Managing RPKI data in such relationships is simple, but should be
done carefully.
First, using whatever administrative and/or contractual procedures
are appropriate in the local hierarchy, the grandparent, A, should
ensure their relationship to the grandchild, G, and that G has the
right to the resources which they wish to have registered. These are
local matters between A and G.
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
relationship to G. Again, these are local matters between A, C, and
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
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
for G's resources. Which is done is a local matter between A and G.
Bush Expires October 12, 2013 [Page 3]
Internet-Draft Responsible Grandparenting in the RPKI April 2013
4. Security Considerations
This operational practice presents no technical security threats
beyond those of the relevant RPKI specifications.
There are threats of social engineering by G, lying to A about their
relationship to and rights gained from C.
There are also threats of social engineering by C, attempting to
prevent A from giving rights to G which G legitimately deserves.
5. IANA Considerations
This document has no IANA Considerations.
6. Informative References
[I-D.ietf-sidr-bgpsec-pki-profiles]
Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPSEC Router Certificates, Certificate Revocation Lists,
and Certification Requests", draft-ietf-sidr-bgpsec-pki-
profiles-04 (work in progress), October 2012.
[I-D.ietf-sidr-origin-ops]
Bush, R., "RPKI-Based Origin Validation Operation", draft-
ietf-sidr-origin-ops-20 (work in progress), February 2013.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012.
Author's Address
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
US
Email: randy@psg.com
Bush Expires October 12, 2013 [Page 4]
