In the recent past, we've had another provider in our same market erroneously advertising prefixes for some of our customers. After we got it cleared up, I noticed that there were some old route objects in RADB that were entered for that provider years ago by 360. These route objects, in a sense, legitimized, the erroneous advertisements by matching the prefixes to that providers ASN. As that provider no longer uses 360/Zayo, I asked Zayo if they could remove the objects. Once the request made it to someone who understood what I was asking, they spent some time and effort over the next few weeks (much appreciated by me, I might add) in hunting down the info they needed to (I assume) manage the old 360 maintnr object. They then removed the offending objects (again, my thanks). One of the Zayo support folks mentioned to me, somewhat apologetically, that it took some time as nobody had ever made such a request before. So this got me wondering: is it really such a rare thing to manage ones route objects such that old defunct data is removed? I'm not under the impression that the issue I had would have been alleviated any by the related route objects having been removed beforehand, but their existence wasn't helping me any either. I've since found a disturbing number of defunct objects that relate to my customers (and me) in a similar way, and I have mostly had success in getting them cleared up. If my relatively small customer base is any indication, there are more incorrect objects out there than correct ones. I feel this is something I should have been looking into sooner. Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts? Sorry that this turned out so long; I wanted to give some context. --TimH
On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote:
I've since found a disturbing number of defunct objects that relate to my customers (and me) in a similar way, and I have mostly had success in getting them cleared up. If my relatively small customer base is any indication, there are more incorrect objects out there than correct ones. I feel this is something I should have been looking into sooner.
People tend to treat things like IRR (eg: RADB, etc) as a garbage pit you toss things into and never remove from.
Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts?
Yes it does. This has a fairly severe impact for those that build off the IRR data for filters. We have seen customers end up including AS7018 in their AS-SET or as you noticed have other legacy routes appear.
Sorry that this turned out so long; I wanted to give some context.
No worries. I've got a transient routing leak detector that does find/fuzz these issues which has been running for a few years now. I'm guessing you may see some of the related prefixes there as a result. It's in need of a U/I redesign (code welcome) but is located here: http://puck.nether.net/bgp/leakinfo.cgi - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch <jared@puck.nether.net> wrote: [snip]
People tend to treat things like IRR (eg: RADB, etc) as a garbage pit you toss things into and never remove from.
So who do we ask about making IRRs expire defunct objects and/or changing their system design to ensure that the legitimate resource holder can remove references to their prefix from ASes they no longer authorize to carry them, without requiring all sorts of assistance, cooperation, and willingness from the AS maintainer? :)
Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts?
Yes it does. This has a fairly severe impact for those that build off the IRR data for filters. We have seen customers end up including AS7018 in their AS-SET or as you noticed have other legacy routes appear.
-- -JH
On Sat, Nov 01, 2014 at 02:30:06PM +0900, Randy Bush wrote:
So who do we ask about making IRRs expire defunct objects
you might start with a rigorous definition of defunct
I have my own ideas on this topic, including routes that have not been seen for over 1 year. You may always miss the routes that are not 'seen' on the public internet though. I'm still reminded of the question on the internic forms in early 90s about "will you be connecting to the internet" when asking for address space. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On Sat, Nov 1, 2014 at 9:04 AM, Jared Mauch <jared@puck.nether.net> wrote:
On Sat, Nov 01, 2014 at 02:30:06PM +0900, Randy Bush wrote:
So who do we ask about making IRRs expire defunct objects you might start with a rigorous definition of defunct
I have my own ideas on this topic, including routes that have not been seen for over 1 year. You may always miss the routes that are not 'seen' on the public internet though. I'm still reminded of the question on the internic forms in early 90s about "will you be connecting to the internet" when asking for address space.
Do the internet route registries exist to track routes that are not to appear on the public internet? I think not. There should probably be an attribute provided for such objects, however, that would indicate "This route does not appear on the public internet". If not tagged like that in some manner, and a matching route does has not appeared on the public internet at any time during the past 6 to 12 months, then I would consider the registry object to be defunct.
- Jared
-- -JH
Jimmy Hess <mysidia@gmail.com> writes:
Do the internet route registries exist to track routes that are not to appear on the public internet? I think not.
What's "the public Internet"? Does it mean "the DFZ as seen at Jimmy Hess' router, with his set of upstreams"? If so, I can assure you that there are plenty of routes that need to pass filters that are (or optimally would be) built off of IRR data that would not pass this test.
There should probably be an attribute provided for such objects, however, that would indicate "This route does not appear on the public internet".
see above. :)
If not tagged like that in some manner, and a matching route does has not appeared on the public internet at any time during the past 6 to 12 months, then I would consider the registry object to be defunct.
Where on the public Internet? Do networks run by organizations such as SITA, ARINC, BT Radianz, UK MOD, and US DOD that use globally unique space and may interconnect with each other in some way (and could hypothetically be using IRR-type structures to describe that routing policy though I don't think the military does that) get their objects unceremoniously booted? -r
On 1 November 2014 23:18, Rob Seastrom <rs@seastrom.com> wrote:
Where on the public Internet?
Do networks run by organizations such as SITA, ARINC, BT Radianz, UK MOD, and US DOD that use globally unique space and may interconnect with each other in some way (and could hypothetically be using IRR-type structures to describe that routing policy though I don't think the military does that) get their objects unceremoniously booted?
Why would I want routes from US DOD in my filters, if this stuff is not supposed to be on the public internet? That is a waste of everyones ressources. Regards, Baldur
Baldur Norddahl <baldur.norddahl@gmail.com> writes:
On 1 November 2014 23:18, Rob Seastrom <rs@seastrom.com> wrote:
Where on the public Internet?
Do networks run by organizations such as SITA, ARINC, BT Radianz, UK MOD, and US DOD that use globally unique space and may interconnect with each other in some way (and could hypothetically be using IRR-type structures to describe that routing policy though I don't think the military does that) get their objects unceremoniously booted?
Why would I want routes from US DOD in my filters, if this stuff is not supposed to be on the public internet? That is a waste of everyones ressources.
If you (and they) use the full capabilities of RPSL... you won't. -r
On Sat, 01 Nov 2014 14:30:06 +0900 Randy Bush <randy@psg.com> wrote:
So who do we ask about making IRRs expire defunct objects
you might start with a rigorous definition of defunct
I can come up with a number of examples, but the ones that concern me the most are route objects where the route should not (or should no longer) originate from the origin AS. Some of these that I found were probably never correct. I can detail what I think were the chain of events that led to their creation, but I'm not sure it would be On Topic. --TimH
On Fri, 31 Oct 2014 13:51:59 -0500 Jimmy Hess <mysidia@gmail.com> wrote:
On Fri, Oct 31, 2014 at 12:39 PM, Jared Mauch <jared@puck.nether.net> wrote: [snip]
People tend to treat things like IRR (eg: RADB, etc) as a garbage pit you toss things into and never remove from.
So who do we ask about making IRRs expire defunct objects and/or changing their system design to ensure that the legitimate resource holder can remove references to their prefix from ASes they no longer authorize to carry them,
without requiring all sorts of assistance, cooperation, and willingness from the AS maintainer? :)
I have been asking the folks who manage the maintnr object in question. I have so far been mostly successful. I spend varying amounts of time explaining myself... /Sometimes/ simply pasting the object in an email to the right person is all that is needed. --TimH
On Friday, October 31, 2014, Jared Mauch <jared@puck.nether.net> wrote:
On Fri, Oct 31, 2014 at 10:34:23AM -0700, Tim Howe wrote:
I've since found a disturbing number of defunct objects that relate to my customers (and me) in a similar way, and I have mostly had success in getting them cleared up. If my relatively small customer base is any indication, there are more incorrect objects out there than correct ones. I feel this is something I should have been looking into sooner.
People tend to treat things like IRR (eg: RADB, etc) as a garbage pit you toss things into and never remove from.
+1, it is a garbage pit Do whatever it takes to deploy today move on, dont look back or update, failover between isps fails, emergency update. Back to sleep If its not systematicly automated for grandma, it is broken and will only be patched by exception / interrupt
Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts?
Yes it does. This has a fairly severe impact for those that build off the IRR data for filters. We have seen customers end up including AS7018 in their AS-SET or as you noticed have other legacy routes appear.
Sorry that this turned out so long; I wanted to give some context.
No worries. I've got a transient routing leak detector that does find/fuzz these issues which has been running for a few years now. I'm guessing you may see some of the related prefixes there as a result. It's in need of a U/I redesign (code welcome) but is located here:
http://puck.nether.net/bgp/leakinfo.cgi
- Jared
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net <javascript:;> clue++; | http://puck.nether.net/~jared/ My statements are only mine.
participants (7)
-
Baldur Norddahl -
Ca By -
Jared Mauch -
Jimmy Hess -
Randy Bush -
Rob Seastrom -
Tim Howe