Selective connection tracking - to be or not to be? :)

[Alexander Demenshin]

On Tue, Jun 20, 2000 at 01:54:54AM +1000, Rusty Russell wrote:

> Sorry; this is not negotiable 8( The design is simplified greatly by
> tracking everything: as soon as you don't track some traffic, tracking
> becomes unreliable.  For example, how can you tell if an ICMP error is
> valid if you haven't tracked all connections?

  If it is possible not to include conntrack at all (kernel option),
  why it is not possible to turn it off for some specific interfaces
  and/or addresses?
  
  For example, the problem I've had few days ago during benchmarking
  of my web server:
  
Jul  4 21:19:25 mirage kernel: ip_conntrack: maximum limit of 16376 entries exceeded
Jul  4 21:19:25 mirage kernel: NAT: 3 dropping untracked packet c3f6eda0 6 10.11.2.7 -> 10.11.2.7

  In fact, there is no need to track _local_ connections. Or even "semi-local",
  like in my corporate network:
  
  - Central location (HQ)
  - Four branches connected to HQ via dedicated channels (no public access)
  
    All traffic between locations is routed through Linux, and all locations
    are trusted, but (there is always but) - I would like to track _only_
    traffic that is going to _outside_, but _not_ traffic between locations.
    
  I am pretty sure this kind of network is not unique, so an option to
  selectively turn off tracking would be useful. IMHO :)


> It'd be pretty easy to have a `conntrack' table which controlled which
> packets get handed to the connection tracking code, but:
> 
> 1) I'll have to deal with the bug reports.

  You have to do so even without this :))

> 2) Give people too many knobs (and the associated 2000-line HOWTO) and
>    they'll end up with something grossly insecure, because they "only"
>    allocated themselves 8 hours to get their Linux-based packet filter
>    working!

  In case of 8hrs they anyway will end up with something insecure :)
  
  I remember we have had this discussion some time ago, but... Everything
  that can be an option should be an option - IMHO... Some time ago,
  during my experiments with Windows firewall (WinRoute; btw very good
  one) I've found that it is impossible to specify IP address 255.255.255.255
  in rules (this is only problem I've found), I wrote to authors asking
  "Why it is impossible?". The answer was: "This IP address is not legal
  and you do not need it". Well, may be they think that it is not legal,
  but it is pretty legal anyway (so called "global broadcast") and I would
  like to filter it out. 
  
  In Netfilter, we are coming to something similar - "It will not be
  implemented because you do not need it".

  I am pretty sure that option to turn off tracking selectively would be
  very nice feature, and I am not only one who need it... In good implemeted
  applications there is always at least two modes of operations - "simple"
  and "advanced" (aka: use at your own risk). Why not to do so in Netfilter?
  
  Anyway you cannot make Netfilter "fool proof" - a lot of people will end up
  in insecure configurations due to misunderstanding, lack of time or experience...
  
  So, what I am trying to say? Easy - "Computers should not think, they should
  do _exactly_ we want". No option in case of conntrack is something like
  "Users are too stupid to manage their computers". Yes, most of the time it is
  true :), but usually firewalls are configured by someone who has enough
  knowledge and/or experience to not misuse the power.
  
  That's all.
  
  Any comments? :)
  
  NB: May be I am totally wrong but at least I express my _own_ opinion
      and I would like to get some feedback on it.

/Al