[Swan-dev] [OpenWrt-Devel] [PATCH v3 2/3] network/config: add xfrm interface support scripts]

[Antony Antony]

On Tue, Jun 11, 2019 at 06:18:26PM -0400, Paul Wouters wrote:
> On Tue, 11 Jun 2019, Antony Antony wrote:
> 
> > XFRMi seems to be picking up fast. A proposed patch to OpenWRT network
> > scripts would add support for an xfrm device. I guess we/Libreswan should
> > merge our branch soon!
> 
> Cool. What is preventing the branch from being merged right now?

waiting on testing and agreeing on what features to implement/support 
initially. I am not up for X-mas lights, enabling lots of features, and 
complicated features without a written use case and testing. Also when I 
mentioned the idea xfrmi interfaces should be maintained by systemd-networkd 
or NetworkManager, I didn't notice response. Now it is quite clear OpenWRT + 
strongswan is likely going that way. Also need to rebase to 3.28, current 
master.

> > OpenWRT patch proposal suggest the whole interface creation and its
> > lifecycle could be managed by system network scripts.
> > I imagine on Debian/Fedora systemd-networkd would get similar support soon.
> > Or may be NetworkManager. I am not sure.
> 
> I think it is certainly something we want to support. If a connection is
> configured with mark=, and something else creates the interface, are we
> still expected to change the routing too?
> 
> > Note they also planned to add ip address there. I wonder how this would work
> > in various cases, road warrior, or BGP/routing protocol situations.
> 
> I guess it would only work for the static IP cases? Which seems to be
> the more likely case for openwrt anyway?
> 
> > This package adds scripts for xfrm interfaces support.
> > Example configuration via /etc/config/network:
> > 
> > config interface 'xfrm0'
> >        option proto 'xfrm'
> >        option mtu '1300'
> >        option zone 'VPN'
> >        option tunlink 'wan'
> >        option ifid 30
> 
> Ok so that would pre-create the interface. But if they already route
> into it without ipsec running, packets would be lost. That could be a
> bug or a feature, depending on your view.
> 
> > config interface 'xfrm0_static'
> >        option proto 'static'
> >        option ifname '@xfrm0'
> >        option ip6addr 'fe80::1/64'
> >        option ipaddr '10.0.0.1/30'
> 
> I guess _static is a generic way to configure an interface? Kind of odd
> it needs a seperate section.
> 
> > Now set in strongswan IPsec policy:
> > 	if_id_in = 30
> > 	if_id_out = 30
> 
> right, which for us would be mark=30/0xffffffff

Why would you, as IPsec admin, want to configure the mark for xfrm 
interface? and which mark is this? there are atleast 2 marks in the kernel 
now, related to xfrm. The current config options are setting a mark which is 
not used xfrm code path.

User setting mark is only for a very advanced user cases.  Where they have 
multiple up links and linux reply with different src address than the 
destination address. Some users may argue that is the most common case for 
route based vpn. Well in that case Libreswan test coverage and design are 
not up to the task. Likely the users have secret sauce to make it work.

I have a feeling you are confusing XFRMi with VTI settings. Simple xfrm 
interface use case do not need user configuring mark. If you need it is not 
the currently configurable marks in Libreswan. It is the recently, 2018, 
introduced OUTPUT_MARK for routing ESP packets. So be careful when 
mentioning mark. xfrmi use "if_id"  not marks for simple cases. Even for the 
cases  as 0/0 - 0/0, or host-to-host,(/32 to - /32) xfrm would set 
OUTPUT_MARK mark for routing the esp packet. That does not need to 
configured. And the suggested complicated case need OUTPUT_MARK and mask.

> (we should support mark's without mask, but our parser doesn't like to
>  get only numbers for a string) 

again  I am not sure. the advanced use cas as I understand need user 
configurable mask 0xfffff won't work. XFRM developers also initially 
thought mask was unnecessary and they had to add lot kludge to add mark later 
on and keep supporting without mask, because it was released.