nanog mailing list archives
Re: the problems being solved -- or not
From: Pekka Savola <pekkas () netcore fi>
Date: Tue, 24 May 2005 19:57:38 +0300 (EEST)
On Tue, 24 May 2005, Pete Templin wrote:
Let's take RIPE, RADB, etc. databases as an example. Apparently we can't count on the ISPs filtering out crap from their customers, because otherwise we'd never have had these attack. Also apparently, we can't count on the transit ISPs from weeding out the cruft that their ISPs spew in their direction and then to everyone else.Two of Tony Li's points (accidentally advertising prefixes and forging prefixes as an attack) have nothing to do with ISPs filtering out crap from their customers. The talk at NANOG demonstrated that peering ISPs were vulnerable to the cruft from the offending ISP, not (just) transit ISPs.
I mentioned two cases; I should have listed this as well (peering between two ISPs) as well. It's exactly the scenario what the route registries are/were for.
So, what can you do? Everyone must process their incoming full Internet feed and filter out bogus advertisements. Prefix lists based on RIPE, RADB, etc. could block the more specific, but not an equal length prefix.Prefix lists aren't the (whole) solution. The solution must check the {prefix, origin AS} correlation, and may check a subset of {prefix, origin AS, AS path, peer AS policy, (intermediate AS policy(ies)}.
Prefix lists as generated from the registries are built based on AS numbers, so there is already a degree of correlation between the prefix and the AS. Currently you just can't disambiguate between "your peer who is authorized to route 8.0.0.0/8 sent it to you, but it was originated by an unauthorized party inside that peer's network" and "your peer sent a correct 8.0.0.0/8 prefix". Such disambiguation may be useful, but it goes (IMHO) beyond the basic requirements.
I'm not sure whether AS9121 would have been prevented or mitigated with prefix filters. I guess that depends on what AS9121's upstreams (in the path towards the affected networks) are allowed (by the routing registry) to advertise.
So, I guess I must ask -- if prefix lists haven't been deployed, why would this be?Probably NVRAM constraints or ability to decipher the RIR tools to make a functional policy implementation. But see above, as prefix lists would NOT have solved the AS9121 problem, as was pointed out.
And managing the certificates, processing them, ...., would be significantly easier?
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Current thread:
- Re: soBGP deployment, (continued)
- Re: soBGP deployment Geoff Huston (May 23)
- Re: soBGP deployment Russ White (May 23)
- Re: soBGP deployment Tony Li (May 23)
- Re: soBGP deployment Alexei Roudnev (May 24)
- Re: soBGP deployment Randy Bush (May 23)
- Re: soBGP deployment bmanning (May 23)
- Re: soBGP deployment Tony Li (May 23)
- the problems being solved -- or not Pekka Savola (May 24)
- Re: the problems being solved -- or not Russ White (May 24)
- Re: the problems being solved -- or not Pete Templin (May 24)
- Re: the problems being solved -- or not Pekka Savola (May 24)
- Re: the problems being solved -- or not Tony Li (May 24)
- Re: soBGP deployment Randy Bush (May 24)
- Re: soBGP deployment Tony Li (May 24)
- Re: soBGP deployment Daniel Karrenberg (May 25)
- Re: soBGP deployment Tony Li (May 25)
- Re: soBGP deployment Jeroen Massar (May 26)
- Re: soBGP deployment william(at)elan.net (May 26)
- Re: soBGP deployment Todd Underwood (May 26)
- Re: soBGP deployment Bill Woodcock (May 26)
- Re: soBGP deployment Bill Woodcock (May 26)