Blocking TCP flows?

Thu Jun 13 22:38:46 UTC 2013

I would assume something FreeBSD based might be best....

On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan <philfagan at gmail.com> wrote:

> 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 at 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 at 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
>

-- 
Phil Fagan
Denver, CO
970-480-7618