freeswan/klips/doc/klipsNGreq/requirements/017/requirement017.tex

   1 \subsection{017: integrate IPsec and firewall policy into Security Policy.}
   2
   3 \subsubsection{017: Definition of requirement }
   4
   5 To provide industrial-strength security, the IPsec Security Policy Database
   6 should be integrated with the regular Linux firewalling facilities,
   7 specifically into the Netfilter/IPtables code.
   8
   9 Integration provides a single place to express policy.
  10 It prevents duplication of code: this is both a savings in physical
  11 quantities (kernel time and code space) as well as a reduction in
  12 opportunities for errors.
  13
  14 \subsubsection{017: response}
  15
  16 This is a core design requirement for KLIPS3.
  17
  18 As I said at OLS (see Claudia's notes, posted to this list at 11:04 AM
  19 8/1/01 -0400)...  Any form of IPsec *requires* proper firewall rule
  20 management.  IPsec security is (and always has been, and always will be)
  21 totally dependent on this.
  22
  23 People think that bringing up a tunnel creates security.  This is
  24 diametrically wrong.  Real life is always a tradeoff between security and
  25 functionality.  A tunnel creates new functionality;  it creates a new path
  26 for packets to flow.  Security comes when AND ONLY WHEN you close down the
  27 old insecure paths.
  28
  29 The IPsec rfcs require IPsec to have a Security Policy Database.  "The form
  30 of the database and its interface are outside the scope of this
  31 specification."  according to section 4.4.1 in
  32    http://www.ietf.org/rfc/rfc2401.txt
  33
  34 But some nontrivial semantics is required.  Just bringing up a tunnel (a
  35 "virtual wire") is !not! sufficient to comply with the letter or the spirit
  36 of this rfc.  IPsec !must! provide the IPsec-administrator with some means
  37 to express a security policy that cuts off the bad old insecure paths.
  38
  39 The tricky part comes when we try to integrate the tunnel-related policies
  40 with whatever other policies the admin might have in mind.
  41
  42 =======
  43
  44 To look at it from a slightly different viewpoint:  Everybody who installs
  45 freeswan will be able to express an ultra-vague ultra-high-level security
  46 objectives:  they want all the good things to happen, and they want none of
  47 the bad things to happen, whatever that means.
  48
  49 At the ultra-low level, the kernel provides some tools for allowing and
  50 disallowing various packet flows based on various criteria.
  51
  52 The problem is that there is a huge disconnect between the high-level
  53 objectives and the low-level tools.  The low-level stuff has a lot of
  54 changeable details:
  55   -- the details change on boot up:  rc.d/init.d/network start
  56   -- the details change on card insertion:  pcmcia/network start $dev
  57   -- the details change when DHCP runs....
  58   -- the details change when tunnels go up and down...
  59   -- the details might depend on what our routing daemons are telling us.
  60
  61   *) Making this work is a royal pain in the neck or worse.
  62   *) Making it work robustion for redhat AND debian AND suse, etc. is an
  63 even bigger pain.
  64 ... but in my humble opinion this is a REQUIRED part of any real-world
  65 IPsec implementation.
  66
  67 The freeswan project has taken quite a firm stand on some other
  68 security-related issues such as single-DES.  I hope it will take an equally
  69 firm stand on implementing an industrial-strength Security Policy
  70 Database.  Single-DES is a joke, suitable for hobbyists only.  Tunneling
  71 without firewalling (etc.) is in the same category.
  72
  73
  74