Re: the problems being solved -- or not
Pekka, First of all, if you are assuming that NO ISPs make use of prefix filters, then you would be incorrect. There are those that try very hard to make use of such filters. However, we do not have 100% deployment of those filters. Since we will never see 100% deployment of such filters, we will continue to have mistakes or attacks floating around within the routing system. For the ISPs that are sufficiently concerned, it would be very nice if they could have an automated mechanism that could authenticate the information that they've recevied via BGP. Not all ISPs will enable this mechanism either, but some will, and they and their customers will gain some advantage by doing so. Just because this mechanism will never see 100% deployment is not a reason to discard the remainder of the benefit that can be had. > And managing the certificates, processing them, , would be > significantly easier? Yes, since more of this can be reasonably automated in a general way, rather than a set of ad hoc hacks. Tony
Re: the problems being solved -- or not
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 Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: the problems being solved -- or not
Pekka Savola wrote:
On Mon, 23 May 2005, Tony Li wrote:
Which is EXACTLY why we need to remember that we are NOT trying to come
up with the perfect solution. We have operational issues *TODAY* that
we are trying to address.
- We have people (admittedly accidentally) advertising prefixes that
they do not own and thereby overloading BGP. See the talk at the
latest NANOG.
- We have people intentionally out there forging /24's as an attack.
- We have OTHER people out there flooding the networks with their /24's
so that they are less vulnerable to attack by forged /24's, and
thereby exacerbating the BGP overload problem.
I think it's also worth considering where we expect this mechanism to be
deployed to be useful.
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.
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)}.
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.
pt
Re: the problems being solved -- or not
Let's look at Tony's points above. These solutions cannot deal with the last case, i.e., the "owner" of the prefix decides to advertise more specifics (and the ISPs pass that crap through). Then we're left with attacks where someone else advertises an equal route, or someone advertises a more specific. One of the various policies available within the soBGP specs is the ability for the owner of an address block to state: "The longest prefix within this block will be /x." This means that if you own 10.1.0.0/16, you can say: "The longest prefix length within 10.1.0.0/16 will be a /17." Or you can say: "The longest prefix within 10.1.0.0/17 will be a /18, and the longest within 10.1.1.0/17 will be a /20." Now, if someone attempts to steal your traffic by advertising a longer prefix, anyone actually checking would toss their routes. Yes, you could advertise the same length, of course, but then, if the origin doesn't match, and/or the AS Path is bogus, they're toast, as well. :-) Russ __ [EMAIL PROTECTED] CCIE <>< Grace Alone
the problems being solved -- or not
On Mon, 23 May 2005, Tony Li wrote: Which is EXACTLY why we need to remember that we are NOT trying to come up with the perfect solution. We have operational issues *TODAY* that we are trying to address. - We have people (admittedly accidentally) advertising prefixes that they do not own and thereby overloading BGP. See the talk at the latest NANOG. - We have people intentionally out there forging /24's as an attack. - We have OTHER people out there flooding the networks with their /24's so that they are less vulnerable to attack by forged /24's, and thereby exacerbating the BGP overload problem. I think it's also worth considering where we expect this mechanism to be deployed to be useful. 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. Let's look at Tony's points above. These solutions cannot deal with the last case, i.e., the "owner" of the prefix decides to advertise more specifics (and the ISPs pass that crap through). Then we're left with attacks where someone else advertises an equal route, or someone advertises a more specific. 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. It certainly seems that "hardened BGP" doesn't do much good for the ISP-endsite security, and little good for transit-ISP security.. So, I guess I must ask -- if prefix lists haven't been deployed, why would this be? -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
