linux-ipsec: New IPsec related RFC

[James Morris]

On Wed, 6 Oct 1999, C. Harald Koch wrote:

> RFC 2709 - Security Model with Tunnel-mode IPsec for NAT Domains

> Several people here were discussing NAT and FreeS/WAN; perhaps they could
> volunteer to read this RFC in that context and report back here? :-)

[Note the cc: to netfilter dev]

Architecturally, this should be possible when/if the project moves to
netfilter by setting the hook priorities for the tunnel such that it sits
'inside' NAT.

I was working on a very simple generic ip tunnel (rfc2003) under netfilter
a while back and there was some feedback from Rusty that it's probably a
very bad idea to get tunneling mixed in with the packet filter (iptables)
layer.  So, I then began working on tunneling 'outside' of both packet
filtering and NAT and it appeared to work ok as a proof of concept.

By 'outside', I mean that the packet filtering and NAT see the tunnel as
an opaque, end-to-end construct.  For example, you can apply iptables 
targets (such as DROP, LOG, RATE) to the entire tunnel, but not to
connections within the tunnel.  

The rationale is relative simplicity, but it raises the
spectre of having to incorporate packet filtering again within the 
tunneling mechanisms (by design, ipsec provides some control, at least).

A rather strange thought did occur to me however.  It might be possible to
think in OO terms, such that tunneling (and other components) inherits
capabilities (such as packet filtering) from iptables.  The idea
would be to implement an object model on top of the netfilter framework
(please note that this is not a slight against the current implementation,
it's really very sexy :-)

While I have not had time to develop the idea any further, I would 
certainly appreciate any feedback/discussion on the idea. 

Managing complexity is a major issue in the implementation and management
of firewalls and VPNs, and security in general.  While I am generally
skeptical of OO as a magic bullet for dealing with complexity, I suspect
it may form the basis of a viable solution here.


- James.
--
James Morris
<jmorris@intercode.com.au>