For example, how many ISPs use TCP MD5 to limit the possibility of a
BGP/TCP connection getting hijacked or disrupted by a ddos attack?
i hope none use it for the latter, as it will not help. more and
more use it for the former. why? becuase they perceived the need
to solve an immediate
Date: Tue, 19 Oct 2004 09:21:46 -0700
From: Randy Bush [EMAIL PROTECTED]
Subject: Re: BCP38 making it work, solving problems
For example, how many ISPs use TCP MD5 to limit the possibility of a
BGP/TCP connection getting hijacked or disrupted by a ddos attack?
i hope none use
On Tue, Oct 19, 2004 at 07:14:32PM +0200, JP Velders scribed:
Date: Tue, 19 Oct 2004 09:21:46 -0700
From: Randy Bush [EMAIL PROTECTED]
Subject: Re: BCP38 making it work, solving problems
For example, how many ISPs use TCP MD5 to limit the possibility of a
BGP/TCP connection
Date: Tue, 19 Oct 2004 13:20:08 -0400
From: David G. Andersen [EMAIL PROTECTED]
Subject: Re: BCP38 making it work, solving problems
[ ... ]
Unless you're worried about an adversary who taps into your
fiber, how is MD5 checksums any better than anti spoofing filters
that protect your BGP
Date: Tue, 19 Oct 2004 13:36:18 +
From: Paul Vixie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: BCP38 making it work, solving problems
[ ... ]
As it was in the old days: first clean up your own act and then
start pointing at others that they're doing it wrong.
It's
On Tue, Oct 19, 2004 at 01:36:18PM +, Paul Vixie wrote:
... the first thing is, some nets who want the internet to work this
way have to implement BCP38 in their own corner of the internet.
then they have to start de-peering with nets who don't do it, and
offer a better rate to
dropped over it's 25 day uptime:
RPF Failures: Packets: 34889152, Bytes: 12838806927
RPF Failures: Packets: 4200, Bytes: 449923
RPF Failures: Packets: 3066337401, Bytes: 122772518288
RPF Failures: Packets: 30954487, Bytes: 3272647457
RPF Failures: Packets:
At 12:01 PM 10/13/04 +0200, Iljitsch van Beijnum wrote:
Trusting the source when it says that its packets aren't evil might be
sub-optimal. Evaluation of evilness is best left up to the receiver.
Likely true. Next question is whether the receiver can really determine
that in real time.
On Thu, Oct 14, 2004 at 11:48:24AM +0100, [EMAIL PROTECTED] wrote:
At 12:01 PM 10/13/04 +0200, Iljitsch van Beijnum wrote:
Trusting the source when it says that its packets aren't evil might be
sub-optimal. Evaluation of evilness is best left up to the receiver.
Likely true. Next
On 14-okt-04, at 0:17, Fred Baker wrote:
Trusting the source when it says that its packets aren't evil might
be sub-optimal. Evaluation of evilness is best left up to the
receiver.
Likely true. Next question is whether the receiver can really
determine that in real time. For some things, yes,
On 12-okt-04, at 7:30, Fred Baker wrote:
From an ISP perspective, I would think that it would be of value to
offer *not* ingress filtering (whether by ACL or by uRPF) as a service
that a customer pays for.
So what is our collective position on ISPs filtering their peers?
Both the position that
For the week starting Sept 12, our dark space telescope saw
1675 spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
randy
At 04:59 AM 13-10-04 -0700, Randy Bush wrote:
For the week starting Sept 12, our dark space telescope saw
1675 spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
No one is DDOSing dark space. The dark space telescope picks up the
richochets caused by DDOS.
Randy Bush wrote:
For the week starting Sept 12, our dark space telescope saw 1675
spoofed DDOS attacks.
any idea why someone(s) is ddosing dark space? seems a bit silly.
Something like this I rather fancy ...
http://lists.planet-lab.org/pipermail/announce/2004-April/12.html
on Wed, Oct 13, 2004 at 07:09:10AM +0530, Suresh Ramasubramanian wrote:
[EMAIL PROTECTED] [12/10/04 13:16 -0400]:
If I, and my little 7-man company, can afford to have me solve the
problem on our end, why the heck can't you do the same?
You can do it because you are a 7-man
On 13 Oct 2004, Paul Vixie wrote:
How many people have seen forged spoofed IP addresses being used for DOS
attacks lately?
syn-flood protection, and random TCP ISS, are now common enough that
spoofed-source isn't effective for TCP flows. if you want to bring down
somebody's web server
On Tue, 12 Oct 2004, Niels Bakker wrote:
* [EMAIL PROTECTED] (Christopher L. Morrow) [Tue 12 Oct 2004, 05:18 CEST]:
a common occurance we've seen is a customer of a customer NOT
announcing , nor planning on announcing, their routes to their
upstream#1 which they use ONLY for outbound
There is, of course, the issue of multihomed networks, or networks that
have satellite connectivity etc emitting spoofed source packets.
y'know, SAC004 (http://www.icann.org/committees/security/sac004.txt) is
only four pages long, and one of those is references. you should read it
before you
Paul Vixie wrote:
There is, of course, the issue of multihomed networks, or networks that
have satellite connectivity etc emitting spoofed source packets.
y'know, SAC004 (http://www.icann.org/committees/security/sac004.txt) is
only four pages long, and one of those is references. you should
On Oct 12, 2004, at 12:50 PM, Bora Akyol wrote:
2.3. For a DDoS attack to succeed more than once, the launch points
must
remain anonymous. Therefore, forged IP source addresses are used.
From
the victim's point of view, a DDoS attack seems to come from
everywhere
at once, even
On Tue, 12 Oct 2004, Bora Akyol wrote:
Excerpt from the text quoted above:
2.3. For a DDoS attack to succeed more than once, the launch points must
remain anonymous. Therefore, forged IP source addresses are used. From
the victim's point of view, a DDoS attack seems to come from
[EMAIL PROTECTED] [12/10/04 13:16 -0400]:
If I, and my little 7-man company, can afford to have me solve the
problem on our end, why the heck can't you do the same?
You can do it because you are a 7-man company. So can I. However, companies
the size of Sprint cannot do it.
Most
From [EMAIL PROTECTED] Tue Oct 12 20:41:45 2004
Date: Wed, 13 Oct 2004 07:09:10 +0530
From: Suresh Ramasubramanian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Steven Champeon [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: BCP38 making it work, solving problems
[EMAIL PROTECTED] [12
SD Date: Sun, 10 Oct 2004 21:35:33 -0400 (EDT)
SD From: Sean Donelan
SD People think BCP38 means the packets could only originate
SD from you.
Were BCP38 universal, this would be true. If one receives a
packet, it's either from the supposed source or a network that
allows spoofing. If no
the problem is that isp security folk doing actual measurement
see very little spoofing. it's easy for the bad folk to get
real bots. and tcp bad things are more popular and desirable,
e.g. spam, ... and tcp does not work from spoofed addresses.
isp security folk have limited resources. so
RB Date: Sun, 10 Oct 2004 20:14:01 -0700
RB From: Randy Bush
RB when it solves critical problems, it'll grow more quickly.
Maybe.
* Use 25/TCP for SMTP and 587/TCP for submission
* Block outbound SMTP by default, but allow for the clueful
* Run SMTP authentication
* Let each authenticated user
At 05:41 PM 10/11/2004, Richard A Steenbergen wrote:
On Mon, Oct 11, 2004 at 02:58:59AM +, Fergie (Paul Ferguson) wrote:
It's better than a sharp stick in the eye, I'll tell ya,
lad.
Listen to me: It's called a best current practice for a
reason -- people should do it. Not sit and around
At 07:51 PM 10/11/2004, Richard A Steenbergen wrote:
On Mon, Oct 11, 2004 at 06:03:08PM -0400, Daniel Senie wrote:
I've removed the rest of your message, talking about which vendors do or
don't have what capabilities. While I agree it'd be nice if more vendors
offered automated tools for
Daniel Senie wrote:
One of your arguments presented was that corporate customers weren't
asking for unicast RPF, and I responded that corporate customers are not
in need of automated mechanisms to implement BCP38, since in most cases
their networks are EDGE networks, and it's quite simple to
At 08:39 AM 10/12/04 +0530, Suresh Ramasubramanian wrote:
Yes I know that multihoming customers must make sure packets going out to
the internet over a link match the route advertised out that link .. but
stupid multihoming implementations do tend to ensure that lots of people
will yell loudly,
On Sun, 10 Oct 2004, James Baldwin wrote:
I agree that BCP 38 should be implemented. I agree that BCP 38 will
have a greater affect on network abuse than port 25 filtering. They
both have their place and address to partially overlapping groups of
abuse imho.
Be conservative in what you send
I have received complaints from people about NOT being able to spoof
packets.
moronicy
Technical Support: This is CompanyX, how can I help you?
31337kiddi0t: wHy c0m3 3ye c4nt sp0of?!$!*@
/moronicy
With all of the different standards which tend to add confusion, too much
time seems to be
It's better than a sharp stick in the eye, I'll tell ya,
lad.
Listen to me: It's called a best current practice for a
reason -- people should do it. Not sit and around and endlessly
discuss it (we've already done that a thousand times).
I wrote it, I stand beside it. I'm sick of hearing why
On Mon, 11 Oct 2004, Fergie (Paul Ferguson) wrote:
I wrote it, I stand beside it. I'm sick of hearing why people
haven't implemented it yet -- it's almost five years later
and there's simply no excuse. It's sickening.
it's cheaper to ignore bcp38 than to implement it.
operators are reactive
True, but yet another cop out.
If you're not part of the solution, .
- ferg
-- Dan Hollis [EMAIL PROTECTED] wrote:
On Mon, 11 Oct 2004, Fergie (Paul Ferguson) wrote:
I wrote it, I stand beside it. I'm sick of hearing why people
haven't implemented it yet -- it's almost five years later
35 matches
Mail list logo
