North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: So -- what did happen to Panix?
> > Hasn't that been said for years? Wouldn't perfect IRRs be great? I > > couldn't agree more. But in the meanwhile, why not protect your own > > ISP by delaying possible misconfigurations. Our proposed delay does > > *not* affect reachability, if the only route left is suspicious, it > > will be chosen regardless. > > Depending on the threat model, then, one attack would be to cause an AS > to damp the non-suspicious route. This seems bad, right? A flapping, > correct route seems better than a stable, suspicious one. A flapping route would only be considered suspicious if it disappears for many consecutive days and no other known route for the prefix originates at the same AS. At which point the attacker has already won. Our primary concern is with keeping BGP stable until its replacement (e.g. sBGP) is ready for deployment. > Perhaps I am missing something, but how does imposing a delay help in > ascertaining a route's correctness? Even looking at some of the > "suspicious" routes I see by hand in the anomalies we detect, I can't > personally tell what's incorrect/actionable vs. simply unusual (again, > this goes back to the problem of inaccurate registries). In the case of > Panix/ConEd, I can imagine that an operator would have responded to the > alarms, checked the registry information and said, "these routes look > reasonable; go for it!" Or, as human nature suggests, the operator > might have even just ignored the alarms (particularly if origin changes > are as frequent as they seem to be). Ascertaining correctness is only half of the work. If you correctly classify a malicious route, but do not take some measure to prevent its spread, you have just done yourself and your customers harm. In the case of PGBGP, there is a lot that an operator can do to verify correctness. Multiple viewpoints of anomalous routes can be collected into a single database in which operators can, once per day, check to make sure that their own address space is not being announced elsewhere. This can easily be automated for both the NOC and the collection process. Relationship information need not be revealed as only the originator of the suspicious route is needed. If, in the worst case, the route is not detected as malicious before it is considered normal, the next wave of routers will be introduced to the route and consider it suspicious. The first wave will then notice the problem and fix it, still protecting a significant portion of the network. Josh