> > 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" >
Having used many different firewalls, I think I see the argument here. Traditionally a proxy is something that would "block" the flow of traffic. The packets would terminate at the proxy, the proxy would inspect them up to the application layer/Layer 7. The proxy would then initiate the conversation to the "outside" on behalf of the client. I believe what is being requested is a kind of state engine that is smart enough to modify packets on the fly and recognize "related" packets. This is common in many commercial firewalls and also in SunScreen and Netfilter/IPTables. I would argue that this is not quite the same as a proxy. However, now-a-days, the difference between a stateful/NAT firewall and a Proxy is a fine line and somewhat subjective. > > 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. > This is very interesting to me. Perhaps I just don't know enough to understand what you are saying. I have done some socket and kernel programming, but I'm no Daniel or Henning. What I don't get, is if what you are saying is true, how do commercial firewall products work? They don't have access to the O/S source code and manage. What am I missing? How is it a layer violation? Can't you link in with a callback or something? Why do you have to re-implement TCP? I do think if you were going to do something like this, a framework would have to be agreed upon. Perhaps it could be a userland framework although you'd have to look at performance and scalability. > 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. > It is definitely true that the more kernel code you have, the higher the risks are. The traditional problem with userland programs (from my understanding) is that they don't scale. That seems to be a big part of why proxies are slow. That's why many people are trying to cache web pages in the kernel--it's faster. Don't get me wrong, I'm not necessarily advocating this position. It's a trade off between performance and security. I'm sure Henning is pulling his hair out reading this... :) In the end, I think Daniel is right. It sounds like a cool feature, but someone would have to step up or help fund it. Perhaps some day, I'll learn enough to be able to contribute... <> Jim
