[anti-abuse-wg] RIPE policy

> While the attribute may be good for informational and RIPE NCC policy-wise use, it is however unusable for any system that partition end-users/sites into particular ranges of ip-space such as blacklists and other types of restriction sysems.
> 
> If I write assignment-size 112 on my /48-block in the ripe db I can pretend to come from a billion companies. A system that believed that the assignment-size was indeed 112 could be subject to abuse. Therefore the problem remains and we still have to treat a /48 as equal to /128. This might force anyone to use /48 instead of /64, /96, /112 or whatever prefixlength that works for you. Perhaps that is good.

That's not the way it works, or at least that's not how it's intended to work. Unless we've overlooked some vital part in designing this system, in which case please explain and we'll find a drawing board again.

You can't easily set 'assignment-size: 112' on 'your' /48. The trick here is that it's your provider who sets it and not for individual assignments, but for a whole bunch in one go. Basically what they say is "In this block, any subnet of size X can be considered a single end site".

This won't work for PI assignments as per policy you shouldn't sub-assign those blocks. So although not up to me to decide, I can imagine any PI block with an assignment-size attribute might raise some questions. In fact the database should prohibit the creation of such an object, because it can be considered invalid.

So the only reasonable way to implement the situation you sketched is to ask your provider for a sub-allocation, instead of an assignment. While adding your maintainer to it and allow you to create the appropriate objects and attributes on or under the sub allocation.

I think the quick start manual for this would read something like:

"Do a lookup, if status is set to AGGREGATED-BY-LIR you can trust the assignment size and act accordingly. If status is 'ASSIGNED' use the object itself as an aggregation point. If in any other status you encounter the assignment-size attribute take it as a hint, but feel free to use your own aggregation scheme."

And as a concerned citizen,  one could add:

"Never aggregate above the size of the most specific database object or even never aggregate above the /64 level when in doubt. This will prevent collateral damage to other users and the reputation of your *list".

Now of course this is the way it works in the RIPE region. As I said before any attempt to copy this to another RIR would mean you have to take the 'local' situation into consideration and adjust the proposal where necessary.

Grtx,

Marco