1 \subsection{017: integrate IPsec and firewall policy into Security Policy.}
3 \subsubsection{017: Definition of requirement }
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.
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.
14 \subsubsection{017: response}
16 This is a core design requirement for KLIPS3.
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.
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
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
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.
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.
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.
49 At the ultra-low level, the kernel provides some tools for allowing and
50 disallowing various packet flows based on various criteria.
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
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.
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
64 ... but in my humble opinion this is a REQUIRED part of any real-world
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.