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 decr
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
spec
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 optiona
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
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 g
Looking at last week's NANOG posts: SAV... 30% of spam from
h4x0r3d boxen... bagle...
It seems the original definition and ideology of layered security
are outdated. Layered security now means:
* Do nothing at a given layer if the problem can be solved, or
partially solved, at another layer;
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, stric
Eddy,
My favorite idiom is; "You're either part of the problem or part of the
solution."
What's your solution?
Regards,
Christopher J. Wolff, VP CIO
Broadband Laboratories, Inc.
http://www.bblabs.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of E.B.
Hello all,
We had 39 responses to the poll. The results follow the signature paragraph.
A few words of explanation about the results.
1) For the Yes-No questions, most answers were either YES or NO. However,
a few of the results were something like "yes, but not encrypted zips."
For t
> 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
Based on Jon's results, it is reasonable to conclude that most corporate
network operators provide some level of email security. Any given
corporation can establish top-down policies mandating the use of an email
security product. Said corporation only needs to manage compliance with the
policy.
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.
>
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 core
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
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 agreein
I'm inclined to think not. Its like opening a flood gate and trying to close
it. Simply put, even dropping passworded Zip files for me has churned
a large degree of debate/resistance from my management and users.
My arguing that SMTP is not FTP, hasn't won me any leverage based
in part from the
CJW> Date: Sun, 7 Mar 2004 12:56:35 -0700
CJW> From: Christopher J. Wolff
CJW> My favorite idiom is; "You're either part of the problem or
CJW> part of the solution."
Thanks for your contribution.
CJW> What's your solution?
There's no one single answer. That's the whole point. The
closest
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 di
[two responses here]
1 of 2
[EMAIL PROTECTED] (fingers) writes:
> 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. ...
yes. for example, most forms of dns cache pollution
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 o
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
> 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 r
[EMAIL PROTECTED] (Sean Donelan) writes:
> SAV doesn't tell you where the packets came from. At best SAV tells you
> where the packets didn't come from.
...which is incredibly more valuable than not knowing anything at all.
> You would be wrong. There are networks that have deployed SAV/uRPF.
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
On Sun, 7 Mar 2004, Paul Vixie wrote:
> in the therefore-unreal world i live in, the ability to tell a GWF ("goober
> with firewall") that the incident report they sent our noc could not possibly
> have come from here, is a net cost savings over having to prove it every time.
Of course, some peop
I know there's always people searching out web based utils for tracking
IP allocations and such, but surprisingly I don't recall there ever
being discussion on tracking circuits. I'm looking for such a tool and
am curious if anyone knows of one?
I'm looking to track: circuit type, circuit id, tro
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> Date: Sun, 7 Mar 2004 17:47:09 -0500 (EST)
SD> From: Sean Donelan
SD> In practice, GWF's ... send reports about packets which have
SD> our IP addresses, but didn't originate here. The last thing
Probably because someone else failed to implement SAV. If
$origin_net prevented spoofing your
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
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
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 nothin
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
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
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 an
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. T
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
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
[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 we
[EMAIL PROTECTED] (Dan Hollis) writes:
> ...
> This isnt the point. The point is, why should others suffer the burden of
> your clients spewing bogon/spoofed/nonsense garbage at them?
when i found out that two e-mail based service companies who had been
acquired by yahoo had stopped doing verifi
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 giv
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. Ther
[EMAIL PROTECTED] (Sean Donelan) writes:
> > 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? Rememb
[EMAIL PROTECTED] (Ken Diliberto) writes:
> 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
43 matches
Mail list logo
