Sometimes earlier this year someone announced this 128/1 and caused heavy loading to our routers to rebuild the CEF.
Would anyone filter out this route (and other similar routes such as 0/1, 128/1, 0/2, 64/2, .... up to /4, for example) as bogus routes?
Sometimes earlier this year someone announced this 128/1 and caused
heavy loading to our routers to rebuild the CEF.
Would anyone filter out this route (and other similar routes such
as 0/1, 128/1, 0/2, 64/2, .... up to /4, for example) as bogus routes?
Would anyone not filter those routes? Why wouldn't you filter to /7?
Every growing season, a new crop of network engineers falls fresh from
the tree, and must be picked up, polished, and clue imparted on the
way to market.....
Well, then don't snip the most important clue in the post:
Because you fear that their routers that distribute the feed could become own3d and used to cause a massive DoS by filtering out some networks?
You asked. And I use their route feed.
I figure it a problem occurs, 1)I won't be the only one that has that problem 2)I'll hear about it on NANOG.
I figure the minute risk is worth the convenience....the chances of their routers getting 0wn3d are probably about the same as my routers getting 0wn3d. The chances of it happening aren't zero, but probably pretty small. Enough so that it sure beats editing the BOGON list manually!
Because you fear that their routers that distribute the feed could become own3d and used to cause a massive DoS by filtering out some networks?
Then use the static list, just be sure to update it frequently.
You asked. And I use their route feed.
I figure it a problem occurs, 1)I won't be the only one that has that problem 2)I'll hear about it on NANOG.
I figure the minute risk is worth the convenience....the chances of their routers getting 0wn3d are probably about the same as my routers getting 0wn3d. The chances of it happening aren't zero, but probably pretty small. Enough so that it sure beats editing the BOGON list manually!
I'd guess the Cymru team is less likely to be hax0r'ed. But that's just 'cause I'm afraid of them. (Especially if Rob's had coffee recently. Which means I'm always afraid of them.
Someone in the NANOG community, I forget who now, had the sensible
suggestion that you create a filter list based on the bogon list at
the time you setup your feed. You use that to limit what you will
accept from Cymru. Since bogon blocks will only get allocated, the
worst that could happen is the breaking of a recently allocated bogon
network. Even if you don't update your filter list for the next 5
years the damage is likely to be minimal.
I'd guess the Cymru team is less likely to be hax0r'ed. But that's just 'cause I'm afraid of them. (Especially if Rob's had coffee recently. Which means I'm always afraid of them.
I don't think Team Cymru offers a "feed" of what is supposed to be in
the routing table. 128/1 isn't a bogon. It's not even that useful
for hijacking adress space.
The correct approach would be to verify prefixes using somewhat
indepedent. more static data, such as RPSL data from RIRs. The old
blacklist vs. whitelist discussoin. (I know that creating a useful
whitelist is a huge tsak.)
The correct approach would be to verify prefixes using somewhat
indepedent. more static data, such as RPSL data from RIRs.
That might be more correct in theory, but in practice it depends on RPSL data stored by RIRs being accurate. Although this is a reasonable dependency in some corners of the network, it's entirely impractical (on its own) if you're seeking to filter a full table.
As one of many contributing hints to whether a particular filter is worth accepting, it might be useful though (along the lines that SpamAssassin doesn't necessarily reply on any one reason to brand a message as spam, but builds a score based on all kinds of tests). There was a relevant presentation in LA: