Hi Gert, On Tue, May 10, 2011 at 4:54 PM, Gert Doering <gert@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