North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: So -- what did happen to Panix?

  • From: Nick Feamster
  • Date: Fri Feb 03 14:18:49 2006

Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your

-certified prefix ownership
-certified AS path ownership
-dynamic changes to the above two items

It seems to me that most of the pieces needed to do
this already exist. RPSL, IRR softwares, regional
addressing authorities (RIRs). If there are to be
certified AS paths in a central database this also
opens the door to special arrangements for AS path
routing that go beyond peering, i.e. agreements with
the peers of your peers.
It is true that most of the pieces do exist. The problem appears to be not a want of tools, but the fact that the tools are not coupled properly---updating records about prefix ownership is, today, performed out-of-band from the routing protocol.

This is a losing proposition. The data in the IRR, CA, or any mechanism that is updated out-of-band from the protocol itself will inherently be out-of-sync.

A better idea, I think, would be to tie the identifier of the route something that is inherently bound to some cryptographic information (e.g., a public key), rather than a separate piece of information whose ownership must be "certified" (i.e., an IP prefix, an AS number).

I can think of some great ways to do this, but they all involve varying degrees of departure from prefix-based routing. I would certinaly be interested in talking offline about this with any forward-thinking types.

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.

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

What is really needed, in any case, is a better way to determine the route's veracity. This still requires some auxiliary mechanism to distinguish "unusual" from "suspcious", and, while you're designing that auxiliary mechanism, it might as well be in-band (per the arguments above).

> If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker: