On Sat, 2005-23-04 at 23:03 +0200, Wolfgang Walter wrote:
>
> 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.
>
So i think design intent must have been to map these to the
netfilter/iptables hooks - fwd/in/out hooks.
> 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.
>
It could certainly be any applicable classifier that can map at least
the 6 tuples {src/dst IP, src/dst port, proto, netdevice}.
> My personal view is that 2.6 native SPD is better. Its easier to understand
> and protect i.e. vpn-gateways.
Except it introduces yet another firewall scheme. We should look at
unifying these schemes. Both the input/fwding can be derived at the
ingress.
> 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 think that it is probably the best path forward - i suppose this being
the first incarnation of native ipsec this could be seen as a lesson.
> 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.
>
from the code it should work just fine.
cheers,
jamal
|