Thanks so much to folks like Bjorn and Yvan who spend the time to do some tough jobs like dealing with IPsec and being stubborn about committing things to security tools without very careful audit.
Seconded.
In case you missed it, IPsec is about security, not features. And, in case you have never been involved in real security or crypto, security is really, really hard. No, no, it's much harder than that! While I'd love to see NAT-T, until someone who knows EXACTLY what the IPsec and NAT-T code is doing and what it is required to do can do the line by line review, it should NOT be committed.
Well, none of my emails advocated applying the patch without a complete review. I asked what the state of the review and testing process was and, in the opinion of my betters, if the patch could kindly be applied. Additionally, if the holdup was related to a lack of time available to the IPsec maintainers, what could be done to assist in getting this patch integrated.
As for Yvans commitment, I would think that 3 years spent maintaining a patch on a moving target more than demonstrates it. I'm also a bit surprised to see that the request I made was categorized as impatient crying. But programmer hide tends to be thicker than most and opinions always vary.
I won't deny that there has been a few misconceptions about what NAT-T is good for and what is involved in NAT-T packet processing. I'm not a BSD kernel hacker, but I have written a full IPv4 IPsec implementation as well as a key daemon from scratch that includes NAT-T support. For portability reasons, this involved emulating the PF_KEY interface on platforms that don't provide one natively so I am quite familiar with that component as well.
No, NAT-T isn't required to interoperate with any particular vendor IPsec in the vanilla sense. It is required to work around issues that arise when at least one peer is behind a NAT device. Its particularly agonizing when you are trying to act as a IPsec remote access client. Without NAT-T, you will quickly experience why its been adopted almost universally. As the author of a port that attempts to offer this style of connectivity, I have a vested interest in seeing this functionality present in FreeBSD which explains my persistence :)
How complex is IPsec NAT-T? The concept behind it is pretty simple. You wrap ESP in UDP so it traverses NAT more easily. The IKE traffic is multiplexed on the same port so you only issue keep-alives from userland to refresh a single NAT state. Most of the complexity related to negotiating NAT-T support, detecting the presence of a NAT and setting up the SA options are handled by the IKE daemon. Kernel side changes for a tunnel-only implementation, like Yvans, can be more or less summed up like so ...
1) A key daemon needs to be able to set a socket option that signifies how packets will be multiplexed on a bound port. This helps the IPsec layer qualify which packets need to be dropped, processed as ESP or passed on to IKE via the socket layer.
2) The PF_KEY system needs to be extended so that IPsec knows which SAs are NAT-T enabled and what UDP port values are to be used.
3) UDP headers, and non-isakmp markers for old versions of NAT-T, need to be added or removed from ESP packets when they are processed using a NAT-T enabled SA. After which, they are processed normally.
Yes, the devil is in the detail but the details in the patch should be self evident.
To coin a popular phrase on this list, IPsec is about security. If you look at Yvans patch, it doesn't do anything to fundamentally change the way ESP payloads are constructed or interpreted. It mostly just inserts or removes a UDP header where appropriate. If your not familiar with PF_KEY, the other parts of the patch may take a bit longer to evaluate. I'm not trying to downplay the expertise or experience that both gnn and bjorn bring to FreeBSD. I just don't think it would take a world class IPsec kernel hacker to review Yvans work competently. RFC3948 is literally 10 pages if you skip the end credits. The draft versions are considerably shorter. Again, opinions may vary.
So the horse seems dead so Ill stop flogging it. If it takes another 6 months or more to get this reviewed, I won't complain. If/when the time comes, I have a half dozen commercial gateways and lots of Linix *BSD on the far side of a NAT if anyone would like additional testing.
One last thing. I admit that I can't qualify how feasible this is, but it may be beneficial to split out the portion of the patch required to set the UDP socket options and commit that first. If this can be done in benign way, it would probably make a lot of people happier. Applying a patch that only requires rebuilding the kernel is a lot less annoying than having to perform a full buildworld.
-Matthew _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
