[ovs-discuss] Understand GRE IPSEC tunnels in 2.5/2.6/2.7

[Keith Holleman]

I am trying to understand a few things about the implementation of GRE over
IPSec tunnels across some of the more recent OVS releases.  As I understand
it, 2.5 had support for it but in 2.6 the IPSec scripts (and effectively
the support) were pulled out in 2.6 due to concerns around mark usage.  I
have also seen patches proposed that migrated from racoon to strongswan but
I don't think they were ever fully accepted.  So I have three questions:

1) What is the plan for IPSec support in 2.7 and/or future releases?
2) Is there any plan to move away from racoon to something else?  The patch
proposed a while ago didn't seem to have any comments or debate against it
that I could find.
3) Can someone explain a bit of the mark behavior?  First as it exists in
2.5?  Apparently part of the problem with it was the fact that OVS expects
to use the LSB of the mark for it's own purposes and it will conflict with
other uses of the mark.  I think this is problem I have in places where the
mark is used for other behaviors.  Is it that after the ESP packet arrives
and is transformed back into the GRE packet, the mark is set to 0x1 by the
xfrm policy and then the OVS layer is expecting that when decap'ing the GRE
packet?  And it is in this manner that a GRE-IPSec packet (with mark 0x1)
is distinguished from a regular GRE packet (with mark 0x0)?  But once this
tunnel port is found and the GRE packet is decapped - what is the state of
the mark, connmark/connstate?  I may have some of it wrong but tried to
learn and trace it out through iptables using the "TRACE" action, by
messing with the mark, and by looking at OVS logs.

And is there an agreed upon way to to fix this mark usage when returning
the IPSec support to OVS?  If so what does that behavior look like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170210/b4b9c798/attachment.html>