MPTCP Y. Coene Internet-Draft UCLouvain Intended status: Informational July 15, 2013 Expires: January 16, 2014 Conformance tests for Multipath TCP draft-coene-mptcp-conformance-00 Abstract This document describes a series of tests which aim at evaluating the compliance of Multipath TCP (MPTCP) implementations to [RFC6824]. The current version of this document focuses on the conformance of the three-way handshake. Subsequent versions of the document will contain tests for the other parts of the protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Test architecture 3. Notations 4. Conformance tests 4.1. Connection Initiation: Test Objectives 4.1.1. OBJ: Send SYN on new connection 4.1.2. OBJ: Send SYN/ACK upon SYN reception 4.1.3. OBJ: Send ACK upon SYN/ACK reception 4.1.4. OBJ: MP_CAPABLE Flag A set to 1 4.1.5. OBJ: MP_CAPABLE Flag B set to 0 4.1.6. OBJ: MP_CAPABLE Flag B ignored 4.1.7. OBJ: MP_CAPABLE Flags C through H 4.1.8. OBJ: MPTCP Version 4.1.9. OBJ: Token 4.1.10. OBJ: Key generation 4.1.11. OBJ: Hash collision detection 4.1.12. OBJ: Initial Data Sequence Number 4.1.13. OBJ: Checksums 4.1.14. OBJ: Crypto negociation 4.1.15. OBJ: SYN/ACK without MP_CAPABLE 4.1.16. OBJ: ACK without MP_CAPABLE 4.1.17. OBJ: Regular SYN 4.2. Connection Initiation: Test Cases 4.2.1. TEST: Initial handshake TS->SUT 4.2.2. TEST: Initial handshake SUT->TS 5. Conclusion 6. Acknowledgments 7. Normative References Author's Address MPTCP Y. Coene Internet-Draft UCLouvain Intended status: Informational July 15, 2013 Expires: January 16, 2014 Conformance tests for Multipath TCP draft-coene-mptcp-conformance-00 Abstract This document describes a series of tests which aim at evaluating the compliance of Multipath TCP (MPTCP) implementations to [RFC6824]. The current version of this document focuses on the conformance of the three-way handshake. Subsequent versions of the document will contain tests for the other parts of the protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Multipath TCP is a major extension to the TCP protocol that allows to combine several TCP subflows into a single Multipath TCP connection. The design of Multipath TCP has been influenced by many factors, notably the presence of middleboxes inside the network. Implementers are starting to enhance TCP implementations to support Multipath TCP. We are not aware of an existing TCP conformance test suite that has been documented in an RFC or a published article. Some earlier work on this topic include: o https://code.google.com/p/tcptest/ o http://www.icir.org/tbit/ o http://link.springer.com/chapter/10.1007/ 978-0-387-35578-8_20#page-1 o http://dl.acm.org/citation.cfm?id=1080123 In this document, we propose a set of conformance tests that are derived from the Multipath TCP specification [RFC6824] and can be used to verify the conformance of the implementation towards this specification. The conformance tests are described in text with reference to the corresponding sections of the RFC. Furthermore, an open-source software implements them to ease the verification of the conformance of a particular implementation. This document is organised as follows: Section 2 describes the test environment, followed by the notations used throughout this draft in Section 3. Section 4 then outlines the considered conformance tests of Multipath TCP. 2. Test architecture Figure 1 illustrates the setup to be used for test execution. The entry points for interacting with the implementation under test (IUT) are its upper and lower layer interfaces. The tester is accordingly split in two modules: o the upper tester drives the service (socket) interface of the IUT; o the lower tester stimulates the IUT through the IP layer. To implement this, the test architecture comprises two network devices: o the test system (TS), which runs the lower tester; o the system under test (SUT), running both the IUT and the upper tester. It is understood that lower and upper tester must communicate with each other in order to coordinate the execution of tests. This is illustrated by the bidirectionnal arrow linking the two modules. TS SUT .-----------. .-----------. | lower | coordination | upper | | tester <--------------------> tester | | | |-----------| | | | IUT | | | IP layer | | '-----------'--------------------'-----------' Figure 1: Test architecture 3. Notations This document outlines two types of definitions that are involved in testing the conformance of MPTCP implementations. On the one hand, we define test objectives that consist in individual requirements isolated from the specification. They each relate to a specific part of [RFC6824]. In particular, they typically consist in standard "MUST" and "SHOULD" statements but may also derive from descriptive text that implies some desirable or mandatory behavior. The test objectives are further classified according to a number of criteria defined below. REQUIREMENT LEVEL level of requirement of the test purpose (e.g. MUST, SHOULD, etc.). TESTABILITY qualitative measure of the difficulty to evaluate the test outcome. For example, implementation requirements, as opposed to behavior requirements, are hard to assess by black-box testing. DESCRIPTION indicative explanation of how the objective is tested as part of a subsequent test case. On the other hand, compliance to individual requirements is evaluated inside test cases. They describe a procedure, expressed as a pseudo- code, that enables testing a set of previously defined objectives. In order to do so, test case descriptions contain "assert" statements whose outcome determines compliance to a corresponding objective. The latter is referenced in brackets after the condition to be asserted. Executing a set of test cases associates an outcome to the test objectives they cover: PASS All assertions on a given objective have succeeded. FAIL At least one assertion on a given objective has failed. INCONCLUSIVE A given objective could not be evaluated. Other test case properties include: PRECONDITION characterization of the connection states in which the test case can be executed. 4. Conformance tests In this section, we describe several conformance tests for Multipath TCP. We start from the three-way handshake that is used to create a Multipath TCP connection. 4.1. Connection Initiation: Test Objectives 4.1.1. OBJ: Send SYN on new connection REFERENCE p. 14: Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. REQUIREMENT LEVEL MUST DESCRIPTION Establish a new connection to the TS on the SUT through the socket interface, i.e. by calling connect(). FAIL if no SYN received. TESTABILITY NORMAL 4.1.2. OBJ: Send SYN/ACK upon SYN reception Upon reception of a SYN segment containing the MP_CAPABLE option, the SUT MUST repond with a SYN/ACK segment that also contains this option. REFERENCE p. 14: Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. REQUIREMENT LEVEL MUST DESCRIPTION Send initial SYN+MP_CAPABLE with flag "B" unset, flag "H" set and flags "C" through "F" unset. FAIL if no response received, or if received packet does not have SYN and ACK flags set, or if it does not include an MP_CAPABLE option of length 12. TESTABILITY NORMAL 4.1.3. OBJ: Send ACK upon SYN/ACK reception REFERENCE p. 14: Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a single path. REQUIREMENT LEVEL MUST DESCRIPTION Trigger remote SYN and send SYN/ACK. FAIL if no ACK returned. TESTABILITY NORMAL 4.1.4. OBJ: MP_CAPABLE Flag A set to 1 REFERENCE p. 16: The leftmost bit, labelled "A", SHOULD be set to 1. REQUIREMENT LEVEL SHOULD DESCRIPTION FAIL if SYN or SYN/ACK received with A=0. TESTABILITY NORMAL 4.1.5. OBJ: MP_CAPABLE Flag B set to 0 REFERENCE p. 16: The second bit, labelled "B", is an extensibility flag, and MUST be set to 0. REQUIREMENT LEVEL MUST DESCRIPTION Send SYN+MP_CAPABLE. FAIL if response MP_CAPABLE has flag B set to 1. TESTABILITY NORMAL 4.1.6. OBJ: MP_CAPABLE Flag B ignored REFERENCE p. 16: If receiving a message with the "B" flag set to 1, and this is not understood, then this SYN MUST be silently ignored. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if packet received after sending initial SYN with "B" flag set. TESTABILITY NORMAL 4.1.7. OBJ: MP_CAPABLE Flags C through H REFERENCE p.16: An implementation that only supports this method MUST set bit "H" to 1, and bits "C" through "G" to 0. A crypto algorithm MUST be specified. If flag bits C through H are all 0, the MP_CAPABLE option MUST be treated as invalid and ignored (that is, it must be treated as a regular TCP handshake). REQUIREMENT LEVEL MUST DESCRIPTION FAIL if packet with MP_CAPABLE option received after sending initial SYN with flag bits from C through H set to 0. TESTABILITY NORMAL 4.1.8. OBJ: MPTCP Version REFERENCE p. 15: (...) the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 0). REQUIREMENT LEVEL MUST DESCRIPTION FAIL if MPTCP Version field different from 0 in either the initial SYN, SYN/ACK. TESTABILITY NORMAL 4.1.9. OBJ: Token REFERENCE p. 16: The token MUST be a truncated (most significant 32 bits) SHA-1 hash of the key. REQUIREMENT LEVEL MUST TESTABILITY NORMAL 4.1.10. OBJ: Key generation REFERENCE p. 14: The key MUST be hard to guess, and it MUST be unique for the sending host at any one time. REQUIREMENT LEVEL MUST TESTABILITY HARD 4.1.11. OBJ: Hash collision detection REFERENCE p. 14: An implementation SHOULD check its list of connection tokens to ensure there is not a collision before sending its key in the SYN/ACK. REQUIREMENT LEVEL SHOULD DESCRIPTION FAIL if token collision occurs while opening $n$ concurrent connections. The probability of false negatives is then approximately equal to $\bar{p}(n)=e^{-n^2/2^{33}}$ (birthday paradox). If one cannot afford to have $n$ concurrent connections, a lower number $m$ can be considered instead but then the experiment must be repeated to acheive a comparable degree of confidence (cf. binomial trials). TESTABILITY HARD 4.1.12. OBJ: Initial Data Sequence Number REFERENCE p. 16: A 64 bit truncation (the least significant 64 bits) of the SHA-1 hash of the key MUST be used as the Initial Data Sequence Number. Note that the key MUST be hashed in network byte order. Also note that the "least significant" bits MUST be the rightmost bits of the SHA-1 digest. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if first DSN received is different from the least significant 64 bits of the SHA-1 hash of the remote key. TESTABILITY NORMAL 4.1.13. OBJ: Checksums REFERENCE p. 16: If either host requires the use of checksums, checksums MUST be used. In other words, the only way for checksums not to be used is if both hosts in their SYNs set A=0. This decision is confirmed by the setting of the "A" bit in the third packet (the ACK) of the handshake. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if received ACK with A=0 after having received SYN and sent SYN/ACK with A=1. TESTABILITY NORMAL 4.1.14. OBJ: Crypto negociation REFERENCE p. 17: The responder responds with only one bit set: this is the chosen algorithm. REQUIREMENT LEVEL MUST TESTABILITY NORMAL 4.1.15. OBJ: SYN/ACK without MP_CAPABLE REFERENCE p. 17: If a SYN contains an MP_CAPABLE option but the SYN/ ACK does not, the MPTCP session MUST operate as a regular, single- path TCP. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if an MPTCP option is received from a connection where a SYN/ACK without MP_CAPABLE was sent. TESTABILITY NORMAL 4.1.16. OBJ: ACK without MP_CAPABLE REFERENCE p. 17: If the third packet (the ACK) does not contain the MP_CAPABLE option, then the session MUST fall back to operating as a regular, single-path TCP. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if an MPTCP option is received from a connection where an ACK without MP_CAPABLE was sent. TESTABILITY NORMAL 4.1.17. OBJ: Regular SYN REFERENCE p. 17: If a SYN does not contain a MP_CAPABLE option, the SYN/ACK MUST NOT contain one in response. REQUIREMENT LEVEL MUST DESCRIPTION FAIL if SYN/ACK with MP_CAPABLE option received after sending a SYN without MP_CAPABLE option. TESTABILITY NORMAL 4.2. Connection Initiation: Test Cases 4.2.1. TEST: Initial handshake TS->SUT TS SUT | | | SYN[+MP_CAPABLE] | |----------------------------->| | | | [SYN/ACK[+MP_CAPABLE]|RST] | |<-----------------------------| | | v v INPUT PARAMETERS "SYN with MP_CAPABLE" in {true, false} "SYN MP_CAPABLE MPTCP version" in {0, 1} "SYN MP_CAPABLE flags" in {A|H, A, A|B|H, B|H} PARAMETERS DOMAIN {false} x {0} x {A|H} u {true} x {0, 1} x {A|H, A, A|B|H, B|H} DESCRIPTION send SYN that corresponds to input parameters if SYN flag B set assert no response received ("Flag B ignored") exit else assert response received ("send SYN/ACK upon SYN reception") if "SYN with MP_CAPABLE" is false or "SYN MP_CAPABLE MPTCP version" is not 0 assert no MP_CAPABLE in SYN/ACK ("Regular SYN") exit if SYN MP_CAPABLE flags C through H unset assert no MP_CAPABLE in SYN/ACK ("Flags C through H") exit else assert MP_CAPABLE in SYN/ACK ("SYN/ACK contains key") exit on assertion fail assert MP_CAPABLE flag A set ("Flag A set to 1") assert MP_CAPABLE flag B unset ("Flag B set to 0") assert MP_CAPABLE flags C through G unset and MP_CAPABLE flag H set ("Flags C through H") assert MP_CAPABLE MPTCP version is 0 ("MPTCP version") assert sender and receiver keys are different ("Key generation: repeated key") reset subflow 4.2.2. TEST: Initial handshake SUT->TS SUT TS | | | Trigger new connection | |- - - - - - - - - - - - - - ->| | | | SYN+MP_CAPABLE | |<-----------------------------| | | | SYN/ACK+[MP_CAPABLE] | |----------------------------->| | | | ACK[+MP_CAPABLE]| |<-----------------------------| | | v v INPUT PARAMETERS "SYN/ACK with MP_CAPABLE" in {true, false} "SYN/ACK flags" in {A|H, H} PARAMETERS DOMAIN {true, false} x {A|H, H} DESCRIPTION trigger new connection from SUT assert receive SYN ("Send SYN on new connection") exit on assertion fail assert MP_CAPABLE of length 12 present ("SYN format") exit on assertion fail assert MP_CAPABLE flag A set ("Flag A set to 1") assert MP_CAPABLE flag B unset ("Flag B set to 0") assert MP_CAPABLE flags C through G unset and MP_CAPABLE flag H set ("Flags C through H") assert MP_CAPABLE MPTCP version is 0 ("MPTCP version") send SYN/ACK that corresponds to input parameters assert receive ACK ("Send ACK upon SYN/ACK reception") exit on assertion fail if "SYN/ACK with MP_CAPABLE" is true assert MP_CAPABLE of length 20 present on ACK ("ACK format") exit on assertion fail else assert no MP_CAPABLE present on ACK ("SYN/ACK without MP_CAPABLE") assert MP_CAPABLE MPTCP version on ACK is 0 ("MPTCP Version") assert keys on ACK correctly repeated ("ACK format") assert MP_CAPABLE flag A set on ACK or (MP_CAPABLE flag A unset on SYN/ACK and MP_CAPABLE flag A unset on SYN) reset subflow 5. Conclusion 6. Acknowledgments This document was produced using the Pandoc2rfc tool. 7. Normative References [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. Author's Address Yvan Coene UCLouvain