Internet DRAFT - draft-bonaventure-tcpm-edo-analysis
draft-bonaventure-tcpm-edo-analysis
TCPM Working Group O. Bonaventure
Internet-Draft O. Tilmans
Intended status: Experimental UCLouvain
Expires: January 21, 2016 July 20, 2015
Analysis of the TCP EDO option
draft-bonaventure-tcpm-edo-analysis-00
Abstract
This document analyses how the proposed TCP EDO option copes with
various types of middlebox interference.
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 21, 2016.
Copyright Notice
Copyright (c) 2015 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.
Bonaventure & Tilmans Expires January 21, 2016 [Page 1]
Internet-Draft EDO Analysis July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Middlebox Interference . . . . . . . . . . . . . . . . . . . 3
2.1. Negotiating EDO . . . . . . . . . . . . . . . . . . . . . 4
2.2. Replacement of the EDO option with NOP . . . . . . . . . 4
2.3. Removal of the EDO option . . . . . . . . . . . . . . . . 6
2.4. Data Injection . . . . . . . . . . . . . . . . . . . . . 6
2.5. Segment Splitting . . . . . . . . . . . . . . . . . . . . 7
2.6. Segment Coalescing . . . . . . . . . . . . . . . . . . . 8
2.7. Option Injection . . . . . . . . . . . . . . . . . . . . 10
2.8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Testing the deployability of EDO with tracebox . . . . . . . 13
3.1. Crafting packets with the EDO options . . . . . . . . . . 13
3.1.1. EDOREQUEST . . . . . . . . . . . . . . . . . . . . . 13
3.1.2. EDO . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. EDOEXT . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Evaluating the deployability of EDO with tracebox tests . 14
3.2.1. Example of test outputs . . . . . . . . . . . . . . . 14
4. Security considerations . . . . . . . . . . . . . . . . . . . 18
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
TCP [RFC0793] has probably been more successful than what its
designers initially expected. TCP was designed with extensibility in
mind thanks to a variable length header. The Data Offset (DO) field
in the TCP header indicates the boundary between the extended TCP
header and the segment payload. The DO is specified in blocks of 32
bits, which forces TCP implementations to pad the TCP header on 32
bits boundaries. The maximum value of the DO field is 15; which
limits the length of the extended TCP header to 60 bytes (including
the 20 bytes standard TCP header).
Various solutions have been proposed to cope with this limited
extensibility of the TCP header (see [I-D.ietf-tcpm-tcp-edo] and the
references cited in this document). A prototype implementation of
the EDO proposal has been recently released [EDOLinux].However, as of
this writing it has not been tested on the global Internet.
In this document we built upon previous work [IMC11] [HotMiddlebox13]
[IMC13] and experience with Multipath TCP [RFC6824] to provide a
qualitative analysis of the interactions between a TCP implementation
Bonaventure & Tilmans Expires January 21, 2016 [Page 2]
Internet-Draft EDO Analysis July 2015
supporting the EDO proposal [I-D.ietf-tcpm-tcp-edo] and different
types of middleboxes.
This document is organised as follows. We qualitatively analyse in
Section 2 the impact of different types of middlebox interference on
the EDO proposal [I-D.ietf-tcpm-tcp-edo]. Then, in Section 3, we
show how tracebox [tracebox] could be used to perform a detailed
evaluation of the interactions between EDO and real middleboxes.
2. Middlebox Interference
In this section, we analyse how the TCP EDO proposals deals with
several of the types of middlebox interference that were identified
in [IMC11] and guided the design of Multipath TCP [RFC6824].
In our analysis, we use the following graphical representation for
the TCP segments. The first box represents the standard 20 bytes TCP
header with the value of the DO field. The second box represents the
EDO option (simple variant) with the header length set to 7 32 bits
words. These two boxes are part of the extended TCP header. The
third box is the TCP option that is encoded inside the payload. The
number between parentheses is the length of the options in bytes.
Finally, the last box contains the user data and its length in bytes
between parentheses.
<-- TCP Header --> <--- Segment Payload ------>
+-----------+-----------+=============+=================+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (6) |
+-----------+-----------+=============+=================+
Figure 1: Simple EDO option
With the second variant of the EDO option that includes the segment
length verification, the figure becomes.
<-- TCP Header --> <--- Segment Payload ------>
+-----------+----------------+=============+=================+
| H (DO=7) | EDO (L=8,S=36) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+=================+
Figure 2: EDO option with Segment Length Verification
Note that in the above figure, two NOP options are missing. These
options should appear immediately after the EDO option to pad the
Bonaventure & Tilmans Expires January 21, 2016 [Page 3]
Internet-Draft EDO Analysis July 2015
extended TCP header to a 32 bits word boundary. We omit these NOP
options used for padding to simplify the figures in this document.
2.1. Negotiating EDO
The utilisation of the EDO option needs to be negotiated by placing
the EDO Supported option in the SYN and SYN+ACK segments. The
negotiation proposed in [I-D.ietf-tcpm-tcp-edo] raises two concerns
based on the experience with such a negotiation for Multipath TCP
[RFC6824].
First, using exactly the same option in the SYN and SYN+ACK segment
is risky because there are some middleboxes [IMC13] that simply echo
in the SYN+ACK any unknown option that they receive in the SYN. This
is an incorrect, but unfortunately deployed behaviour.
Second, [I-D.ietf-tcpm-tcp-edo] uses two different TCP option types :
EDO Supported in the SYN and EDO Extension in the other segments.
The initial design of Multipath TCP also used different option types
but it then opted for a single option type and different subtypes.
This change was motivated by the fact that if a middlebox accepts
option type 'x' in the SYN, it will likely also accept it in the
other segments since the handling of TCP options some middleboxes is
often configured on a per-type basis [Normalizer]. However,
accepting option type 'x' in the SYN is not a guarantee for the
acceptance of option type 'y' in other segments.
In the remainder of this document, we only analyse the impact of
middlebox interference on TCP segments that contain both options and
data.
2.2. Replacement of the EDO option with NOP
The first middlebox interference that we consider is a middlebox that
replaces the EDO option with NOPs [HotMiddlebox13] [Normalizer].
Replacing an unknown option with a NOP is a frequently used solution
by middlebox vendors because it does not require any modification to
the segment length. This is illustrated in Figure 3 for the simple
EDO option.
Bonaventure & Tilmans Expires January 21, 2016 [Page 4]
Internet-Draft EDO Analysis July 2015
Initial segment
+-----------+-----------+=============+=================+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (6) |
+-----------+-----------+=============+=================+
||
\/
+-----------+-----------+=============+=================+
| H (DO=6) | NOP NOP | TCP Opt (4) | User Data (6) |
+-----------+-----------+=============+=================+
Modified segment
Figure 3: Simple EDO option through a middlebox that replaces EDO
with NOP
Upon reception of the modified segment, the receiver will ignore the
segment because it does not contain the EDO option. Unfortunately,
if the sender retransmits the same segment, it is likely that the
same modification will happen and the modified segment will again be
lost. This could cause a blackhole where all segments sent by the
sender are discarded by the receiver.
If the receiver accepts the segment without the EDO option, the
situation is worse. Upon reception of the modified segment, the
receiver will consider that the 4 bytes of the TCP options are part
of the user data. If the segment was received in sequence, the
receiver will acknowledge more data than the data sent by the sender.
If the EDO option includes the segment length verification, the same
problem occurs.
Initial segment
+-----------+----------------+=============+=================+
| H (DO=7) | EDO (L=8,S=36) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+=================+
||
\/
Modified segment
+-----------+----------------+=============+=================+
| H (DO=7) | NOP NOP | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+=================+
Figure 4: EDO option with Segment Length Verification through a
middlebox that replaces EDO with NOP
Bonaventure & Tilmans Expires January 21, 2016 [Page 5]
Internet-Draft EDO Analysis July 2015
2.3. Removal of the EDO option
If a middlebox removes the EDO option [IMC11], then the receiver will
act as explained in the previous section.
2.4. Data Injection
Middleboxes such as NAT boxes that include an ALG for protocols such
as FTP are known to insert or remove data inside the payload of some
segments.
Figure 5 shows the impact of such a middlebox on a TCP segment that
contains the EDO option. The modified segment will be received and
processed correctly (including the injected data) by the receiver.
Initial segment
+-----------+-----------+=============+=================+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (6) |
+-----------+-----------+=============+=================+
||
\/
+-----------+-----------+=============+======================+
| H (DO=7) | EDO (L=7) | TCP Opt (4) | User Data (8) |
+-----------+-----------+=============+======================+
Modified segment
Figure 5: EDO option through a middlebox that injects data
If the EDO option includes the segment length, the situation is
different. Figure 6 provides a graphical representation of the
scenario. When the receiver parses the EDO option, it detects that
the segment does not have the correct length and silently discards
it. In this case, the same problem as described in Section 2.2
happens.
Bonaventure & Tilmans Expires January 21, 2016 [Page 6]
Internet-Draft EDO Analysis July 2015
Initial segment
+-----------+----------------+=============+=================+
| H (DO=7) | EDO (L=8,S=36) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+=================+
||
\/
Modified segment
+-----------+----------------+=============+======================+
| H (DO=8) | EDO (L=8,S=36) | TCP Opt (4) | User Data (8) |
+-----------+----------------+=============+======================+
Figure 6: EDO option with Segment Length Verification through a
middlebox that injects data
2.5. Segment Splitting
We now consider a middlebox that splits segments. Such a middlebox
will usually copy the TCP options in the extended TCP header of the
splitted segments. [IMC11] notes "All the NICs we tested correctly
copied the options to all the split segments. TSO is now
sufficiently commonplace so that designers of extensions to TCP
should assume it." Segment splitting is illustrated in Figure 7.
+-----------+-----------+=============+=================+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (6) |
+-----------+-----------+=============+=================+
||
\/
+-----------+-----------+=============+==============+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (2)|
+-----------+-----------+=============+==============+
and
+-----------+-----------+===============+
| H (DO=6) | EDO (L=7) | User Data (4) |
+-----------+-----------+===============+
Figure 7: EDO option through a middlebox that splits segments
In this case, the receiver will correctly process the option in the
payload of the first segment and pass the first two bytes of the user
data to the application. However, in the second segment, the EDO
option indicates that the first four bytes of the payload contain TCP
Bonaventure & Tilmans Expires January 21, 2016 [Page 7]
Internet-Draft EDO Analysis July 2015
options. This part of the data will not be acknowledged by the
receiver and will probably be retransmitted by the sender.
With the EDO option that includes the segment length information, the
situation is different as shown in Figure 8. The receiver detects
immediately that the segment has an invalid length and silently
discards them and the same problem as described in Section 2.2
happens.
+-----------+----------------+=============+==============+
| H (DO=7) | EDO (L=8,S=38) | TCP Opt (4) | User Data (6)|
+-----------+----------------+=============+==============+
||
\/
+-----------+----------------+=============+===============+
| H (DO=7) | EDO (L=8,S=38) | TCP Opt (4) | User Data (2) |
+-----------+----------------+=============+===============+
and
+-----------+----------------+===============+
| H (DO=7) | EDO (L=8,S=38) | User Data (4) |
+-----------+----------------+===============+
Figure 8: EDO option with Segment Length Verification through a
middlebox that splits segments
2.6. Segment Coalescing
Our last middleboxes coalesces successive segments. We assume that
the middlebox only coalesces the segments that contain the same
option in the (extended) TCP header. This is inline with [IMC11]
which notes after having tested segments with both a known and an
unknown option : "For both option kinds, packets were coalesced only
when their option values are same. The coalesced segment has one of
the options on the original segments."
In our example, shown in Figure 9, the two segments contain the same
EDO option but different TCP options in the payload. Due to the
coalescing, the receiver will pass to the user application the second
TCP option inside the payload.
Bonaventure & Tilmans Expires January 21, 2016 [Page 8]
Internet-Draft EDO Analysis July 2015
+-----------+-----------+=============+=================+
| H (DO=6) | EDO (L=7) | TCP OptA(4) | User Data (6) |
+-----------+-----------+=============+=================+
+
+-----------+-----------+=============+==============+
| H (DO=6) | EDO (L=7) | TCP OptB(4) | User Data (2)|
+-----------+-----------+=============+==============+
||
\/
+-----------+-----------+=============+===============+...
| H (DO=6) | EDO (L=7) | TCP OptA(4) | User Data (6) |
+-----------+-----------+=============+===============+...
...============================+
TCP OptB(4) | User Data (2)|
...=============+==============+
Figure 9: EDO option through a middlebox that coalesces segments
With the EDO option that includes the segment length, the receiver
will silently discard the coalesced segment. However, as explained
earlier, this may result in a deadlock where the sender retransmits
segments that are never acknowledged by the receiver.
+-----------+----------------+=============+===============+
| H (DO=7) | EDO (L=8,S=38) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+===============+
+
+-----------+----------------+=============+===============+
| H (DO=7) | EDO (L=8,S=38) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+===============+
||
\/
+-----------+----------------+============+===============+...
| H (DO=7) | EDO (L=8,S=38) |TCP Opt (4) | User Data (6) |
+-----------+----------------+============+===============+...
...============+===============+
TCP Opt (4) | User Data (6) |
============+===============+
Figure 10: EDO option with Segment Length Verification through a
middlebox that coalesces segments
Bonaventure & Tilmans Expires January 21, 2016 [Page 9]
Internet-Draft EDO Analysis July 2015
2.7. Option Injection
Finally, let us now consider what happens when a middlebox inserts an
option inside the TCP header. For simplicity, we add an option that
has a length of 4 bytes. We have no evidence of such behaviour, but
it is possible in environments where middleboxes that operate in pair
as shown in Figure 11. Several middelbox vendors have defined
options that are used in the SYN segment to discover the presence of
a downstream middlebox [I-D.ananth-middisc-tcpopt] and some vendors
have defined specific TCP options that are used between such
middleboxes. If the upstram upstream middlebox inserts an option,
this option could be removed or replaced by NOP on the downstream
middlebox.
client ---- mbox1 ---------- mbox2 ----- server
Figure 11: Cooperating middelboxes
The scenario with this middlebox is illustrated in Figure 12.
Initial segment
+----------+-----------+=============+==============+
| H (DO=6) | EDO (L=7) | TCP Opt (4) | User Data (6)|
+----------+-----------+=============+==============+
||
\/
+----------+-----------+-------------+=============+==============+
| H (DO=7) | EDO (L=7) | Added Opt(4)| TCP Opt (4) | User Data (6)|
+----------+-----------+-------------+=============+==============+
Modified segment
Figure 12: Simple EDO option through a middlebox that inserts an
option
In this case, the receiver receives a strange segment. The DO field
of the TCP header indicates that the extended header contains :
o the EDO option
o the Added option
The EDO option indicates that the extended header has a length of 28
bytes. This implies that it contains the following options :
Bonaventure & Tilmans Expires January 21, 2016 [Page 10]
Internet-Draft EDO Analysis July 2015
o the EDO option
o the Added option
The four bytes TCP option that is included in the TCP payload is not
detected as an option by the receiver based on the EDO option. This
option is thus included in the data passed to the application.
With the TCP EDO option that includes the segment length information,
the receiver can detect that the segment has been modified and
silently discards it. Unfortunately, it is likely that when the
sender retransmits the segment the same option is added to the
retransmission. In this case, the same problem as described in
Section 2.2 happens.
Initial segment
+-----------+----------------+=============+===============+
| H (DO=7) | EDO (L=8,S=34) | TCP Opt (4) | User Data (6) |
+-----------+----------------+=============+===============+
||
\/
Modified segment
+-----------+----------------+-------------+===========+==============+
| H (DO=8) | EDO (L=8,S=34) | Added Opt(4)|TCP Opt (4)| User Data (6)|
+-----------+----------------+-------------+===========+==============+
Figure 13: EDO option with Segment Length Verification through a
middlebox that inserts an Added option
2.8. Summary
We summarise the main results of our qualitative analysis in two
tables. First, Table 1 shows how the simple EDO option reacts with
the different types of middlebox interference that have been
discussed in this section. Table 2 shows the same information with
the EDO option that includes the segment length information.
Bonaventure & Tilmans Expires January 21, 2016 [Page 11]
Internet-Draft EDO Analysis July 2015
+-----------------------+-------------------------------------------+
| Middlebox | Outcome |
| Interference | |
+-----------------------+-------------------------------------------+
| Replacement of EDO | silently discarded by receiver but risk |
| with NOP | of blackhole |
| | |
| Removal of EDO | silently discarded by receiver but risk |
| | of blackhole |
| | |
| Data injection | ok |
| | |
| Segment splitting | some data parsed as option and then |
| | likely retransmitted |
| | |
| Segment coalescing | option passed as user data in the |
| | bytestream |
| | |
| Option injection | option passed as user data in the |
| | bytestream |
+-----------------------+-------------------------------------------+
Table 1: Summary of Middelbox interference with the EDO extension
+------------------------+------------------------------------------+
| Middlebox Interference | Outcome |
+------------------------+------------------------------------------+
| Replacement of EDO | silently discarded by receiver but risk |
| with NOP | of blackhole |
| | |
| Removal of EDO | silently discarded by receiver but risk |
| | of blackhole |
| | |
| Data injection | silently discarded by receiver but risk |
| | of blackhole |
| | |
| Segment splitting | silently discarded by receiver but risk |
| | of blackhole |
| | |
| Segment coalescing | silently discarded by receiver but risk |
| | of blackhole |
| | |
| Option injection | silently discarded by receiver but risk |
| | of blackhole |
+------------------------+------------------------------------------+
Table 2: Summary of Middelbox interference with the EDO extension
with segment length validation
Bonaventure & Tilmans Expires January 21, 2016 [Page 12]
Internet-Draft EDO Analysis July 2015
3. Testing the deployability of EDO with tracebox
The qualitative analysis described in the previous section provides
some insights on several issues with the proposed EDO option.
However, experience with Multipath TCP [IMC11] [HotMiddlebox13]
[IMC13] shows that real measurements are required to understand the
practical limits to the deployability of a TCP extension such as EDO.
In this section, we present how tracebox [tracebox] can help
verifying the deployability of the proposed EDO extension. tracebox
is a network diagnostic software that is similar to traceroute except
that it allows to send any type of packet and support various
options. tracebox detects middlebox interference by sending packets
with increasing TTL/HopLimit values and analyses the ICMP replies
returned by routers to infer modifications that were made on packets
between two hops. tracebox works better through IPv6 routers that
return the entire packet in the ICMP reply or IPv4 routers that
implement the recommendation of [RFC1812] and quote the received
packet in the return ICMP message. Furthermore, it can be extended
through LUA scripts to support more advanced tests [traceboxlua].
3.1. Crafting packets with the EDO options
tracebox provides high-level functions to build packets that can then
be used as probes for its default behavior, or sent/received to build
more complex tests such as the ones involving data transfer after the
TCP handshake. The latest version of tracebox provides bindings for
all the three variants of the EDO option defined in
[I-D.ietf-tcpm-tcp-edo].
3.1.1. EDOREQUEST
Implements the 2-bytes version of the option that is used in the
three-way handshake.
Usage example: "IP / TCP / EDOREQUEST / sackp() / mpcapable()"
This builds a TCP SYN segment, advertising support for SACK, EDO and
MPTCP.
3.1.2. EDO
Implements the 4-bytes extension containing the extended header
length. When used, tracebox automatically adjusts the data offset
field in the TCP header such that EDO is the last part of the header
covered by the field.
Bonaventure & Tilmans Expires January 21, 2016 [Page 13]
Internet-Draft EDO Analysis July 2015
Usage example: "IP / tcp{flags=TCP.ACK} / EDO / sack{{123, 456},
{789, 1011}} / NOP / NOP"
This builds a TCP header whose DO will be set to 6 (to cover only
EDO), while the HeaderLength in the EDO extension will be set to 11
(44 bytes) (to include the SACK blocks in the payload)
3.1.3. EDOEXT
Implements the 6-bytes variant, which adds the segment length field.
Usage example: "IP / tcp{flags=TCP.ACK} / EDOEXT / NOP /NOP /
sack{{123, 456}, {789, 1011}} / NOP / NOP"
This builds a TCP header whose DO will be set to 7, while the
HeaderLength in the EDO extension will be set to 11 (46 bytes) and
the SegmentLength field will be set to 46.
3.2. Evaluating the deployability of EDO with tracebox tests
The first set of tests is similar as to what has been done in
[IMC11]. It uses tracebox to send packets containing one of the EDO
variants with an increasing TTL and checks the ICMP payloads and the
final reply from the target host to detect the eventual modifications
that took place.
The second set of tests uses the Lua scripting capabilities of
tracebox as well as its packet capture engine. In these tests,
tracebox is used both on the client and on the server side. This
enables to write a simple implementation of the TCP handshake,
negociating EDO, then doing an actual data transfer where TCP options
are included in the payload.
3.2.1. Example of test outputs
The test outputs shown in Figure 14 and Figure 15 reveal the
different modifications that occur on a TCP SYN when being forwarded
to either google.com or baidu.cn, and eventually the reply that we
received from the server. Hops marked with the "[PARTIAL]" tags
denotes routers not following the recommendations of [RFC1812]
regarding ICMP replies. We can see that Google does not advertize
back the support for the EDO extension (as expected ...) and that
instead it added a TCP MSS option in the SYN+ACK (hop 20).
Bonaventure & Tilmans Expires January 21, 2016 [Page 14]
Internet-Draft EDO Analysis July 2015
# tracebox -n -p 'IP/TCP/EDOREQUEST' www.google.com
tracebox to 74.125.70.105 (www.google.com): 64 hops max
1: 192.168.0.1 [PARTIAL]
2: *
3: 78.129.127.145 [PARTIAL] IP::TTL IP::CheckSum
4: 212.68.211.13 [PARTIAL] IP::TTL IP::CheckSum
5: 149.6.135.141 TCP::CheckSum IP::TTL IP::CheckSum
6: 154.54.39.50 TCP::CheckSum IP::DiffServicesCP IP::TTL
IP::CheckSum
...
19: *
20: 74.125.70.105 TCP::SrcPort TCP::DstPort TCP::SeqNumber
TCP::AckNumber TCP::Flags TCP::WindowsSize TCP::CheckSum
IP::Identification IP::Flags IP::TTL IP::CheckSum IP::SourceIP
IP::DestinationIP +TCPOptionMaxSegSize -TCPOptionPad
-TCPEDORequest
Figure 14: Sending TCP SYN advertizing EDO support.
The trace towards Baidu however exhibits the same behavior as what
was reported in [IMC13]: EDO is an unkown option, but it is echo'ed
back to the sender in the TCP SYN+ACK (unlike in the Google trace,
there is no -TCPEDORequest modification that has been detected).
# tracebox -n -p 'IP/TCP/EDOREQUEST' www.baidu.com
tracebox to 103.235.46.39 (www.baidu.com): 64 hops max
1: 192.168.0.1 [PARTIAL]
2: *
3: 78.129.127.145 [PARTIAL] IP::TTL IP::CheckSum
4: 212.68.211.13 [PARTIAL] IP::TTL IP::CheckSum
5: 195.219.227.17 [PARTIAL] IP::TTL IP::CheckSum
6: 195.219.241.9 TCP::CheckSum IP::TTL IP::CheckSum
...
16: *
17: *
18: 103.235.46.39 TCP::SrcPort TCP::DstPort TCP::SeqNumber
TCP::AckNumber TCP::Flags TCP::WindowsSize TCP::CheckSum
IP::TTL IP::CheckSum IP::SourceIP IP::DestinationIP
Figure 15: Sending TCP SYN advertizing EDO support.
Our second sample test is a stateful one. It consists in a client
establishing a TCP connection towards a FTP server running on the
standard port (21), and then sending a PORT command. Both the client
and the server are implemented using tracebox Lua API, and visible in
Bonaventure & Tilmans Expires January 21, 2016 [Page 15]
Internet-Draft EDO Analysis July 2015
Figure 16 and Figure 17. The client connection starts from a home
network, behind a NAT, while the server runs in a datacenter. The
client output is shown in Figure 18. The server-side output of the
test is visible in Figure 19, and shows that an unconsistency due to
the client NAT has been detected between the EDOEXT reported segment
length and the actual segment length, which would cause the packet to
be silently ignored by the server resulting in a blackhole.
iph = ip{dst=dn4('test1.multipath-tcp.org')}
syn = iph / tcp{dst=21} / EDOREQUEST
synack = syn:sendrecv{}
if not synack then
print("Server did not reply...")
return
end
if synack:tcp():getflags() ~= TCP.SYN + TCP.ACK then
print("Server did not reply with SYN+ACK")
return
end
if not synack:get(EDOREQUEST) then
print('Server does not support EDO')
return
end
-- build PORT probe
ip_port = syn:source():gsub("%.", ",")
data = iph / tcp{src=syn:tcp():getsource(),
dst=21, seq=syn:tcp():getseq()+1,
ack=synack:tcp():getseq()+1,
flags=TCP.ACK}
/ EDOEXT
/ raw('PORT '.. ip_port .. ',189,68\r\n')
print('Sending: ' .. tostring(data:payload():data()))
data:send()
Figure 16: Lua code for a client establishing a connection to a FTP
server supporting EDO
Bonaventure & Tilmans Expires January 21, 2016 [Page 16]
Internet-Draft EDO Analysis July 2015
function receive(pkt)
if pkt:tcp():getflags() == TCP.SYN then
print('Client connected from ' .. pkt:source())
if pkt:get(EDOREQUEST) then
print('Client advertized EDO option')
local synack = ip{dst=pkt:source()}
/ tcp{src=21,
dst=pkt:tcp():getsource(),
ack=pkt:tcp():getseq() + 1,
flags=TCP.SYN + TCP.ACK}
/ EDOREQUEST / NOP / NOP
synack:send()
else
print('No EDO option, ignoring client')
end
else
local edoh = pkt:get(EDO)
if edoh ~= nil edoh:length() == 6 then
print('Received data: '
.. tostring(pkt:payload():data()))
print('Packet has an extended EDO option')
local seg_len = pkt:iplayer():payloadlen()
- edoh:headerlength() * 4
print('Segment length is: ' .. seg_len)
print('EDO Segment length is: '
.. edoh:segmentlength())
end
end
end
snif({'-p', 'tcp', '--dport', 21}, receive)
Figure 17: Lua code for a server listening on port 21 supporting EDO
# tracebox -s client_ftp_edo.lua test1.multipath-tcp.org
Sending: PORT 192,168,0,4,189,68
Figure 18: Client output for the EDO/FTP test
Bonaventure & Tilmans Expires January 21, 2016 [Page 17]
Internet-Draft EDO Analysis July 2015
# tracebox -s server_ftp_eco.lua
Client connected from 85.27.48.241
Client advertized EDO option
Received data: PORT 85,27,48,241,189,68
Packet has an extended EDO option
Segment length is: 26
EDO Segment length is: 25
Figure 19: Server output for the EDO/FTP test
4. Security considerations
This document discusses the interference between the proposed EDO TCP
option [I-D.ietf-tcpm-tcp-edo] and middleboxes. It does not affect
the security of TCP.
5. Conclusion
In this document, we have analysed how the proposed EDO option can
cope with various types of middlebox interferences. For the simple
EDO extension, our analysis reveals that this option is not safe for
several important types of middlebox interference. For the EDO
extension that includes a segment length verification, the main risk
is that when a receiver detects a segment that has been modified by a
middlebox, that segment is silently discarded and there is no
guarantee that a future retransmission of this segment will not again
be discarded by the receiver. There is thus a risk of blackhole that
does not appear acceptable for a TCP option that is intended to be
used to support other TCP extensions.
The main problem with the current EDO proposal
[I-D.ietf-tcpm-tcp-edo] is that it does not include any feedback
mechanism to enable the receiver to inform the sender about either
the correct operation of EDO or the detection of any invalid segment.
Without such a feedback mechanism, it is unlikely that a variant of
EDO would be able to cope with the different types of middlebox
interference.
Finally, we have shown that tracebox can be used to perform tests
with the proposed EDO option and we would encourage the TCPM working
group to conduct such tests on a large scale before any final
decision on EDO.
Bonaventure & Tilmans Expires January 21, 2016 [Page 18]
Internet-Draft EDO Analysis July 2015
6. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project.
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
7.2. Informative References
[EDOLinux]
Trieu, H., Touch, J., and T. Faber, "Implementation of the
TCP Extended Data Offset Option", ISI-TR-696 , n.d.,
<http://www.isi.edu/touch/pubs/isi-tr-2015-696.pdf>.
[HotMiddlebox13]
Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O.
Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT
workshop HotMiddlebox , December 2013,
<http://inl.info.ucl.ac.be/publications/
are-tcp-extensions-middlebox-proof>.
[I-D.ananth-middisc-tcpopt]
Knutsen, A., Ramaiah, A., and A. Ramasamy, "TCP option for
transparent Middlebox negotiation", draft-ananth-middisc-
tcpopt-02 (work in progress), February 2013.
[I-D.ietf-tcpm-tcp-edo]
Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
draft-ietf-tcpm-tcp-edo-03 (work in progress), April 2015.
[IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference (IMC '11) ,
2011, <http://doi.acm.org/10.1145/2068816.2068834>.
[IMC13] Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and
B. Donnet, "Revealing Middlebox Interference with
tracebox", Proceedings of the 2013 ACM SIGCOMM conference
on Internet measurement conference , 2013,
<http://inl.info.ucl.ac.be/publications/
revealing-middlebox-interference-tracebox>.
Bonaventure & Tilmans Expires January 21, 2016 [Page 19]
Internet-Draft EDO Analysis July 2015
[Normalizer]
Cisco Systems, ., "Configuring TCP Normalization", 2015, <
http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/co
nfiguration/guide/config/conns_tcpnorm.html#wp1084313>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[tracebox]
Detal, G. and O. Tilmans, "tracebox",
<http://www.tracebox.org>.
[traceboxlua]
Tilmans, O., "LUA bindings for tracebox", n.d.,
<http://www.tracebox.org/lua_doc/index.html>.
Authors' Addresses
Olivier Bonaventure
UCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Olivier Tilmans
UCLouvain
Email: Olivier.Tilmans@uclouvain.be
Bonaventure & Tilmans Expires January 21, 2016 [Page 20]
