NOW INTEGRATED as of OpenSolaris build 53.
NOW in Solaris 10 08/07 (aka Update 4)
The Solaris IPsec implementation has been dogged by complaints about poor interoperability with other implementations in IPsec's Tunnel Mode. As defined in RFC 2401, Tunnel Mode is when a packet needs to be protected not only by an IPsec header (AH or ESP), but also be encapsulated inside another IP header first (sometimes with different source and/or destination IP addresses).
In Solaris 8, tunnels were implemented as network interfaces. This decision made for easier network construction, as well as dovetailing in with IPv6 tunnels. The downside to this, however, was that configuring IPsec to tunnel packets was not solely in the domain of IPsec configuration. This confused some customers. Also, because tunneling was a forwarding decision, not an IPsec decision, some possible uses of IPsec tunnel mode could not be performed in Solaris 8. The best example was the case where the outer packet's destination IP address was equal the inner packet's destination IP address. In Solaris 8 (and later) one could not configure tunnelling to perform such an encapsulation - it would black-hole due to a never-ending forwarding loop.
In Solaris 9 and Solaris 10, the changes made for IKE and other IPsec policy improvements did nothing to change how tunnels were implemented. Also, the IKE daemon would express Phase II identities in a non-standard way. According to RFC 2409 the Phase II identities must be set as follows:
This is a fancy way of saying "use some form of the inner IP addresses for Tunnel Mode". Currently Solaris sets both identities for packets protected on a tunnel interface as proto=4 (IP-in-IP), 0.0.0.0/0 for IPv4-in-* tunnels, and proto=41 (IPv6-in-IP), 0::0/0 for IPv6-in-* tunnels. This decision lead to many interoperability problems with other IKE implementations.
The Tunnel Reform project aims to end these shortcomings. Using an extended set of ipsecconf(1m) syntax, extensions to PF_KEY to express inner-packet selectors, and an improved IKE daemon, the goals of Tunnel Reform are:
- For packets that originate or are destined for a Solaris node (where a tunnel interface counts as an originator or destination), implement the RFC 2401 set of selectors, while keeping in mind the upcoming changes in RFC 4301.
- To severely reduce or eliminate customer calls of the form, "We can't talk to foo in Tunnel Mode (especially when IKE is involved)."
- To lay groundwork for better PF_KEY expression of RFC 2401 and 4301 selectors, hopefully as input into PF_KEYv3.
Peforming IPsec actions on forwarded packets that do not go through an explicit tunnel interface is well beyond the scope of this project.
Documentation
Code snapshots
- July 14, 2006
Fragment cache and per-port tunnel policy is incomplete, but everything else passes initial smoke-tests, and passes basic regression tests. - Nevada build 45
Gate snapshot versus Build 45 of Nevada. - Nevada build 47
Gate snapshot versus Build 47 of Nevada. DEV COMPLETE SNAPSHOT. - Nevada build 50
Gate snapshot versus Build 50 of Nevada. CODE REVIEW SNAPSHOT. - Nevada build 51
Gate snapshot versus Build 51 of Nevada. - Nevada build 51 vs. Nevada build 50
Gate snapshot versus the build 50 gate snapshot. BEST WAY TO SEE CODE REVIEW CHANGES.