Internet DRAFT - draft-coene-mptcp-conformance
draft-coene-mptcp-conformance
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
