Re: [db-wg] re-evaluate route-object authorisation model
Job Responding to the Questions in your 13 May email, thanks for helping me get up to speed. | - should the authorisation model work differently for RIPE managed | space versus non-RIPE managed space? Should we even continue to | allow route-objects covering non-RIPE managed space? No. Authorisation for an AS to originate a route needs to come from the maintainer of the address space. If the address space is assigned by a different RIR then Creating a Route Object in RIPE should be disallowed. Legacy v4 may need special case, I do not know. However, a global routing information database will need to contain copies of information from other regions, but it would support no modification of the copied records. Mirror only. | - should the authorisation model work differently when creating a | route-object for RIPE managed space with a non-RIPE managed | autnum? If yes, how so? No. We should follow the more recent thinking behind RPKI: "the design of the rpki is that an address resource holder is the sole authority over what ASs may announce that resource", Randy Bush | - although in this idea the autnum owner is no longer required to | approve /creation/ of a route-object, would it be a good idea to | allow the autnum owner to /delete/ any route-object in which their | autnum is referenced as origin? I see no need, since the AS still has the choice whether or not to announce the route. The database grants authority, not compulsion, to announce. | - Is RFC 2725 the only reason why the authorisation model was | implemented as it was implemented, can someone remember practical | reasons for doing it this way? During the BoF it was pointed out | that any potential DoS vector already exists today. Wilfried Woeber's concerns in 2006 seem largely to be about accreditation and authority of what is now the inetnum maintainer. Those concerns may still be valid, and may need addressing, but are not directly related to this discussion. The worst examples of IRR seem to have many exploitable faults independently of this. Our objective is to inspire confidence in RIPE's routing database for use in routing policy, to facilitate the completeness of the routing database by reducing a hindrance to maintaining its correctness, whilst retaining the higher standards adopted in RIPE. Steve Nash
If the address space is assigned by a different RIR then Creating a Route Object in RIPE should be disallowed.
sigh, let's try once more o there are operators at euro ixen which require peers' routes be registered in ripe irr. we don't have to like it, it's just business; get over it. o there are folk who peer at those same ixen whose address space was not assigned by ripe ncc. no one said that turning a sow's ear into a silk purse was easy. randy
On Fri, Jun 26, 2015 at 08:14:49AM +0900, Randy Bush wrote:
If the address space is assigned by a different RIR then Creating a Route Object in RIPE should be disallowed.
sigh, let's try once more o there are operators at euro ixen which require peers' routes be registered in ripe irr. we don't have to like it, it's just business; get over it. o there are folk who peer at those same ixen whose address space was not assigned by ripe ncc.
Which IXPs? You are referring to route servers? In November 2014 the group had some on and offline discussion about setting a different value for the "source:" attribute in case the space covered by the route-object was non-ripe-managed. https://www.ripe.net/ripe/mail/archives/db-wg/2014-November/004421.html I still think this is a sound idea and am waiting on some external factors to make this reality. Kind regards, Job
On 26/06/2015 00:14, Randy Bush wrote:
o there are operators at euro ixen which require peers' routes be registered in ripe irr. we don't have to like it, it's just business; get over it.
from the point of view of ixp operations, insisting in ripe-irr is neither necessary nor a good idea. Nick
o there are operators at euro ixen which require peers' routes be registered in ripe irr. we don't have to like it, it's just business; get over it.
from the point of view of ixp operations, insisting in ripe-irr is neither necessary nor a good idea.
i gave up trying to explain that to peers a long time ago. and note that, with one mouth, job has said that the ripe irr is the only one he will trust. randy
On Sat, Jun 27, 2015 at 05:54:08AM +0900, Randy Bush wrote:
o there are operators at euro ixen which require peers' routes be registered in ripe irr. we don't have to like it, it's just business; get over it.
from the point of view of ixp operations, insisting in ripe-irr is neither necessary nor a good idea.
i gave up trying to explain that to peers a long time ago.
I wouldn't mind reaching out to those 'euro ixen' you mentioned. Can you either onlist or offlist tell me?
and note that, with one mouth, job has said that the ripe irr is the only one he will trust.
Unsure if i follow you exactly, but indeed, I only trust the RIPE IRR when it comes to RIPE managed space. Kind regards, Job
participants (4)
-
Job Snijders -
Nick Hilliard -
Randy Bush -
snash