North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: So -- what did happen to Panix?
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.Wouldn't a well-operated network of IRRs used by 95% of network operators be able to meet all three of your requirements? -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.
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? IDepending 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
That process seems to be getting quicker: http://www.equinix.com/prod_serv/network/ed.htm -Nick