On Fri, Nov 14, 2014 at 11:06:59AM -1000, Kaveh Ranjbar wrote:
On 14 Nov 2014, at 10:26, Nigel Titley <nigel@titley.com> wrote:
I'm sorry, I don't understand what you mean with less "secure" routing table in this context. Can you elaborate? Or maybe give an (hypothetical) example?
I'm not sure but this sounds like Kaveh thinks that ISPs perform negative filtering whereas, at least in my experience they perform positive filtering, which will be made *more* secure.
To my understanding, these are the three scenarios where most operators make their routing decision:
1- Route is seen and is in the IRR: Provider accepts it.
2- Route is seen but differs from IRR: Except if the received route is a subset of IRR object, it is rejected.
3- Route is seen and is absent in IRR: Provider rejects if the route is coming from a downstream provider, accepts it otherwise.
So, if we change the RIPE Database default behaviour to return "%ERROR:101: no entries found” when they run their trustworthy scripts, they will get less route objects, which will in practice downgrade some of the cases which would have caught by strategy (2) and rejected to the category (3) and accepted. This is where if we only make this change on the server side, we have made the system less useful.
Yes, the purpose of this proposal is that with "-s RIPE" added to queries, _less_ route objects are returned, as foreign objects are excluded. Autopilot scripts most likely will not query with "-s RIPE", I don't worry about those, for autopilot networks the behaviour of the database will not change. People that explicitly seek certain sources of information (like some IXP operators for their route servers) will benefit from the change. Looking at tooling: bgpq3's default behaviour will not change.
As I have written to routing-wg, I just wanted to point out that these kinds of changes should accompany provider behaviour and toolset changes as well. Without them, they will have no effect, if not negative. If we have the commitment in the operator space and toolset provider space, this can be a very positive change towards better data quality.
Can RIPE NCC provide more information on how many route objects have been created that do not belong to RIPE NCC administrated space or ERX space? I did find ~ 12.000, but that was only because of that specific "mnt-by:" attribute. If people remove that attribute, as an external observer I cannot find the foreign route objects easily. Kind regards, Job