Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

RE: dsl providers that will route /24

  • From: David Schwartz
  • Date: Fri Mar 30 05:18:20 2001



> On Fri, Mar 30, 2001 at 12:20:22AM -0800, David Schwartz wrote:
> > 	Again, doesn't help you 5:30 on a Friday if the only person
> > who can log
> > into the router isn't there. If they're an OC3 government site
> > and you're a
> > small site whose T1 is being saturated, I don't think their provider is
> > going to shut them down.

> No, but they can modify their ingress filters to block the flood
> from transiting
> their network and hitting me.  (And still get paid by that government
> site
> for the priviledge ;)

	The time this actually happened, the ISP wouldn't do anything without
talking to the site contact. And, after all, I couldn't prove the packets
really came from their customer. (And who was I to tell them what to do? And
who was my customer representative? And what was my account number?)

	In fact, I couldn't even be positive the packets transited their network.
The origin site had more than one uplink at more than one point on their
network. There was no easy way for me to determine which of their possible
paths the traffic was taking and thus knowing who to talk to, other than the
origin site. The network admin there had just left for the weekend, and they
would page him.

	Perhaps things would be different now. This was circa 1997.

	The point is, an unspoofed attack can do as much damage as a spoofed attack
and can be almost as frustrating. I will admit, howover, that it is nicer to
know almost exactly who to blame (and, for that matter, who to sue if it
comes to that.)

	If the person who launches the attack has enough compromised hosts, you can
go crazy tracking them down one by one. One day more recently we got hit
with a DDoS attack that wasn't spoofed (or at least was mostly unspoofed).
We sent out over 100 emails and followed up by telephone for the highest
traffic sources. Fortunately, the traffic level was only about 20Mbps, but
it took it about a week to die down as we tracked down the administration of
each origin machine in turn.

	I'd love to see IP redesigned from the ground up with a view towards the
lessons learned to date. Of course that's just not going to happen. But I
think smaller structural or protocol changes might make a large dent.

	As an example, imagine if you could construct a filter 'block all traffic
with source IP X and destination IP Y' and your router could bubble the
filter close to the origin. For security, you would have to receive the
filter from the interface you would normally route traffic to Y to, and you
would 'push the filter up' any interfaces you received a matching packet on.

	How good an idea is that? Could it be implemented? What are the security
implications of it? Are there better ways?

	Or what if you could make a rule that said 'track all traffic with source
mask X and destination IP Y and report to IP Z'. This request would also
bubble up the same way and in a few minutes, you'd have a report of a list
of routers going closer and closer to the source. To automatically stop the
attack, you could make a filter (that also bubbled up) that blocked all
traffic to a particular destination IP but only as they transit the selected
routers. You would select one or two routers as high up on that chain as
possible (to block as little legitimate traffic as possible). And before you
know it, the spoofed attack would be both traced and filtered near its
source.

	That's the kind of effort that's going to have to take place if this
problem is ever going to be actually solved. All the ingress filtering in
the world won't solve the actual problems. Claiming it will discredits the
effort to find real solutions.

	DS






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.