Hello folks!
Since Solaris 10 we've supported IPsec NAT-Traversal (RFC's 3947 and 3948) by
using "nattymod" -> a STREAMS module that gets pushed in between a UDP
application (like the IKE daemon) and UDP.
Solaris 10 FCS did not have the Yosemite (PSARC 2005/082) project integrated,
so we could not de-STREAMS NAT-Traversal. OpenSolaris has Yosemite, so we
can finally revisit the problem.
By eliminating nattymod we can:
* Reduce the amount of lines of code in the system (~700 lines).
* Eliminate race-condition bugs like 6481450 (nattymod calls
putnext() on a freed queue.)
* Open up the API for other Key Management implementations to use
NAT-Traversal IPsec SAs with local-port == 4500.
The new API for an AF_INET UDP endpoint to enable NAT-Traversal is the
UDP_NAT_T_ENDPOINT socket option. It's boolean (off or on), is only allowed
on AF_INET socket (AF_INET6 will return EAFNOSUPPORT, even for IPv4-mapped
sockets, because they can become IPv6 again), and requires the sys_ip_config
privilege to set. I'll have to run this through PSARC via a fast-track, but
I can do that next week.
I have a webrev of code changes available at the new OpenSolaris code-review
site:
http://cr.opensolaris.org/~danmcd/detangle/
and I encourage discussion and criticism. These set of changes fall squarely
in the "networking" half of IPsec, vs. the "security" half, so discussions
should be held on networking-discuss at opensolaris.org.
One open question is whether or not we should allow NAT-Traversal SAs with a
local port that is NOT UDP 4500. The changes required from the kernel side
are pretty small, and marked with TODO in the appropriate IPsec kernel source
files. The user-land side for our IKE daemon, besides being in
closed-source, are non-trivial, and would require substantive changes. I'm
willing to entertain making the kernel changes, however, given sufficient
community motiviation. :)
I won't be able to THINK about putting these changes back until mid-June at
the earliest, but I think I'm pretty close to finished. I've run our own IKE
and IPsec tests, plus I plan on having additional punchin-client and
punchin-server testing ("punchin" is a Sun-internal IPsec remote access
solution that is a testbed for our IPsec and other TCP/IP and crypto
components).
Please share your comments, criticism, and questions!
Thanks,
--
Daniel L. McDonald - Solaris Security & Networking Engineering
Mail: danmcd at sun.com | * MY OPINIONS ARE NOT NECESSARILY SUN'S!
*
1 Network Drive Burlington, MA |"rising falling at force ten
http://blogs.sun.com/danmcd/ | we twist the world and ride the wind" - Rush
