Hello!
Check out here:
http://cr.opensolaris.org/~danmcd/detangle/
and if you're internal and wish to see IKE mods we used for testing, check
here:
http://zhadum.east/~danmcd/detangle/
My apologies to OpenSolaris folks who don't get to see how much code was
ripped out of in.iked and libike.
I'm closing the review period in one week. Comments are due by 11:59pm
US/Eastern on Tuesday, August 14th.
I have detangled IPsec NAT-Traversal by ridding us of "nattymod", which was
pushed on top of a UDP socket and performed strip-and/or-shuffle of UDP
packets dealing with NAT-Traversal. We needed to use a STREMS module, BTW,
because Yosemite (FireEngine-style UDP) wasn't in S10 FCS, when we
wanted/needed NAT-T.
So what we do now is:
- Create a new (privileged) UDP socket option: UDP_NAT_T_ENDPOINT.
- If UDP_NAT_T_ENDPOINT is set, datagrams that go out this socket
have a 'zero-SPI' inserted between the UDP header and the data.
- On inbound datagrams to a UDP_NAT_T_ENDPOINT socket:
- If there are 0-3 bytes after the UDP header, drop the
packet (it's probably a keepalive).
- If the first four bytes after the UDP header is 0, strip
the zero-SPI and proceed like a regular UDP datagram.
- Otherwise, strip out UDP, convert the packet to ESP, and
proceed like a regular ESP datagram.
- We also now have the keepalive sending be the responsibility of the
SADB grim-reaper task, instead of a qtimeout() inside nattymod.
And while I was digging around, I also allowed the NAT-T port to be anything
so long as it's specified in the SA. We don't support this in our IKE, but
someone writing their own Key Management application can now do ESP-in-UDP
for an arbitrary set of ports, both local AND remote.
Additional details are available on the publically-available ARC case page.
(You can reach it via the opensolaris.org webrev.)
Thanks!
Dan
