[address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)

Hi Gert,

On Tue, May 10, 2011 at 11:47 AM, Gert Doering <gert at 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