Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: deny udp any a.b.c.d/24 eq 80 …to refuse and tell us we must subscribe to their managed DDOS product? -cjp
Depends on the provider. Many just do not want to manage hundreds of customer ACL's on access routers. Especially when it would compete with a managed service (firewall, IDP, DDOS) of some sort. Some still are under the impression that ACL's are software based and their giant $100k+ edge box would crash if they configured them for any reason. 2011/10/25 Christopher Pilkington <cjp@0x1.net>
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
-cjp
On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley <keegan.holley@sungard.com>wrote:
Depends on the provider. Many just do not want to manage hundreds of customer ACL's on access routers. Especially when it would compete with a managed service (firewall, IDP, DDOS) of some sort. Some still are under the impression that ACL's are software based and their giant $100k+ edge box would crash if they configured them for any reason.
Conversely, some don't want to be paid for bare colocation (at bare colocation prices) and have to then support 1000+ rules (yes, 1000+) with 10-20 change requests per day. YMMV/slippery slope/service scope/etc.
On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote:
On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley <keegan.holley@sungard.com>wrote:
Depends on the provider. Many just do not want to manage hundreds of
Conversely, some don't want to be paid for bare colocation (at bare colocation prices) and have to then support 1000+ rules (yes, 1000+) with
This is a large colo provider on the Upper West Side of Manhattan, so I (naively) expected more of them. It looks like this will be their final nail though. -cjp
Why not put the ACL on your ingress side at your switch or router? I would typically not expect a colo provider to provide this service unless I'm paying extra for it. The smaller they are, the more likely they are to do so to keep you happy, but I certainly wouldn't be asking this request unless it was some 11th hour DOS-prevention request. Even then, they may not want to install this ACL as ultimately they should be billing you for this UDP traffic (which this ACL, may prevent their billing system from metering). On Tue, Oct 25, 2011 at 12:53 PM, Christopher Pilkington <cjp@0x1.net>wrote:
On Oct 25, 2011, at 2:50 PM, Brandon Galbraith wrote:
On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley < keegan.holley@sungard.com>wrote:
Depends on the provider. Many just do not want to manage hundreds of
Conversely, some don't want to be paid for bare colocation (at bare colocation prices) and have to then support 1000+ rules (yes, 1000+) with
This is a large colo provider on the Upper West Side of Manhattan, so I (naively) expected more of them. It looks like this will be their final nail though.
-cjp
2011/10/25 Brandon Galbraith <brandon.galbraith@gmail.com>
On Tue, Oct 25, 2011 at 1:46 PM, Keegan Holley <keegan.holley@sungard.com>wrote:
Depends on the provider. Many just do not want to manage hundreds of customer ACL's on access routers. Especially when it would compete with a managed service (firewall, IDP, DDOS) of some sort. Some still are under the impression that ACL's are software based and their giant $100k+ edge box would crash if they configured them for any reason.
Conversely, some don't want to be paid for bare colocation (at bare colocation prices) and have to then support 1000+ rules (yes, 1000+) with 10-20 change requests per day. YMMV/slippery slope/service scope/etc.
They are no worse than route filters or bandwidth increases, or IP address requests/changes. The provider should be able to do a temporary filter if the customer needs it though rather than forcing them to wait weeks or months to install a managed service/device. I agree permanent custom ACL's with indefinite growth/management could be considered a managed service and should either be an additional charge or not allowed at all.
On Tue, Oct 25, 2011 at 2:43 PM, Christopher Pilkington <cjp@0x1.net> wrote:
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
Christopher, That seems reasonable to me. You're buying colo and transit, not firewall service. If you want firewall service, that's extra. If you do decide to move, I suggest a carrier neutral facility so that you can change transit providers without moving your equipment. The easier it is for you to walk away, the more accommodating vendors tend to be. Seeing much port 80 UDP traffic? My curiosity is piqued. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 10/25/2011 08:43 AM, Christopher Pilkington wrote:
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
-cjp
For colo? No, filtering is the customers concern, unless failure to do so is causing a problem for the colo network. Such services are almost always paid for add-ons to a colo package. The colocation business is usually fairly low on the profit margin with most companies trying to get away with the bare minimum possible over and above the basics.
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers. 2011/10/25 Paul Graydon <paul@paulgraydon.co.uk>
On 10/25/2011 08:43 AM, Christopher Pilkington wrote:
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
-cjp
For colo? No, filtering is the customers concern, unless failure to do so is causing a problem for the colo network. Such services are almost always paid for add-ons to a colo package. The colocation business is usually fairly low on the profit margin with most companies trying to get away with the bare minimum possible over and above the basics.
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers.
Most? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
2011/10/25 Jay Ashworth <jra@baylink.com>
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers.
Most?
I'm sure there are exceptions to that rule. It's better than "YMMV".
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers.
Most?
I'm sure there are exceptions to that rule. It's better than "YMMV".
Perhaps I look at a different category of colo provider, then, but I'm accustomed to seeing it be well up into double-digit percentage of the ones I've ever looked at. "Hosting", to me, means "provider's hardware", not just "local blended bandwidth". Cheers, -- jr 'so many things are just me' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
----- Original Message -----
From: "Keegan Holley" <keegan.holley@sungard.com>
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers.
Most?
I'm sure there are exceptions to that rule. It's better than "YMMV".
Perhaps I look at a different category of colo provider, then, but I'm accustomed to seeing it be well up into double-digit percentage of the ones I've ever looked at.
"Hosting", to me, means "provider's hardware", not just "local blended bandwidth".
I think you may have misunderstood me. I mean local blended bandwidth to be a colo provider offering extra services. Hosting is provider hardware and
2011/10/26 Jay Ashworth <jra@baylink.com> there should be a certain level of quality to the services and operation. A colo provider providing the same service as either courtesy access or a low cost alternative to access from an ISP wouldn't be held to the same standard for obvious reasons. There's also "virtual hosting" which can be nothing other than "local blended bandwidth". But none of those webfarm types would be on a list like this.... right?? ;)
On Tue, Oct 25, 2011 at 9:21 PM, Keegan Holley <keegan.holley@sungard.com> wrote:
I'm assuming colo means hosting, and the OP misspoke. Most colo providers don't provide active network for colo (as in power and rack only) customers.
Yes, hosting. I did indeed misspeak.
Christopher, This is pretty common policy. Not many datacenters of any size is going to act differently. If you don't purchase this service then you will not get the service. They may be willing work work with you on black-holing problem IPs though. This is pretty common, but don't expect a filtering package without purchasing it. James ----- Original Message ----- From: "Christopher Pilkington" <cjp@0x1.net> To: "NANOG mailing list" <nanog@nanog.org> Sent: Tuesday, October 25, 2011 2:43:00 PM Subject: Colocation providers and ACL requests Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as: deny udp any a.b.c.d/24 eq 80 …to refuse and tell us we must subscribe to their managed DDOS product? -cjp
I tend to disagree somewhat, you really have to put some context around the request and convey that to your provider. If the request is "please help me block this DDoS traffic so that I can contact the source as it's impacting my ability to do business" I think that is a reasonable request as long as it's not a permanent solution. I have worked through similar incidents in some datacenter in Northern Virginia (Sterling, Ashburn) and all of them accommodated that request at no cost. -- Michael Gatti ekim.ittag@gmail.com On Oct 27, 2011, at 8:09 PM, James Ashton wrote:
Christopher, This is pretty common policy. Not many datacenters of any size is going to act differently. If you don't purchase this service then you will not get the service.
They may be willing work work with you on black-holing problem IPs though. This is pretty common, but don't expect a filtering package without purchasing it.
James
----- Original Message ----- From: "Christopher Pilkington" <cjp@0x1.net> To: "NANOG mailing list" <nanog@nanog.org> Sent: Tuesday, October 25, 2011 2:43:00 PM Subject: Colocation providers and ACL requests
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
-cjp
Christopher Pilkington wrote:
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry. I do feel it is bad practice to regularly implement customer specific ACL's on routers. If a customer wants a managed firewall we have a full range of those services available. - Kevin
On 11/1/2011 1:22 PM, Kevin Loch wrote:
Christopher Pilkington wrote:
Is it common in the industry for a colocation provider, when requested to put an egress ACL facing us such as:
deny udp any a.b.c.d/24 eq 80
…to refuse and tell us we must subscribe to their managed DDOS product?
We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry.
I do feel it is bad practice to regularly implement customer specific ACL's on routers. If a customer wants a managed firewall we have a full range of those services available.
And Managed DDOS products better be a LOT more than an ACL. If I'm going to pay someone to manage DDOS, they will scrub the traffic and let all my legitimate traffic through. That's what I'm paying for. null routing an IP or a simple acl isn't worth paying a dime for. Jack
On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch <kloch@kl.net> wrote:
Christopher Pilkington wrote: We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry.
And it's reasonable to accomodate the customer that asks, and reasonable for a customer to ask for a temporary ACL in such situations. However, it's also reasonable for the provider to refuse, and there's nothing wrong with that, unless the provider agreed that they would be willing to do that, and then refused to do something they had already agreed to do. The provider might be especially dissuaded from responding and providing a temporary ACL for free if the DoS is a "small" one based on the provider's definition of small, or if the provider doesn't have or won't allocate the resources to respond, without charging a fee to do so. Or its a cut rate hosting service, and the customer refused to buy the "managed filtering" firewall (or whatever solution). In that case, it's reasonable for the provider to counter the request with "You can buy our such and service, and we will gladly implement that" If this is something you want to be sure you can do, then you should ask the provider about it before signing that colocation contract for IP connectivity, and make sure you have it in writing that the provider will create an ACL on your interface of sufficient length to do what you want.. And be sure you have worked out with the provider how this effects billing in advance. It's quite possible you still have to pay or have said dropped traffic counted against your commit. -- -JH
On Tue, Nov 1, 2011 at 8:00 PM, Jimmy Hess <mysidia@gmail.com> wrote:
On Tue, Nov 1, 2011 at 1:22 PM, Kevin Loch <kloch@kl.net> wrote:
We have always accommodated temporary ACL's for active DDOS attacks. I think that is fairly standard across the ISP/hosting industry.
Indeed. We'll do it; ditto every reputable hosting, collocation, or IP transit shop I've come into contact with.
And it's reasonable to accomodate the customer that asks, and reasonable for a customer to ask for a temporary ACL in such situations.
However, it's also reasonable for the provider to refuse, and there's nothing wrong with that, unless the provider agreed that they would be willing to do that [...]
Disagree. Furthermore, I think providers refusing to implement temporary ACLs should be called out on fora such as NANOG, to aid others in the vendor selection process. This is not to say it's sustainable as a repeat or permanent configuration -- possible up-sell and business drivers aside, TCAM exhaustion, performance implications, and man-hours required for ACL maintenance are all very real concerns -- but denying your customers this type of emergency response is bad for the Internet, and goes against basic tenets of customer service. -a
participants (14)
-
Adam Rothschild -
Brandon Galbraith -
Christopher J. Pilkington -
Christopher Pilkington
-
Jack Bates -
James Ashton -
Jay Ashworth -
Jimmy Hess -
Keegan Holley -
Kevin Loch -
Mike Gatti -
Paul Graydon -
PC -
William Herrin