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, . 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., . [HotMiddlebox13] Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O. Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT workshop HotMiddlebox , December 2013, . [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, . [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, . 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, . [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, . [tracebox] Detal, G. and O. Tilmans, "tracebox", . [traceboxlua] Tilmans, O., "LUA bindings for tracebox", n.d., . 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]