On Fri, Mar 15, 2013 at 2:10 PM, Ansis Atteka <[email protected]> wrote: > On Thu, Mar 14, 2013 at 4:23 PM, Jesse Gross <[email protected]> wrote: >> On Thu, Mar 14, 2013 at 2:27 PM, Ansis Atteka <[email protected]> wrote: >>> After tunnel packet is unencapsulated we should unset IPsec flag from >>> skb_mark. >>> >>> Otherwise, IPsec policies would be applied one more time on internal >>> interfaces, if there is one. This is especially necessary after we >>> will introduce global, low-priority IPsec drop policy that will make >>> sure that we never let through marked but unencrypted packets. >>> >>> Signed-off-by: Ansis Atteka <[email protected]> >>> Issue: 15074 >> >> Is it possible to make the IPsec drop policy apply only on outbound packets? > > > A good point - it is possible. Though, we would have to install this > IPsec policy explicitly and not from the keying daemon itself with > something like this: > ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 dir out mark 1 mask 1 > action block priority 32768 > Which I think is fine. > > > If we go this simple way, then we don't need this patch at all. On the > other hand that would mean that: > 1. we would have to ensure that strongSwan under some circumstances > does not flush this policy away (for example, it cleans all policies > on restart) > 2. decapsulated packet would travel all the netfilter/iptables hooks > with mark set on the internal interface. Not sure, if this is big > deal, but then, for example, following nested tunneling scenario would > not work any more: > > Node1---gre--->Node2---gre over ipsec_gre--->Node3(terminates both gre > and ipsec_gre tunnels) > > There is a: > 1. GRE tunnel between NODE1 and Node3 (internal interface) > 2. IPSEC_GRE tunnel between NODE2 and NODE3 (physical interface) > > Tunnel lookup for plain GRE would fail because it still had the mark set.
Hmm, probably neither of these issues are huge problems but they are somewhat annoying. It doesn't really seem worth dealing with them, so let's just go with your patch. I'm somewhat worried about our use of skb mark conflicting with other uses but this doesn't really change that all that much. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
