Am Samstag, 23. April 2005 19:49 schrieb jamal:
> On Fri, 2005-22-04 at 15:22 +0200, Wolfgang Walter wrote:
> So to allow pass-through of esp packets from a<->d at c, you will have
> to essentially create special policy rules (at FWD and OUT) to basically
> just allow if src/dst = a/d, correct?
Yes.
>
> > spdadd 192.168.2.100 192.168.3.10 any -P in ipsec
> > esp/transport//require
> > ah/transport//require;
> >
> > installs both in and fwd rules (in RFC-mode).
>
> What is "RFC mode"?
The RFCs for ipsec talk about the SPD. This database must be consulted for
every packet entering or leaving. Its defined as an ordered database. A rules
has direction, selectors (i.e. src, dst, next layer protocoll, src-port,
dst-port, icmp-type) and processing info (BYPASS = not handled by ipsec,
DISCARD = drop the packet, PROTECT = handled by ipsec).
So setkey in RFC mode sets in anf fwd rules as RFC-in = linux-in + linux-fwd.
>
> > Use option -k for only setting in rules (RFC only knows IN and OUT
> > rules). This behaviour was added to
> > ipsec-tools. As far as I know earlier kernels had a bug and didn't check
> > fwd ruleset so that setkey and racoon worked by accident under linux.
> >
> >
> > racoon now behaves like pluto: it inserts always in and fwd rules. Its
> > easier than to check if a in or fwd rule or both is needed.
>
> I think i am still lost on the desire to have the FWD database. Unless
> we are trying to use SPD for firewalling?
SPD is indeed also a sort of firewall. You can use it to construct i.e. a
vpn-gateway and forbid any non-vpn-traffic entering or leaving.
How the SPD is implemented is of course not specified. I think KLIPS use a
mixing of routing and netfilter and "ipsec-netdevices" to realise the SPD.
My personal view is that 2.6 native SPD is better. Its easier to understand
and protect i.e. vpn-gateways.
Using selectors other than src, dst in the SPD is tricky, by the way, because
of fragments. Say a rule selects packets from a to b with protocol tcp and
dst-port 80 to be sent through a tunnel you must have an extra rule (and
tunnel) for the fragments (and all fragments are tunneled then).
Maybe more complex selectors should be realised by netfilter, a module which
can mark packets. And SPD uses that mark. Then statefull policies are
possible, i.e.
I don't know if linux handles ICMP traffic well, often one must check the
payload against the SPD. I had no time yet to do some tests.
>
> > And no, we do not use setkey any more but ip xfrm (though setkey displays
> > more information, i.e. it tells you if a policy is socket-specific).
>
> Should be fixable in ip xfrm ..
>
> > Reason is
> > that neither setkey nor racoon can handle large rule sets. And for most
> > fwd rules we also set an in rule (as pluto does).
>
> Do you know why pfkey doesnt scale? Herbert?
It seems to deliver the whole message at once. If one increase the
socket-buffer (must change racoon and setkey source, at least with version
0.3.3) enough one gets complete dumps, ie. But sometimes there seems to be
still problems - i.e. if you send a lot of messages. Maybe the kernel can not
create these large messages because it cannot allocate enough memory in that
moment or racoon cannot read fast enough.
Greetings,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leopoldstraße 15
80802 München
|