Introduction to Interop Tests for RFC 2845

TSIG (RFC 2845, (Secret Key Transaction Authentication for DNS (TSIG))) provides an authentication mechanism at the transaction level using shared secrets and one way hashing. It can be used:

• To authenticate dynamic updates as coming from an approved client
• To authenticate responses as coming from an approved recursive name server
• To authenticate zone transfers as coming from an authoritative name server

RFC2845 is currently in the "Proposed Standard" status. In order to pass it to the "Draft Standard" status, an interop test report is needed. At least two implementations should be found interoperable.

The goal is to test interoperability, not conformance. This means that the features to be tested in the RFC are only those that have a potential impact on interoperability. We don't need to check the full conformance of each implementation to the RFC.

So far, we have decided to test the MUSTs and SHOULDs in the RFC.

Interoperability on SHOULDs is not mandatory in a strict sense, but we believe it would be good to obtain the status on SHOULDs too.

The version of IP used is orthogonal to the protocol tested because DNS messages can be transported using IPv4 or IPv6. Some implementations only support IPv4 transport at the time of interop tests and as far as those implementations are involved, only IPv4 is used.

A first set of tests was jointly organized by 6Wind and AFNIC with the help of Euro6IX project and France Telecom R&D.
It took place on June 17th, 2003 at AFNIC.

Attendees list:

Mohsen Souissi		AFNIC				mohsen.souissi@nic.fr
Vincent Levigneron	AFNIC				vincent.levigneron@nic.fr
Bertrand Leonard	AFNIC				bertrand.leonard@nic.fr
Jean-Philippe Pick	AFNIC				jean-philippe.pick@nic.fr
Jean-Jacques Bernard	AFNIC				jean-jacques.bernard@nic.fr
Vladimir Ksinant	6WIND/Euro6IX			vladimir.ksinant@6wind.com
Jean-Mickaël Guérin	6WIND/Euro6IX			jean-mickael.guerin@6wind.com
Samuel Gauthier		6WIND/Euro6IX			samuel.gauthier@6wind.com
Cyril Corre		6WIND/Euro6IX			cyril.corre@6wind.com
Fabien Giffard		6WIND/Euro6IX			fabien.giffard@6wind.com
Philippe Conversin	6WIND/Euro6IX			philippe.conversin@6wind.com
Luc Beloeil		FT R&D/Euro6IX			luc.beloeil@francetelecom.com
Antonio Gomez Skarmeta  University of Murcia/Euro6IX	skarmeta@dif.um.es
Felix Garcia Clemente   University of Murcia/Euro6IX	fgarcia@dif.um.es

Comprehensive list of RFC 2845 sections with explanation of specific test needs

• Section 1: No tests needed.
• Section 2: In 2.2, HMAC-MD5 interoperability should be checked.
• Section 3: Interop tests are needed in this section.
  • Sub-section 3.1: Truncation test: see test C.7.Truncation in Client-Server category).
• Section 4: Sub-sections from 4.2 to 4.7 require tests.
• Sub-section 4.2: The basic behavior is tested. When receiving a signed query from a client (respectively from a slave), the server (respectively the master) uses the same algorithm/key for its response. This sub-section also deals with the cases where the server (respectively the master) responds exclusively/non exclusively to TSIG queries originating from the client (respectively the slave). See C.1.OK, C.5.EXCLUSIVE and C.6.NOTEXCLUSIVE in Client-Server category. See also S.1.OK, S.5.EXCLUSIVE and S.6.NOTEXCLUSIVE in Slave-Master category.
• Sub-section 4.3: This sub-section covers tests related to error handling on TSIG keys or time intervals. See tests C.2.BADKEY, C.3.1.BADTIME_CLIENTEARLY, C.3.2.BADTIME_CLIENTLATE and C.4.BADSIG in Client-Server category. See also tests S.2.BADKEY, S.3.1.BADTIME_CLIENTEARLY, S.3.2.BADTIME_CLIENTLATE and S.4.BADSIG in Slave-Master category
• Sub-section 4.4: This sub-section deals with tests related to large zone transfers requiring multiple TSIG RRs in order to protect the TCP connection against hijacking. See tests C.8.1.MultipleEnvelopesOK and C.8.2.MultipleEnvelopesKO in Client-Server category. See also tests S.7.1.MultipleEnvelopesOK and S.7.2.MultipleEnvelopesKO in Slave-Master category
• Sub-section 4.5: This sub-section covers in more depth tests mentioned in sub-section 4.3 with respect to TSIG processing on the server (or master) side.
• Sub-section 4.6: This sub-section covers in more depth tests mentioned in sub-section 4.3 with respect to TSIG processing on the client (or slave) side.
• Sub-section 4.7: This sub-section is entirely dedicated to the scenario where a "forwarding server" is used between the client and an upstream server. It covers all tests in Client-Forwarder-Server category
• Sections 5, 6, 7: No tests needed.

Tests Results

After a first analysis, we have identified three categories of tests:

1. Client-Server category: Involves one client and one server at a time.
2. Slave-Master category: Involves two servers, one slave and one master.
3. Client-Forwarder-Server category: Involves one client and two servers, one of them acting as a "forwarder". The "forwarder" forwards the queries
   originating from the client to its upstream server.

Three client implementations (A, B and C) and two server implementations (X and Y) were used for the interop tests.

Some of the tests are not checkable. In those cases, the traffic/protocol analyzer at our disposal cannot tell whether the entities in question (Client, Server or Forwarder) had the right behavior.

• In Client-Server category:
  • All tests from C.1.OK up to C.6.NOTEXCLUSIVE are successful by all possible Client-Server combinations.
  • Test C.7.Truncation worked fine with DIG A and DIG C as clients. It failed with DIG B as a client.
  • Test C.8.1.MultipleEnvelopesOK is successful with DIG B and DIG C. It is not checkable with DIG A.
  • Test C.8.2.MultipleEnvelopesKO is partially successful. The client detects loss of time synchronization but does not close the connection as specified in section 4.4 (a MUST !).
• In Slave-Master category:
  • All tests from S.1.OK up to S.6.NOTEXCLUSIVE are successful by all possible Slave-Master combinations.
  • Tests S.7.1.MultipleEnvelopesOK and S.7.2.MultipleEnvelopesKO are not checkable.
• In Client-Forwarder-Server category:
  • Tests F.1.1 and F.1.2 failed. Server implementations X and Y, configured as forwarding servers, do not accept to be bypassed by a client directly sharing a secret with the upstream server .
  • DIG A - Y - X combination passes all the remaining tests.
  • Tests F1.4 failed with combination DIG A - X - Y. The client times out before getting a response from X.
  • Tests F2.* failed with combination DIG A - X - Y. Moreover, the forwarding server X crashes after receiving the response from the upstream server. Forwarder X does not seem to support key sharing with the client. This behavior was reported to server X implementers. We received a patch which we applied before performing again the F2.* series. Then F2.1 and F2.3 were successful. F2.2 did not provoke server X crash but it did provoke client DIG A timeout. It seems that forwarder X fails to handle BADKEY errors (from its upstream server) in time.