| 1 |
On Feb 19, 2012 1:27 AM, "Michael Mol" <mikemol@×××××.com> wrote: |
| 2 |
> |
| 3 |
> And every time that's successful, it's because some idiot admin wasn't |
| 4 |
filtering their incoming BGP traffic properly. Ditto the network in Florida |
| 5 |
which acted as a black hole for the entire Internet in the late 90s. |
| 6 |
> |
| 7 |
> Proper training and filtering helps prevent these kinds of issues. It's |
| 8 |
happened, sure. And it will happen again. And it will be recovered from |
| 9 |
again. Policies will be adapted, trained and forgotten, again. |
| 10 |
|
| 11 |
Not necessarily. BGP routers at network borders are already configured to |
| 12 |
filter practically all BGP traffic that do not come from their trusted |
| 13 |
neighbors. |
| 14 |
|
| 15 |
They have to be able to respond quickly to outages, to switch to another |
| 16 |
neighbor. |
| 17 |
|
| 18 |
In both incidents in the article, the causes are the same: misconfiguration |
| 19 |
(accidental or deliberate) of the China backbone router. This |
| 20 |
misconfiguration got propagated to the neighbor router, which are |
| 21 |
explicitly configured to trust the China backbone routers. |
| 22 |
|
| 23 |
Remember that, unlike IP addresses, AS numbers are not assigned |
| 24 |
hierarchically. So, impacted routers have no way to detect if the China |
| 25 |
router is actually authorized to route for the ASes it advertised (except |
| 26 |
directly connected ASes). |
| 27 |
|
| 28 |
Rgds, |
Archives