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

Ansis Atteka aatteka at nicira.com
Thu Feb 23 13:37:58 UTC 2017


On Thu, Feb 16, 2017 at 3:40 AM, Keith Holleman
<holleman at skyportsystems.com> wrote:
>
> Ansis,
>
> Thanks for the quick reply.  I have looked at your repository but am not
> really at a point right now where I can move and try it out.  Looks like you
> are again proposing moving from Racoon to Strongswan which is a good thing
> in my opinion.
>
> Since you didn't answer all of the questions directly, I'll relay what I
> found by looking at your repo and let me know if I'm off base.  As best I
> can tell you have you proposed again to still use the mark but have given
> the user control over which bit they can use.  However, I see that mark used
> in the scripts you have proposed but I see no changes to set that mark
> to/from the tunnels in other code.  Therefore, and I think you eluded to
> this, it is up to the user to ensure that the mark/bit is set properly prior
> to leaving OVS via a IPSEC-GRE tunnel port in order to be encrypted
> properly.  Is that right - nothing will automatically set this bit?

Thanks, that is a bug and I will remove the iptables rule that
currently installs skb mark. I think that it should be up to
administrator to set ingress skb mark because otherwise
ovs-monitor-ipsec would have to know how to do that with raw iptables,
ufw and potentially also with firewalld.

I missed this because to reduce development test cycle I was just just
scp'īng ovs-monitor-ipsec daemon and started it directly.

>
> How about for incoming packets that have been decrypted?  Does the XFRM
> policy set the mark on those packets after decryption?   Or is your what
No XFRM never sets mark on its own. Though, it retains previously set mark.

> your iptables rules in debian/openvswitch-ipsec.init is attempting to do?
> That however still seem to be hardcoded to bit 1/1.  And the GRE tunnel code
> checks that the mark is set and therefore IPSEC-GRE tunnels only decap GRE
> packets that have come through the IPSec tunnel?  In other words, someone
> can't just inject unencrypted GRE packets to the host and make it look like
> they arrived on the tunnel?
>
> I still am not sure I have the whole path laid out clearly.
You discovered a bug in my code hence probably the new implementation
proposal was not fully clear yet. Thanks and I will update the code!


>
> -K
>
> On Sat, Feb 11, 2017 at 3:33 PM, Ansis Atteka <aatteka at nicira.com> wrote:
>>
>> On Fri, Feb 10, 2017 at 6:41 PM, Keith Holleman via discuss
>> <ovs-discuss at openvswitch.org> wrote:
>> >
>> > 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?
>>
>> Here is my private ovs IPsec repository -
>> https://github.com/ansisatteka/ovs-ipsec.git that I recently rebased
>> on latest OVS. Any feedback would be greatly appreciated. It is for
>> sure not production ready but should work on Ubuntu.
>>
>>
>> > 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.
>>
>> Racoon development seems to have stalled. Also there were few features
>> lacking in racoon that were available in strongSwan.
>>
>> > 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.
>>
>> You can check the proposed skb mark usage in my private repository.
>> Let me know what you think.
>>
>> The problem with previous  IPsec implementation was that it was
>> impossible to use skb mark with overlays and hence it was removed.
>>
>> >
>> > _______________________________________________
>> > discuss mailing list
>> > discuss at openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>> >
>
>


More information about the discuss mailing list