source: field for non RIPE address space
Hello, There's been a bit of media panic recently about registration of non RIPE address space in the RIPE IRRDB, e.g.
http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-looph...
The premise is that if you can register a prefix in a routing registry, this will give you the ability to inject a prefix into the DFZ. We'll ignore the fact that what you actually need to inject a prefix into the DFZ is a complicit transit provider and that most transit providers don't use the IRRDBs for bgp leaf filtering anyway, and even if they did, there are plenty of other IRRDBs where this information can be registered. But that aside, some organisations use IRRDB information extensively, particularly IXPs running route servers. Many of these organisations filter on source: because of the amount of trash in alternative IRRDBs. So, could the RIPE NCC database people consider using a different source: value for non RIPE address space, so that it would be possible for irrdb users to easily filter out authoritative data from non authoritative data? E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like "210.57.192.0/20" might have "source: RIPE-NONAUTH". Would this be feasible for the RIPE DB software? Interesting to note that Mega-Spred has started providing transit for Telstra Hong Kong, Sify in Chennai, iWay Africa in Cape Town and others:
% peval AS201640 ({210.57.192.0/20, 210.57.0.0/19, 202.39.112.0/20, 119.227.224.0/19, 105.154.248.0/21, 41.198.224.0/20})
Nick
On Fri, Nov 14, 2014 at 11:15:22AM +0000, Nick Hilliard wrote:
<snip>
But that aside, some organisations use IRRDB information extensively, particularly IXPs running route servers. Many of these organisations filter on source: because of the amount of trash in alternative IRRDBs.
So, could the RIPE NCC database people consider using a different source: value for non RIPE address space, so that it would be possible for irrdb users to easily filter out authoritative data from non authoritative data?
E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like "210.57.192.0/20" might have "source: RIPE-NONAUTH".
Would this be feasible for the RIPE DB software?
I think this is a good idea. If we implement such a RIPE-NONAUTH source, I'd expect a query structered like this: $ whois -h whois.ripe.net -- "-K -s RIPE -Troute 210.57.192.0/20" to return "%ERROR:101: no entries found". Maybe another way of phrasing the feature request: anything created due to authorisation against the RIPE-NCC-RPSL-MNT object will have "source: RIPE-NONAUTH" set, instead "source: RIPE".? Do we expect a different split file on the FTP site for RIPE-NONAUTH objects? Kind regards, Job
On 14 Nov 2014, at 03:05, Job Snijders <job@instituut.net> wrote:
On Fri, Nov 14, 2014 at 11:15:22AM +0000, Nick Hilliard wrote:
<snip>
Would this be feasible for the RIPE DB software?
Hello, It should be doable in a reasonable amount of time.
If we implement such a RIPE-NONAUTH source, I'd expect a query structered like this:
$ whois -h whois.ripe.net -- "-K -s RIPE -Troute 210.57.192.0/20"
to return "%ERROR:101: no entries found".
Maybe another way of phrasing the feature request: anything created due to authorisation against the RIPE-NCC-RPSL-MNT object will have "source: RIPE-NONAUTH" set, instead "source: RIPE”.?
Job, the query you have outlined is very similar to the queries that IRRToolset sends. Doing that will basically result in a much smaller filter list which some providers might not even notice (depending on filtering strategy). This eventually might result in a less “secure” (for a lack of better word) routing table. If that is the desired outcome, why not. This is a clear example of the decision I am trying to put forward for the community in my last post to routing-wg.
Do we expect a different split file on the FTP site for RIPE-NONAUTH objects?
In my opinion, to be consistent, we should. All the best, Kaveh.
Kind regards,
Job
On Fri, Nov 14, 2014 at 10:10:58AM -1000, Kaveh Ranjbar wrote:
If we implement such a RIPE-NONAUTH source, I'd expect a query structered like this:
$ whois -h whois.ripe.net -- "-K -s RIPE -Troute 210.57.192.0/20"
to return "%ERROR:101: no entries found".
Maybe another way of phrasing the feature request: anything created due to authorisation against the RIPE-NCC-RPSL-MNT object will have "source: RIPE-NONAUTH" set, instead "source: RIPE”.?
Job, the query you have outlined is very similar to the queries that IRRToolset sends. Doing that will basically result in a much smaller filter list which some providers might not even notice (depending on filtering strategy). This eventually might result in a less “secure” (for a lack of better word) routing table.
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? Kind regards, Job
On 14/11/14 20:21, Job Snijders wrote:
If we implement such a RIPE-NONAUTH source, I'd expect a query structered like this:
$ whois -h whois.ripe.net -- "-K -s RIPE -Troute 210.57.192.0/20"
to return "%ERROR:101: no entries found".
Maybe another way of phrasing the feature request: anything created due to authorisation against the RIPE-NCC-RPSL-MNT object will have "source: RIPE-NONAUTH" set, instead "source: RIPE”.? Job, the query you have outlined is very similar to the queries that IRRToolset sends. Doing that will basically result in a much smaller filter list which some providers might not even notice (depending on filtering strategy). This eventually might result in a less “secure” (for a lack of better word) routing table. I'm sorry, I don't understand what you mean with less "secure" routing
On Fri, Nov 14, 2014 at 10:10:58AM -1000, Kaveh Ranjbar wrote: 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. Of course I may be completely off beam Nigel
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.
Hello, Sorry for not being clear. 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. 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. All the best, Kaveh.
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
On Fri, Nov 14, 2014 at 10:32:36PM +0100, Job Snijders wrote:
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.
*bump*
Hi Job, I checked all route objects in the RIPE database, against the delegated stats file for each region, and found which region the (IPv4) address space belongs in. RIPE: 185,537 ARIN: 7,609 AFRINIC: 37,683 LACNIC: 1,930 APNIC: 2,004 Regards Ed Shryane RIPE NCC
On 20 Nov 2014, at 14:17, Job Snijders <job@instituut.net> wrote:
On Fri, Nov 14, 2014 at 10:32:36PM +0100, Job Snijders wrote:
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.
*bump*
On Thu, Nov 20, 2014 at 03:03:49PM +0100, Edward Shryane wrote:
I checked all route objects in the RIPE database, against the delegated stats file for each region, and found which region the (IPv4) address space belongs in.
RIPE: 185,537 ARIN: 7,609 AFRINIC: 37,683 LACNIC: 1,930 APNIC: 2,004
Can you provide me with a list of all route objects which belong to ARIN, AFRINIC, LACNIC or APNIC in the following format (one prefix per line): $prefix/$subnetsize $origin_as $RIR Please generate this file for IPv4 and IPv6 route objects, based on the data from 20 November 2014. I'd like to correlate foreign route objects with a BGP RIB dump from the NLNOG RING. Kind regards, Job
On Thu, Nov 20, 2014 at 06:41:16PM +0100, Job Snijders wrote:
On Thu, Nov 20, 2014 at 03:03:49PM +0100, Edward Shryane wrote:
I checked all route objects in the RIPE database, against the delegated stats file for each region, and found which region the (IPv4) address space belongs in.
RIPE: 185,537 ARIN: 7,609 AFRINIC: 37,683 LACNIC: 1,930 APNIC: 2,004
Edward was kind enough to provide me with data dumps. I've run some simple seek & count code, comparing the route objects (and their real source) and the BGP table: Correct route object, prefix-length, origin which are visible in BGP DFZ: IPv6 IPv4 AFRINIC: 72 7146 APNIC: 17 498 ARIN: 264 4030 LACNIC: 11 1448 OTHER: 2 NaN RIPE: 6430 106081 Registered route objects which are NOT visible in BGP DFZ: IPv6 IPv4 AFRINIC: 95 31018 APNIC: 9 515 ARIN: 168 2694 LACNIC: 15 448 OTHER: 0 NaN RIPE: 3038 78393 Correct route object prefix length, wrong origin & visible in BGP DFZ: IPv6 IPv4 AFRINIC: 7 582 APNIC: 3 1002 ARIN: 84 1085 LACNIC: 0 35 OTHER: 45 NaN RIPE: 357 10896 OK, so what does this mean?! If we proceed with our plan to set 'source: RIPE-NONAUTH' for objects, the prefixes from the first category (correct length & origin & visible) might be impacted. Roughly 13k prefixes, of which ARIN & AFRINIC are the largest. The real number might be lower as it is quite possible that route objects for those 13k prefixes exist in other registries as well. Curiously enough running those 13122 prefixes through aggregate(1), the set is shrunken down to only 3941 prefixes. So, what's next? Please share your thoughts & insights. Kind regards, Jobi ps. My data and crude scripts are available here: http://instituut.net/~job/correlate-route-objects-with-bgp-ripe/
Correct route object prefix length, wrong origin & visible in BGP DFZ:
is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward. randy
On Tue, Nov 25, 2014 at 08:28:55AM +0900, Randy Bush wrote:
Correct route object prefix length, wrong origin & visible in BGP DFZ:
is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward.
Yes, good remark. I have not attempted to figure out why those route objects are there. One could for instance take a wider time window for the BGP data (6 months?) and run the correlations to assess which are in transfer/mbb and which potentially are stale garbage. Kind regards, Job
Correct route object prefix length, wrong origin & visible in BGP DFZ: is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward. I have not attempted to figure out why those route objects are there.
is there a second route: object for the same prefix which is correct? randy
On Tue, Nov 25, 2014 at 08:35:56AM +0900, Randy Bush wrote:
Correct route object prefix length, wrong origin & visible in BGP DFZ: is this not legitimate in a make before break origin transfer? of course, many will forget to clean old up afterward. I have not attempted to figure out why those route objects are there.
is there a second route: object for the same prefix which is correct?
Quickly ran something for IPv4: {'AFRINIC': 99, 'APNIC': 10, 'ARIN': 112, 'LACNIC': 1, 'RIPE': 6200} This means there are 99 objects which fall within AfriNIC administrated space which have an origin not seen in the DFZ, but a _correct_ route object already exists. Kind regards, Job
Hi Kaveh, On 14/11/2014 20:10, Kaveh Ranjbar wrote:
Job, the query you have outlined is very similar to the queries that IRRToolset sends.
by default irrtoolset does not specify a source: list:
% peval -T all -h whois.ripe.net -protocol ripe as-inexie |& grep WriteQuery Whois: WriteQuery -k -V irrtoolset-5.0.1 -r -T as-set AS-INEXIE Whois: WriteQuery -k -V irrtoolset-5.0.1 -r -K -i origin AS2128
Nor does bgpq3, as far as I remember. Nick
Hi Nick,
So, could the RIPE NCC database people consider using a different source: value for non RIPE address space, so that it would be possible for irrdb users to easily filter out authoritative data from non authoritative data?
E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like "210.57.192.0/20" might have "source: RIPE-NONAUTH".
I think this might be a good way to get started on this issue.
Would this be feasible for the RIPE DB software?
I'll leave that to the RIPE DB guru's to answer. This might be a good way for transit providers who manually or automatically (scripted) check if a prefix AND a route Object was created as a result based on the RIPE-NONAUTH sources, resulting that the request to be flagged with big red flags. And they should ask their customers directly for proper LOA's ( to get started...)
Interesting to note that Mega-Spred has started providing transit for Telstra Hong Kong, Sify in Chennai, iWay Africa in Cape Town and others:
% peval AS201640 ({210.57.192.0/20, 210.57.0.0/19, 202.39.112.0/20, 119.227.224.0/19, 105.154.248.0/21, 41.198.224.0/20})
I've been looking at what AS201640 is currently doing and I noticed that they are currently not announcing anything .. At least I don't see it in our DFZ view.. And also RIPE STAT is reporting the same. So in short, this would have my support. Regards, Erik Bais
On Fri, Nov 14, 2014 at 11:15:22AM +0000, Nick Hilliard wrote: Hi
There's been a bit of media panic recently about registration of non RIPE address space in the RIPE IRRDB, e.g.
http://krebsonsecurity.com/2014/11/network-hijackers-exploit-technical-looph...
The premise is that if you can register a prefix in a routing registry, this will give you the ability to inject a prefix into the DFZ.
We'll ignore the fact that what you actually need to inject a prefix into the DFZ is a complicit transit provider and that most transit providers don't use the IRRDBs for bgp leaf filtering anyway, and even if they did, there are plenty of other IRRDBs where this information can be registered.
But that aside, some organisations use IRRDB information extensively, particularly IXPs running route servers. Many of these organisations filter on source: because of the amount of trash in alternative IRRDBs.
So, could the RIPE NCC database people consider using a different source: value for non RIPE address space, so that it would be possible for irrdb users to easily filter out authoritative data from non authoritative data?
E.g. 185.6.36.0/22 might continue to have "source: RIPE", but a prefix like "210.57.192.0/20" might have "source: RIPE-NONAUTH".
This is a good idea, taking into account comments made by Kaveh. We should not throw the baby out with the bathwater. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
participants (8)
-
Edward Shryane -
Erik Bais -
Job Snijders -
Kaveh Ranjbar -
Nick Hilliard -
Nigel Titley -
Piotr Strzyzewski -
Randy Bush