[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Blocking TCP flows?
- Subject: Blocking TCP flows?
- From: philfagan at gmail.com (Phil Fagan)
- Date: Thu, 13 Jun 2013 14:47:58 -0600
- In-reply-to: <CAL9jLaZaPVmYrt_1tBn9ekRWX-=z1SE8Xu6tCb16wTsW6E8Z0A@mail.gmail.com>
- References: <CAGsuqq2c9+6fjzodGUqonGbK4Mg3bbgZwM+P92L46e-4Y1tgYg@mail.gmail.com> <CAL9jLaZaPVmYrt_1tBn9ekRWX-=z1SE8Xu6tCb16wTsW6E8Z0A@mail.gmail.com>
I didn't think the bus up to the FGPA was very beefy...wouldn't you need to
send flows up there off the data-plane for inspection?
On Thu, Jun 13, 2013 at 2:03 PM, Christopher Morrow <morrowc.lists at gmail.com
> wrote:
> On Thu, Jun 13, 2013 at 3: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.
> >
>
> this sounds like a job for the arista box with the FGPA onboard, no?
>
>
> > 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