the problems being solved -- or not

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