Re: [PATCH]: latest netfilter+ipsec patches

[Patrick McHardy <kaber@trash.net>]

[-- Attachment #1: Type: text/plain, Size: 4497 bytes --]

Hi Willy,

Willy Tarreau wrote:
> This is excellent. So if I understand it right, a packet now passes this way
> (please excuse the ascii-art, it seems I'll never take the time to start xfig)
> 
>             [incoming packet]
>                     |<-----------------. 
>                     v                  |
>                PREROUTING              |
>     dest!=local?  /  \  dest==local?   |
>                 /      \               |
>          FORWARD        LOCAL_IN       |
>              |            |            |
>              |      (ipsec?decrypt:nop)|
>              |            |   \        / dest!=local ? nf_postxfrm_nonlocal()
>              |            |    `------'
>              v            v  dest==local ? ip_local_deliver_finish()
> 
> 
> So if it behaves like this (which is what seems the best solution to me), is
> there a risk that a carefully crafted packet loops many times on the right
> side (multiple encapsulation with local DIP) ? And if so, is it risky or not,
> wrt resource leak, multiple locks, etc... ?

Not exactly. the ipsec transformers are ip protocol handlers,
their input handler (xfrm4_input) is called from
ip_local_deliver_finish. After decrypting the payload the packets
are either reposted into the network stack (in case of a tunnel-mode
SA) or again delivered to the ip-protocol contained in the next
header. packets reposted into the stack may be in some intermediate
state in case of a transport mode encapsulation following a tunnel
mode encapsulation. The difficulty is to know when the packet
is "done". So nf_postxfrm_nonlocal is called directly after input
routing if the destination is non-local, but only for packets which
were reposted into the stack. The fact that they have a non-local
destination means ipsec must be done with them. For packet with
local destination, we look at what the ipprotocol handler does
in ip_local_deliver_finish (xfrm_prot or not) and if the packet
was handled by ipsec before and the protocol handler is no xfrm_prot,
ipsec is done, so the packets are passed through nf_postxfrm_input.

I attached a xfig file with a little picture of how it works, I hope
it's understandable. The blue lines represent the flow as it happens
without my patches, the red lines represent whats new. While drawing
it, I noticed a bug, packets with their destination changed
in nf_postxfrm_nonlocal may need to be delivered locally afterwards.

Regarding loop-danger, I'm not totally sure yet, but I don't think
that it would be triggerable by crafted packets but only by
adventurous configurations. Multiple encapsulations are no error
and they are limited to 4.

>>The only problem with this approach I'm currently aware of is that
>>one of the ip-protocol handlers marked with xfrm_prot
>>(xfrm4_tunnel.c) is also responsible for dispatching packets to
>>ipip.c; the encapsulated packets heading for a ipip-tunnel won't
>>traverse the netfilter hooks on input.
> 
> 
> I don't know well the internals of IPSEC (bought the book but didn't read it
> yet). Are IPIP tunnels often used ? or are they simply used according to a
> negociation, in which case the ipsec implementation on the netfilter side
> could refuse them ?

It's not IPIP with IPSEC that misbehaves but plaintext-IPIP tunnels.
xfrm4_tunnel.c is the registered handler for IPIP, it used to be ipip.c.
ipip.c now registers itself with xfrm4_tunnel, but xfrm4_tunnel is
marked as a xfrm_prot which is not true for ipip.c. Right now I'm not
even sure that it is a problem and under what exact circumstances, I
need to think about this some more (tomorrow).

>>- new match "policy" for matching the policy that was used during
>>decapsulation (well, the used SAs, policy checks come later), and the
>>policy that will be used for encapsulation.
> 
> 
> Even more interesting... Now we can for sure check that packets coming from
> a tunnel have not been spoofed by another tunnel.

That should also be handled by the policy checks, although at a
later time (at socket-delivery/forwarding). I'm unsure if the
policy checks should happen before packets are looked at by
netfilter, after all it manipulates it's state from information
in these untrusted packets.

> 
> Thanks a lot Patrick.
> My main goal is to use this on 2.4 with davem/herbert xu's ipsec backport.
> I will soon check if your patches apply on top of their implementation.

Thanks for your comments, I'm looking forward to your testing.

Best regards
Patrick


> 
> Cheers,
> Willy
> 


[-- Attachment #2: nf+ipsec.xfig.fig --]
[-- Type: image/x-xfig, Size: 3113 bytes --]