Re: So -- what did happen to Panix?

From: Josh Karlin (no email)
Date: Fri Feb 03 2006 - 16:55:50 EST

  • Next message: Randy Bush: "flow -> web"

    > > 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


  • Next message: Randy Bush: "flow -> web"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD