Detecting NAT in IPsec
The Xelerance team spent about 5 solid hours tonight on the NAT-Traversal code, debugging connections with Win32, OSX and Linux peers.
There were about 6 bugs in the tracker for NAT detection failing in various cases. It turns out it was all related - the NAT ‘detection’ via hashs of IP + ports code was at fault.
Various people had suggested patches, include Jacco’s here, and a few more in Mantis. Most fixed it for 1 case - thiers. Nothing was generic enough to work. Some blamed Apple, as they send the NAT Hashes in a different other than Openswan. Other blamed us, however interop with most other vendors was fine.
So I went back to RFC3947, which says:
3.2. Detecting the Presence of NAT
The NAT-D payload not only detects the presence of NAT between the
two IKE peers, but also detects where the NAT is. The location of
the NAT device is important, as the keepalives have to initiate from
the peer “behind” the NAT.
To detect NAT between the two hosts, we have to detect whether the IP
address or the port changes along the path. This is done by sending
the hashes of the IP addresses and ports of both IKE peers from each
end to the other. If both ends calculate those hashes and get same
result, they know there is no NAT between. If the hashes do not
match, somebody has translated the address or port. This means that
we have to do NAT-Traversal to get IPsec packets through.
If the sender of the packet does not know his own IP address (in case
of multiple interfaces, and the implementation does not know which IP
address is used to route the packet out), the sender can include
multiple local hashes to the packet (as separate NAT-D payloads). In
this case, NAT is detected if and only if none of the hashes match.
The hashes are sent as a series of NAT-D (NAT discovery) payloads.
Each payload contains one hash, so in case of multiple hashes,
multiple NAT-D payloads are sent. In the normal case there are only
two NAT-D payloads.
So basically everyone was wrong. The RFC says nothing about the order of the hashes, and in fact it says you can have more than 2 (if say, you have a multihomed machine, since the RFC says you send 1 hash per interface/port combination). Feeding this information to mcr resulted in him spitting back a refactored function in 15 minutes (the man is a C machine). We now generate our local hashes, and run through all of the hashes supplied by the peer, comparing various combinations to see where the NAT actually it, and if there’s more than one.
Paul and I tested the new code on Linux, OSX & Win32 under both NAT and no NAT networks, and I has to fix 1 minor bug. As a result, 2.4.5dr2 is now out, with a slew of NAT bugs fixes.
Enjoy!
PCWorld’s Top 100 Computer Products of 2005
PCWorld.com posted thier Top 100 Products of 2005 today. I took a quick look though, and I either bought or use 15 of during the past 12 months… 4 of which were within thier top 10. I guess I’m mainstream now…
Openswan 2.4.3 Released
I pushed 2.4.3 over to the website, which has the patch for the 2nd DoS found as part of PROTOS’s testsuite. This flaw required you be running aggressive mode, and know the passphrase - certianly not something that would normally happen. Either way, it’s fixed and released.
We’re integrating PROTOS’s 5000 tests into our nightly regression suite, which, while doubling the length of time to run the tests (Each test takes approximately 5 seconds), will provide a nice regression set to make sure new changes don’t break things.
Openswan updates for vulnerabilities
NISTCC released this today, which doesn’t really tell you much. They contacted us about 4 months ago to report a vulernability, but wouldn’t tell us anything unless we signed an NDA. We refused - way too many issues with being unable to release/publish (Openswan is open source, so all commits are public) fixes until NISTCC decided it was okay. So we just knew there was a potential Denial of Service, maybe. One of our partners who did sign the NDA confirmed 2 bugs, but since we weren’t allowed to use the testsuite (covered by NISTCC’s NDA) we couldn’t confirm for ourselves, or confirm fixes.
The
PROTOS folks in Finland have now released thier paper, and included the isakmp testsuite so we’ve busy verifying fixes to the codebase. In the meantime, Openswan 2.4.2 is out with fixes for one of the two bugs. The other one requires aggressive mode, so it’s not nearly as widespread. We expect to have that fixed and 2.4.3 out by end of day.
Apparently we aren’t the only ones annoyed with NISTCC on this case - MITRE doesn’t have any CVE entries for this (yet)
Links:
- Open Source Vulernability Database Blog post
- NISTCC ISAKMP Vulnerability Release [PDF]
- MITRE CVE
- SearchSecurity.com Article
- FrSIRT advistory
- eWeek’s Story
- news.com.com’s Story
CVS commit logging with Activitymail
We’d been using SyncMail from SourceForge to email out diffs from all the Openswan commits. When we upgraded to CVS 1.12, all this broke. We waited for syncmail to get updated, but that never happened.
Instead, I found ActivityMail which is written in Perl instead of Python, and supported the new log format. However, the docs are less than clear on dealing with CVS 1.12, and the examples are wrong. Here’s what I’m using:
^openswan /usr/local/bin/activitymail -q -d -P "%p" -f "%{sVv}" -t cvs@lists.openswan.org
We use -q, since any stdout messages confused some of the CVS clients. The key was the “’s, as they are required in CVS 1.12 and higher. With this in place, we’re back to flooding our inboxes with CVS commit logs 
Flickr Photos
