On Thu, 21 Nov 2013 12:07:24 +0200 Timo Teras <[email protected]> wrote:
> On Thu, 21 Nov 2013 10:02:14 +0100 > Martin Willi <[email protected]> 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 _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
