MPTCP working Group A. Palanivelan Internet Draft Verizon Labs Intended status: Informational H. Chetan Expires: Dec 26, 2015 Verizon Labs S. Senthil Cisco Systems June 29,2015 MPTCP Implementation (Challenges) Usecases draft-palanivelanchetan-mptcp-challenges-usecases-00 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 26, 2015. 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. A.Palanivelan, H.Chetan,. Expires December 26, 2015 [Page 1] Internet-Draft MPTCP Implementation (Challenges) Usecases June 2015 Abstract MPTCP Intends to address a wide range of issues, with minimal implementation tweaks. Though this works in a range of use cases, there are some use cases, where some standard implementation recommendations could help. The Purpose of this draft is to document the use cases, where there are opportunities for standard implementation recommendations. Table of Contents 1. Introduction...................................................3 2. MPTCP Implementation Challenges -Usecases......................3 2.1. Impact on existing monitoring and security tools..........3 2.2. Fragmentation.............................................3 2.3. Aggregation, Persistence & Resilience.....................3 2.4. Address Hopping...........................................4 2.5. Security Issues...........................................4 2.6. MPTCP for DATA CENTRES....................................4 2.7. MPTCP performance in presence and absence of proxies......4 3. Security Considerations........................................4 4. IANA Considerations............................................4 5. Conclusions....................................................4 6. References.....................................................5 6.1. Normative References......................................5 6.2. Informative References....................................5 7. Acknowledgments................................................5 A.Palanivelan, H.Chetan,. Expires December 26, 2015 [Page 2] Internet-Draft MPTCP Implementation (Challenges) Usecases June 2015 1. Introduction There are several existing MPTCP Implementations and no doubt there is a growing demand to adopt this in addressing a wide range of issues. This draft documents use cases where there are implementation challenges and would need standard recommendations. The Opportunities (design recommendations) to address one or set of use cases, independently is not in the scope of this document. 2. MPTCP Implementation Challenges -Usecases 2.1. Impact on existing monitoring and security tools If an endpoint sending data wants to add paths to an MPTCP session, it notifies the receiving server, which then opens up the new path. That's a contradiction -- it's meant to be a stream sending data (envision that as data being sent from "left" to "right" on a diagram), but the connection is originating in the other direction, right to left. From the point of view of a network tool, that new stream is "outbound, but incoming," That could cause confusion in some monitoring and security tools. 2.2. Fragmentation In MPTCP since the party can choose how to divide up data it can do fragmentation attacks very easily, for instance by sending every alternate byte down alternate paths vi different interfaces. Because of technical details of how the mapping occurs, this wouldn't be very efficient, however if both ends are doing this then there may be no single point on the network which can observe the traffic from both flows. This is the unique danger of a multipath fragmentation attack reassembly capability alone is not sufficient to observe all traffic. 2.3. Aggregation, Persistence & Resilience In the immediate term however, MPTCP is designed to provide reliable delivery over multiple paths and to detect where interference happens and avoid that path. This may cause issues for organizations who use active or transparent security measures. If a client can find a path that supports MPTCP it will prefer it over the recommended path, leading to both avoidance of security measures and the potential for new forms of phishing attacks. A.Palanivelan, H.Chetan,. Expires December 26, 2015 [Page 3] Internet-Draft MPTCP Implementation (Challenges) Usecases June 2015 2.4. Address Hopping An endpoint can add and remove addresses at will throughout the connection, with no requirement that any connection remain available, just that the chain of connections remains so. This adds additional complexity for monitoring and state handling, for now, we need to watch every connection, every possible connection, and track every advertised address. 2.5. Security Issues Many organizations use network security which is highly dependent on tight perimeters, flow monitoring and data inspection. Where network security technology is not ready, it may be significantly less effective against MPTCP traffic 2.6. MPTCP for DATA CENTRES 2.7. MPTCP performance in presence and absence of proxies 3. Security Considerations None 4. IANA Considerations None 5. Conclusions None A.Palanivelan, H.Chetan,. Expires December 24, 2015 [Page 4] Internet-Draft MPTCP Implementation (Challenges) Usecases June 2015 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC6356, October 2011. 7. Acknowledgments We like to appreciate and thank all contributions to this document, by means of useful feedback and inputs Authors' Addresses Chetan Harsha R&D Software Engineer, Verizon Labs Bangalore, India Email: chetan.harsha@verizon.com Senthil sivakumar Principal Engineer, Cisco systems Durham, NC Email: ssenthil@cisco.com Palanivelan Appanasamy DMTS-Engineering, Verizon Labs Bangalore, India Email: palanivelan.appanasamy@verizon.com A.Palanivelan, H.Chetan,. Expires December 26, 2015 [Page 5]