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/news/18201396
It’s the right time before it’s too late!
Regards,
-J
"MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help
IP services customers thwart and defend against Internet viruses and threats.
The new SLA is focused on Denial of Service (DoS) attacks and is extended
immediately for free to all current customers of the telecommunications
company, according to MCI. It ensures that all MCI Internet customers will
have immediate access to the company's security staff to help them rapidly
address and mitigate DoS attacks
According to Santarelli, MCI will guarantee a response to suspected DoS
attacks within 15 minutes of a customer-generated trouble-ticket through
MCI Customer Support"
Blah, blah, blah.... I would say this is a lot more like a self-ad then
press-release of new service. UUNET already responded within 15 minutes
or less to DoS attacks, at least this is what it was several years ago.
Possibly this changed when they went ch11 and now they are just trying to
get back to normal. But I would not say that this is anything "special".
Of course, I would be happy to see others say the same too in their SLA, but
how about that they simply would just RESPOND in 15 minute to customer request.
(And actually one of my upstreams does exactly that they respond and have that
in their SLA. And they usually respond within 1-3 minutes and not only do
I not have to call them, but they actually call me if the link is down or
if there is serious congestion on it. Quite a a bit overzellous actually!)
> 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 thwart and defend against Internet viruses and
threats.
--- snippety snip ---
Blah, blah, blah.... I would say this is a lot more like a self-ad then
press-release of new service. UUNET already responded within 15 minutes
or less to DoS attacks, at least this is what it was several years ago.
Possibly this changed when they went ch11 and now they are just trying to
get back to normal. But I would not say that this is anything "special".Of course, I would be happy to see others say the same too in their SLA,
but
how about that they simply would just RESPOND in 15 minute to customer
request.
(And actually one of my upstreams does exactly that they respond and have
that
in their SLA. And they usually respond within 1-3 minutes and not only do
I not have to call them, but they actually call me if the link is down or
if there is serious congestion on it. Quite a a bit overzellous
actually!)
agreed, not very spectacular. in fact, i expect most ddos attack issues to
be *resolved* within 15 minutes, for reasonable values of 'most' and
'resolved'. i would probably be very dissatisfied if i could not get to a
warm, clueful and enabled body in under 10 minutes in an emergency, but then
we are a reasonably large customer of a good smaller carrier so my
expectations may be invalid in big boy customer land.
paul
william(at)elan.net 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 IP to allow your pipe to pass packets and so that your router is
pingable (which is probably the measure for whether you are up or not?)
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.
paul
What most people seem to forget is that neither of these steps actually
counter the DoS...they merely make the DoS as invisible as possible to
customers while the traffic keeps hitting the carrier in question. For
the large carriers this is only a minor inconvenience.
For smaller carriers or for co-location facilities/NSP's that are
relying on not-so-clueful carriers (read: carriers not supporting any
kind of communities with possible lack of pro-active network management
and/or bad communications) this is a BIG problem. Even though they might
take the heat off the targeted customer, they could be in for a rough
ride themselves as the DoS keeps going and going.
I haven't seen any major press-releases on actually solving the problem
instead of hiding it... (granted...I haven't put out one either 
Cheers,
erik,
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 not, as
long as service isn't interrupted the carrier is doing the job he's
promised to do in his SLA
we tend to get small ddos (a few hundred megs) that are more of an annoyance
than anything else, at least before they hit the customer-in-question 's
faste handoff.
This is a bit more problematic IMHO. A "small DoS" is very
geographically dependent and very "supporting party" dependent: in Ghana
with BT as the only provider running over DS3, a few hundred megs means
the entire network is cut-off for ages 
I know this is NANOG and bandwidth is a simple commodity, but even in
our parts of the western world bandwidth can be hard to come by and a
few hundred megs might be a bigger deal to a smaller NSP's network.
<grin>. in other news, noone has solved the perpetuum mobile problem either.
as a carrier, your job is to solve the problem for the customer. this
includes staying up afterwards.
Hehe...sadly this perpetuum mobile keeps on running and running (which
is what it's supposed to do literally but you're completely right:
cutomers should always come first and "hiding" the problem is our only
option at the moment. I'm still waiting for that press-release though
Regards,
Erik
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 elligible for partial credit.
[Wed, Mar 03, 2004 at 12:42:05AM -0800]
william(at)elan.net Inscribed these words...
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 them, we
should be emulating them.
randy
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 23,
2004:
Dear Customer,
If you have received this email, you are either a direct customer of
AS3561, (i.e. you have registered a route object for a customer of AS3561),
or are listed in the maintainer of a customer of AS3561.
AS3561 has implemented a blackhole/DDoS community string based solution to
aid customers in the mitigation of DoS attacks. If you are currently running
BGP with us, you will be able to use this feature.
If you advertise a prefix (route) to us with the community string
3561:666, we will NULL route or 'blackhole' all traffic destined to that
prefix. The prefixes accepted are based on the current prefix-list generated
for you. Instead of doing exact match filtering, we will accept any prefix
(more "specific") within your address block(s). e.g. if you have
192.168.0.0/16 registered, we will accept 192.168.0.0/16 upto /32 as long as
the 3561:666 community string is attached.
Please ensure you are configured to send community strings and understand
the impact of errant advertisements. Diligence should be used when
administrating this feature. Once the prefix is received and propagated
within AS3561, all traffic destined to the prefix will be discarded and the
blackholing of traffic will continue as long as DDoS community string is
being advertised. Neither Cable & Wireless nor AS3561 will be held liable
or responsible for customers who errantly advertise prefixes with the
blackhole community string.
If you wish to utilize this feature, you can verify our acceptance of the
advertised prefix by querying the AS3561 route server located at
http://lg.cw.net.
Please remember, we require you to complete a priority one incident report
at http://www.security.cw.net (Report an Incident) and include details of the
attack. An email describing further details of the attack can be sent to
security@cw.net, please include the incident report number in the subject to
assist in the tracking and documentation of the incident. This will ensure
the attack is properly administrated handled by our Security and Legal
Groups.
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:9999. 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 blackhole community if you are having any troubles.
[Wed, Mar 03, 2004 at 08:34:00AM -0800]
Andy Ellifson Inscribed these words...
Indeed. One could even get "fancy" and set of different community
sets to allow customers to drop traffic only on peering routers (as
opposed to customer or all routers, etc..). The "Customer-Triggered
Real Time Blackhole" tutorial that Chris, Tim and I gave in Miami
talks about how to go about doing this.
One step further is uRPF coupling with blackhole routing for sourced-
based drops, though I suspect you probably won't want to do this
with customers
Finally, the BGP Flow Specification stuff provides a start at a more
granular BGP-based method by employing new AFI/SAFI. If you've got
feedback please pass it along.
http://www.tcb.net/draft-marques-idr-flow-spec-00.txt
-danny
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 from CW dated Januray 23,
] 2004:
UUNET/MCI has had that capability since circa 2002, I believe. Several
ISPs borrowed heavily from the following page to create similar services.
<http://www.secsup.org/CustomerBlackHole/>
Kudos to Chris and Brian.
Thanks,
Rob.