Fwd: Re: Digital Island sponsors DoS attempt?

Paul Vixie vixie at vix.com
Sat Nov 10 18:38:33 UTC 2001

It took me a while to get back to this.  There's actually some operational
content this time.

> I don't have the AUP's in question so my speculation is going to be
> tainted.  I would probably have told them that I would continue announcing
> their route (with the known hole) and prepended the heck out of it
> to cause people to deprefer that prefix.

That wouldn't've solved the problem others have described here -- since
some people in some places would end up seeing that route.  The customer in
question was given several choices, and could have depref'd on their end,
or withdrawn the route from the session, or whatever.  The end result was
the maximum overlap between the interests of the route-owner and the
interest of the network-owner, and for that reason I deem the result to have
been the best success possible under the circumstances.

> Additionally, I might have added a new community 6461:foo and registered
> that info in the IRR saying that 6461:foo means that some customer is
> being abusive and you're protecting the Internet from them.

The network owner in question wasn't concerned with protecting the Internet
from anybody, it was protecting its own backbone from AUP-violating traffic.

> The point, I guess, is you're AUP wasn't propagated.  You can only
> enforce the AUP with your direct customer.

I must be missing that point, then.  Abovenet's AUP is a contract term with
every one of its customers.  It is applied at the point where the customer's
traffic enters Abovenet's backbone.  Where the traffic came from before that
and whose customers is downstream of whom is not even a tertiary concern
other than to ensure that whatever filters are in place are the bare minimum
needed to enforce the AUP.

No customer is ever allowed to point downstream and say "but the traffic that
violates the AUP didn't come from here, it came from a customer's customer."
When traffic violates an AUP, that traffic is subject to border filtering,
no matter how far downstream it might have come from originally.

> > (c) block traffic to/from the /24 in question after carefully notifying
> > the /16 owner that this would be done and why.
> This causes the least problems to your direct customer.  I can
> understand, from a business perspective, how this was the preferred
> option.  However, it punished those who used your routes and wanted
> <no-value-judgement> to reach ORBS </no-value-judgement> and rewarded
> your customer for lax AUP.

"Punish" is an interesting word and I reject its use here since its
definition requires that pain be a goal.  I know that some ill effects were
felt by some consumers of this route.  The owner of the route was given
choices, like "look here, see this bad traffic? it has to stop coming here,
so if you don't stop it on your side, we will have to stop it on ours, and
we have no technology available which would prevent our stoppage from having
a global impact, so you might just as well stop it on your side."

> > what would YOU have done?  justify your answer.  (show all work.)
> ...
> I'm asking/suggesting: Is this just a business issue?  Given the
> way the routing system works today are we going to see a lot more
> blackholes in the system?  Does the routing protocol need to be adjusted
> to deal with this business need or should the AUP deal with it?

I'm told that on some modern Cisco boxes it is now possible to drop traffic
based on its source rather than on its destination, but still feeding the
ACL from a distributive source (which is a "avibgp" session in AS6461's case).
I don't know whether Juniper can do this yet.  I hope so, or if not, soon.

Assuming that this technology comes into wide use, it will become possible
to block AUP-violating _packets_ rather than prevent AUP-violating _sessions_
from becoming established, which would make an ORBS-vs-Abovenet issue into
a strictly local event.  (The /16 netblock owner tried to send this /24's
transit through a non-Abovenet path, but since many of the destinations were
inside AS6461 and most of the SYN-ACK's came back through AS6461, this
didn't help as much as it should have.)

To your question, though, I think the answer is "yes."  We will see a lot
more blackholes in the system, because the technology needed to perform an
end to end policy verification before beginning a new session is on the same
order as "call setup" and there are just too many "calls" for a core of this

More information about the NANOG mailing list