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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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
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
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
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
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 nothing by
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
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
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.
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
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 were
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
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.
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
[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:
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
--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
--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
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
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
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
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?
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
...
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
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
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
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
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 CW does? Or will that wait until the integration?
This thread has caused me to add this as a requirement for a new
snip
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.
/snip
Shared view,
mh (Teleglobe, btw)
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.
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 CW 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 ;-),
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
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
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
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
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
, 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
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
-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
: 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
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
- 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
- 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
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
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
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
Hi Paul,
snip
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
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
) 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 CW, Verio
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
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
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
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
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
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
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)
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
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
: 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
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
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
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
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
]
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
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
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
, 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
[..] 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,
[..] 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.
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
- 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
--- 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
Hello Nanogers!
I'm happy to see this, and I hope CW, 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.
On Tue, 2 Mar 2004, John Obi wrote:
Hello Nanogers!
I'm happy to see this, and I hope CW, 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
william(at)elan.net wrote:
On Tue, 2 Mar 2004, John Obi wrote:
Hello Nanogers!
I'm happy to see this, and I hope CW, 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
94 matches
Mail list logo
