Internet DRAFT - draft-palanivelanchetan-mptcp-challenges-usecases
draft-palanivelanchetan-mptcp-challenges-usecases
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]
