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

[Steve Francis]

Sean Donelan wrote:

On Mon, 8 Mar 2004, Steve Francis wrote:
 

That was exactly what I was doing by saying I will only get service from
ISPs that run loose-uRPF in cores. (or all edges, including peering links.)
I will not take service from ISP X, who is cheaper than ISP Y, if ISP X
cannot assure me that I will not get bogon sourced traffic on my link.
   

Why do you care how a provider does X?

Your requirement doesn't seem to be run loose-uRPF in cores, although that
may be one way a provider chooses to solve the problem.  You requirement
is "not get bogon sourced traffic on your link."
I know its tempting to tell other people how to run their networks.  But
specifying the solution sometimes cuts out alternative solutions which
work just as well or maybe better.
 

Correct. I was overstating my requirement.
What I really want is as you described: I want assurance that any packet 
I receive on my proposed circuit is NOT sourced from a patently false IP 
address. (i.e. no packets sourced from reserved IP addresses, RFC 1918 
IP addresses; addresses from blocks not yet allocated by routing 
registries, or addresses from blocks that are not currently 
being announced via BGP to the Internet.)

I would also prefer that such packets be dropped as far as possible from 
the POP I am connected to, to minimise the chance of such packets 
overloading the carriers circuits into that POP.
I know of no way to do this other than loose-uRPF in the core, or at 
least loose-uRPF on all edges, including peering connections.

Can any of the operators that are arguing against loose-uRPF in the core 
state if they run loose uRPF on all peering connections, regardless of 
speed, as well as on all their edges?
Or propose another way to achieve the same thing?

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

[Sean Donelan]

On Mon, 8 Mar 2004, Steve Francis wrote:
> That was exactly what I was doing by saying I will only get service from
> ISPs that run loose-uRPF in cores. (or all edges, including peering links.)
>
> I will not take service from ISP X, who is cheaper than ISP Y, if ISP X
> cannot assure me that I will not get bogon sourced traffic on my link.

Why do you care how a provider does X?

Your requirement doesn't seem to be run loose-uRPF in cores, although that
may be one way a provider chooses to solve the problem.  You requirement
is "not get bogon sourced traffic on your link."

I know its tempting to tell other people how to run their networks.  But
specifying the solution sometimes cuts out alternative solutions which
work just as well or maybe better.

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

[Steve Francis]

Christopher L. Morrow wrote:

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 :(
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.
 

That was exactly what I was doing by saying I will only get service from 
ISPs that run loose-uRPF in cores. (or all edges, including peering links.)

I will not take service from ISP X, who is cheaper than ISP Y, if ISP X 
cannot assure me that I will not get bogon sourced traffic on my link.

What you  are saying above is not a technical argument against uRPF (as 
you grant that there is equipment that will do uRPF at core speeds.) - 
its a business one. So I am giving you a business incentive to take to 
your managers. "Customers want this service which we cannot deliver w/o 
upgrades. Customers will not give us money unless we spend this money, 
and they will go to our competitors who have infrastructure that can do 
it." If your vendors cannot deliver equipment that meets your 
requirements to meet your customers' needs, you need to say the same 
thing to your vendors, and vote with dollars for those that can.

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

[Henry Linneweh]

Here is some insight on this issue 
What is Unicast Reverse Path Forwarding (uRPF)? Can a default route 0.0.0.0/0 be used to perform a uRPF check? 
http://www.cisco.com/warp/public/105/44.html#Q18
-Henry

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

[Avleen Vig]

On Mon, Mar 08, 2004 at 12:40:18AM -0500, Sean Donelan wrote:
> > No. The work you've done is expected of you, as a good Internetwork
> > neighbour.
> > If you're not a good neighbour, next time you need my help, or the help
> > of anyone else I know, please expect the finger.
> 
> But I keep trying to do good work; and you keep giving me the finger.  Why
> should I keep trying to do good work?  Remember it works both ways.

No I don't! You're a good Internet Neighbour. If I can expect you to do
the right thing, you can expect it of me. And if I don't, you give me
the finger instead. But don't give it to everyone, as a side of effect
of wanting to just flip me off.

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)

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

[Ken Diliberto]

Sean Donelan wrote:

On Sun, 7 Mar 2004, E.B. Dreger wrote:

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?
Where do you draw the line between large and not large?  Does a
university with a /16 count as large?  We do both SAV and a version of
uRPF.  It makes our network run better, saves us money (reduces the
amount of time we spend on support and makes
troubled/distressed/evil/mean/nasty boxes easier to track down) and
reduces backbone congestion making the network run better.  Another
benefit is it improves the world (betcha' were wondering if I'd squeeze
all that in).
We're now blocking all SMTP traffic leaving the campus from non-blessed
sources (read mail servers).  The first day doing this we had comments
about less junk mail traffic.  We block traffic we consider harmful that
shouldn't leave the campus.  We're trying to do our part.
Any suggestions how we can do better?

Ken

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

[Sean Donelan]

On Sun, 7 Mar 2004, Avleen Vig wrote:
> No. The work you've done is expected of you, as a good Internetwork
> neighbour.
> If you're not a good neighbour, next time you need my help, or the help
> of anyone else I know, please expect the finger.

But I keep trying to do good work; and you keep giving me the finger.  Why
should I keep trying to do good work?  Remember it works both ways.

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

[Paul Vixie]

[EMAIL PROTECTED] (vijay gill) writes:

> Putting rubber to the road eventually, we actually went ahead and
> packetfiltered rfc1918 space on our edge. I know paul and stephen
> will be crowing with joy here, as we had several arguments about
> it in previous lives, ...

fwiw, in retrospect you were right at the time, but in my defense it
was only because of things neither of us could have known.  given only
what we actually knew and could prove, you were deadass wrong :-).
-- 
Paul Vixie

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

[Avleen Vig]

On Sun, Mar 07, 2004 at 09:24:44PM -0500, Sean Donelan wrote:
> >  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?

No. The work you've done is expected of you, as a good Internetwork
neighbour.
If you're not a good neighbour, next time you need my help, or the help
of anyone else I know, please expect the finger.

Yes, I suppose this does sound somewhat like a cross between an
old-school network, and rule by bullying. But we don't have a better
way (yet).

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)

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

[Joe Provo]

On Sun, Mar 07, 2004 at 09:24:44PM -0500, Sean Donelan wrote:
> On Mon, 8 Mar 2004, E.B. Dreger wrote:
> > SD> They saw no _net_ savings.
> > SD>
> > SD> In the real world, it costs more to deploy and maintain
> > SD> 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.
 

-- 
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE

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

[E.B. Dreger]

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


SD> This confirms my statement.  You save nothing by deploying
SD> 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.


SD> at some indeterminate time in the future after everyone else
SD> in the world correctly implements SAV.  But there is no way
SD> to verify if every other network in the world has correctly
SD> 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.


SD> know when someone may misconfigure something, so you still
SD> 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.


SD> In the mean time, you get to pay for the extra costs for
SD> deploying SAV/uRPF in addition to doing everything you were
SD> 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
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

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

[vijay gill]

On Sun, Mar 07, 2004 at 08:35:54PM +, Christopher L. Morrow wrote:
> 
> 
> Here is a sticky point... There are reasons to allow 10.x.x.x sources to
> transit a network. Mostly the reasons come back to 'broken' configurations
> or 'broken' hardware. The reasons still equate to customer calls and
> 'broken' networking fromm their perspective. I think the thing you are
> actually driving at is the 'intent' of the packet, which is quite tough
> for the router to determine.


Putting rubber to the road eventually, we actually went ahead and
packetfiltered rfc1918 space on our edge. I know paul and stephen
will be crowing with joy here, as we had several arguments about
it in previous lives, but having gone ahead and filtered it,
nothing appears to have broken, or at least nothing got called
in. We've been doing it for several months now.

/vijay

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

[Dan Hollis]

On Sun, 7 Mar 2004, Sean Donelan wrote:
> This confirms my statement.  You save nothing by deploying SAV on your
> network.

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

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

[Laurence F. Sheldon, Jr.]

Sean Donelan wrote:
On Mon, 8 Mar 2004, E.B. Dreger wrote:

SD> They saw no _net_ savings.
SD>
SD> In the real world, it costs more to deploy and maintain
SD> SAV/uRPF.
The benefit is to other networks.  When other networks make your
life easier, you benefit.
This confirms my statement.  
How much do you save by putting handrails on your stairways?
Restrooms in you lobby?  Precipitators on your smoke stacks?

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

[Sean Donelan]

On Mon, 8 Mar 2004, E.B. Dreger wrote:
> SD> They saw no _net_ savings.
> SD>
> SD> In the real world, it costs more to deploy and maintain
> SD> 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?

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

[E.B. Dreger]

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


CLM> in a perfect world yes[...]
CLM> Until this is a default behaviour and you can't screw it up
CLM> (ala directed-broadcast) this will be something we all have
CLM> 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.


CLM> it melts routers, good enough for you? Specifically it
CLM> melts linecards :(

:-(


CLM> This is a problem that could be migrated out as new
CLM> equipment/capabilities hit everyone's networks. I suspect
CLM> that market pressure will push things in this direction
CLM> 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
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

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

[Christopher L. Morrow]

On Mon, 8 Mar 2004, E.B. Dreger wrote:

>
> SD> Date: Sun, 7 Mar 2004 16:17:50 -0500 (EST)
> SD> From: Sean Donelan
>
>
> SD> SAV doesn't tell you where the packets came from.  At best
> SD> 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 :( How, if they are filtering every packet that leaves
their country, can I still get attacked from them? :(

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.

>
> SD> Have you noticed this thread is full of people who don't run
> SD> large networks saying other people who do run networks should
> SD> 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 :(
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.

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

[E.B. Dreger]

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


SD> SAV doesn't tell you where the packets came from.  At best
SD> 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...


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

Some.  I said "all".


SD> They saw no _net_ savings.
SD>
SD> In the real world, it costs more to deploy and maintain
SD> 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.


SD> Have you noticed this thread is full of people who don't run
SD> large networks saying other people who do run networks should
SD> 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
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

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

[Christopher L. Morrow]

removed paul from the direct reply since his mailserver doesn't like uunet
mail servers :)

On Sun, 7 Mar 2004, Stephen J. Wilcox wrote:

> > smurf attacks are far from 'non-existent' today, however they are not as
> > popular as in 1999-2000-2001.
>
> thats interesting, i've not seen/heard of one for ages.. (guess u have a wider
> testing ground :)
>

just last week we had one... they do still happen.

> > In fact netscan.org still shows almost 9k networks that are 'broken'.
>
> actually i just ran that file thro a quick awk and sort to see to what extent
> these networks exist..
>
> as you can see almost all only reply two or three times, not like in the old
> days with >100 replies being commonplace..
>

Sure, but a list of 9k networks with this leve of response is still enough
to do damage. It's getting better, no doubt about it but it's still a
factor.



--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

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

[Stephen J. Wilcox]

> smurf attacks are far from 'non-existent' today, however they are not as
> popular as in 1999-2000-2001. 

thats interesting, i've not seen/heard of one for ages.. (guess u have a wider 
testing ground :)

> In fact netscan.org still shows almost 9k networks that are 'broken'.

actually i just ran that file thro a quick awk and sort to see to what extent 
these networks exist..

as you can see almost all only reply two or three times, not like in the old
days with >100 replies being commonplace.. 

5224 2
1834 3
 897 4
 334 5
 167 6
  56 7
  19 8
  15 9
   7 10
  11 11
   6 12
   3 13
   6 14
   1 15
   1 16
   4 17
   5 18
   1 23
   1 26
   1 28
   1 100

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

[Avleen Vig]

On Sun, Mar 07, 2004 at 08:48:00PM +, Christopher L. Morrow wrote:
> > > actually, it would.  universal uRPF would stop some attacks, and it would
> > > remove a "plan B" option for some attack-flowcharts.  i would *much* rather
> > > play defense without facing this latent weapon available to the offense.
> >
> > I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be
> > non-existent these days so shall we stop disabling 'ip directed-broadcast' on
> > our routers?
> 
> smurf attacks are far from 'non-existent' today, however they are not as
> popular as in 1999-2000-2001. In fact netscan.org still shows almost 9k
> networks that are 'broken'.

A few of us tried (like netscan, only more agressively on a weekly
basis) to find and try to get closed, smurf amplifiers in the RIPE
region.
We eventually gave up after closing ~20k, when the last few k refused to
do anything at all.
"My network is just a /30! Who cares, you're only getting TWO replies
back for ONE packet, it's not like the big amplifiers! I'm not going to
fix this!".

To anyone with this attitude: You are an idiot.

-- 
Avleen Vig
Systems Administrator

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

[Avleen Vig]

On Sun, Mar 07, 2004 at 08:28:53PM +, Christopher L. Morrow wrote:
> > Without any data to back this up, I'm estimating based on the attacks
> > I've dealt with.
> > I don't believe the number have gone down at all. If it has, it's done
> > that for someone else, not me,
> 
> Is this attacks on 'known magnets' or 'random stuff'. From what I've seen
> the frequency of attacks on 'all customers' seems to be slowing SOME.
> There are the normal nuisance points which attract attacks for whichever
> reason. So, Avleen, can you seperate the 'known magnets' from 'random
> stuff' and say which direction the trend is moving?

If we class "popular websites", "servers / networks at major ISPs", "IRC
servers" and "the latest popular thing" as magnets, and "small business
sites", "personal pages" etc as the random stuff, then I don't believe
attacks on magnets have gone down at all.
On the random stuff I cannot comment, as I've had surprisingly little
dealing with that.

> As to the 'strength' of attacks. It seems that bandwidth and pps rates
> have incresed over time. This COULD BE because you can own up 10,000 xp
> machines in a heartbeat, or it could be a reflection of
> bigger/better/faster single hosts being taken over. It's hard to tell from
> my end of the party :(

I don't think it would be unfair to assume it is both. Again that stands
to simple logic. More hosts on the internet = more potential drones.
More availible global bandwidth = larger volume output from each drone.

> > I don't have any evidence. Nor do I *believe* the number of attacks is
> > decreasing. If anything, its staying the same or going up, as more
> > people decide it's fun to take networks offline through the greater and
> > greater number of compromised hosts.
> 
> The greater number of compromisable hosts seems to be the constant in this
> arguement. So, like we've said for several years, until the end station is
> secured 'better' the consistency and strength of attacks will continue
> that upward trend.

Indeed. I believe the ISP of the end user is the party responsible here.
If the ISP is allowing access through their network, they need to be
responsible for the data leaving their networl which originates in their
network.

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

[Sean Donelan]

On Sun, 7 Mar 2004, E.B. Dreger wrote:
> 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?

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

[Christopher L. Morrow]

On Sun, 7 Mar 2004, Stephen J. Wilcox wrote:

>
> > actually, it would.  universal uRPF would stop some attacks, and it would
> > remove a "plan B" option for some attack-flowcharts.  i would *much* rather
> > play defense without facing this latent weapon available to the offense.
>
> I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be
> non-existent these days so shall we stop disabling 'ip directed-broadcast' on
> our routers?

smurf attacks are far from 'non-existent' today, however they are not as
popular as in 1999-2000-2001. In fact netscan.org still shows almost 9k
networks that are 'broken'.

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

[Christopher L. Morrow]

On Sun, 7 Mar 2004, Laurence F. Sheldon, Jr. wrote:

>
> fingers wrote:
>
> > just a question
> >
> > why is DDoS the only issue mentioned wrt source address validation?
> >
> > i'm sure there's other reasons to make sure your customers can't send
> > spoofed packets. they might not always be as news-worthy, but i feel it's
> > a provider's duty to do this. it shouldn't be optional (talking
> > specifically about urpf on customer interfaces, loose where needed)
>
> Because _Distributed_ is the hot buzzword of the day.

and people offten seperate 'ddos' from 'dos', even though the end is the
same as far as your customer is concerned... it's kinda funny really :)

>
> At least one of us thinks clean traffic is a Good Thing all the time.
>
> Packets that can't possibley be used for anything ought to be dumped at
> the earliest possible opportunity as soon as it is apparent (or could
> be if anybody looked) that they are "from" addresses that can't be
> reached or have any other obviously fatal defect.

Here is a sticky point... There are reasons to allow 10.x.x.x sources to
transit a network. Mostly the reasons come back to 'broken' configurations
or 'broken' hardware. The reasons still equate to customer calls and
'broken' networking fromm their perspective. I think the thing you are
actually driving at is the 'intent' of the packet, which is quite tough
for the router to determine.



--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

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

[Christopher L. Morrow]

On Sun, 7 Mar 2004, fingers wrote:

>
> just a question
>
> why is DDoS the only issue mentioned wrt source address validation?

its easier to discuss than other things... for instance the number of
broken vpn/nat systems out there that uRPF will break. Also, the folks
with private addressed cores that will start appearing 'broken' when
traceroute/unreachables stop working across their networks...

>
> i'm sure there's other reasons to make sure your customers can't send
> spoofed packets. they might not always be as news-worthy, but i feel it's
> a provider's duty to do this. it shouldn't be optional (talking
> specifically about urpf on customer interfaces, loose where needed)
>

I'm not sure that anyone would argue that uRPF is bad, the arguement is in
it's placement. I do think that part still needs to be worked out, that
and making sure that your equipment can handle the task. There are
certainly some people hampered by early adoption of some technologies
which they can't get out from under in any reasonable fashion.



--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

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

[Christopher L. Morrow]

On Sun, 7 Mar 2004, Avleen Vig wrote:

>
> On Sun, Mar 07, 2004 at 02:13:38AM -0500, Sean Donelan wrote:
> > > Try saying that after running a major DDoS target, with "HIT ME" your
> > > forehead.
> > > No offense Sean but I'd like you to back your claim up with some
> > > impirical data first.
> >
> > Has the number of DDOS attacks increased or decreased in the last few
> > years has uRPF has become more widely deployed?
> > Do you have any evidence the number of attacks are decreasing?
>
> Without any data to back this up, I'm estimating based on the attacks
> I've dealt with.
> I don't believe the number have gone down at all. If it has, it's done
> that for someone else, not me,

Is this attacks on 'known magnets' or 'random stuff'. From what I've seen
the frequency of attacks on 'all customers' seems to be slowing SOME.
There are the normal nuisance points which attract attacks for whichever
reason. So, Avleen, can you seperate the 'known magnets' from 'random
stuff' and say which direction the trend is moving?

As to the 'strength' of attacks. It seems that bandwidth and pps rates
have incresed over time. This COULD BE because you can own up 10,000 xp
machines in a heartbeat, or it could be a reflection of
bigger/better/faster single hosts being taken over. It's hard to tell from
my end of the party :(

>
> I don't have any evidence. Nor do I *believe* the number of attacks is
> decreasing. If anything, its staying the same or going up, as more
> people decide it's fun to take networks offline through the greater and
> greater number of compromised hosts.
>

The greater number of compromisable hosts seems to be the constant in this
arguement. So, like we've said for several years, until the end station is
secured 'better' the consistency and strength of attacks will continue
that upward trend.

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

[Stephen J. Wilcox]

> actually, it would.  universal uRPF would stop some attacks, and it would
> remove a "plan B" option for some attack-flowcharts.  i would *much* rather
> play defense without facing this latent weapon available to the offense.

I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be 
non-existent these days so shall we stop disabling 'ip directed-broadcast' on 
our routers?

Steve

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

[James Edwards]

On Sun, 2004-03-07 at 11:08, fingers wrote:
> just a question
> 
> why is DDoS the only issue mentioned wrt source address validation?


uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private
address space via broken NAT. Also, all other customer facing interfaces
run uRPF, strict mode. It is a very powerful tool; null route some
trouble causing customer space and traffic destined to this space is
dropped via this null route AND traffic sourced from this space is
dropped via uRPF, strict check. An AS112 NS also takes care of another
facet of this problem.

As to the question of DDoS'es and spoofed address space; once we close
the hole of allowing DDoS'es to come from untraceable address space I
feel we gain something very useful. We now know where the bad stuff is
coming from. The solution to DDoS is not a black box that will go to
Def Con 1 at the first sign of a port scan. You don't put out a fire
with more fuel. Criminal investigation techniques are quite advanced.
We cannot start to put them to use if attacks come from addresses that 
do not point back to the attacker. I am just as jaded as the next person
with the present lack of law enforcement support in abuse issues but all
of this is a quite new form of crime through a new medium. A "push back"
system would give us the ability to quickly bring DDoS/DoS'es
under control and complement a system to track down, gather evidence,
and prosecute to persons in control of a DDoS/DoS.  

Based on my limited experience with all of this it seems the place for 
uRPF is not at the core (core in the context of the Internet backbone) 
but at the customer edge, where the problem starts.

-- 
James H. Edwards
Routing and Security
At the Santa Fe Office: Internet at Cyber Mesa  
[EMAIL PROTECTED]
[EMAIL PROTECTED]

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

[E.B. Dreger]

SD> Date: Sun, 7 Mar 2004 02:13:38 -0500 (EST)
SD> From: Sean Donelan


SD> Has the number of DDOS attacks increased or decreased in the
SD> last few years has uRPF has become more widely deployed?

Number of life guards on duty increases in the summer.  So does
drowning.  Therefore, having life guards on duty is not an
effective measure to prevent drowning.

Ice cream consumption increases in the summer.  So does drowning.
Therefore, it is ice cream consumption that causes drowning.

(Time for arguments over who has the best and worst analogies!)


SD> Do you have any evidence the number of attacks are decreasing?

Is "number of attacks" the sole metric?  Are all attacks created
equal?


Eddy
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

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

[E.B. Dreger]

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


SD> Would you rather ISPs spend money to
SD> 1. Deploying S-BGP?
SD> 2. Deploying uRPF?
SD> 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
--
EverQuick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_
  DO NOT send mail to the following addresses :
  [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED]
Sending mail to spambait addresses is a great way to get blocked.

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

[Laurence F. Sheldon, Jr.]

fingers wrote:

just a question

why is DDoS the only issue mentioned wrt source address validation?

i'm sure there's other reasons to make sure your customers can't send
spoofed packets. they might not always be as news-worthy, but i feel it's
a provider's duty to do this. it shouldn't be optional (talking
specifically about urpf on customer interfaces, loose where needed)


Because _Distributed_ is the hot buzzword of the day.

At least one of us thinks clean traffic is a Good Thing all the time.

Packets that can't possibley be used for anything ought to be dumped at
the earliest possible opportunity as soon as it is apparent (or could
be if anybody looked) that they are "from" addresses that can't be
reached or have any other obviously fatal defect.

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

[fingers]

just a question

why is DDoS the only issue mentioned wrt source address validation?

i'm sure there's other reasons to make sure your customers can't send
spoofed packets. they might not always be as news-worthy, but i feel it's
a provider's duty to do this. it shouldn't be optional (talking
specifically about urpf on customer interfaces, loose where needed)

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

[Avleen Vig]

On Sun, Mar 07, 2004 at 02:13:38AM -0500, Sean Donelan wrote:
> > Try saying that after running a major DDoS target, with "HIT ME" your
> > forehead.
> > No offense Sean but I'd like you to back your claim up with some
> > impirical data first.
> 
> Has the number of DDOS attacks increased or decreased in the last few
> years has uRPF has become more widely deployed?
> Do you have any evidence the number of attacks are decreasing?

Without any data to back this up, I'm estimating based on the attacks
I've dealt with.
I don't believe the number have gone down at all. If it has, it's done
that for someone else, not me,

I don't have any evidence. Nor do I *believe* the number of attacks is
decreasing. If anything, its staying the same or going up, as more
people decide it's fun to take networks offline through the greater and
greater number of compromised hosts.

If you want to do a little test, try this:
In the last 5 years, compromised hosts have become a favourite for
launching DDoS attacks from. If the number of compromised hosts with
outbound Internet access has gone up, then either the frequency of
attacks, or the amplitude of said attacks, or both have gone UP.

We all know the number of compromised hosts continues to go up. The rest
is simple logic.

-- 
Avleen Vig
Systems Administrator

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

[Sean Donelan]

On Sat, 6 Mar 2004, Avleen Vig wrote:
> On Sat, Mar 06, 2004 at 06:39:21PM -0500, Sean Donelan wrote:
> > Source address validation (or Cisco's term uRPF) is perhaps more widely
> > deployed than people realize.  Its not 100%, but what's interesting is
> > despite its use, it appears to have had very little impact on DDOS or
> > lots of other bad things.
>
> Try saying that after running a major DDoS target, with "HIT ME" your
> forehead.
> No offense Sean but I'd like you to back your claim up with some
> impirical data first.

Has the number of DDOS attacks increased or decreased in the last few
years has uRPF has become more widely deployed?

Do you have any evidence the number of attacks are decreasing?

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

[Avleen Vig]

On Sat, Mar 06, 2004 at 06:39:21PM -0500, Sean Donelan wrote:
> Source address validation (or Cisco's term uRPF) is perhaps more widely
> deployed than people realize.  Its not 100%, but what's interesting is
> despite its use, it appears to have had very little impact on DDOS or
> lots of other bad things.

Try saying that after running a major DDoS target, with "HIT ME" your
forehead.
No offense Sean but I'd like you to back your claim up with some
impirical data first.
>From experience the majority of TCP based denial of service attacks
(which usually seem to be balanced with UDP, but ICMP is not as frequent
as it once was), use spoofed sources.

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com

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

[Paul Vixie]

> ...
> buying screen doors for igloos may not be the best use of resources.  uRPF
> doesn't actually prevent any attacks.

actually, it would.  universal uRPF would stop some attacks, and it would
remove a "plan B" option for some attack-flowcharts.  i would *much* rather
play defense without facing this latent weapon available to the offense.

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

"yes."

and i can remember being sick and tired of competing (on price, no less)
against providers who couldn't/wouldn't do #2 or #3.  i'm out of the isp
business at the moment, but the "race to the bottom" mentality is still
a pain in my hindquarters, both present and remembered.

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

[Sean Donelan]

On Sat, 6 Mar 2004, Laurence F. Sheldon, Jr. 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?

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?

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

[Sean Donelan]

On Sat, 6 Mar 2004, Dan Hollis wrote:
> 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.

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?

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

[Laurence F. Sheldon, Jr.]

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?

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

[Sean Donelan]

On Sun, 7 Mar 2004, Paul Vixie wrote:
> 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.

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?

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

[Dan Hollis]

On Sun, 7 Mar 2004, Paul Vixie wrote:
> 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.

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

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

[Paul Vixie]

> 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.

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

[Alex Bligh]

--On 06 March 2004 18:39 -0500 Sean Donelan <[EMAIL PROTECTED]> wrote:

Source address validation (or Cisco's term uRPF) is perhaps more widely
deployed than people realize.  Its not 100%, but what's interesting is
despite its use, it appears to have had very little impact on DDOS or
lots of other bad things.
...
But relatively few DDOS attacks use spoofed
packets.  If more did, they would be easier to deal with.
AIUI that's cause & effect: the gradual implementation of source-address
validation has made attacks dependent on spoofing less attractive to
perpetrators. Whereas the available of large pools of zombie machines
has made the use of source spoofing unnecessary. Cisco et al have shut
one door, but another one (some suggest labeled Microsoft) has opened.
Those with long memories might draw parallels with the evolution of
phreaking from abuse of the core, which became (reasonably) protected
to abuse of unprotected PABXen. As I think I said only a couple of days
ago, there is nothing new in the world.
Alex

Re: UUNet Offer New Protection Against DDoS

[Alex Bligh]

--On 06 March 2004 23:02 + Paul Vixie <[EMAIL PROTECTED]> wrote:

ok, i'll bite.  why do we still do this?  see the following from June
2001:
http://www.cctec.com/maillists/nanog/historical/0106/msg00681.html
Having had almost exactly that phrase in my peering contracts for
$n years, the answer is because if you are A, and peer is B,
if ( A>B )
 your spoofed traffic comes (statistically) from elsewhere so you don't
 notice. You are dealing with traffic from C, where C>>A
else
 you've signed their peering agreement, and are 'peering' on their
 terms instead. Was I going to pull peering with $tier1 from whom
 the occasional DoS came? Nope.
The only way this was ever going to work was if the largest networks
cascaded the requirements down to the smallest. And the largest networks
were the ones for whom (quite understandably) rpf was most difficult.
DoS (read unpaid for, unwanted traffic) is one of the best arguments
against settlement-free peering (FX: ducks & runs).
Alex

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

[Sean Donelan]

On Sat, 6 Mar 2004, Paul Vixie wrote:
> (and according to that text, it was a 9-year-old idea at that time.)
>
> it's now 2004.  how much longer do we want to have this problem?

Source address validation (or Cisco's term uRPF) is perhaps more widely
deployed than people realize.  Its not 100%, but what's interesting is
despite its use, it appears to have had very little impact on DDOS or
lots of other bad things.

Root and other DNS servers bear the brunt of misconfigured (not
necessarily malicious attack) devices.  So some people's point of
view may be different.  But relatively few DDOS attacks use spoofed
packets.  If more did, they would be easier to deal with.

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

Re: UUNet Offer New Protection Against DDoS

[Paul Vixie]

[EMAIL PROTECTED] (Steve Francis) writes:

> ...
> But in the real world...given that you are going to be peering with ISPs 
> (or their upstreams) that do not do uRPF or anything at all on their 
> edges, ...

ok, i'll bite.  why do we still do this?  see the following from june 2001:

http://www.cctec.com/maillists/nanog/historical/0106/msg00681.html

(and according to that text, it was a 9-year-old idea at that time.)

it's now 2004.  how much longer do we want to have this problem?
-- 
Paul Vixie

Re: UUNet Offer New Protection Against DDoS

[Steve Francis]

Christopher L. Morrow wrote:

miniscule amounts of traffic in uunet's core is still enough to ddos many
a victim into oblivion. anyone who has been ddos'd by uunet customers can
appreciate that.
   

miniscule is enough to cause problems in anyone's network the point
here was: "Core isn't the right place for this" I wasn't really trying to
argue the 'urpf is good' or 'urpf is bad' arguement, just the placement.
Sorry if I made that confusing earlier.

 

So we all agree that in the ideal world, everyone has anti-spoofing ACLs 
and route map filters and what not on every link into their network.
But in the real world...given that you are going to be peering with ISPs 
(or their upstreams) that do not do uRPF or anything at all on their 
edges,  if you want to drop the patently bogus traffic, or your 
customers don't want to pay you for delivering it to them over links 
they don't want congested with it, what do you do?

I guess you can say "peering links are not core", and that's fine if you 
run loose-uRPF there, and can be assured that all access to your network 
has filters on all links.I was thinking of large peering routers as 
part of the core of an ISP, so loose-uRPF is sufficient on those 
routers, if edges are protected.

But if you are going to run loose-uRPF on your peering routers, why not 
run it on your core? Is there a technogical reason not to? Cisco OC48  
line cards not support it (at least some do.), I'm almost sure Juniper 
does too. But I don't play in that area.

And given that there are ISP's running it in the core; that it will 
block some malicious traffic; and spoofed traffic may well be used as an 
attack vector again (sometime people are going to have to catch on and 
patch machines, or worms will patch them for them, and reduce the botnet 
farm size. Maybe not this year, but sometime...), I still don't see why 
you are against it.

I accept that filtering on all edges, including peering, is a better 
place to do it. So do you filter on, say, peering links to other tier 
1's? Even so, why not have belt AND suspender, and run it in the core?

Re: UUNet Offer New Protection Against DDoS

[Christopher L. Morrow]

On Fri, 5 Mar 2004, Dan Hollis wrote:

> On Fri, 5 Mar 2004, Christopher L. Morrow wrote:
> > the packets as possible. Nebulous filtering and dropping of miniscule
> > amounts of traffic in the core of a large network is just a waste of
> > effort and false panacea.
>
> uunet does operate lots of dialup RAS though correct? any reason why urpf
> is not reasonable there?

For some sure, for others perhaps not :( We have some customers with
dedicated networks over dial, some with dial-backup and even some with dsl
backup.

>
> just because its not perfect and doesnt solve every problem doesnt mean
> its useless.
>

Sure, I'm just not really sure that the core is the right place to do
this... I agree that the edge is a fine place, I'd prefer not my edge :)
but the edge is the right place. You can make all the decisions correctly
there, you can not in the core.

> miniscule amounts of traffic in uunet's core is still enough to ddos many
> a victim into oblivion. anyone who has been ddos'd by uunet customers can
> appreciate that.

miniscule is enough to cause problems in anyone's network the point
here was: "Core isn't the right place for this" I wasn't really trying to
argue the 'urpf is good' or 'urpf is bad' arguement, just the placement.

Sorry if I made that confusing earlier.



--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

RE: UUNet Offer New Protection Against DDoS

[Terranson, Alif]

> On Fri, 5 Mar 2004, Christopher L. Morrow wrote:
> > the packets as possible. Nebulous filtering and dropping of 
> > miniscule amounts of traffic in the core of a large network is 
> > just a waste of effort and false panacea.

Agreed.  

> uunet does operate lots of dialup RAS though correct? any 
> reason why urpf 
> is not reasonable there?

Nobody I know terminates a dial connection on a *core router* ;-)
//Alif

Alif Terranson
OpSec Engineering Mgr.
Operations Security Dept.
Savvis Communications Corp.
(314) 628-7602 Voice
(618) 558-5854 Cell
(314) 628-7710 Fax

> 

Re: UUNet Offer New Protection Against DDoS

[Dan Hollis]

On Fri, 5 Mar 2004, Christopher L. Morrow wrote:
> the packets as possible. Nebulous filtering and dropping of miniscule
> amounts of traffic in the core of a large network is just a waste of
> effort and false panacea.

uunet does operate lots of dialup RAS though correct? any reason why urpf 
is not reasonable there?

just because its not perfect and doesnt solve every problem doesnt mean 
its useless.

miniscule amounts of traffic in uunet's core is still enough to ddos many 
a victim into oblivion. anyone who has been ddos'd by uunet customers can 
appreciate that.

-Dan

Re: UUNet Offer New Protection Against DDoS

[Christopher L. Morrow]

On Fri, 5 Mar 2004, Steve Francis wrote:

> Christopher L. Morrow wrote:
>
> >
> >
> >uRPF in the core seems like a bad plan, what with diverse routes and such.
> >Loose-mode might help SOME, but really spoofing is such a low priority
> >issue why make it a requirement? Customer triggered blackholing is a nice
> >feature though.
> >
> >
> >
> Obviously loose-mode.
> Spoofing may not be the current weapon of choice, but why not encourage
> the best net infrastructure?
>

Loose mode will not save you very much, many larger backbones route lots
of 'unused' or 'unallocated' ip space internally for various valid
reasons, some even related to security issues for their customers. So,
does stopping rfc-1918 (maybe) space help much? not really... atleast not
that I can see. Many flooding tools now flood from legittimate space, so
the ONLY way to limit this is by filtering as close to the device sourcing
the packets as possible. Nebulous filtering and dropping of miniscule
amounts of traffic in the core of a large network is just a waste of
effort and false panacea.

--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

RE: UUNet Offer New Protection Against DDoS

[Terranson, Alif]

> Terranson, Alif wrote:
> 
> >As long as we're doing "Me Too"...
> >
> >Savvis has had prefix:666 for around 18 months as well.
> >  
> >
> Do you know if C&W does? Or will that wait until the integration?

While I am not 100% certain (and there are plenty of "new-Savvis" folks here who *do* 
know for sure ;-), I believe the CW network does support a BH tag.

> This thread has caused me to add this as a requirement for a 
> new gigabit  ISP circuit I am ordering, as well as uRPF in the core, 

Woah!  Never said *anything* about that!  No plans for it that I am aware of.  No 
reason I can think of to do this either.

> etc.
> I've had two ISPs say "We don't do this yet, but based on the 
> fact you are making it a requirement, we will role those functions out 
> into our core."

This is really not "new", and considering how easy it is to implement, I'm surprised 
it isn't *much* more widely implemented.

> Steve
> Voting with his money for better net-security

Go Steve!  Go!!

Alif Terranson
OpSec Engineering Mgr.
Operations Security Dept.
Savvis Communications Corp.
(314) 628-7602 Voice
(618) 558-5854 Cell
(314) 628-7710 Fax
 

Re: UUNet Offer New Protection Against DDoS

[Steve Francis]

Christopher L. Morrow wrote:



uRPF in the core seems like a bad plan, what with diverse routes and such.
Loose-mode might help SOME, but really spoofing is such a low priority
issue why make it a requirement? Customer triggered blackholing is a nice
feature though.
 

Obviously loose-mode. 
Spoofing may not be the current weapon of choice, but why not encourage 
the best net infrastructure?

RE: UUNet Offer New Protection Against DDoS

[Michael Hallgren]

 
> 
> uRPF in the core seems like a bad plan, what with diverse 
> routes and such.
> Loose-mode might help SOME, but really spoofing is such a low 
> priority issue why make it a requirement? Customer triggered 
> blackholing is a nice feature though.
> 


Shared view,

mh (Teleglobe, btw)


> --Chris
> (formerly [EMAIL PROTECTED])
> ###
> ## UUNET Technologies, Inc.  ##
> ## Manager   ##
> ## Customer Router Security Engineering Team ##
> ## (W)703-886-3823 (C)703-338-7319   ##
> ###
> 
> 

Re: UUNet Offer New Protection Against DDoS

[Christopher L. Morrow]

On Fri, 5 Mar 2004, Steve Francis wrote:

>
> Terranson, Alif wrote:
>
> >As long as we're doing "Me Too"...
> >
> >Savvis has had prefix:666 for around 18 months as well.
> >
> >
> Do you know if C&W does? Or will that wait until the integration?
>
> This thread has caused me to add this as a requirement for a new gigabit
> ISP circuit I am ordering, as well as uRPF in the core, etc.

uRPF in the core seems like a bad plan, what with diverse routes and such.
Loose-mode might help SOME, but really spoofing is such a low priority
issue why make it a requirement? Customer triggered blackholing is a nice
feature though.

--Chris
(formerly [EMAIL PROTECTED])
###
## UUNET Technologies, Inc.  ##
## Manager   ##
## Customer Router Security Engineering Team ##
## (W)703-886-3823 (C)703-338-7319   ##
###

Re: UUNet Offer New Protection Against DDoS

[Steve Francis]

Terranson, Alif wrote:

As long as we're doing "Me Too"...

Savvis has had prefix:666 for around 18 months as well.
 

Do you know if C&W does? Or will that wait until the integration?

This thread has caused me to add this as a requirement for a new gigabit 
ISP circuit I am ordering, as well as uRPF in the core, etc.
I've had two ISPs say "We don't do this yet, but based on the fact you 
are making it a requirement, we will role those functions out into our 
core."

Steve
Voting with his money for better net-security
Alif Terranson
OpSec Engineering Manager
Operations Security Department
Savvis Communications Corporation
(314) 628-7602 Voice
(314) 208-2306 Pager
(618) 558-5854 Cell
 

-Original Message-
From: Michael Hallgren [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 03, 2004 3:45 PM
To: [EMAIL PROTECTED]
Subject: RE: UUNet Offer New Protection Against DDoS



   

Global Crossing has this, already in production.
 

Idem, Teleglobe,

mh

   

I was on the phone with Qwest yesterday & this was one of
this things I asked about. Qwest indicated they are going to 
deploy this shortly. (i.e., send routes tagged with a 
community which they will set to null)

James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa Store hours:
9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965


 

   

 

Re: UUNet Offer New Protection Against DDoS

[Avleen Vig]

On Thu, Mar 04, 2004 at 03:39:30PM +, Alex Bligh wrote:
> >A lot of people seem to be doing this.
> 
> there is nothing (well very little) new in the world:
> http://www.merit.edu/mail.archives/nanog/1999-07/msg00083.html

Does anyone know if Cogent offer such a community?
Anyone from Cogent on the line?

-- 
Avleen Vig
Systems Administrator
Personal: www.silverwraith.com
EFnet:irc.mindspring.com (Earthlink user access only)

Re: UUNet Offer New Protection Against DDoS

[Deepak Jain]

They also are not guaranteeing that opening up the ticket won't take 
more than 15 minutes. I know a number of networks (when they hear you 
want to open a ticket for something important), put you on hold, 
call/page whoever it is and then take 10 minutes to open a ticket.

I know I may be nitpicking, but having been on hold BEFORE I've opened a 
ticket doesn't make me very happy with time-sensitive SLAs.

DJ

Lumenello, Jason wrote:

No, but it sounds like SLA payouts are made in the event that they fail
to respond in 15 minutes after a call is made. Maybe I am
misinterpreting their SLA, but this seems much different then offering
blanket payments for DoS down time.
I will give them credit for guaranteeing a response in 15 minutes or
less. Now is a response the opening of a ticket or the null routing of
the attack traffic in 15 minutes?
Jason


-Original Message-
From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 7:21 PM
To: Randy Bush
Cc: [EMAIL PROTECTED]; Lumenello, Jason
Subject: Re: UUNet Offer New Protection Against DDoS
Randy Bush  [3/4/2004 6:40 AM] :


i think the north american idiom is putting your money where your
mouth is.
Thank you.  That's exactly what I was driving at.

Hmm.. one of the people in that "we've been doing this too" thread was
XO.  Do I take it then that XO provides for DDoS downtime in its SLA?
--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

> -Original Message-
> From: Christopher L. Morrow [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 04, 2004 11:50 AM
> To: Lumenello, Jason
> Cc: Suresh Ramasubramanian; Randy Bush; [EMAIL PROTECTED]
> Subject: RE: UUNet Offer New Protection Against DDoS
> 
> 
> On Thu, 4 Mar 2004, Lumenello, Jason wrote:
> 
> >
> > No, but it sounds like SLA payouts are made in the event that they
fail
> > to respond in 15 minutes after a call is made. Maybe I am
> 
> fail to get you in touch with 'security expertise' in 15 minutes...
> 
> > misinterpreting their SLA, but this seems much different then
offering
> > blanket payments for DoS down time.
> >
> 
> downtime is seperate from this SLA.
> 
> > I will give them credit for guaranteeing a response in 15 minutes or
> > less. Now is a response the opening of a ticket or the null routing
of
> > the attack traffic in 15 minutes?
> 
> Just speaking to an engineer that can help you. There is no way to
> guarantee and end to a DoS in any reasonable amount of time ;( For
> instance, Suresh's main 'job' is email, so null routing his MX hosts
will
> stop the attack, but it is hardly desirable, eh? Same for filtering
tcp/25
> syn packets :(
> 
> There is no magic here, you all are smart enough to understand how DoS
> works, how to stop it and the complications inherent in both.

Well, kudos to you guys for raising the SLA bar to include this
provision then.

Jason

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

This sounds like a good idea for us to consider.
I think DoS attacks typically get erased in the 95% discard a lot of people use
in billing though, but it still has value for the customer.

 

 

Thanks!

 

Jason

 



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark
Kasten
Sent: Wednesday, March 03, 2004
5:35 PM
To: [EMAIL PROTECTED]
Subject: Re: UUNet Offer New
Protection Against DDoS

 

We actually accept up to the customers
aggregate.  So if they have a /16, they can tag the whole /16.  And
we do not tag no-export.  I saw some time ago on a list, and I think Bill
Manning suggested it, that if you are getting bits for unused address space, to
announce that address space (up to host specific) with the DDoS community
string.  That keeps the packets off of your link and thus you don't get
charged for them.  The same can be done in reverse.  We have a
customer that is advertising their larger block with the DDoS community string,
and then advertising the addresses they are actually using more specifically,
so we blackhole everything less specific.  These are a couple of
applications that can be utilized if you don't tag no-export and accept more
than just /32's within their address space.  FWIW.


Also, we are utilizing Juniper's DCU for tracebacks, which makes life MUCH
easier when tracing an attack.  :-)  SNMP polling the DCU counters
every few minutes is relatively fast and painless, and provides quick results.


Mark


Lumenello, Jason wrote:



Oh, and I strip their communities, and apply no-export, on the firstterm of my route map so the /32 does not get out. Of course my peerfacing policy requires specific communities to get out as well (belt andsuspenders). This method works very well, and you do not have to give up lengthrestrictions or maintain two sets of customer prefix/access lists. Jason   

-Original Message-From: Lumenello, JasonSent: Wednesday, March 03, 2004 4:52 PMTo: 'Stephen J. Wilcox'; jamesCc: [EMAIL PROTECTED]Subject: RE: UUNet Offer New Protection Against DDoS I struggled with this, and came up with the following. We basically use a standard route-map for all customers where the    

first  

term looks for the community. The customer also has a prefix-list on    

their  

neighbor statement allowing their blocks le /32. The following terms    

(term  

2 and above) in the route-map which do NOT look for the customer    

discard  

community, have a different standard/generic prefix-list evaluation    

which  

blocks cruft and permits 0.0.0.0/0 ge 8 le 24. By doing this, I only accept a customer /32 from his dedicated    

prefix-list  

when it has the DOS discard community, otherwise I catch them with the    

ge  

8 le 24 in the following terms. Jason LumenelloIP EngineeringXO Communications 

-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf  



Of  



Stephen J. WilcoxSent: Wednesday, March 03, 2004 3:48 PMTo: jamesCc: [EMAIL PROTECTED]Subject: Re: UUNet Offer New Protection Against DDoS   I'm puzzled by one aspect on the implementation.. how to build yourcustomerprefix filters.. that is, we have prefix-lists for prefix and  



length.  



Thereforeat present we can only accept a tagged route for a whole block.. not  

good    

if theannouncement is a /16 etc ! Now, I could do as per the website at secsup.org which means we have  



a  



route-mapentry to match the community before the filtering .. but that would  

allow    

thecustomer to null route any ip. What we need is one to allow them to announce any route including  



more  



specifics of the prefix list - how are folks doing this? Steve On Wed, 3 Mar 2004, james wrote:   

Global Crossing has this, already in production.I was on the phone with Qwest yesterday & this was oneof this things I asked about. Qwest indicated they aregoing to deploy this shortly. (i.e., send routes tagged witha community which they will set to null)  James EdwardsRouting and Security[EMAIL PROTECTED]At the Santa Fe Office: Internet at Cyber MesaStore hours: 9-6 Monday through Friday505-988-9200 SIP:1(747)669-1965  





   

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

No, but it sounds like SLA payouts are made in the event that they fail
to respond in 15 minutes after a call is made. Maybe I am
misinterpreting their SLA, but this seems much different then offering
blanket payments for DoS down time.

I will give them credit for guaranteeing a response in 15 minutes or
less. Now is a response the opening of a ticket or the null routing of
the attack traffic in 15 minutes?

Jason

> -Original Message-
> From: Suresh Ramasubramanian [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 03, 2004 7:21 PM
> To: Randy Bush
> Cc: [EMAIL PROTECTED]; Lumenello, Jason
> Subject: Re: UUNet Offer New Protection Against DDoS
> 
> Randy Bush  [3/4/2004 6:40 AM] :
> 
> > i think the north american idiom is putting your money where your
> > mouth is.
> 
> Thank you.  That's exactly what I was driving at.
> 
> Hmm.. one of the people in that "we've been doing this too" thread was
> XO.  Do I take it then that XO provides for DDoS downtime in its SLA?
> 
> --
> srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
> manager, outblaze.com security and antispam operations

Re: UUNet Offer New Protection Against DDoS

[Alex Bligh]

--On 03 March 2004 18:17 -0500 "Patrick W.Gilmore" <[EMAIL PROTECTED]> 
wrote:

A lot of people seem to be doing this.
there is nothing (well very little) new in the world:
http://www.merit.edu/mail.archives/nanog/1999-07/msg00083.html
Alex

Re: UUNet Offer New Protection Against DDoS

[James]

in our case, we do the following setup:

1. allow up to /32 within customer's prefix(es)
2. check for 27552:666 (null comm), if matched, set to null'd nexthop
3. now match any prefixes that are longer than /22 on 0.0.0.0/1,
   that are longer than /22 on 128.0.0.0/2, that are longer than /24
   on 192.0.0.0/3. if any of these longer prefixes are matched, tag
   them with 27552:31337 (which is our equivalent of no-export).

 If a customer has a legitimate reason to send a /24 within say,
   0.0.0.0/1, then we can always override it by adding a deny rule to
   the matching prefix-list used by the route-map.

4. finally, add maximum-prefix limit to 500

I'll be more than glad to provide config template if anyone is interested. Also
have ipv6 version of it as well if interested.

-J


On Wed, Mar 03, 2004 at 10:22:16PM +, Stephen J. Wilcox wrote:
> 
> > > I'm puzzled by one aspect on the implementation.. how to build your customer
> > > prefix filters.. that is, we have prefix-lists for prefix and length.  
> > > Therefore at present we can only accept a tagged route for a whole block..
> > > not good if the announcement is a /16 etc !
> > 
> > MCI handles this by only filtering on prefix, not length.  Well, 
> > allowing you to only announce up to your length, not shorter, but 
> > longer is allowed.
> 
> Hmm not keen, have moved acl->prefix w/len to stop folks from doing this, in 
> addition we have an extra filter which overrides anything that would deny 
> anything longer than a /24. I'm not keen to change that.. LART appears to have 
> little or no effect with my customers, preemption appears to be the only way!
> 
> Steve
> 
> 
> > > Now, I could do as per the website at secsup.org which means we have a 
> > > route-map
> > > entry to match the community before the filtering .. but that would 
> > > allow the
> > > customer to null route any ip.
> > >
> > > What we need is one to allow them to announce any route including more
> > > specifics of the prefix list - how are folks doing this?
> > 
> > It's not hard.  I think the old UUNET just used standard ACLs (1->99). 
> > :)  But with prefix filters, you can set gt & lt prefix lengths on the 
> > filters trivially.
> > 
> > Of course, your customers can then deaggregate to their hearts content. 
> >   If they do, you should hunt them down and LART them.  But it is useful 
> > for some things, especially when combined with no_export, the 
> > black-hole communities, or other communities.
> > 
> > 

-- 
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED]  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867   web: http://www.towardex.com , noc: www.twdx.net

Re: UUNet Offer New Protection Against DDoS

[David Barak]

--- "Patrick W.Gilmore" <[EMAIL PROTECTED]> wrote:
> What's wrong with letting customers announce /32s
> into your network, as 
> long as you do not pass it to anyone else (including
> other customers)?

Theoretically nothing.  However, you do need to watch
out, because there are a certain percentage of
clue-impaired folks who believe that {traffic
engineering | load-balancing | whatever mojo they're
calling it now} can be best accomplished by announcing
every /32 out of their legitimate /16 block. 

While there are certainly vendors who can take an
extra 60,000 routes with impunity, there is a lot of
gear out there which can't.  

Moral: if you let your customers advertise more
specifics to you, use maximum-prefix filters...

-David Barak-
-Fully RFC 1925 Compliant-

__
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: UUNet Offer New Protection Against DDoS

[Paul]

- Original Message - 
From: "Suresh Ramasubramanian" <[EMAIL PROTECTED]>
To: "Randy Bush" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 03, 2004 8:21 PM
Subject: Re: UUNet Offer New Protection Against DDoS


>
> Randy Bush  [3/4/2004 6:40 AM] :
>
> > i think the north american idiom is putting your money where your
> > mouth is.
>
> Thank you.  That's exactly what I was driving at.
>
> Hmm.. one of the people in that "we've been doing this too" thread was
> XO.  Do I take it then that XO provides for DDoS downtime in its SLA?

correct me if i am wrong, but uunet's sla extends to response time - the
efficacy of the response is not guaranteed, yes? hence, it is not downtime
that is compensated for, but rather unavailability of support.

paul

Re: UUNet Offer New Protection Against DDoS

[Suresh Ramasubramanian]

Randy Bush  [3/4/2004 6:40 AM] :

i think the north american idiom is putting your money where your
mouth is.
Thank you.  That's exactly what I was driving at.

Hmm.. one of the people in that "we've been doing this too" thread was 
XO.  Do I take it then that XO provides for DDoS downtime in its SLA?

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: UUNet Offer New Protection Against DDoS

[Randy Bush]

>> [..] set up a similar customer community last year for our
>> customers to
> 
> [snip a whole bunch of "we've been doing this for some time"
> posts]
> 
> Yeah - lots of ISPs have been advertising blackhole communities
> for over a year now.  However, UUNET did say they'd got an SLA
> set up for this.
> 
> So, presumably, now there's an implication if you suffer any
> downtime caused by a DoS, beyond what the SLA specifies.

i think the north american idiom is putting your money where your
mouth is.

randy, just a bozo on this bus

Re: UUNet Offer New Protection Against DDoS

[Suresh Ramasubramanian]

[..] set up a similar customer community last year for our customers to
[snip a whole bunch of "we've been doing this for some time" posts]

Yeah - lots of ISPs have been advertising blackhole communities for over 
a year now.  However, UUNET did say they'd got an SLA set up for this.

So, presumably, now there's an implication if you suffer any downtime 
caused by a DoS, beyond what the SLA specifies.

--
srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9
manager, outblaze.com security and antispam operations

Re: UUNet Offer New Protection Against DDoS

[Mark Kasten]

We actually accept up to the customers aggregate.  So if they have a
/16, they can tag the whole /16.  And we do not tag no-export.  I saw
some time ago on a list, and I think Bill Manning suggested it, that if
you are getting bits for unused address space, to announce that address
space (up to host specific) with the DDoS community string.  That keeps
the packets off of your link and thus you don't get charged for them. 
The same can be done in reverse.  We have a customer that is
advertising their larger block with the DDoS community string, and then
advertising the addresses they are actually using more specifically, so
we blackhole everything less specific.  These are a couple of
applications that can be utilized if you don't tag no-export and accept
more than just /32's within their address space.  FWIW.


Also, we are utilizing Juniper's DCU for tracebacks, which makes life
MUCH easier when tracing an attack.  :-)  SNMP polling the DCU counters
every few minutes is relatively fast and painless, and provides quick
results.


Mark


Lumenello, Jason wrote:

  Oh, and I strip their communities, and apply no-export, on the first
term of my route map so the /32 does not get out. Of course my peer
facing policy requires specific communities to get out as well (belt and
suspenders).

This method works very well, and you do not have to give up length
restrictions or maintain two sets of customer prefix/access lists.

Jason

  
  
-Original Message-
From: Lumenello, Jason
Sent: Wednesday, March 03, 2004 4:52 PM
To: 'Stephen J. Wilcox'; james
Cc: [EMAIL PROTECTED]
Subject: RE: UUNet Offer New Protection Against DDoS

I struggled with this, and came up with the following.

We basically use a standard route-map for all customers where the

  
  first
  
  
term looks for the community. The customer also has a prefix-list on

  
  their
  
  
neighbor statement allowing their blocks le /32. The following terms

  
  (term
  
  
2 and above) in the route-map which do NOT look for the customer

  
  discard
  
  
community, have a different standard/generic prefix-list evaluation

  
  which
  
  
blocks cruft and permits 0.0.0.0/0 ge 8 le 24.

By doing this, I only accept a customer /32 from his dedicated

  
  prefix-list
  
  
when it has the DOS discard community, otherwise I catch them with the

  
  ge
  
  
8 le 24 in the following terms.

Jason Lumenello
IP Engineering
XO Communications



  -Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
  

  
  Of
  
  

  Stephen J. Wilcox
Sent: Wednesday, March 03, 2004 3:48 PM
To: james
Cc: [EMAIL PROTECTED]
Subject: Re: UUNet Offer New Protection Against DDoS



I'm puzzled by one aspect on the implementation.. how to build your
customer
prefix filters.. that is, we have prefix-lists for prefix and
  

  
  length.
  
  

  Therefore
at present we can only accept a tagged route for a whole block.. not
  

good


  if the
announcement is a /16 etc !

Now, I could do as per the website at secsup.org which means we have
  

  
  a
  
  

  route-map
entry to match the community before the filtering .. but that would
  

allow


  the
customer to null route any ip.

What we need is one to allow them to announce any route including
  

  
  more
  
  

  specifics of the prefix list - how are folks doing this?

Steve

On Wed, 3 Mar 2004, james wrote:

  
  
Global Crossing has this, already in production.
I was on the phone with Qwest yesterday & this was one
of this things I asked about. Qwest indicated they are
going to deploy this shortly. (i.e., send routes tagged with
a community which they will set to null)


James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965



  

  
  
  

Re: UUNet Offer New Protection Against DDoS

[Patrick W . Gilmore]

On Mar 3, 2004, at 5:51 PM, Lumenello, Jason wrote:

I struggled with this, and came up with the following.

We basically use a standard route-map for all customers where the first
term looks for the community. The customer also has a prefix-list on
their neighbor statement allowing their blocks le /32. The following
terms (term 2 and above) in the route-map which do NOT look for the
customer discard community, have a different standard/generic
prefix-list evaluation which blocks cruft and permits 0.0.0.0/0 ge 8 le
24.
By doing this, I only accept a customer /32 from his dedicated
prefix-list when it has the DOS discard community, otherwise I catch
them with the ge 8 le 24 in the following terms.
A lot of people seem to be doing this.

Mind if I ask what's the harm of letting customers announce /32 or /29s 
into your core as long as you filter at your borders?

The additional prefixes are not going to kill your routers, and it 
allows the customer more finely tuned traffic controls.  IOW: Seems 
there is some utility and no harm.

--
TTFN,
patrick

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

Oh, and I strip their communities, and apply no-export, on the first
term of my route map so the /32 does not get out. Of course my peer
facing policy requires specific communities to get out as well (belt and
suspenders).

This method works very well, and you do not have to give up length
restrictions or maintain two sets of customer prefix/access lists.

Jason

> -Original Message-
> From: Lumenello, Jason
> Sent: Wednesday, March 03, 2004 4:52 PM
> To: 'Stephen J. Wilcox'; james
> Cc: [EMAIL PROTECTED]
> Subject: RE: UUNet Offer New Protection Against DDoS
> 
> I struggled with this, and came up with the following.
> 
> We basically use a standard route-map for all customers where the
first
> term looks for the community. The customer also has a prefix-list on
their
> neighbor statement allowing their blocks le /32. The following terms
(term
> 2 and above) in the route-map which do NOT look for the customer
discard
> community, have a different standard/generic prefix-list evaluation
which
> blocks cruft and permits 0.0.0.0/0 ge 8 le 24.
> 
> By doing this, I only accept a customer /32 from his dedicated
prefix-list
> when it has the DOS discard community, otherwise I catch them with the
ge
> 8 le 24 in the following terms.
> 
> Jason Lumenello
> IP Engineering
> XO Communications
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> > Stephen J. Wilcox
> > Sent: Wednesday, March 03, 2004 3:48 PM
> > To: james
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: UUNet Offer New Protection Against DDoS
> >
> >
> >
> > I'm puzzled by one aspect on the implementation.. how to build your
> > customer
> > prefix filters.. that is, we have prefix-lists for prefix and
length.
> > Therefore
> > at present we can only accept a tagged route for a whole block.. not
> good
> > if the
> > announcement is a /16 etc !
> >
> > Now, I could do as per the website at secsup.org which means we have
a
> > route-map
> > entry to match the community before the filtering .. but that would
> allow
> > the
> > customer to null route any ip.
> >
> > What we need is one to allow them to announce any route including
more
> > specifics of the prefix list - how are folks doing this?
> >
> > Steve
> >
> > On Wed, 3 Mar 2004, james wrote:
> >
> > >
> > > Global Crossing has this, already in production.
> > > I was on the phone with Qwest yesterday & this was one
> > > of this things I asked about. Qwest indicated they are
> > > going to deploy this shortly. (i.e., send routes tagged with
> > > a community which they will set to null)
> > >
> > >
> > > James Edwards
> > > Routing and Security
> > > [EMAIL PROTECTED]
> > > At the Santa Fe Office: Internet at Cyber Mesa
> > > Store hours: 9-6 Monday through Friday
> > > 505-988-9200 SIP:1(747)669-1965
> > >
> > >

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

I struggled with this, and came up with the following.

We basically use a standard route-map for all customers where the first
term looks for the community. The customer also has a prefix-list on
their neighbor statement allowing their blocks le /32. The following
terms (term 2 and above) in the route-map which do NOT look for the
customer discard community, have a different standard/generic
prefix-list evaluation which blocks cruft and permits 0.0.0.0/0 ge 8 le
24.

By doing this, I only accept a customer /32 from his dedicated
prefix-list when it has the DOS discard community, otherwise I catch
them with the ge 8 le 24 in the following terms.

Jason Lumenello
IP Engineering
XO Communications

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Stephen J. Wilcox
> Sent: Wednesday, March 03, 2004 3:48 PM
> To: james
> Cc: [EMAIL PROTECTED]
> Subject: Re: UUNet Offer New Protection Against DDoS
> 
> 
> 
> I'm puzzled by one aspect on the implementation.. how to build your
> customer
> prefix filters.. that is, we have prefix-lists for prefix and length.
> Therefore
> at present we can only accept a tagged route for a whole block.. not
good
> if the
> announcement is a /16 etc !
> 
> Now, I could do as per the website at secsup.org which means we have a
> route-map
> entry to match the community before the filtering .. but that would
allow
> the
> customer to null route any ip.
> 
> What we need is one to allow them to announce any route including more
> specifics of the prefix list - how are folks doing this?
> 
> Steve
> 
> On Wed, 3 Mar 2004, james wrote:
> 
> >
> > Global Crossing has this, already in production.
> > I was on the phone with Qwest yesterday & this was one
> > of this things I asked about. Qwest indicated they are
> > going to deploy this shortly. (i.e., send routes tagged with
> > a community which they will set to null)
> >
> >
> > James Edwards
> > Routing and Security
> > [EMAIL PROTECTED]
> > At the Santa Fe Office: Internet at Cyber Mesa
> > Store hours: 9-6 Monday through Friday
> > 505-988-9200 SIP:1(747)669-1965
> >
> >

Re: UUNet Offer New Protection Against DDoS

[Mark Kasten]

We still implement exact match prefix filtering, but also generate a 
second "aggregated" prefix-list for customers to match more specifics.  
If a prefix matches 3561:666 _and_ falls within the DDoS/aggregated 
prefix-list, we accept it and blackhole it.  If a customer announces the 
more specific without the community, we won't accept it.  (No flame wars 
about exact match filtering please).  Yes, that means we maintain two 
prefix-lists for each customer. 

uRPF is another matter.  We use policies for prefix-lists on Junipers 
and prefix-lists on Cisco's, which means that if we want to do strict 
uRPF for customers we have to generate a third prefix-list/acl?  

Regards,
   Mark Kasten
   C&W^H^H^H^Savvis
.

Stephen J. Wilcox wrote:

I'm puzzled by one aspect on the implementation.. how to build your customer 
prefix filters.. that is, we have prefix-lists for prefix and length. Therefore 
at present we can only accept a tagged route for a whole block.. not good if the 
announcement is a /16 etc !

Now, I could do as per the website at secsup.org which means we have a route-map 
entry to match the community before the filtering .. but that would allow the 
customer to null route any ip. 

What we need is one to allow them to announce any route including more 
specifics of the prefix list - how are folks doing this?

Steve

On Wed, 3 Mar 2004, james wrote:

 

Global Crossing has this, already in production. 
I was on the phone with Qwest yesterday & this was one
of this things I asked about. Qwest indicated they are
going to deploy this shortly. (i.e., send routes tagged with
a community which they will set to null)

James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
   

 

Re: UUNet Offer New Protection Against DDoS

[Patrick W . Gilmore]

On Mar 3, 2004, at 5:22 PM, Stephen J. Wilcox wrote:

I'm puzzled by one aspect on the implementation.. how to build your 
customer
prefix filters.. that is, we have prefix-lists for prefix and length.
Therefore at present we can only accept a tagged route for a whole 
block..
not good if the announcement is a /16 etc !
MCI handles this by only filtering on prefix, not length.  Well,
allowing you to only announce up to your length, not shorter, but
longer is allowed.
Hmm not keen, have moved acl->prefix w/len to stop folks from doing 
this, in
addition we have an extra filter which overrides anything that would 
deny
anything longer than a /24. I'm not keen to change that.. LART appears 
to have
little or no effect with my customers, preemption appears to be the 
only way!
What's wrong with letting customers announce /32s into your network, as 
long as you do not pass it to anyone else (including other customers)?

Here is what I did (when I had a network =) :
  * Prefix filter customers in, allowing more specifics
  * Filter > /24s & Bogons out to customers
  * Bogon & /24 filter peers in
  * Bogon, /24, and cust-only community filter peers out
Theoretically, the Bogon out filters are irrelevant, since your table 
should be clean from the inbound filters, but I like "belt and 
suspenders".  (Plus one day I leaked a slew of 10-net from a NOC test 
LAN and hit one of the Merit instability mailing lists.  Burned once, 
twice shy. :)

--
TTFN,
patrick

Re: UUNet Offer New Protection Against DDoS

[Stephen J. Wilcox]

> > I'm puzzled by one aspect on the implementation.. how to build your customer
> > prefix filters.. that is, we have prefix-lists for prefix and length.  
> > Therefore at present we can only accept a tagged route for a whole block..
> > not good if the announcement is a /16 etc !
> 
> MCI handles this by only filtering on prefix, not length.  Well, 
> allowing you to only announce up to your length, not shorter, but 
> longer is allowed.

Hmm not keen, have moved acl->prefix w/len to stop folks from doing this, in 
addition we have an extra filter which overrides anything that would deny 
anything longer than a /24. I'm not keen to change that.. LART appears to have 
little or no effect with my customers, preemption appears to be the only way!

Steve


> > Now, I could do as per the website at secsup.org which means we have a 
> > route-map
> > entry to match the community before the filtering .. but that would 
> > allow the
> > customer to null route any ip.
> >
> > What we need is one to allow them to announce any route including more
> > specifics of the prefix list - how are folks doing this?
> 
> It's not hard.  I think the old UUNET just used standard ACLs (1->99). 
> :)  But with prefix filters, you can set gt & lt prefix lengths on the 
> filters trivially.
> 
> Of course, your customers can then deaggregate to their hearts content. 
>   If they do, you should hunt them down and LART them.  But it is useful 
> for some things, especially when combined with no_export, the 
> black-hole communities, or other communities.
> 
> 

Re: UUNet Offer New Protection Against DDoS

[Patrick W . Gilmore]

On Mar 3, 2004, at 4:47 PM, Stephen J. Wilcox wrote:

I'm puzzled by one aspect on the implementation.. how to build your 
customer
prefix filters.. that is, we have prefix-lists for prefix and length. 
Therefore
at present we can only accept a tagged route for a whole block.. not 
good if the
announcement is a /16 etc !
MCI handles this by only filtering on prefix, not length.  Well, 
allowing you to only announce up to your length, not shorter, but 
longer is allowed.


Now, I could do as per the website at secsup.org which means we have a 
route-map
entry to match the community before the filtering .. but that would 
allow the
customer to null route any ip.

What we need is one to allow them to announce any route including more
specifics of the prefix list - how are folks doing this?
It's not hard.  I think the old UUNET just used standard ACLs (1->99). 
:)  But with prefix filters, you can set gt & lt prefix lengths on the 
filters trivially.

Of course, your customers can then deaggregate to their hearts content. 
 If they do, you should hunt them down and LART them.  But it is useful 
for some things, especially when combined with no_export, the 
black-hole communities, or other communities.

--
TTFN,
patrick

RE: UUNet Offer New Protection Against DDoS

[Terranson, Alif]

As long as we're doing "Me Too"...

Savvis has had prefix:666 for around 18 months as well.

Alif Terranson
OpSec Engineering Manager
Operations Security Department
Savvis Communications Corporation

(314) 628-7602 Voice
(314) 208-2306 Pager
(618) 558-5854 Cell
> -Original Message-
> From: Michael Hallgren [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 03, 2004 3:45 PM
> To: [EMAIL PROTECTED]
> Subject: RE: UUNet Offer New Protection Against DDoS
> 
> 
> 
> > 
> > Global Crossing has this, already in production.
> 
> Idem, Teleglobe,
> 
> mh
> 
> > I was on the phone with Qwest yesterday & this was one of
> > this things I asked about. Qwest indicated they are going to 
> > deploy this shortly. (i.e., send routes tagged with a 
> > community which they will set to null)
> > 
> > 
> > James Edwards
> > Routing and Security
> > [EMAIL PROTECTED]
> > At the Santa Fe Office: Internet at Cyber Mesa Store hours:
> > 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
> > 
> > 
> > 
> 
> 
> 

Re: UUNet Offer New Protection Against DDoS

[Deepak Jain]

So maybe a guy with customer connections to each of these networks will 
offer a BGP-redirector whereby you can send it 1 prefix and it will send 
it to all the customer networks.

Boy. Is that abusable. eesh.

Deepak Jain
AiNET
james wrote:

Global Crossing has this, already in production. 
I was on the phone with Qwest yesterday & this was one
of this things I asked about. Qwest indicated they are
going to deploy this shortly. (i.e., send routes tagged with
a community which they will set to null)

James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965

Re: UUNet Offer New Protection Against DDoS

[Stephen J. Wilcox]

I'm puzzled by one aspect on the implementation.. how to build your customer 
prefix filters.. that is, we have prefix-lists for prefix and length. Therefore 
at present we can only accept a tagged route for a whole block.. not good if the 
announcement is a /16 etc !

Now, I could do as per the website at secsup.org which means we have a route-map 
entry to match the community before the filtering .. but that would allow the 
customer to null route any ip. 

What we need is one to allow them to announce any route including more 
specifics of the prefix list - how are folks doing this?

Steve

On Wed, 3 Mar 2004, james wrote:

> 
> Global Crossing has this, already in production. 
> I was on the phone with Qwest yesterday & this was one
> of this things I asked about. Qwest indicated they are
> going to deploy this shortly. (i.e., send routes tagged with
> a community which they will set to null)
> 
> 
> James Edwards
> Routing and Security
> [EMAIL PROTECTED]
> At the Santa Fe Office: Internet at Cyber Mesa
> Store hours: 9-6 Monday through Friday
> 505-988-9200 SIP:1(747)669-1965
> 
> 

RE: UUNet Offer New Protection Against DDoS

[Michael Hallgren]

> 
> Global Crossing has this, already in production. 

Idem, Teleglobe,

mh

> I was on the phone with Qwest yesterday & this was one of 
> this things I asked about. Qwest indicated they are going to 
> deploy this shortly. (i.e., send routes tagged with a 
> community which they will set to null)
> 
> 
> James Edwards
> Routing and Security
> [EMAIL PROTECTED]
> At the Santa Fe Office: Internet at Cyber Mesa Store hours: 
> 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
> 
> 
> 

Re: UUNet Offer New Protection Against DDoS

[james]

Global Crossing has this, already in production. 
I was on the phone with Qwest yesterday & this was one
of this things I asked about. Qwest indicated they are
going to deploy this shortly. (i.e., send routes tagged with
a community which they will set to null)


James Edwards
Routing and Security
[EMAIL PROTECTED]
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965

RE: UUNet Offer New Protection Against DDoS

[Lumenello, Jason]

XO set up a similar customer community last year for our customers to
trigger their own black hole at our edge. There is no such thing as an
original idea. :) This "promised response" probably means if you press 3
on your phone, you will get a CSR to open a ticket within 15 minutes.
Sounds like nice marketing.

Jason

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
> Stephen Perciballi
> Sent: Wednesday, March 03, 2004 12:25 PM
> To: Andy Ellifson
> Cc: [EMAIL PROTECTED]
> Subject: Re: UUNet Offer New Protection Against DDoS
> 
> 
> 
> To the best of my knowledge, MCI/UUNET ~was~ the first to implement
this.
> I've
> been using it for well over a year now.
> 
> The community is 701:.  Any route you tag with that community gets
> dropped
> accross the entire 701 edge.  Feel free to contact support and tell
them
> you
> want to setup the blackhole community if you are having any troubles.
> 
> [Wed, Mar 03, 2004 at 08:34:00AM -0800]
> Andy Ellifson Inscribed these words...
> 
> 
> >
> > When I first saw this post I thought that MCI/UU.Net implemented
some
> DDOS
> > BGP community strings like CW implemented a month ago.  If only all
of
> my
> > upstreams would have this type of BGP Community string my life would
be
> made
> > easier.  Here is the customer release letter from from CW dated
Januray
> 23,
> > 2004:
> >
> > Dear Customer,
> >
> > If you have received this email, you are either a direct customer of
> > AS3561, (i.e. you have registered a route object for a customer of
> AS3561),
> > or are listed in the maintainer of a customer of AS3561.
> >
> > AS3561 has implemented a blackhole/DDoS community string based
solution
> to
> > aid customers in the mitigation of DoS attacks. If you are currently
> running
> > BGP with us, you will be able to use this feature.
> >
> > If you advertise a prefix (route) to us with the community string
> > 3561:666, we will NULL route or 'blackhole' all traffic destined to
that
> > prefix. The prefixes accepted are based on the current prefix-list
> generated
> > for you. Instead of doing exact match filtering, we will accept any
> prefix
> > (more "specific") within your address block(s). e.g. if you have
> > 192.168.0.0/16 registered, we will accept 192.168.0.0/16 upto /32 as
> long as
> > the 3561:666 community string is attached.
> >
> > Please ensure you are configured to send community strings and
> understand
> > the impact of errant advertisements. Diligence should be used when
> > administrating this feature. Once the prefix is received and
propagated
> > within AS3561, all traffic destined to the prefix will be discarded
and
> the
> > blackholing of traffic will continue as long as DDoS community
string is
> > being advertised. Neither Cable & Wireless nor AS3561 will be held
> liable
> > or responsible for customers who errantly advertise prefixes with
the
> > blackhole community string.
> >
> > If you wish to utilize this feature, you can verify our acceptance
of
> the
> > advertised prefix by querying the AS3561 route server located at
> > http://lg.cw.net.
> >
> > Please remember, we require you to complete a priority one incident
> report
> > at http://www.security.cw.net (Report an Incident) and include
details
> of the
> >
> > attack. An email describing further details of the attack can be
sent to
> > [EMAIL PROTECTED], please include the incident report number in the
> subject to
> > assist in the tracking and documentation of the incident. This will
> ensure
> > the attack is properly administrated handled by our Security and
Legal
> > Groups.
> >
> >
> >
> > --- John Obi <[EMAIL PROTECTED]> wrote:
> > > Hello Nanogers!
> > >
> > > I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc
will do
> the
> > > same!
> > >
> > > MCI/WorldCom Monday unveiled a new service level agreement (SLA)
to
> help IP
> > > services customers thwart and defend against Internet viruses and
> threats.
> > >
> > > http://informationweek.securitypipeline.com/news/18201396
> > >
> > > It's the right time before it's too late!
> > >
> > > Regards,
> > >
> > > -J
> > >
> > >
> > > -
> > > Do you Yahoo!?
> > > Yahoo! Search - Find what you're looking for faster.
> >
> 
> --
> 
> Stephen (routerg)
> irc.dks.ca

Re: UUNet Offer New Protection Against DDoS

[Rob Thomas]

Hi, NANOGers.

] When I first saw this post I thought that MCI/UU.Net implemented some DDOS
] BGP community strings like CW implemented a month ago.  If only all of my
] upstreams would have this type of BGP Community string my life would be made
] easier.  Here is the customer release letter from from CW dated Januray 23,
] 2004:

UUNET/MCI has had that capability since circa 2002, I believe.  Several
ISPs borrowed heavily from the following page to create similar services.

   

Kudos to Chris and Brian.  :)

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: UUNet Offer New Protection Against DDoS

[Danny McPherson]

On Mar 3, 2004, at 11:24 AM, Stephen Perciballi wrote:
To the best of my knowledge, MCI/UUNET ~was~ the first to implement 
this.  I've
been using it for well over a year now.
Indeed.  One could even get "fancy" and set of different community
sets to allow customers to drop traffic only on peering routers (as
opposed to customer or all routers, etc..).  The "Customer-Triggered
Real Time Blackhole" tutorial that Chris, Tim and I gave in Miami
talks about how to go about doing this.
One step further is uRPF coupling with blackhole routing for sourced-
based drops, though I suspect you probably won't want to do this
with customers :-)
Finally, the BGP Flow Specification stuff provides a start at a more
granular BGP-based method by employing new AFI/SAFI.  If you've got
feedback please pass it along.
http://www.tcb.net/draft-marques-idr-flow-spec-00.txt

-danny

Re: UUNet Offer New Protection Against DDoS

[Stephen Perciballi]

To the best of my knowledge, MCI/UUNET ~was~ the first to implement this.  I've
been using it for well over a year now.  

The community is 701:.  Any route you tag with that community gets dropped
accross the entire 701 edge.  Feel free to contact support and tell them you
want to setup the blackhole community if you are having any troubles.

[Wed, Mar 03, 2004 at 08:34:00AM -0800]
Andy Ellifson Inscribed these words...


> 
> When I first saw this post I thought that MCI/UU.Net implemented some DDOS
> BGP community strings like CW implemented a month ago.  If only all of my
> upstreams would have this type of BGP Community string my life would be made
> easier.  Here is the customer release letter from from CW dated Januray 23,
> 2004:
> 
> Dear Customer, 
> 
> If you have received this email, you are either a direct customer of 
> AS3561, (i.e. you have registered a route object for a customer of AS3561), 
> or are listed in the maintainer of a customer of AS3561. 
> 
> AS3561 has implemented a blackhole/DDoS community string based solution to 
> aid customers in the mitigation of DoS attacks. If you are currently running 
> BGP with us, you will be able to use this feature. 
> 
> If you advertise a prefix (route) to us with the community string 
> 3561:666, we will NULL route or 'blackhole' all traffic destined to that 
> prefix. The prefixes accepted are based on the current prefix-list generated 
> for you. Instead of doing exact match filtering, we will accept any prefix 
> (more "specific") within your address block(s). e.g. if you have 
> 192.168.0.0/16 registered, we will accept 192.168.0.0/16 upto /32 as long as 
> the 3561:666 community string is attached. 
> 
> Please ensure you are configured to send community strings and understand 
> the impact of errant advertisements. Diligence should be used when 
> administrating this feature. Once the prefix is received and propagated 
> within AS3561, all traffic destined to the prefix will be discarded and the 
> blackholing of traffic will continue as long as DDoS community string is 
> being advertised. Neither Cable & Wireless nor AS3561 will be held liable 
> or responsible for customers who errantly advertise prefixes with the 
> blackhole community string. 
> 
> If you wish to utilize this feature, you can verify our acceptance of the 
> advertised prefix by querying the AS3561 route server located at 
> http://lg.cw.net. 
> 
> Please remember, we require you to complete a priority one incident report 
> at http://www.security.cw.net (Report an Incident) and include details of the
> 
> attack. An email describing further details of the attack can be sent to 
> [EMAIL PROTECTED], please include the incident report number in the subject to 
> assist in the tracking and documentation of the incident. This will ensure 
> the attack is properly administrated handled by our Security and Legal 
> Groups. 
> 
> 
> 
> --- John Obi <[EMAIL PROTECTED]> wrote:
> > Hello Nanogers!
> >  
> > I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc will do the
> > same!
> >  
> > MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP
> > services customers thwart and defend against Internet viruses and threats. 
> >  
> > http://informationweek.securitypipeline.com/news/18201396
> >  
> > It's the right time before it's too late!
> >  
> > Regards,
> >  
> > -J
> > 
> > 
> > -
> > Do you Yahoo!?
> > Yahoo! Search - Find what you’re looking for faster.
> 

-- 

Stephen (routerg)
irc.dks.ca

Re: UUNet Offer New Protection Against DDoS

[Andy Ellifson]

When I first saw this post I thought that MCI/UU.Net implemented some DDOS
BGP community strings like CW implemented a month ago.  If only all of my
upstreams would have this type of BGP Community string my life would be made
easier.  Here is the customer release letter from from CW dated Januray 23,
2004:

Dear Customer, 

If you have received this email, you are either a direct customer of 
AS3561, (i.e. you have registered a route object for a customer of AS3561), 
or are listed in the maintainer of a customer of AS3561. 

AS3561 has implemented a blackhole/DDoS community string based solution to 
aid customers in the mitigation of DoS attacks. If you are currently running 
BGP with us, you will be able to use this feature. 

If you advertise a prefix (route) to us with the community string 
3561:666, we will NULL route or 'blackhole' all traffic destined to that 
prefix. The prefixes accepted are based on the current prefix-list generated 
for you. Instead of doing exact match filtering, we will accept any prefix 
(more "specific") within your address block(s). e.g. if you have 
192.168.0.0/16 registered, we will accept 192.168.0.0/16 upto /32 as long as 
the 3561:666 community string is attached. 

Please ensure you are configured to send community strings and understand 
the impact of errant advertisements. Diligence should be used when 
administrating this feature. Once the prefix is received and propagated 
within AS3561, all traffic destined to the prefix will be discarded and the 
blackholing of traffic will continue as long as DDoS community string is 
being advertised. Neither Cable & Wireless nor AS3561 will be held liable 
or responsible for customers who errantly advertise prefixes with the 
blackhole community string. 

If you wish to utilize this feature, you can verify our acceptance of the 
advertised prefix by querying the AS3561 route server located at 
http://lg.cw.net. 

Please remember, we require you to complete a priority one incident report 
at http://www.security.cw.net (Report an Incident) and include details of the

attack. An email describing further details of the attack can be sent to 
[EMAIL PROTECTED], please include the incident report number in the subject to 
assist in the tracking and documentation of the incident. This will ensure 
the attack is properly administrated handled by our Security and Legal 
Groups. 



--- John Obi <[EMAIL PROTECTED]> wrote:
> Hello Nanogers!
>  
> I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc will do the
> same!
>  
> MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP
> services customers thwart and defend against Internet viruses and threats. 
>  
> http://informationweek.securitypipeline.com/news/18201396
>  
> It's the right time before it's too late!
>  
> Regards,
>  
> -J
> 
> 
> -
> Do you Yahoo!?
> Yahoo! Search - Find what you’re looking for faster.

RE: UUNet Offer New Protection Against DDoS

[Terranson, Alif]

Hi John,

While the formalities of the C&W acquisition have yet to kick in, I
have no reason to believe that anything will change here:  Savvis
pioneered the 15 minute response time for DoS issues - whether or not
it's our customer calling in.  If it involves Savvis customers in any
way, we will have the oncall security person on the phone and working
the issue in less than 15 minutes - *always* (usual times are closer to
3 minutes because of the oncall cell phone).

//Alif

Alif Terranson
OpSec Engineering Manager
Operations Security Department
Savvis Communications Corporation

(314) 628-7602 Voice
(314) 208-2306 Pager
(618) 558-5854 Cell 
-Original Message-
From: John Obi [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 03, 2004 1:21 AM
To: [EMAIL PROTECTED]
Subject: UUNet Offer New Protection Against DDoS


Hello Nanogers!

I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc will do
the same!

MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help
IP services customers thwart and defend against Internet viruses and
threats. 

http://informationweek.securitypipeline.com/news/18201396

It's the right time before it's too late!

Regards,

-J


Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster.

Re: UUNet Offer New Protection Against DDoS

[Randy Bush]

> i expect most ddos attack issues to be *resolved* within 15
> minutes, for reasonable values of 'most' and 'resolved'.

the vast majority of isps don't meet your expectations by a
long shot.  uunet has put a lot of effort into doing so, and
has been pretty successful.  instead of badmouthing them, we
should be emulating them.

randy

Re: UUNet Offer New Protection Against DDoS

[Stephen Perciballi]

The key here is that it is part of the SLA.  Customers are elligible for credit
based on outages depending on the circumstance.  In the past this was only telco
and backbone related outages.  Therefore, depending on the nature of the attack
and the cooperation of the customer, they ~may~ be elligible for partial credit.


[Wed, Mar 03, 2004 at 12:42:05AM -0800]
william(at)elan.net Inscribed these words...


> 
> On Tue, 2 Mar 2004, John Obi wrote:
> > Hello Nanogers!
> >  
> > I'm happy to see this, and I hope C&W, Verio, and Level3 will do the same!
> > http://informationweek.securitypipeline.com/news/18201396
> 
> "MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help 
>  IP services customers thwart and defend against Internet viruses and threats. 
> 
>  The new SLA is focused on Denial of Service (DoS) attacks and is extended 
>  immediately for free to all current customers of the telecommunications 
>  company, according to MCI. It ensures that all MCI Internet customers will 
>  have immediate access to the company's security staff to help them rapidly 
>  address and mitigate DoS attacks
> 
>  According to Santarelli, MCI will guarantee a response to suspected DoS 
>  attacks within 15 minutes of a customer-generated trouble-ticket through 
>  MCI Customer Support"
> 
> Blah, blah, blah I would say this is a lot more like a self-ad then 
> press-release of new service. UUNET already responded within 15 minutes 
> or less to DoS attacks, at least this is what it was several years ago. 
> Possibly this changed when they went ch11 and now they are just trying to 
> get back to normal. But I would not say that this is anything "special". 
> 
> Of course, I would be happy to see others say the same too in their SLA, but
> how about that they simply would just RESPOND in 15 minute to customer request.
> (And actually one of my upstreams does exactly that they respond and have that
>  in their SLA. And they usually respond within 1-3 minutes and not only do 
>  I not have to call them, but they actually call me if the link is down or 
>  if there is serious congestion on it. Quite a a bit overzellous actually!)
> 
> -- 
> William Leibzon
> Elan Networks
> [EMAIL PROTECTED]
> 

-- 

Stephen (routerg)
irc.dks.ca

Re: UUNet Offer New Protection Against DDoS

[Erik Haagsman]

Hi Paul,


> correct. from our pov, it is gone. given that 'solving the problem' is not
> always possible, this is almost as good as it gets in the real world.

Fully agree, and this is basically the way it should be: a customer
shouldn't be concerned about the carrier solving the problem or not, as
long as service isn't interrupted the carrier is doing the job he's
promised to do in his SLA

> we tend to get small ddos (a few hundred megs) that are more of an annoyance
> than anything else, at least before they hit the customer-in-question 's
> faste handoff.

This is a bit more problematic IMHO. A "small DoS" is very
geographically dependent and very "supporting party" dependent: in Ghana
with BT as the only provider running over DS3, a few hundred megs means
the entire network is cut-off for ages :-)
I know this is NANOG and bandwidth is a simple commodity, but even in
our parts of the western world bandwidth can be hard to come by and a
few hundred megs might be a bigger deal to a smaller NSP's network.

> . in other news, noone has solved the perpetuum mobile problem either.
> as a carrier, your job is to solve the problem for the customer. this
> includes staying up afterwards.

Hehe...sadly this perpetuum mobile keeps on running and running (which
is what it's supposed to do literally :-) but you're completely right:
cutomers should always come first and "hiding" the problem is our only
option at the moment. I'm still waiting for that press-release though
:-)

Regards,

Erik

> 
> paul
-- 
---
Erik Haagsman
Network Architect
> > I haven't seen any major press-releases on actually solving the problem
> > instead of hiding it... (granted...I haven't put out one either :-)
> 
We Dare BV
tel: +31.10.7507008
fax: +31.10.7507005
http://www.we-dare.nl

RE: UUNet Offer New Protection Against DDoS

[Douglas.Dever]

From: On Behalf Of John Obi
Sent: Wednesday, March 03, 2004 2:21 AM

> MCI/WorldCom Monday unveiled a new service level agreement (SLA) 

At the risk of sounding thoroughly underwhelmed...  Uhm, where's the beef?  All I see 
is the opportunity to get a service credit should one complain loud enough after a DoS 
attack.  Maybe I'm missing something here, but I doubt it.  I've never seen an SLA 
that guarantees 5 9's of reliability keep a T1 from going down - but the paper it was 
written on was nice... somewhat soft, and you didn't have to worry about your finger 
poking through it.


--
Douglas A. Dever
ACI/IT Network Services
ALLTEL Communications Inc.
330.963.1720
**
The information contained in this message, including attachments, may contain 
privileged or confidential information that is intended to be delivered only to the 
person identified above. If you are not the intended recipient, or the person 
responsible for delivering this message to the intended recipient, ALLTEL requests 
that you immediately notify the sender and asks that you do not read the message or 
its 
attachments, and that you delete them without copying or sending them to anyone else. 

Re: UUNet Offer New Protection Against DDoS

[Paul G]

erik,

- Original Message - 
From: "Erik Haagsman" <[EMAIL PROTECTED]>
To: "Paul G" <[EMAIL PROTECTED]>
Cc: "Deepak Jain" <[EMAIL PROTECTED]>; "william(at)elan.net" <[EMAIL PROTECTED]>;
"John Obi" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 03, 2004 3:47 AM
Subject: Re: UUNet Offer New Protection Against DDoS


>
> On Wed, 2004-03-03 at 09:26, Paul G wrote:
> > cant speak for them, but this would be my preferred first step. next
step
> > is, of course, an attempt to filter on {source, unique characteristics,
what
> > have you} and removing the blackhole.
>
> What most people seem to forget is that neither of these steps actually
> counter the DoS...they merely make the DoS as invisible as possible to
> customers

correct. from our pov, it is gone. given that 'solving the problem' is not
always possible, this is almost as good as it gets in the real world.

> while the traffic keeps hitting the carrier in question. For
> the large carriers this is only a minor inconvenience.
> For smaller carriers or for co-location facilities/NSP's that are
> relying on not-so-clueful carriers (read: carriers not supporting any
> kind of communities with possible lack of pro-active network management
> and/or bad communications) this is a BIG problem. Even though they might
> take the heat off the targeted customer, they could be in for a rough
> ride themselves as the DoS keeps going and going.

we tend to get small ddos (a few hundred megs) that are more of an annoyance
than anything else, at least before they hit the customer-in-question 's
faste handoff.

> I haven't seen any major press-releases on actually solving the problem
> instead of hiding it... (granted...I haven't put out one either :-)

. in other news, noone has solved the perpetuum mobile problem either.
as a carrier, your job is to solve the problem for the customer. this
includes staying up afterwards.

paul

Re: UUNet Offer New Protection Against DDoS

[Erik Haagsman]

On Wed, 2004-03-03 at 09:26, Paul G wrote:
> cant speak for them, but this would be my preferred first step. next step
> is, of course, an attempt to filter on {source, unique characteristics, what
> have you} and removing the blackhole.

What most people seem to forget is that neither of these steps actually
counter the DoS...they merely make the DoS as invisible as possible to
customers while the traffic keeps hitting the carrier in question. For
the large carriers this is only a minor inconvenience. 
For smaller carriers or for co-location facilities/NSP's that are
relying on not-so-clueful carriers (read: carriers not supporting any
kind of communities with possible lack of pro-active network management
and/or bad communications) this is a BIG problem. Even though they might
take the heat off the targeted customer, they could be in for a rough
ride themselves as the DoS keeps going and going.
I haven't seen any major press-releases on actually solving the problem
instead of hiding it... (granted...I haven't put out one either :-)

Cheers,


-- 
---
Erik Haagsman
Network Architect
We Dare BV
tel: +31.10.7507008
fax: +31.10.7507005
http://www.we-dare.nl

Re: UUNet Offer New Protection Against DDoS

[Paul G]

- Original Message - 
From: "Deepak Jain" <[EMAIL PROTECTED]>
To: "william(at)elan.net" <[EMAIL PROTECTED]>
Cc: "John Obi" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 03, 2004 2:56 AM
Subject: Re: UUNet Offer New Protection Against DDoS


>
>
> william(at)elan.net wrote:
>
> > On Tue, 2 Mar 2004, John Obi wrote:
> >
> >>Hello Nanogers!
> >>
> >>I'm happy to see this, and I hope C&W, Verio, and Level3 will do the
same!
> >>http://informationweek.securitypipeline.com/news/18201396
> >
>
>
> And what kind of response to DOS are we talking about? Blackholing the
> target IP to allow your pipe to pass packets and so that your router is
> pingable (which is probably the measure for whether you are up or not?)

cant speak for them, but this would be my preferred first step. next step
is, of course, an attempt to filter on {source, unique characteristics, what
have you} and removing the blackhole.

paul

Re: UUNet Offer New Protection Against DDoS

[Paul G]

- Original Message - 
From: "william(at)elan.net" <[EMAIL PROTECTED]>
To: "John Obi" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, March 03, 2004 3:42 AM
Subject: Re: UUNet Offer New Protection Against DDoS


>
> On Tue, 2 Mar 2004, John Obi wrote:
> > Hello Nanogers!
> >
> > I'm happy to see this, and I hope C&W, Verio, and Level3 will do the
same!
> > http://informationweek.securitypipeline.com/news/18201396
>
> "MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help
>  IP services customers thwart and defend against Internet viruses and
threats.

--- snippety snip ---

>
> Blah, blah, blah I would say this is a lot more like a self-ad then
> press-release of new service. UUNET already responded within 15 minutes
> or less to DoS attacks, at least this is what it was several years ago.
> Possibly this changed when they went ch11 and now they are just trying to
> get back to normal. But I would not say that this is anything "special".
>
> Of course, I would be happy to see others say the same too in their SLA,
but
> how about that they simply would just RESPOND in 15 minute to customer
request.
> (And actually one of my upstreams does exactly that they respond and have
that
>  in their SLA. And they usually respond within 1-3 minutes and not only do
>  I not have to call them, but they actually call me if the link is down or
>  if there is serious congestion on it. Quite a a bit overzellous
actually!)

agreed, not very spectacular. in fact, i expect most ddos attack issues to
be *resolved* within 15 minutes, for reasonable values of 'most' and
'resolved'. i would probably be very dissatisfied if i could not get to a
warm, clueful and enabled body in under 10 minutes in an emergency, but then
we are a reasonably large customer of a good smaller carrier so my
expectations may be invalid in big boy customer land.

paul

Re: UUNet Offer New Protection Against DDoS

[Deepak Jain]

william(at)elan.net wrote:

On Tue, 2 Mar 2004, John Obi wrote:

Hello Nanogers!

I'm happy to see this, and I hope C&W, Verio, and Level3 will do the same!
http://informationweek.securitypipeline.com/news/18201396



And what kind of response to DOS are we talking about? Blackholing the 
target IP to allow your pipe to pass packets and so that your router is 
pingable (which is probably the measure for whether you are up or not?)

Deepak Jain
AiNET

Re: UUNet Offer New Protection Against DDoS

[william(at)elan.net]

On Tue, 2 Mar 2004, John Obi wrote:
> Hello Nanogers!
>  
> I'm happy to see this, and I hope C&W, Verio, and Level3 will do the same!
> http://informationweek.securitypipeline.com/news/18201396

"MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help 
 IP services customers thwart and defend against Internet viruses and threats. 

 The new SLA is focused on Denial of Service (DoS) attacks and is extended 
 immediately for free to all current customers of the telecommunications 
 company, according to MCI. It ensures that all MCI Internet customers will 
 have immediate access to the company's security staff to help them rapidly 
 address and mitigate DoS attacks

 According to Santarelli, MCI will guarantee a response to suspected DoS 
 attacks within 15 minutes of a customer-generated trouble-ticket through 
 MCI Customer Support"

Blah, blah, blah I would say this is a lot more like a self-ad then 
press-release of new service. UUNET already responded within 15 minutes 
or less to DoS attacks, at least this is what it was several years ago. 
Possibly this changed when they went ch11 and now they are just trying to 
get back to normal. But I would not say that this is anything "special". 

Of course, I would be happy to see others say the same too in their SLA, but
how about that they simply would just RESPOND in 15 minute to customer request.
(And actually one of my upstreams does exactly that they respond and have that
 in their SLA. And they usually respond within 1-3 minutes and not only do 
 I not have to call them, but they actually call me if the link is down or 
 if there is serious congestion on it. Quite a a bit overzellous actually!)

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

UUNet Offer New Protection Against DDoS

[John Obi]

Hello Nanogers!
 
I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc will do the same!
 
MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP services customers thwart and defend against Internet viruses and threats. 
 
http://informationweek.securitypipeline.com/news/18201396
 
It's the right time before it's too late!
 
Regards,
 
-J
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster.