On Fri, Mar 15, 2013 at 3:27 PM, Jesse Gross <je...@nicira.com> wrote: > On Fri, Mar 15, 2013 at 2:10 PM, Ansis Atteka <aatt...@nicira.com> wrote: >> On Thu, Mar 14, 2013 at 4:23 PM, Jesse Gross <je...@nicira.com> wrote: >>> On Thu, Mar 14, 2013 at 2:27 PM, Ansis Atteka <aatt...@nicira.com> 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 <aatt...@nicira.com> >>>> 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. Thanks, I pushed this to branch 1.10 and master
> > I'm somewhat worried about our use of skb mark conflicting with other > uses but this doesn't really change that all that much. Agree. Do you think it would make sense to specify (e.g. from ovs-vsctl or ./configure) which bit of skb_mark should go for the IPsec? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
