Hi Gert, On Tue, May 10, 2011 at 11:47 AM, Gert Doering <gert@space.net> wrote:
Hi,
On Tue, May 10, 2011 at 11:38:46AM -0400, Martin Millnert wrote:
What I trust *the most* is for the proper holders of a resource to attest to their own resource(s) *themselves*.
So how do you determine which of the following attestations is true?
"I permit 195.30.0.0/16 to be announced by AS5539" "I permit 80.81.192.0/22 to be announced by AS5539"
AS5539 is my AS number, and one of those netblocks is mine, while the other one isn't.
If I were trustworthy, and wouldn't make typing mistakes, you just would believe me that I'll only ever announce my netblocks - but reality shows that mis-announcements do happen, so the attestations are only useful if there is an authority that tells you that I'm indeed the holder of one of those blocks, and can do attestations about them...
Yes, this is indeed the key issue. I'd like to single out the registry function you mention above, and separate it from that authority also having the power to lease out resources under some kind of notion that they can be called back. Clearly, as long as [people are in agreement that] resources are leased, the lessor will remain the single dominant authority over said resources, but this only works if there is also agreement that resources have been called back. This is quite different from stating that the only solution to my base routing security model is to lease out resources. So, are there other ways to organize a registry? (I don't want you to get stuck at too specific details since the following suggestion would need development work no doubt, but) the general idea is something along the lines of: Imagine you have a data file, let's say XML since it allows types and is reasonably clear-text, which states: <xml> <holder number=1> <asn>5539</asn> <contact-data>... ... </holder number=1> </xml> Now imagine you sign this file with a PKI crypt-system, using your private key. Following this you send this signed object to the RIPE NCC, because they're your current RIR. RIPE signs this blob irrevocably, with their own private key and may attach some other useful data, like perhaps a time stamp. You can now show up a signed object, signed *irrevocably* by the RIPE NCC (set validity=inf, /etc/init.d/crl-server stop), which now for all intents and purposes has become your ASN - it's come to life in this file and in doing so you can now do what you want with it, including sending out copies of it anyway you wish or running it through /usr/bin/shred . When the RIPE NCC signs this object, they in effect sign it over to you and should update their records accordingly. Repeat the same process for the netblock which is yours. The RIPE NCC won't sign the one which isn't registered to you over to you, though. There are issues with the RIPE NCC losing their key(s), signing away a previously un-signed-away resource to the wrong recipient, and also, later signing someone else's XML file signed with their private key, stating your ASN. A possible and interesting mitigation to part of the above may be to include your blob into a distributed database system, which perhaps use some time windowing to the effect that, at T=435 , there were 25644 incorporated objects, yours not included. Then, when you add one of your own, it will eventually after some form of system agreement get rolled into the ddb, which then rolls over to T=436 where it now has 25645 objects and yours is one of them. Doing something similar to this, I imagine you can be able to trace the existence of your resource or any later duplicates of your object in this system, which presumably would not get accepted into the system since they previously already exists. How to organize transfer of resources between parties is another chapter, but soluble no doubt. There are likely attacks possible against this system, both known and unforeseeable, and hopefully known ones can be mitigated (reaching agreement in rolling forward and ensuring correctness of data that is entered are the two single biggest issue I can think of right now). For correctness, there is probably no way to remove an object from the ddb without organizing sufficient a-prior agreement amongst the participants. It does not have any removeObject() calls. As always, you have to be careful with your private key. I guess it is free for people to organize their private keys best they wish. Perhaps some put a backup at the RIPE NCC? (Or under their pillow?) It's worthwhile to note that this ddb does not care whether or not the RIPE NCC did mark their records correctly (and that they stay that way) after they signed away a resource which then got incorporated into the ddb. The real remaining issue with the above is the RIPE NCC "signing away a previously un-signed-away resource", a problem it shares with RPKI, for which it was proposed there would be sanity checks in place. In the above, more than sanity checks are required to keep the ddb correct, however. Interesting topic that. If anything similar has been proposed before, I must have missed it.
... and that would be a hierarchical attestation following the allocation/assignment hierarchy.
(Of course, my friends would know that I'm to be trusted, and could point a local trust anchor my way, but how would a network on the other end of the world know that?)
See ddb above. Kind Regards, Martin