netdev
[Top] [All Lists]

Re: linux-ipsec: FreeS/WAN redesign thoughts (KLIPS, IPSEC)

To: Richard Guy Briggs <rgb@xxxxxxxxxxxxxxxxxxxxx>
Subject: Re: linux-ipsec: FreeS/WAN redesign thoughts (KLIPS, IPSEC)
From: Bart Trojanowski <bart@xxxxxxxxx>
Date: Thu, 17 Aug 2000 09:35:08 -0400 (EDT)
Cc: Linux Ipsec mailing list <linux-ipsec@xxxxxxxxx>, NetFilter mailing list <netfilter@xxxxxxxxx>, Linux Network Development mailing list <netdev@xxxxxxxxxxx>, John Gilmore <gnu@xxxxxxxx>, Hugh Daniel <hugh@xxxxxxxx>, Henry Spencer <henry@xxxxxxxxxxxxx>, Hugh Redelmeier <hugh@xxxxxxxxxx>, Richard Guy Briggs <rgb@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to: <20000815143539.B4771@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Tue, 15 Aug 2000, Richard Guy Briggs wrote:
> 
> The way that nfmark is used is rather vague.  It is presently only 32
> bits.  Ideally, I would like to be able to indicate exactly which SAs
> were processed on the way in, which would most easily be represented by
> as many as 4 SAs (AH, ESP, IPCOMP, IPIP), each having an 8 bit protocol
> field (absolute minimum of a 2-bits), 32-bit destination address field
> (for IPv4, IPv6 would be 128) and a 32-bit SPI.  This is a potential
> maximum of 672 bits.  A way of mapping 672 bits on to the 32 bits
> available would be required to use this.  A lookup table could be used
> to map nfmarks to SAIDs, not the SAs themselves, since the SAs could
> disappear at any time the tdb table is not locked.  It should be able to
> represent a bundle of SAs where one SA could be used in more than one
> bundle.  There could also be more than one right answer for the incoming
> SPDB.

I don't have a clear understanding on why a packet would need to know
which SAs where used.  Was this because we want to check if a packet is
allowed to emerge from a certain tunnel?

> The SPDB would be managed via a combination of PF_KEYv2 socket I/F
> extensions and iptables.  A separate NetFilter table called 'ipsec'
> (as opposed to 'filter' or 'nat') would have the first hook at
> NF_IP_PRE_ROUTING and the last hook at NF_IP_POST_ROUTING.  iptables
> uses the AF_NETLINK socket family.

With respect to backwards compatibility in kernels and the ipchains ->
iptables issue.  You mentioned using iptables hooks for this.  I think
that backwards compatibility is important so I would like to explore this
a bit to see if it would be possible to have a source base that compiled
on 2.2 and 2.4 without any hacks to the kernel source.

Ipchains does not have provisions for a new table - thus sharing the 1
table with other chains (input, output and forward) is needed.  I assume
that having a disjoint chain in ipchains is possible so this is not really
an issue... even though it's much cleaner to have your own table as in
iptables.

At OLS Andy, I think it was him anyway, commented on the posibility of
backporting some of the new networking code from 2.4 to 2.2.  Does anyone
remember if this included iptabless?

> I'm not certain exactly where a packet routed through an optional IPSEC
> virtual I/F gets injected into the system.

I believe this is done using nf_reinject(); this function allows you to
decide what to do with the packet upon reinjection. I know that you can
tell it to DROP, ACCEPT, and REPEAT.  It is probably the later that we
will want to do further routing checks and so on.

I don't know how this translates to ipchains.


> Treat incoming IPSEC encapsulation as an enhancement of the layer 2
> protocol and decapsulate it at the NF_IP_PRE_ROUTING hook.  This option
> is less favourable as it stands since it involves creating our own SPDB
> engine.

I think that reusing the existing tools is a good idea.  At first glance I
like the first scenario more.

Bart.

-- 
        WebSig: http://www.jukie.net/~bart/sig/




<Prev in Thread] Current Thread [Next in Thread>