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
On Thu, Jun 13, 2013 at 3: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.
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
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@gmail.com
wrote:
On Thu, Jun 13, 2013 at 3: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.
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
On Thu, Jun 13, 2013 at 4:47 PM, Phil Fagan <philfagan@gmail.com> wrote:
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?
not sure, but their docs talk about using the fpga for doing HFT... so I presume it's got the abiliity to see all traffic on at least on interface, eh? (I believe the fpga is really connected to the bus as a 10g link... but I haven't tried this I've only read their docs)
On Thu, Jun 13, 2013 at 2:03 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Thu, Jun 13, 2013 at 3: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.
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
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
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
I would assume something FreeBSD based might be best.... On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan <philfagan@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@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
-- Phil Fagan Denver, CO 970-480-7618
On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan <philfagan@gmail.com> wrote:
I would assume something FreeBSD based might be best....
Meh... personal choice. I prefer Linux, mostly because I know it best and most network application development is taking place there.
On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan <philfagan@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?
Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have the best support in the kernel.
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?
Heh... "fast" Perl. As for programming the processing, I would do as much as possible in the kernel, as passing packets off to userland really slows everything down. If you really need to, I'd do something with Go and/or C these days. Using iptables and the "string" module to match patterns, you can chew through packets pretty efficiently. This comes with the caveat that this can only match against strings contained within a single packet; this doesn't do L4 stream reconstruction. You can do some incredibly-parallel stuff with ntop's PF_RING code, if you blow more traffic through a single core than it can chew through. It all depends on what you're trying to do. --j
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
-- Phil Fagan Denver, CO 970-480-7618
Yeah, I only thought of perl cause I'm used to running through 'while true' loops and someone showed me Perl was about 400x faster....good thing I'm not running through 10gb/s worth of data :-D Figured getting closer to hardware was the way to go.....I'll have to check out PF_RING. On Thu, Jun 13, 2013 at 4:49 PM, Jonathan Lassoff <jof@thejof.com> wrote:
On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan <philfagan@gmail.com> wrote:
I would assume something FreeBSD based might be best....
Meh... personal choice. I prefer Linux, mostly because I know it best and most network application development is taking place there.
On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan <philfagan@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?
Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have the best support in the kernel.
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?
Heh... "fast" Perl. As for programming the processing, I would do as much as possible in the kernel, as passing packets off to userland really slows everything down. If you really need to, I'd do something with Go and/or C these days.
Using iptables and the "string" module to match patterns, you can chew through packets pretty efficiently. This comes with the caveat that this can only match against strings contained within a single packet; this doesn't do L4 stream reconstruction.
You can do some incredibly-parallel stuff with ntop's PF_RING code, if you blow more traffic through a single core than it can chew through.
It all depends on what you're trying to do.
--j
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
-- Phil Fagan Denver, CO 970-480-7618
-- Phil Fagan Denver, CO 970-480-7618
Johnathan is correct about not using perl for this. There are some iptables modules, but they're all out of date or incomplete (I mention this because if you get around to making them work decent, I'll love you for it). Otherwise, perl -> IPC::Run -> ipt isn't going to gain you anything. And I'd be amazed if you could even keep up with a gbit. Per signature detection, see Bro. Though, it seems the ipt state module might fit the bill just fine. And you could log that and then have an ETL that scraped your log file and created a new ACL based on that (so that hardware could do the majority of the work). I'm sure an ipt -> acl isn't a new idea and you can probably find something that handles most edge cases. On Jun 13, 2013 7:12 PM, "Phil Fagan" <philfagan@gmail.com> wrote:
Yeah, I only thought of perl cause I'm used to running through 'while true' loops and someone showed me Perl was about 400x faster....good thing I'm not running through 10gb/s worth of data :-D
Figured getting closer to hardware was the way to go.....I'll have to check out PF_RING.
On Thu, Jun 13, 2013 at 4:49 PM, Jonathan Lassoff <jof@thejof.com> wrote:
On Thu, Jun 13, 2013 at 3:38 PM, Phil Fagan <philfagan@gmail.com> wrote:
I would assume something FreeBSD based might be best....
Meh... personal choice. I prefer Linux, mostly because I know it best and most network application development is taking place there.
On Thu, Jun 13, 2013 at 4:37 PM, Phil Fagan <philfagan@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?
Personally, I'd use modern-ish Intel Ethernet NICs. They seem to have the best support in the kernel.
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?
Heh... "fast" Perl. As for programming the processing, I would do as much as possible in the kernel, as passing packets off to userland really slows everything down. If you really need to, I'd do something with Go and/or C these days.
Using iptables and the "string" module to match patterns, you can chew through packets pretty efficiently. This comes with the caveat that this can only match against strings contained within a single packet; this doesn't do L4 stream reconstruction.
You can do some incredibly-parallel stuff with ntop's PF_RING code, if you blow more traffic through a single core than it can chew through.
It all depends on what you're trying to do.
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
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
--j the 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
-- Phil Fagan Denver, CO 970-480-7618
Better still, http://dilbert.com/strips/comic/1996-09-07/ Jeff On 6/13/2013 6:41 PM, Christopher Morrow wrote:
On Thu, Jun 13, 2013 at 6:37 PM, Phil Fagan <philfagan@gmail.com> wrote:
fast Perl haha :) that's cute.
Procera Networks -- http://proceranetworks.com That will do what you want. Thanks, --- Patrick Bailey On Jun 13, 2013, at 3: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
+1 for Bro http://www.bro.org http://packetpushers.net/healthy-paranoia-show-11-bro-the-outer-limits-of-id... Sent from my iPad On Jun 13, 2013, at 2: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
On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote:
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.
What's the actual application for this mechanism? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
Oddly enough, anticensorship. We use similar technology as the censors (DPI, flow blocking), but use our system in a non-censoring country's ISP to detect secret tags in connections from censored countries, and serve as a proxy for them. Once we detect a flow with a secret tag passing through the ISP, we block the real flow, and start spoofing half of the connection. We use this covert channel to communicate to the client and act as a proxy. To the censor, this looks like a normal connection to some innocuous, unrelated (and unblocked) website. The obvious difficulty is convincing ISPs to deploy such a proxy. More details can be found at https://telex.cc/ On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote:
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.
What's the actual application for this mechanism?
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
I think we just discussed this over in the huawei list ;-) This is pretty awesome! On Fri, Jun 14, 2013 at 12:30 PM, Eric Wustrow <ewust@umich.edu> wrote:
Oddly enough, anticensorship. We use similar technology as the censors (DPI, flow blocking), but use our system in a non-censoring country's ISP to detect secret tags in connections from censored countries, and serve as a proxy for them. Once we detect a flow with a secret tag passing through the ISP, we block the real flow, and start spoofing half of the connection. We use this covert channel to communicate to the client and act as a proxy. To the censor, this looks like a normal connection to some innocuous, unrelated (and unblocked) website. The obvious difficulty is convincing ISPs to deploy such a proxy. More details can be found at https://telex.cc/
On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote:
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.
What's the actual application for this mechanism?
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
-- Phil Fagan Denver, CO 970-480-7618
Eric, I haven't read the full paper yet, however, are you simply acting as a proxy and redirecting based on the secret tag found in the header? What is your expectation for session/second use? I would think you would need to scale largely, however, I don't have a good understanding of how large the market is for users trying to obfuscate the states firewall/proxy/dns controls etc. ISP seems like a great place to live for that; what have they said so far? On Fri, Jun 14, 2013 at 12:30 PM, Eric Wustrow <ewust@umich.edu> wrote:
Oddly enough, anticensorship. We use similar technology as the censors (DPI, flow blocking), but use our system in a non-censoring country's ISP to detect secret tags in connections from censored countries, and serve as a proxy for them. Once we detect a flow with a secret tag passing through the ISP, we block the real flow, and start spoofing half of the connection. We use this covert channel to communicate to the client and act as a proxy. To the censor, this looks like a normal connection to some innocuous, unrelated (and unblocked) website. The obvious difficulty is convincing ISPs to deploy such a proxy. More details can be found at https://telex.cc/
On Fri, Jun 14, 2013 at 3:15 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Jun 14, 2013, at 2:32 AM, Eric Wustrow wrote:
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.
What's the actual application for this mechanism?
----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Luck is the residue of opportunity and design.
-- John Milton
-- Phil Fagan Denver, CO 970-480-7618
participants (10)
-
Christopher Morrow -
Dobbins, Roland -
Eric Wustrow -
Jeff Kell -
Jonathan Lassoff -
Kenny Kant -
Patrick Bailey -
Phil Fagan -
QliX=D! [aka EHB] -
shawn wilson