[Top] [All Lists]

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

To: Bart Trojanowski <bart@xxxxxxxxx>
Subject: Re: linux-ipsec: FreeS/WAN redesign thoughts (KLIPS, IPSEC)
From: Richard Guy Briggs <rgb@xxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 17 Aug 2000 09:24:16 -0400
Cc: Richard Guy Briggs <rgb@xxxxxxxxxxxxxxxxxxxxx>, 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>
In-reply-to: <Pine.LNX.4.21.0008170843060.8729-100000@localhost.localdomain>; from on Thu, Aug 17, 2000 at 09:35:08AM -0400
References: <> <Pine.LNX.4.21.0008170843060.8729-100000@localhost.localdomain>
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.2i
On Thu, Aug 17, 2000 at 09:35:08AM -0400, Bart Trojanowski wrote:
> 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?

We must be able to ensure that a certain policy was followed in
sending the packet to this machine.  If it was sent in cleartext from
a spoofed machine, but policy dictates that it was expected to be 3DES
MD5 processed from a certain SG, we *must not* trust that packet and
we *must not* reply to it.

> > 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.

I believe NetFilter has been backported to 2.2?  Can someone confirm

> 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.

Possibly.  I wondered this myself.  I did contemplate using the 'nat'
table to accomplish our goals, but decided it would be cleaner to use
our own table that would have a different priority so that IPSEC would
always be applied before DNAT on input and after SNAT on output.

> 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 don't remember, but he did opine in the last couple of days in an
informal channel that all of the interesting network stuff had been
backported from 2.4 to 2.2 and this would annoy the 2.4 spindoctors.

> > 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.

Right, possibly to NF_IP_LOCAL_OUT

> I don't know how this translates to ipchains.

It would have to be routed, so I would hazzard to guess input chain.

> > 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.

I tend to agree, but don't have a solution yet to the NFMARK->SPDB

> Bart.

Thanks for your comments.

        slainte mhath, RGB
Richard Guy Briggs -- PGP key available            Auto-Free Ottawa! Canada
<>                       <>
Prevent Internet Wiretapping!        --        FreeS/WAN:<>
Thanks for voting Green! -- <>      Marillion:<>

Attachment: pgpsmgPGZOnjM.pgp
Description: PGP signature

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