So -- what did happen to Panix?

Fri Feb 3 19:15:45 UTC 2006

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

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:
http://www.equinix.com/prod_serv/network/ed.htm

-Nick