[strongSwan-dev] GRE KEY in traffic selectors

[Timo Teras]

On Thu, 21 Nov 2013 12:07:24 +0200
Timo Teras <timo.teras at iki.fi> wrote:

> On Thu, 21 Nov 2013 10:02:14 +0100
> Martin Willi <martin at strongswan.org> wrote:
> 
> > > 3) Supporting GRE KEY in SPD traffic selectors. This might be
> > > tricky because GRE KEY is 32-bit tunnel identifier, and it is
> > > split to be in the TS source port, and destination port -
> > > similarly to how ICMP message type/code is split [4]. Would be
> > > nice to have config syntax like: leftproto = gre/1234 # 1234
> > > being the 32-bit gre key
> > 
> > That shouldn't be too hard, more a configuration/backend thing.
> > Maybe some minimal changes to the traffic selector code are
> > required, but probably not.
> 
> Ok. I'll dig in on this then.

Ok, I know figured out which places I need to patch for this. And the
ICMP special case gives good idea on how things should be done.

It seems that a full flow is split to two traffic selectors src and dst
that work independently. The 8-bit ICMP type/code are internally
compressed to 16-bits and duplicated in src/dst TSes - but on kernel
interface it's taken from one of these TSes, and then exploded to kernel
selectors' src/dst ports.

I cannot use similar trick as the GRE KEY is full 32-bits.

In all cases, the sensible thing is to store the full GRE KEY in
individual TSes.

So my options are:
1) Split the key to from_port and to_port internals. This would of
   course disallow real gre key ranges.
2) Change port from u_int16_t to u_int32_t, which would be rather
   intrusive I suppose - as that means changing the existing API and
   everyone using the get_{from,to}_port accessors.
3) Add new methods for explicitly accessing 32-bit routing key.
   Something like get_{from,to}_route_key accessors.

Any opinions for how to proceed on this?

Thanks,
 Timo