[Swan] What to do with some rare KLIPS-only options, currently broken

[Ken Bantoft]

Hi, 

overridemtu= is something I have needed to use the past, especially in Satellite networking, where the actual MTU is below what you'd expect.  Otherwise I clamp on the physical interface, but since I'm using PPPoE it gets a bit messy.

hidetos= is also an option I think should be kept - as there are times when you want the TOS markings on the packets to be carried through (i.e.: VoIP, Video) where you care slightly less about security, and more about performance over the Internet.  Having it an option lets you pick your poison.  I'm not sure how this works in netkey work, but as I'm back to using klips in my product lines I haven't looked at it.

Ken


On 2013-06-20, at 4:01 PM, Paul Wouters wrote:

> 
> Hi,
> 
> When we merged _startklips/_startnetkey into _stackmanager, support for
> the following KLIPS-only config setup options was lost:
> 
> overridemtu=<value>
> hidetos=yes|no (default yes)
> fragicmp=yes|no (default yes)
> 
> The first one was simply setting the mtu on the ipsecX interface. It
> would not be too hard to bring this back. However, I don't know of any
> scenario where this option was ever needed. So unless someone can give
> me an example of when it was/is needed, I'm going to change this keyword
> to kt_obsolete.
> 
> The hidetos and fragicmp options _could_ be useful. However, these are
> options that can be set using sysctl directly against the ipsec.ko
> module. Again, we could add support for this into addconn --configsetup,
> so _stackmanager can set these when on klips, but I wonder if it is
> better to just leave these out as well, and just document the KLIPS
> option for people to use. Especially because KLIPS is mostly used for
> embedded systems, and those systems tend to not use our initscripts
> anyway. So I'm tempted to also kt_obsolete these.
> 
> If we think hidetos/fragicmp are that important, one should wonder how
> NETKEY is doing this, and whether we should fix the option to support
> NETKEY as well, which would likely require some kernel changes.
> 
> Opinions?
> 
> Paul
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan