On 20 Oct 2004, at 21:49, Jon Lewis wrote:
On Wed, 20 Oct 2004, Patrick W Gilmore wrote:
Have you actually done the work to see how many packets it takes to
shut down a session with and without MD5 enabled? (The question is
rhetorical, since your post shows that you have not.)
Just a bit more sau
On Wed, 20 Oct 2004, Patrick W Gilmore wrote:
> Have you actually done the work to see how many packets it takes to
> shut down a session with and without MD5 enabled? (The question is
> rhetorical, since your post shows that you have not.)
Just a bit more sauce for the goose...enabling MD5 on
> Date: Wed, 20 Oct 2004 03:33:05 GMT
> From: "Fergie (Paul Ferguson)" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: BCP38 making it work, solving problems
> Hmm, so let me figure this one out... Are you arguing against
&g
On Oct 19, 2004, at 1:14 PM, JP Velders wrote:
jacking the connection is in a completely different class as someone
bombarding you with a bunch of forged BGP packets to close down a
session. Without that MD5 checksum you are quite vulnerable to that. I
haven't seen a vendor come up with a solution
> Hmm, so let me figure this one out... Are you arguing against
> BCP38 implementation/filtering, or what?
no one is arguing against it. they're just trying to tell
the religious zealots (who seem not to run large networks)
why it is not deploying as rapidly as they might like.
randy
Hmm, so let me figure this one out... Are you arguing against
BCP38 implementation/filtering, or what?
- ferg
-- JP Velders <[EMAIL PROTECTED]> wrote:
In most cases it will go like that, the minority of when it doesn't
go like that, you start filtering / whatever, just like we do now.
Regard
>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: 470
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
> 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 point
> 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 sp
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 l
> 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
> 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 p
> > ... 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 customers who do it than to those who don't.
> > then they
At 01:11 PM 10/19/04 +0200, JP Velders wrote:
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.
hear hear... But Paul knows and in fact does that. He is pointing out the
difficulty of getting people to do basic things that ar
> Date: 12 Oct 2004 16:22:17 +
> From: Paul Vixie <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: BCP38 making it work, solving problems
> [ ... ]
> how are we going to get there? the first thing is, some nets who want the
> internet to work this way
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, b
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 t
> 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
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. For some t
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
> >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 then blackhats really do have to use
> Some medium-big (and up) operators implement 'RFC-1918 source' filters on
> their gateways to the 'external internet', ...
maybe so. but i want to renew an old complaint, with updated numbers:
# ipfw show
...
00400 576234043927757977 deny ip from 10.0.0.0/8 to any in
00500
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
>> 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.
sorry. i guess i should give up getting more sleep and go make
coffee.
randy
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
[Planetlab-anno
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
> 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
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 th
At 09:50 AM 12-10-04 -0700, Bora Akyol wrote:
How many people have seen "forged" spoofed IP addresses being used
for DOS attacks lately?
For the week starting Sept 12, our dark space telescope "saw" 1675 spoofed
DDOS attacks. No idea how many non-spoofed attacks took place during the
same time p
> 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,
[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.
>
M
> 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.
Alex
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
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 from
on Tue, Oct 12, 2004 at 12:49:54PM -0400, [EMAIL PROTECTED] wrote:
> This is just the cold blooded economic reality. The same reality which
> dictates that only smaller companies can enfore strict anti-spam policies,
> and prevent their customers from behaving badly.
You want cold-blooded economi
> uPRF is only one of several ways to implement BCP38. you could do it with
> contracts and reverse-SLA's and thus no technology (on your side) at all:
> demand that a customer pay 10X his bill, or $1.00 per packet, whichever is
> lower, if they emit packets with source addresses no explicitly na
On 10/12/04 9:06 AM, "Paul Vixie" <[EMAIL PROTECTED]> 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 p
> ...
> Example:
>
> the 'chris.net' network is a customer of MCI, his customer "bakker.net".
> 'bakker.net' decides 'chris.net' has priced transit cheaply this
> year/month/day and choses not to accept traffic from 'chris.net' but send
> all outbound traffic through 'chris.net'. 'chris.net' neve
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 read
> 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 yo
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 outbo
* [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 traffic (cheap transit for
> instance, and perha
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 Tue, 12 Oct 2004, Suresh Ramasubramanian wrote:
> 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 cas
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 fil
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 im
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 implementing ingress filtering, such tools are
> u
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 an
Fergie (Paul Ferguson) wrote:
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 -- i
>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 and endlessly
> discuss it (we've already
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 us
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 wh
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 n
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 la
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 reactiv
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 p
> I have received complaints from people about NOT being able to spoof
> packets.
Technical Support: "This is CompanyX, how can I help you?"
31337kiddi0t: "wHy c0m3 3ye c4nt sp0of?!$!*@"
With all of the different standards which tend to add confusion, too much
time seems to be going to waste
58 matches
Mail list logo
