the problems being solved -- or not
Pekka Savola
pekkas at netcore.fi
Tue May 24 16:57:38 UTC 2005
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
More information about the NANOG
mailing list