2 min read
QA Cafe is constantly testing as many home networking devices as we can find, both to make sure CDRouter is the best testing product around and to find new and interesting tests to write. During that time, we have learned that the quality level of home and business routers/gateways on the market varies considerably. We know the world of networking protocols is complex and nuanced, and often a slight oversight in a standard or interpretation of a standard can mean the difference between a functioning home networking product and a high-tech paperweight.
That’s why we’re committed to providing you with common router bugs that we discover. We not only want to have the best home network testing product out there, but we want the best home networking products to be out there, too.
When performing tests using the CDRouter IKE add-on, CDRouter and the DUT go through the steps of setting up an IKE tunnel as part of the test setup. During this process, the DUT conveys version and feature support information for the IKE tunnel, including its method for NAT traversal in the IKE. This is performed through an exchange of vendor-ID payloads using the NAT-D packets.
This interesting bug came as result of a change in the Payload Type identifier in the published version of IETF RFC 3947, Negotiation of NAT-Traversal in the IKE, versus its value in draft versions of the document. The standard specifies the Payload Type value to be 20. In earlier versions of the draft, it was specified to be 15. Protocol stacks that implemented IKE NAT traversal before the standard was completed may be using the wrong Payload Type value, which will cause the IKE tunnel to not successfully initiate.
You can see the difference in these two versions of the standard here, using the IETF’s “diffs” tool (which is pretty handy).
The moral of this story: be careful when implementing a standard before it is finished! You might miss important changes later.
