If you only want 1gig, then if the SP provides it, won't it be cheaper
to simply get a 1gig circuit from them that hands off to you on a GigE
port rather than pay for all the various higher spec equipment that
you'd otherwise require?
Paul.
-Original Message-
From: Kevin Hodle
On Jan 3, 2010, at 4:11 PM, Eric Brunner-Williams wrote:
I'm sure someone must, but google as I have I only find fact sheets (marcom
collateral) and reports to Congress.
Thanks in advance!
Eric
These are restricted to those that have signed a Trusted Agent Agreement for
participation in
I feel your pain, as I'm a little frustrated by the stance that Internap
is taking on the FCP. We've used them for many years, back when there
were numerous competitors to choose from. However, now that they are
pretty much the only major player they seem to care less about the
results and
Most of the SOHO router vendors (Netgear, Linksys, etc) have a model
targeted at this application. When this class of dual homed router
first came out several years ago, they were notoriously unreliable, but
I would hope they work better by now. A search on the term ping based
routing should give
In a message written on Thu, Dec 10, 2009 at 01:35:16PM -0500, Jared Mauch
wrote:
As always, good research by renesys.
http://www.renesys.com/blog/2009/12/bonjour-yall-asn-split-persona.shtml
http://blog.isc.org/2010/01/asn-collisions-and-human-error.html
--
Leo Bicknell -
On Mon, 4 Jan 2010, Holmes,David A wrote:
I do not know of Comcast's Ethernet services specifically, but a general
problem with carrier Ethernet services that are based upon the Metro
Ethernet Forum (MEF) is that PIM-snooping is not implemented for
multicast traffic. The absence of
CAIDA plans to conduct a comparison of geolcocation tools for
determining the location of Internet Protocal (IP) address (and other
identifiers) in the summer of 2010.
At this time we wish to receive feedback from interested parties
on input to the comparison survey, whether they wish to
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned
several times but they haven't been responsive to literature requests (hint,
if anybody from Arbor is looking...). Our current upstream is 3x GigE from
3 different providers, each landing on their own BGP endpoint feeding
We have substantial direct experience with both RioRey and IntruGuard.
RR is more plug and play while IG is more robust but both are great.
Use a robust firewall such as a Netscreen in front of your mitigation
tool.
Best regards, Jeff
On Mon, Jan 4, 2010 at 4:19 PM, Rick Ernst
Rick,
If you pass me your contact info I can forward it to our Arbor Sales guy who
can get in touch with you. I been pretty impressed by Arbor so far.
Thanks,
Raj Singh
-Original Message-
From: Rick Ernst [mailto:na...@shreddedmail.com]
Sent: Monday, January 04, 2010 1:20 PM
To:
Several responses already, and Arbor has poked their head up.
I'm going to start there and keep the other suggestions at-hand.
Thanks,
On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst na...@shreddedmail.com wrote:
Looking for D/DoS mitigation solutions. I've seen Arbor Networks mentioned
I've been looking up information on the Annex M Standard today and am unable
to find any ISPs in the US offering this.
Can anyone tell me if there are providers in the US using the Annex M
standards and increased upstream with it, or if not is there a good reason
why its not being done yet?
PIM-snooping is not in the MEF specs, but should be if multicast is to
work properly over a carrier's Ethernet service. Regardless of the
specs, RFPs and other user requirements for Ethernet services should
include a must have clause requiring PIM-snooping functionality.
-Original
Ask them if they'd come down to $10 - 20k for a full featured model
and they might make two sales, although I doubt it unfortunately.
Best regards, Jeff
On Mon, Jan 4, 2010 at 4:59 PM, Rick Ernst na...@shreddedmail.com wrote:
Several responses already, and Arbor has poked their head up.
I'm
The Deathstar opt-e-man service says they will knee-cap you at 1Mb/s of
multicast.
- Jared
On Jan 4, 2010, at 4:56 PM, Holmes,David A wrote:
PIM-snooping is not in the MEF specs, but should be if multicast is to
work properly over a carrier's Ethernet service. Regardless of the
specs, RFPs
Hi Luke.
We offer it, along with bonded ADSL. We don't do it often but it is very useful
sometimes.
Regards,
John
John Souvestre - New Orleans LA
-Original Message-
From: Luke Marrott [mailto:luke.marr...@gmail.com]
Sent: Monday, January 04, 2010 4:03 PM
To:
Hello Fellow NANOG'ers,
As you all should know by now, NANOG 48 is coming up in February. The NANOG
Program Committee has been busily recruiting, collecting, and reviewing
submissions for the program, however, we still need more content. We have lined
up many interesting Tracks and Panels, but
On Tue, Dec 15, 2009 at 7:46 AM, Eric J Esslinger eesslin...@fpu-tn.com wrote:
So in any case, due to customer privacy concerns we feel we can't do that.
If you don't want to handle email for the long-obsolete customer
accounts, but just don't want to send that mail to anybody else, it's
pretty
We offer it, but practically speaking we haven't gotten much higher than 1.5
Mbps on the upstream.
Frank
-Original Message-
From: Luke Marrott [mailto:luke.marr...@gmail.com]
Sent: Monday, January 04, 2010 4:03 PM
To: nanog@nanog.org
Subject: ITU G.992.5 Annex M - ADSL2+M Questions
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a Netscreen in front of your mitigation
tool.
Absolutely not - the firewall will fall over due to state-table exhaustion
before the mitigation system will. Firewalls (which have no place in front of
servers in
and to add, OTDR at several wavelengths, just in case you want to do
xWDM in the future.
Frank
-Original Message-
From: ML [mailto:m...@kenweb.org]
Sent: Friday, January 01, 2010 6:24 PM
To: Mike
Cc: nanog@nanog.org
Subject: Re: dark fiber and sfp distance limitations
On 1/1/2010
Kinda funny you state that Roland. I know of at least two very large
carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS
mitigation.
State table exhaustion on the netscreen platform is something that is very
easy to protect against with some protections and hasn't been a problem for
What Roland said, I've seen people do this, no rules in place, still
was able to kill the box (firewall) with a single CPU server.
-jim
On Mon, Jan 4, 2010 at 10:04 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote:
Use a robust firewall such as a
If you want to recreate D/DoS from captures (for testing purposes) you
might want to check out:
http://www.pcapr.net/dos
This lets you validate how your mitigation solutions are holding up.
K.
On Mon, Jan 4, 2010 at 1:19 PM, Rick Ernst na...@shreddedmail.com wrote:
Looking for D/DoS
On Jan 5, 2010, at 9:17 AM, Tim Eberhard wrote:
I would argue that firewalls place is in fact directly infront of servers
and load balancers to protect them.
The very idea of placing a stateful firewall in front of a Web/DNS/email/etc.
server, in which *every single incoming packet is
On Tue, Jan 05, 2010, Dobbins, Roland wrote:
None of the large, well-known Web properties on the Internet today - at
least, the ones which stay up and running, heh - have stateful firewalls in
front of them. Including prominent vendors of said stateful firewall
solutions.
But as you
We have such a configuration in progress, it works great without any of the
issues you're proposing.
Jeff
On Jan 4, 2010 9:09 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: Use a robust firewall such
as a Netscreen in fro...
Absolutely not - the
On Tue, Jan 5, 2010 at 8:36 AM, Jeffrey Lyon
jeffrey.l...@blacklotus.net wrote:
We have such a configuration in progress, it works great without any of the
issues you're proposing.
So .. this is interesting.
The firewall would have to frontend your mail / web / whatever
application .. and if
On Jan 5, 2010, at 10:14 AM, Dobbins, Roland wrote:
If it's a stateful firewall, and state-tracking is turned on, it's quite
possible to craft sufficient pathological traffic which conforms to the
firewall policies and yet which leads to state-table inspection.
That should read
On Jan 5, 2010, at 10:06 AM, Jeffrey Lyon wrote:
We have such a configuration in progress, it works great without any of the
issues you're proposing.
Then you aren't testing it to destruction, heh.
;
If it's a stateful firewall, and state-tracking is turned on, it's quite
possible to
Two more options. And for Netflow device - read that to mean Arbor or
its competitors.
5 Ditch the stateful firewall and exclusively use a netflow device
6. Outsource to a hosted DDoS mitigation service (Prolexic etc)
On Tue, Jan 5, 2010 at 8:43 AM, Suresh Ramasubramanian
ops.li...@gmail.com
On Jan 5, 2010, at 10:18 AM, Suresh Ramasubramanian wrote:
5 Ditch the stateful firewall and exclusively use a netflow device
NetFlow analysis is very useful for network visibility, and
detection/classification/traceback. There are both open-source and commercial
NetFlow collection and
On Mon, Jan 4, 2010 at 9:18 PM, jim deleskie deles...@gmail.com wrote:
What Roland said, I've seen people do this, no rules in place, still
was able to kill the box (firewall) with a single CPU server.
not to pile on, but... +1 to roland here as well. I've seen more than
enough folks put in a
Frank Bulk - iName.com frnk...@iname.com wrote:
We offer it, but practically speaking we haven't gotten much higher than 1.5
Mbps on the upstream.
Sorry that I'm coming into this thread late (I have just subscribed),
but since I see people discussing DSL with beefy upstream, I thought I
would
1. We have multiple nodes conducting DDoS scrubbing, one failing would not
be catastrophic.
2. Indeed.
3. Sort of, such devices are downstream for extremely valid reasons I won't
get into now.
4. Indeed, were equipped to handle substantially higher than 150kpps.
I'm sure Arbor is really neat
A lot of this has to do with scaling the environment. I've had plenty of
asa's and even netscreens fall over from state-table and session
limitations. I've also seen a hosts fill up the connection table prior to a
firewall being affected. I'm not familiar with the specs and anyone can
chime in,
With these safeguards in place - and with flow devices being part of
the mix somewhere .. what you propose is quite reasonable.
There's still the question of whether an application that receives a
lot of new / untrusted traffic - a mail or web server - would benefit
from having a stateful
On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote:
I'm sure Arbor is really neat but I disagree that any DDoS appliance is a
standalone solution.
I disagree with this proposition, too.
S/RTBH and/or flow-spec are great DDoS mitigation tools which don't require any
further investment beyond
On Mon, Jan 4, 2010 at 11:20 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 11:05 AM, Jeffrey Lyon wrote:
I'm sure Arbor is really neat but I disagree that any DDoS appliance is a
standalone solution.
I disagree with this proposition, too.
S/RTBH and/or flow-spec are
On Jan 5, 2010, at 11:41 AM, Christopher Morrow wrote:
(note I think Roland may have been party to some of the presenations I linked
in this...
Yes, sir, and thanks for posting those links! You and Barry and Tim Battles
and Sean Donelan and Danny McPherson and Don Smith and Steve Bellovin
On Tue, Jan 5, 2010 at 10:35 AM, Rick Ernst na...@shreddedmail.com wrote:
I'm interested in seeing products (including software) that already have the
development (anomaly detection, trends/reports, etc.) work done so I can
spend my cycles elsewhere.
This might fit the bill -
On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote:
A solution preferably that integrates with NetFlow and RTBH. An in-line
solution obviously requires an appliance, or at least special/additional
hardware.
The key is to not be inline all the time, but only inline *when needed*. This
On Mon, Jan 4, 2010 at 9:08 PM, Dobbins, Roland rdobb...@arbor.net wrote:
On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote:
A solution preferably that integrates with NetFlow and RTBH. An in-line
solution obviously requires an appliance, or at least special/additional
hardware.
The key
On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland rdobb...@arbor.net wrote:
Additional mitigation would be via manual or automatic RTBH or
security/abuse@ involvement with upstreams.
Automagic is generally bad, as it can be gamed.
... and manual wont scale in ddos
--
Suresh
-Original Message-
From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
Sent: Monday, January 04, 2010 11:41 PM
The original poster seemed to be asking about appliance based
solutions, so your pointed remarks about Roland aside he was actually
answering the question. I wonder
On Jan 5, 2010, at 12:19 PM, Suresh Ramasubramanian wrote:
... and manual wont scale in ddos
Actually, it can and does.
;
I'm referring to the employment and selection of situationally-appropriate
tools, mind. The tools themselves must of necessity perform their work in a
largely
On Jan 5, 2010, at 12:19 PM, Rick Ernst wrote:
I'd argue just the opposite. If your monitoring/mitigation system changes
dependent on the situation (normal vs under attack), you are adding
complexity to the system.
What mode is the system in right now? Is this customer having
-Original Message-
From: Rick Ernst [mailto:na...@shreddedmail.com]
Sent: Tuesday, January 05, 2010 12:19 AM
I'd argue just the opposite. If your monitoring/mitigation system
changes
dependent on the situation (normal vs under attack), you are adding
complexity to the system.
On Tue, Jan 5, 2010 at 10:52 AM, Dobbins, Roland rdobb...@arbor.net wrote:
I'm referring to the employment and selection of situationally-appropriate
tools, mind. The tools themselves must of necessity perform their work in a
largely automated fashion once they're employed, which is what I
On Tue, Jan 05, 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an offramp method.
These devices perform a lot better when you can forward just the subset of
the traffic through as opposed to
I think you, Roland, and I are all agreeing on the same argument.
The (my) confusion entered with the statement of, The key is to not be
inline all the time, but only inline *when needed*.
I inferred a topological or physical path change from that.
Redirecting traffic (which is really just an
-Original Message-
From: Suresh Ramasubramanian [mailto:ops.li...@gmail.com]
Sent: Tuesday, January 05, 2010 12:19 AM
On Tue, Jan 5, 2010 at 10:38 AM, Dobbins, Roland rdobb...@arbor.net
wrote:
Additional mitigation would be via manual or automatic RTBH or
security/abuse@
On Jan 5, 2010, at 12:39 PM, Adrian Chadd wrote:
I mean, I assume that there's checks and balances in place to limit
then number of routes being injected into the network so one doesn't
overload the tables, but what's the behaviour if/when this limit is
reached? Does mitigation cease being
On Jan 5, 2010, at 12:39 PM, Stefan Fouant wrote:
The trick is to try to automate as much around the process as possible - I've
worked in environments where just making little changes to incident handling
response methods reduced the time to mitigate an attack from hours to
minutes, all
On Jan 5, 2010, at 12:39 PM, Rick Ernst wrote:
I think you, Roland, and I are all agreeing on the same argument.
GMTA.
;
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
Injustice is relatively easy
On Jan 5, 2010, at 11:57 AM, Dobbins, Roland wrote:
You and Barry and Tim Battles and Sean Donelan and Danny McPherson and Don
Smith and Steve Bellovin and Jared Mauch and John Kristoff and a lot of other
folks too numerous to mention
. . . including Paul Vixie, Darrel Lewis, Ryan
On Tue, 5 Jan 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an offramp method.
These devices perform a lot better when you can forward just the subset of
the traffic through as opposed to
-Original Message-
From: Hank Nussbacher [mailto:h...@efes.iucc.ac.il]
Sent: Tuesday, January 05, 2010 1:02 AM
On Tue, 5 Jan 2010, Stefan Fouant wrote:
Almost all of the scalable DDoS mitigation architectures deployed in
carriers or other large enterprises employ the use of an
I actually agree with most of this, but want to correct a clearly
inadvertent error below, and make a couple of points.
PCI DSS does not require a Web application firewall. It requires that OR
an independent audit of all code within PCI scope by a third party. If a
WAF is used, it only need be
On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
* Defense in depth. You've never had a host that received external traffic
ever accidentally have iptables or windows firewall turned off? Even when
debugging a production outage or on accident?
Again, policy should be enforced via
On Jan 5, 2010, at 2:38 PM, Darren Bolding wrote:
PCI DSS does not require a Web application firewall.
http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1313797,00.html
Since no business is going to allow an external 'code review' (if it's even
possible, given that
61 matches
Mail list logo
