FreeBSD NAT-T patch integration

[Matthew Grooms]

> 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