[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/