North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Public shaming list for ISPs announcing other ISPs IP space by mistake
On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote: > On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote: >> On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote: >>> >>> The italian courts seem to have told ISPs there to block ThePirateBay >>> (bittorrent tracker), and this evening (CET) LLNW (AS22822) >>> originated >>> 188.8.131.52/24 via 6762 (telecom italia) to what I presume is most of >>> Europe. >>> >>> Basically same thing that happened when people tried to block >>> YouTube a >>> few months back (afghanistan?). >>> >>> How do we hinder this in the short term? I know there are a lot of >>> long >>> term solutions that very few is implementing, but would the fact that >>> these mistakes are brought up into the (lime)light by a public >>> shaming >>> list make ISPs shape up and perform less mistakes? >>> >>> I am still waiting for a response from LLNW NOC on the issue. >> >> Sure. I'd also like to see providers actually just shut >> off customers that originate stuff like ms-sql slammer >> packets still. But it keeps flowing. I'm sure there are >> smurf amps and other badness still going. codered anyone? >> >> these are all issues, but operational? depends. > > I beg to differ, this is absolutely operational. So, I should shut down or depeer networks that continue to originate the crap to me? (packets, announcements). >> If LLNW is not being filtered by telecom italia, time for >> 6762 to fix that. If they persist, will you depeer them >> as a security risk until they clean up their act? > > De-peering won't help if someone is propagating it as a transit customer > route. Filtering the prefix is all you can do. Taking this example, if I were to depeer 6762 becuase they can't keep their routing table clean to me, I suspect they would look at how to fix the issue. I could just filter their as-path globally until they contact me to resolve the issue. I'm not saying I would actually do that, but there is a question of what level of action should be taken to resolve these issues, and a timescale for their resolution. I've found some networks excellent to work with, and others "we'll stop leaking to you in a few days once we finish escalating the issue to our tier-n NOC in XXX city". Honestly, I find that to be kinda lazy considering how critical the routing infrasturcture is for our survival as an industry. > P.S. Obligatory BCP38 shout-out, even though it's not exactly on-point. I can't agree with this more, If you're not doing u-RPF on your customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be. The only excuses are broken software or incapable hardware from your vendor. Sadly those last two seem to impair the ability to take these basic network security requirements into account for a network of any size. It'll help reduce the possible attack home-base for various spoofing attacks (including some DNS one, did you hear about it?) - Jared -- Jared Mauch | pgp key available via finger from jared@xxxxxxxxxxxxxxx clue++; | http://puck.nether.net/~jared/ My statements are only mine.