[163657] in North American Network Operators' Group
Re: Blocking TCP flows?
daemon@ATHENA.MIT.EDU (Phil Fagan)
Thu Jun 13 18:38:27 2013
In-Reply-To: <CAHsqw9sE_RsN-y+KCtnQiWDD0er9izMqiFqvyFJzC=PG6z6oQA@mail.gmail.com>
From: Phil Fagan <philfagan@gmail.com>
Date: Thu, 13 Jun 2013 16:37:57 -0600
To: Jonathan Lassoff <jof@thejof.com>
Cc: Eric Wustrow <ewust@umich.edu>, "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I really like the idea of a stripe of linux boxes doing the heavy lifting.
Any suggestions on platforms, card types, and chip types that might be
better purposed at processing this type of data?
I assume you could write some fast Perl to ingest and manage the tables?
What would the package of choice be for something like this?
On Thu, Jun 13, 2013 at 3:11 PM, Jonathan Lassoff <jof@thejof.com> wrote:
> Are you trying to block flows from becoming established, knowing what
> you're looking for ahead of time, or are you looking to examine a
> stream of flow establishments, and will snipe off some flows once
> you've determined that they should be blocked?
>
> If you know a 5-tuple (src/dst IP, IP protocol, src/dst L4 ports) you
> want to block ahead of time, just place an ACL. It depends on the
> platform, but those that implement them in hardware can filter a lot
> of traffic very quickly.
> However, they're not a great tool when you want to dynamically
> reconfigure the rules.
>
> For high-touch inspection, I'd recommend a stripe of Linux boxes, with
> traffic being ECMP-balanced across all of them, sitting in-line on the
> traffic path. It adds a tiny bit of latency, but can scale up to
> process large traffic paths and apply complex inspections on the
> traffic.
>
> Cheers,
> jof
>
> On Thu, Jun 13, 2013 at 12:32 PM, Eric Wustrow <ewust@umich.edu> wrote:
> > Hi all,
> >
> > I'm looking for a way to block individual TCP flows (5-tuple) on a 1-10
> gbps
> > link, with new blocked flows being dropped within a millisecond or so of
> > being
> > added. I've been looking into using OpenFlow on an HP Procurve, but I
> don't
> > know much in this area, so I'm looking for better alternatives.
> >
> > Ideally, such a device would add minimal latency (many/expandable CAM
> > entries?), can handle many programatically added flows (hundreds per
> > second),
> > and would be deployable in a production network (fails in bypass mode).
> Are
> > there any
> > COTS devices I should be looking at? Or is the market for this all under
> > the table to
> > pro-censorship governments?
> >
> > Thanks,
> >
> > -Eric
>
>
--
Phil Fagan
Denver, CO
970-480-7618
