[arin-ppml] Draft Policy 2012-3: ASN Transfers
tvest at eyeconomics.com
Fri Mar 23 20:04:18 EDT 2012
On Mar 23, 2012, at 2:41 PM, David Farmer wrote:
> On 3/23/12 13:16 CDT, Gary Buhrmaster wrote:
>> On Fri, Mar 16, 2012 at 21:23, Tom Vest<tvest at eyeconomics.com> wrote:
>>> The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes.
>> So, what I am hearing the RPKI experts say, is that ASNs (at least
>> from some point moving forward) might need to be eternally unique,
>> and that in (all?) cases of mergers, acquisitions, and/or bankrupcy transfers
>> of numbers, ARIN should issue a new ASN in exchange (with some
>> period of overlap, presumably) in order that reputation is not migrated.
>> Also, presumably, the (new) ASN should be issued by ARIN without
>> an additional needs review (it is an exchange in the best interests
>> of the (RPKI) community, not a new request).
> I think that is what was said. However, I'm not sure Owen or Tom classify themselves as RPKI experts, please correct me if I'm wrong. And, if I'm wrong, I apologize. Further, this is the first I heard of this being an issue, it's never been brought up in any of the several RKPI talks I've been to.
I can positively and emphatically identify myself as an RPKI non-expert. That said, I've been to trying to keep an inexpert (+casual, +passive, etc.) eye on its evolution from afar ever since it first appeared (?) on the back of a napkin in March 2006. Rather than opining inexpertly, I'll just provide a couple of likely non-representative primary source references that arguably speak to your question:
1. M. Lepinski & S. Kent, "RFC6480: An Infrastructure to Support Secure Internet Routing"
"In order to facilitate deployment, the architecture takes advantage of existing technologies and practices. The structure of the PKI element of the architecture corresponds to the existing resource allocation structure. Thus management of this PKI is a natural extension of the resource-management functions of the organizations that are already responsible for IP address and AS number resource allocation. Likewise, existing resource allocation and revocation practices have well-defined correspondents in this architecture. Note that while the initial focus of this architecture is routing security applications, the PKI described in this document could be used to support other applications that make use of attestations of IP address or AS number resource holdings."
"An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate."
The relevant question here to my mind is whether or not the adoption of a completely new "resource allocation and revocation practices" associated with AS transfers are likely to be compatible with the continued competent functioning of the "organizations that are already responsible for IP address and AS number resource allocation" and/or with the associated "existing resource allocation and revocation practices" upon which the RPKI was modeled.
To be fair, a real RPKI expert would probably emphasize the fact that the "existing resource distribution mechanisms and practices" are actually treated as completely optional by many aspects of RPKI., c.f.:
"In any PKI, each relying party (RP) chooses its own set of trust anchors (TAs). This general property of PKIs applies here as well. There is an extant IP address space and AS number allocation hierarchy, and thus IANA and/or the five RIRs are obvious candidates to be default TAs here. Nonetheless, each RP ultimately chooses the set of trust anchors it will use for certificate validation."
However, in the end you have to "trust" somebody or something to perform the "authentication" function to which the RPKI attests but does not itself provide:
2. J. Snyder, K. O'Donoghue, M. Shore, "draft-snyder-trust-relationships-00: A Survey of Trust Models and Relationships in Internet Protocols"
"Perhaps the key assumption around which PKIX is built is that it is not necessary for two entities to have an existing relationship in order to make a decision whether or not to accept the otherE1/4s assertions as 1) correct, and 2) trustworthy. Rather than negotiating in advance of any communication, those decisions are mediated through the use of third party agents, and consequently whether or not a given entity is trustworthy comes down to the question of whether or not the agent (and its agent, and on up the chain) can be seen as trustworthy and authoritative, and can make reliable assertions about the credentials it has issued."
Thus ISTM that while the RPKI may make it technically possible for a thousand new trust anchors to bloom, if they do not all agree to be mutually accountable to each other, at least for some minimal set of shared conditions, the results would likely look something like the domain of customary (non-treaty based) international commercial law, c. back when when inter-national trade was relative new and risky.
Hint: That wouldn't be "anarchy" exactly, but neither would it likely be the kind of environment that provides a great deal of reassurance to prospective inter-domain commercial actors.
Hopefully a real RPKI expert will chime in and provide a more thorough/representative/accurate account...
>> Is this a correct characterization of the RPKI experts opinions?
> I would appreciate comments from RPKI experts on this issue. If ASN transfers actually create additional risk within RPKI, then that is something we need to consider. But I for one would like to have a much more detail description of the problem and/or a pointer to previous discussion of the issue.
> David Farmer Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
More information about the ARIN-PPML