Source address validation (was Re: UUNet Offer New Protection Against DDoS)

Mailman List Mirror (Read Only)
1

After all these years, perhaps its time to re-examine the assumptions.

it's always fun and useful to re-example assumptions. for example, anyone
who assumes that because the attacks they happen to see, or the attacks
they hear about lately, don't use spoofed source addresses -- that spoofing
is no longer a problem, needs to re-examine that assumption.

for one thing, spoofed sources could be occurring outside local viewing.

for another thing, spoofed sources could be "plan B" when other attacks
aren't effective.

the last thing is, this is war. information warfare. the enemy knows us
better than we know them, and their cost of failure is drastically lower
than our cost of failure.

don't be lulled into some kind of false sense of security by the fact
that YOU are not seeing spoofed packets TODAY. let's close the doors we
CAN close, and give attackers fewer options.

2

sadly the prevailing thought seems to be 'we cant block every exploit so
we will block none'. this (and others) are used as an excuse to not deploy
urpf on edge interfaces facing singlehomed customers.

its a fatalistic approach to dealing with network abuse, and its retarded.

-Dan

3

I don't have a false sense of security. We have lots of open doors and
windows and even missing walls. Let's close the doors we can close, but
buying screen doors for igloos may not be the best use of resources. uRPF
doesn't actually prevent any attacks.

Would you rather ISPs spend money to
  1. Deploying S-BGP?
  2. Deploying uRPF?
  3. Respond to incident reports?

4

Sean Donelan wrote:

Would you rather ISPs spend money to
  1. Deploying S-BGP?
  2. Deploying uRPF?
  3. Respond to incident reports?

Why are we limited to that set?

5

This is one of the few locations SAV/uRPF consistently works. SAV/uRPF is
widely (but not 100%) deployed int those location. However I think you
are mis-stating the issue. I do not know of anyone that has stated your
reason as the reason not to deploy SAV/uRPF on non-routing interfaces.
The issue which prompt this thread was deploying uRPF on multi-path
backbone interfaces using active routing.

How many exploits does uRPF block?

Biometric smart cards may do wonders for credit card fraud. Why don't
credit card companies replace all existing cards with them?

Does uRPF solve more problems than it causes, and saves more than it
costs?

6

You are not limited to any particular set. However you are limited. No
one has infinite resources. Pick and choose the things you do, and you
will discover you still do not do everything everyone wants.

Create your own list of things to spend money on. Was uRPF high enough
on your list before you ran out of money? Why did you choose to spend
money on other security projets instead of uRPF, or the opposite why did
you choose to spend money on uRPF instead of other things which would have
improved security?

7

sean@donelan.com (Sean Donelan) writes:

How many exploits does uRPF block?

that's hard to measure since we end up not receiving those. but one can
assume that spoofed-source attacks aren't tried, either because (1) it's
easier to just use a high number of windows-xp drones, or because of (2)
uRPF deployment.

Does uRPF solve more problems than it causes, and saves more than it costs?

until you know what percentage of the attacks you don't see is due to (1)
vs (2) above, you can't really pose that question meaningfully. anytime
there's a way to protect against a whole class of attack weapons, we have
to deploy it. this is war, information warfare. let's deprive the enemy
of options until we can force them to meet us on our own chosen terms.

8

Date: Sat, 6 Mar 2004 22:04:58 -0500 (EST)
From: Sean Donelan

Would you rather ISPs spend money to
  1. Deploying S-BGP?
  2. Deploying uRPF?
  3. Respond to incident reports?

Let's look at the big picture instead of a taking a shallow mutex
approach.

If SAV were universal (ha ha ha!), one could discount spoofed
traffic when analyzing flows. But, hey, why bother playing nice
and helping other networks, eh?

Am I the only one who's had IWFs -- even legitimate entities --
complain about packets "from your network" that weren't? It
certainly would have been nice if $other_networks had used SAV.

SAV doesn't take long to implement. Considering the time spent
discounting spoofing when responding to incidents, I think there
would be a _net_ savings (no pun intended) in time spent
responding to incidents.

Alas, that requires cooperation and doesn't provide instantaneous
gratification. If it doesn't make/save a quick buck, why bother?

Detection of sarcasm is left as an exercise to the reader.

Eddy

9

If SAV were universal (ha ha ha!), one could discount spoofed
traffic when analyzing flows. But, hey, why bother playing nice
and helping other networks, eh?

SAV doesn't tell you where the packets came from. At best SAV tells you
where the packets didn't come from.

Am I the only one who's had IWFs -- even legitimate entities --
complain about packets "from your network" that weren't? It
certainly would have been nice if $other_networks had used SAV.

You still need to spend the same amount of time tracing the flows because
you can't tell from the packet itself if something went wrong with SAV.
Even if everyone said they did SAV (and meant it), things like uRPF rely
on a number of things to work correctly. If any of those break or aren't
secure, you still can't rely on the source address being accurate.

Even if you deployed SAV/uRPF on 100% of your network, you probably
wouldn't want to tell people about it due to the idiots with firewalls.

SAV doesn't take long to implement. Considering the time spent
discounting spoofing when responding to incidents, I think there
would be a _net_ savings (no pun intended) in time spent
responding to incidents.

You would be wrong. There are networks that have deployed SAV/uRPF.

They saw no _net_ savings.

In the real world, it costs more to deploy and maintain SAV/uRPF.

Have you noticed this thread is full of people who don't run large
networks saying other people who do run networks should deploy SAV/uRPF.

But there hasn't been anyone who does run large networks saying they
deployed SAV/uRPF and it saved them money, made their network run better
or improved the world?

10

sean@donelan.com (Sean Donelan) writes:

SAV doesn't tell you where the packets came from. At best SAV tells you
where the packets didn't come from.

...which is incredibly more valuable than not knowing anything at all.

You would be wrong. There are networks that have deployed SAV/uRPF.

They saw no _net_ savings.

In the real world, it costs more to deploy and maintain SAV/uRPF.

in the therefore-unreal world i live in, the ability to tell a GWF ("goober
with firewall") that the incident report they sent our noc could not possibly
have come from here, is a net cost savings over having to prove it every time.

Have you noticed this thread is full of people who don't run large
networks saying other people who do run networks should deploy SAV/uRPF.

distinguishingly, i do help run a network, and i'm not limiting my accusation
("you guys are slackers") to uPRF-free networks of any particular size ("big").

11

Of course, some people claim large networks say that anyway so there is
not net cost savings :slight_smile:

In practice, GWF's do not send reports to noc's about packets which could
not have possibly have come from here. They send reports about packets
which have our IP addresses, but didn't originate here. The last thing
you want to admit is you do SAV because GWF think SAV means every packet
with that source address must have originated here.

Whether or not we do SAV or everyone else does SAV, it doesn't save any
time validating if a packet stream originated here. Did the packet
actually originate here, or did SAV fail somewhere and it originated
somewhere else?

Dear NOC, 192.5.5.241 is attacking me. Prove it isn't. Rinse, Lather,
Repeat. Maybe you got hacked in the last 5 seconds, and now you really
are attacking them.

12

Date: Sun, 7 Mar 2004 16:17:50 -0500 (EST)
From: Sean Donelan

SAV doesn't tell you where the packets came from. At best
SAV tells you where the packets didn't come from.

If SAV were universal, source addresses could not be spoofed. If
source addresses could not be spoofed...

You would be wrong. There are networks that have deployed
SAV/uRPF.

Some. I said "all".

They saw no _net_ savings.

In the real world, it costs more to deploy and maintain
SAV/uRPF.

The benefit is to other networks. When other networks make your
life easier, you benefit. If you want others to help you, help
them.

Have you noticed this thread is full of people who don't run
large networks saying other people who do run networks should
deploy SAV/uRPF.

1. SAV is most effective at the edge, which often implies the
   smaller networks should be doing it

2. I've not seen large networks talking about their awful
   experiences with SAV.

Eddy

13

Date: Sun, 7 Mar 2004 17:47:09 -0500 (EST)
From: Sean Donelan

In practice, GWF's ... send reports about packets which have
our IP addresses, but didn't originate here. The last thing

Probably because someone else failed to implement SAV. If
$origin_net prevented spoofing your IP space, you'd not have had
the problem.

If other networks prevented spoofed sources, nobody else could
source a packet from your address space. In this case, a packet
apparently sourced from you network definitely would have come
from your network. Therefore you'd no longer need to check to
see if a packet was spoofed.

Notice how AS_PATHs and netblock announcements tend to get
filter. Why?

you want to admit is you do SAV because GWF think SAV means
every packet with that source address must have originated
here.

Uh, no... a spoofed packet from someone else's network means you
had no control over it. That's pretty obvious.

Eddy

14

> Date: Sun, 7 Mar 2004 16:17:50 -0500 (EST)
> From: Sean Donelan

> SAV doesn't tell you where the packets came from. At best
> SAV tells you where the packets didn't come from.

If SAV were universal, source addresses could not be spoofed. If
source addresses could not be spoofed...

in a perfect world yes, for today we still have LOTS of folks that
firewall in one direction only. A great example of this is the great
firewall of China :frowning: How, if they are filtering every packet that leaves
their country, can I still get attacked from them? :frowning:

Until this is a default behaviour and you can't screw it up (ala
directed-broadcast) this will be something we all have to deal with.

> Have you noticed this thread is full of people who don't run
> large networks saying other people who do run networks should
> deploy SAV/uRPF.

1. SAV is most effective at the edge, which often implies the
   smaller networks should be doing it

excellent, the original point of the conversation has been satisfied...
uRPF for the core is not a good plan, edge networks are a great place for
this. Doing this on single homed customers is a great step in the right
direction. However, as you say, the best place for this is on the edge of
the network. So this implies that each edge LAN router will/should have
uRPF or atleast an acl permitting only local LAN traffic to source from
it, right?

I have a question, I wonder if uRPF works on low end platforms without
running CEF? Do all low-end platforms gracefully support CEF along with
the other things enterprises typically do on routers? (just a question
really...)

2. I've not seen large networks talking about their awful
   experiences with SAV.

it melts routers, good enough for you? Specifically it melts linecards :frowning:
my experience is only on Cisco equipment though, so the linecard/ios/rev
games must be played. If you upgrade, or initially install, E3 cards a
large portion of this care is not necessary though. This is a problem that
could be migrated out as new equipment/capabilities hit everyone's
networks. I suspect that market pressure will push things in this
direction anyway over time.

15

Date: Mon, 8 Mar 2004 01:32:51 +0000 (GMT)
From: Christopher L. Morrow

in a perfect world yes[...]
Until this is a default behaviour and you can't screw it up
(ala directed-broadcast) this will be something we all have
to deal with.

Yes. But the only way we'll get there is 1) a flag day or 2) if
we gradually work in that direction.

it melts routers, good enough for you? Specifically it
melts linecards :frowning:

:frowning:

This is a problem that could be migrated out as new
equipment/capabilities hit everyone's networks. I suspect
that market pressure will push things in this direction
anyway over time.

...and hopefully will be safe-by-default. Anyone who has
multihomed downstreams should be clued enough to disable strict
SAV as needed -- similar to, yet the opposite of, manually
configuring OSPF to treat interfaces as passive by default.

As for low-end routers, uRPF is supported on 26xx. I don't know
about a 16xx or 25xx... a scary thought, but chances are such a
router would have a very small list of reachable netblocks to
check.

Eddy

16

> They saw no _net_ savings.
>
> In the real world, it costs more to deploy and maintain
> SAV/uRPF.

The benefit is to other networks. When other networks make your
life easier, you benefit.

This confirms my statement. You save nothing by deploying SAV on your
network. There may be some indeterminate benefit at some indeterminate
time in the future after everyone else in the world correctly implements
SAV. But there is no way to verify if every other network in the world
has correctly deployed SAV. Even if everyone deploys SAV/uRPF you never
know when someone may misconfigure something, so you still have to keep
doing everything you were doing.

In the mean time, you get to pay for the extra costs for deploying
SAV/uRPF in addition to doing everything you were already doing.

http://www.rhyolite.com/anti-spam/you-might-be.html

If you want others to help you, help them.

I've already done my part. I'm still waiting for others to help me.

Should I be expecting a check in the mail?

17

Sean Donelan wrote:

18

This isnt the point. The point is, why should others suffer the burden of
your clients spewing bogon/spoofed/nonsense garbage at them?

The effect is cumulative. If everyone takes this lazy apathetic approach
to network administration, it hurts everyone.

Its the difference between being a good neighbor and being the fat
beerbelly neighbor with dogs barking all night and rusting camaro with no
tires up on cinderblocks on his beercan littered lawn.

Just because everyone else doesnt maintain a good network doesnt mean you
shouldnt.

-Dan

19

Date: Sun, 7 Mar 2004 21:24:44 -0500 (EST)
From: Sean Donelan

This confirms my statement. You save nothing by deploying
SAV on your network. There may be some indeterminate benefit

Unless, of course, the traffic originated from your network and
it simplifies your backtrace. Tracing flows isn't difficult, but
it's more time consuming than a traceroute.

at some indeterminate time in the future after everyone else
in the world correctly implements SAV. But there is no way
to verify if every other network in the world has correctly
deployed SAV. Even if everyone deploys SAV/uRPF you never

s/SAV/AS_PATH filtering and netblock adverts/ in your above
statement. While technically true, it's highly disingenuous.
Should providers quit filtering those simply because not everyone
does it? It's extra cost with no selfish benefit, right?

If you want a network to extend that courtesy to you, extend it
to them. If you extend the courtesy to them, demand it in
return.

know when someone may misconfigure something, so you still
have to keep doing everything you were doing.

Perhaps on a lesser scale, though. There's benefit in knowing
something did not originate from certain sources.

In the mean time, you get to pay for the extra costs for
deploying SAV/uRPF in addition to doing everything you were
already doing.

Just like AS_PATH and netblock announcement filters. Just like
flow monitoring. Just like chasing down spammers. Just like
dealing with "pwned" systems. Just like most anything else that
wouldn't be necessary in a perfect world.

Also note various posters' interest in shifting costs to
responsible parties. One can argue what is "reasonable", but
consequences boost motivation. Perhaps if lack of certain
precautions were considered [legally] negligent, failure would be
the more expensive option.

Eddy

20

> > They saw no _net_ savings.
> >
> > In the real world, it costs more to deploy and maintain
> > SAV/uRPF.

[snip]

In the real word, there are different networks with different
tools and different gear. In some networks, it is a flip of
the switch, you are done, and can move on.

The direct benefit to my network is eliminating a category of
crap from it. I save having to deal with that category. Yes
there is other crap, but reducing the workload... reduces the
workload.

[snip]

has correctly deployed SAV. Even if everyone deploys SAV/uRPF
you never know when someone may misconfigure something,
so you still have to keep doing everything you were doing.

You mean internally to the network? Config management must exist
for a huge number of reasons. Drop the right knob in your standards
and move on. I don't follow 'having to keep doing everything'
when I have one less things to do.

In the mean time, you get to pay for the extra costs for deploying
SAV/uRPF in addition to doing everything you were already doing.

I'm sorry your network has such huge costs for trivial changes that
follow simple logic. Actually, I've lost track of how many tiers
of soapboxes are involved here, so I'm not sure what level of
hypothetical-vs-real this [sub]thread is tackling.

I'll encourage my competators to let more crap on their networks.
I'll take out the trash at the points where I can.