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
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
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
I think that reusing the existing tools is a good idea. At first glance I
like the first scenario more.