[Click] tcp stack in click

[Weidong Cui]

> What kind of TCP proxy are you implementing?  Is it more like a NAT,
> or more like an endpoint?  The answers will influence how well Click
> currently supports it.

It's more like an endpoint (I have used the NAT support in Click a
lot).  I have implemented a replay proxy based on my NDSS paper on
protocol-independent replay
(http://www.cs.berkeley.edu/%7Ewdc/papers/CPWK06.pdf), using socket
APIs.  On one side, the replay proxy accepts incoming connections from
remote attackers.  On the other side, it opens connections to
honeypots to relay any data received from remote attackers.  So what
I'm interested in now is a set of APIs in Click which can replace the
basic socket APIs such as open(), listen(), select(), send(), recv(),
etc.  By using such APIs in Click, I can make the replay proxy a lot
more flexible and scalable.  I know this will limit my Click code to
run in the user level, but it's okay for me.

Eddie, do you have any suggestions or comments?

Weidong

--
Weidong Cui
Ph.D. Candidate
EECS, UC Berkeley
http://www.cs.berkeley.edu/~wdc/