> In fact, even if it does not really matter to you in fact, I'm not > talking about a kernel "proxy" here. I'm talking about something smart > enough to tag packets "related" and so to "pass" them.
A piece of kernel code smart enough to inspect packets comprising a partular protocol, and extract enough information to determine if they are, in fact "related" is exactly what Henning is referring to as a kernel "proxy" > If we go on with FTP, a piece of code that attach data connexions to > the command connexion initiated before. In case of a bridge, I > clearly do not need (and do not want !) a proxy, nor NAT support. Yes. Since the kernel sees traffic a packet at a time, it essentially has to "fake" the statefulness of TCP in order to track these things. It's a layer violation. It's also next to impossible, without re-implementing TCP. This is EXACTLY why the decision to make these kinds of per-protocol decision was relegated to userland in the first place: because TCP will handle the state issues, before userland sees the packets. Think fragment attacks. Think of the attacks against IPF's ftp kernel code. Think of EVERY ambiguity that scrub was intended to help correct. We had this debate long ago. The kernel way is the WRONG way. Writing a userland proxy for a particular protocol is by definition easier than writing the kernel equivalent, since you don't have to figure out what the TCP will do with ambiguities. -kj
