[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 4:54 PM, Gert Doering <gert at space.net> wrote:
> Hi,
>
> On Tue, May 10, 2011 at 01:25:21PM -0400, Martin Millnert wrote:
>> >  "I permit 195.30.0.0/16 to be announced by AS5539"
>> >  "I permit 80.81.192.0/22 to be announced by AS5539"
>> >
>> > [and needing some sort of document from RIPE NCC to say which
>> >  one is true]
>>
>> 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.
>
> Well, that's the IP resource assignment framework we have today: numbers
> are given out as long as they are needed, and given back when they are
> no longer needed (or under special circumstances, e.g. fraud involved).

Yes, I agree with your description of the current model. And maybe it
can be an healthy exercise to consider alternative solutions, if only
to broaden the horizon a little on threats / possible mitigations, or,
to reinforce the perception that what we do have is the best of what
we can accomplish.

There will soon be virtually no IPv4 for the RIRs to give out, despite
need. And if we please may save ourselves from a "Internet Fairness
Re-appropriation and Re-assignment Committe", clearly money will play
a role in assessing IPv4 holders relative needs of address blocks in
the future. Considering legacy resources, these may well trade hands
without the involvement of a RIR if it is seen as too
complex/expensive/pointless.  So even if RIR transfer policy is
infinitely simple and free, we still have to worry about how to keep
transferred resources up-to-date in the registry. I understand that
resource certification may come to play a role in this too. (The ddb
solves this aspect too.)

> If you change that model to something where number blocks are actually
> traded ("Sold by the NCC to entity A, which can do then with the numbers
> whatever it want, e.g. sell to entity B without registering with the
> RIPE NCC"), the model would look different - and a trade could, for example,
> be done in your model by adding an "eternal signature" to the hand-over
> XML blob.

I imagine something like that could be done, yes.

> So, assuming we want to keep the existing model of number resource
> allocations from the RIRs (and giving them *back* to the RIRs eventually),
> what can we do to have that reflected in whatever attestation system?

First, I think it is quite hard to combine the goals of having the
ability to revoke resources, with a fault-tolerant hierarchical
routing registry/security system.
Second, yes, we can polish up copies of resource certifications, even
have lots of independent copies of them, and even the RIR data, but as
long as resource registrations may be changed in the original registry
without a method of rejecting unfortunate changes, we're left with
copies of the duplicated data that over time increasingly will be
disagreeing with the registry data.  Thus, if ever so slowly, we will
move towards a somewhat ad-hoc ("distributed") chaos model. ("with
t->\inf, quality(rir data) -> 0" points to a flaw in the model IMHO.)

I think Sander and Rob started up on a good trail, when working within
the current model of number resource allocations, by having emergency
exit-strategies.  But it's hard to see how this can work in practice
without some effective method to implement them.

I do like the LTA magic of rewriting the root (or somewhere else) of a
hierarchical system onto yourself.  As I've expressed before, if the
community does end up going for RPKI, I'd seriously like to see more
software which can cook up alternative trees, ignoring certain
changes, comparing source data trees and so on and so forth. (diluting
accuracy of RIR data)

> It should be pointed out that the nice folks over at the anti-abuse WG
> would scream bloody murder if they hear about the notion of resources
> being given to spammers, scammers, phishers and whatnot, with no way
> to take them back...  (and that's not "LEA type" anti-abuse folks, but
> "netizen" anti-abuse folks).

If a network wants to filter out certain prefixes they have the choice
of doing so, right? Not sure how this is at all relevant in an
automated filtering world of free choice.

Kind Regards,
Martin