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
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 wi
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 upgrad
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
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 tryi
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
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
[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
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
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
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 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
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
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 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
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> 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
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...
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
> 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
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
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, 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
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
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, 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, 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.
>
> 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
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
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
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
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
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
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
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 v
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 b
> ...
> 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 fac
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
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 consisten
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 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 doo
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 exp
> 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
i
--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 othe
--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 answ
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%, bu
[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
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 r
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
> 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?
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, 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 blackho
> 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*
kn
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.
Spoof
>
> 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)
> -
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 req
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:
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 o
ssage-
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 w
> -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
>
&g
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
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.
>
--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
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
--- "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 percen
- 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 Agai
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 S
>> [..] 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 fo
[..] 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, presum
al 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 custo
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
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 Agains
: [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
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
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 annou
> > 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 handl
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
anno
--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.
>
>
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 wa
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
>
> 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 nul
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
ounds 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
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
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 peerin
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
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
ion
(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 h
> 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 the
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 ellig
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,
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 eno
ED]>; <[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 attem
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 st
- 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 N
- 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
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
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 thwa
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/
99 matches
Mail list logo
