Stephen Kent <firstname.lastname@example.org> Wed, 13 June 2012 21:17 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFEE11E80A3 for <email@example.com>; Wed, 13 Jun 2012 14:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([188.8.131.52]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFuDt5ufJDF8 for <firstname.lastname@example.org>; Wed, 13 Jun 2012 14:17:53 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [184.108.40.206]) by ietfa.amsl.com (Postfix) with ESMTP id B26BA11E8097 for <email@example.com>; Wed, 13 Jun 2012 14:17:53 -0700 (PDT)
Received: from dhcp89-089-114.bbn.com ([220.127.116.11]:49364) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <firstname.lastname@example.org>) id 1SeuwG-000AZP-09 for email@example.com; Wed, 13 Jun 2012 17:17:16 -0400
Date: Wed, 13 Jun 2012 17:17:48 -0400
From: Stephen Kent <firstname.lastname@example.org>
Content-Type: multipart/alternative; boundary="============_-872500224==_ma============"
Subject: [sidr] grandparenting
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2012 21:17:54 -0000
OK, I just got around to reading this doc, and I have several observations: In the introduction (Section 1) the first example is: provider A allowed a child, C, to move to other provider(s) and keep their [sic] address space, either temporarily or permanently, and C's child, G, wished to stay with provider A. This seems like a poor example, absent additional info about the nature of the contractual arrangement between C and G. It might be the case that the arrangement allows G to opt out of having C advertise the address space that C received from A and sub-allocated to G, but that was not stated. If that option is not part of the deal between C and G, then G may have no basis for asking A to advertise this space, right? So, it would help to have more details in this example to make sure we're not suggesting that the RPKI be used to circumvent an agreement. I think the second, more generic example, is better, but it too could use some tweaking. The situation here is one in which a resource holder (C) is a player in the RPKI, but does not want to assume responsibility for managing resources that it sub-allocates, e.g., to G, AND it has no objection to this function being provided by the resource holder from which C receives its allocation. I agree with Wes's example. G may be looking to outsource management of its RPKI functions, but not change service providers. That has different implications for how this process is managed, and who does it. For example, G might hire someone to manage RPKI functions for it, and that need not be A, IF C is willing to issue a CA cert to the 3rd party selected by G. This would be invisible to RPs, if it is managed in the way I mentioned, whether the service is provided by A or Z. Section 3 talks about A having to verify that G is the holder of the resources in question. It omits a discussion about A verifying with C that C does not object to A inserting itself into the hierarchy in this fashion, essentially between C and G. The initial example fro Section 1 is used here and, again, I think it needs additional text to state assumptions as I noted above. I worry about the statement "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." This implies details of the relationship between A and C that have not been stated. I also would have imagined a different technical proposal here. For example, A might reissue a certificate to C removing G's prefix(es) at some point in this process (consistent with a "make before break" model). This would ensure that C does not reallocate the prefix that A is now managing directly in its relationship with G. Also, removing that prefix would prevent C from issuing a ROA for the subsuming address space, causing G's traffic to be directed to C, if more-specific routes for G disappear. Yes, there needs to be a time overlap for this, but not suggesting this as the preferred end state is likely to confuse matters. The text here suggests that A might issue EE certificates and ROAs on behalf of G. I'd suggest it would be much cleaner for A to create a CA certificate representing G and the issue EE certificates and ROAs (and manifests and CRLs) relative to that CA, if G does not wish to operate its own CA. Since these certificates contain no names, A is not impersonating C or G by doing this, and it makes for a cleaner distinction between the resources that A is managing in the normal, hierarchic fashion, and the ones that are being treated specially.