Lazy Engineers and Viable Excuses

Tue Aug 26 10:58:45 UTC 2003

> If folks want to filter, please, please, PLEASE, employ IRR 
> infrastructure and filter customers *AND* peers explicitly. 
> If your vendors have issues with this, push them to fix it. 
> Then you don't have to worry about bogons, max-prefixes, 
> route hijacking, de-aggregation, or...
> 
> Then we can worry about IRR infrastructure hardening and 
> accuracy and derive explicit data plane filters from the 
> output, as well as other tangible benefits.
> 
> Is it really that hard?

I can see not filtering peers if the hardware can't handle it, but there
doesn't appear to be such a good excuse for not edge filtering.  If
Barry Green is listening out there, I'd be interested to hear how
successful he and his team have been at convincing ISPs to do this.  I
know he's been on his ISP Security Best Practices world tour for quite a
while now, and am curious if he's found it more difficult to get edge
filtering implemented vs. other security measures (and if so, why) or if
it's just security in general that's difficult to get ISPs to do.

Also, are recommendations given for how edge filters should be
maintained?  This was discussed here a short while ago but I don't think
a broad consensus was reached.  The mere existence of the filters is
nice to prevent AS7007-like incidents but does little to prevent other
bad things such as address hijacking if the customer (or someone posing
as the customer?) can call the ISP and get holes punched in a filter for
address blocks that he/she has no business announcing.  It seems that a
common practice amongst ISPs who do filter on the edge is to blindly
punch holes in these filters when asked without somehow "validating" the
request.  Does this negate a significant portion of the advantages
gained by edge filtering or are we primarily concerned with
accidental/malicious route table leaking at this point?

-Terry