"Reverse routing" - a solution for spoofed packets

Spoofed packets may be used for everything from denial of service
attacks, breakins, session sniping, and cache-poisoning.

We were DDOS'ed again this evening. It was a spoofed SYN
flood. Not much harm came of it, but it, yet again, cost us a *lot*
of money. It was also larger and longer than most. Many of you
reading
this have felt it at one point or another. And many of you have found
out that the reason why these can occur is because of shoddy
egress filtering.

Clearly, the current system we have of allowing admins to put egress
filters on "whenever they feel like it" isn't working.

This "spoofing" problem typically affects people who host hundreds of
thousands of sites, or those with billions of hits, or those involved
in abuse prevention and security. If you run some corporate site that
gets a few thousand "hits per day", then you might have no
idea why I am whining about security and spoofing. If this is the
case, then this message is not for you, please feel free to ignore it.

Routers spend an inordinate amount of effort determining which
interface packets should be routed to. They should spend an *equal*
amount of time determining whether the packet should have come *from*
the interface they came in on.

The system we have now is tenuous at best, and anyone who says
otherwise knows very little about the larger security issues that are
at stake.

We at ZoneEdit are one of the few companies in a position to know
exactly how serious this threat is.

This "reverse routing" must be made a requirement of the entire
network, and not an option. I like to call it that to differentiate
it from "filtering". It needs to go beyond filtering. To make the
system truly work, we need routers to exchange reverse routing tables,
the same way they exchange forward routing tables. That is, lists of
ip's and the associated interfaces that the *downstream* router can
expect to see packets *coming in* on.

Sure, we may need "reverse RIP" and "reverse BGP" to build all these
"reverse routing tables". But that's a small price to pay, and it's a
damn easy protocol to write. No, RPF doesn't cut it, because it can't
take into account the more complex routing.

What we need plug-and-play security.

I have some ideas on a "2-phase process" to build this system.

However, I need at least 3 people to help me build some code around
the phase 1 product that will put an end to this growing situation.

I'm not certain I want to advertise my phase-1 plan on a newsgroup
just yet.

If anyone is interested in helping, please email me.

: (E-Mail Removed) (Erik Aronesty)
: Spoofed packets may be used for everything from denial of service
: attacks, breakins, session sniping, and cache-poisoning.
: [...]
: Routers spend an inordinate amount of effort determining which
: interface packets should be routed to. They should spend an *equal*
: amount of time determining whether the packet should have come *from*
: the interface they came in on.

That doesn't sound like an adequate solution... or at least, not without
some additional work. In particular, what about the case where the
route-to differs from the route-from for benign reasons? For one
possible example, connections with satellite downlink and
phone uplink. There are other reasonable benign possibilities,
and though I am only an egg, I don't see how this proposal addresses it.


Wayne Throop (E-Mail Removed) http://sheol.org/throopw

"Erik Aronesty" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...

> Routers spend an inordinate amount of effort determining which
> interface packets should be routed to. They should spend an *equal*
> amount of time determining whether the packet should have come *from*
> the interface they came in on.

If you design your networks to have redundant or load balanced routes that
concept doesn't make any sense at all. I use access lists to block strictly
internal source addresses that appear on the wrong side of border routers
but
there is no way the routers could know automatically which addresses have
alternate routes and which don't. If you know, you should add the access
lists.

---
Les Mikesell
(E-Mail Removed)