[secdir] [New-work] WG Review: Multipath TCP (mptcp)

[IESG Secretary <[e-mail]>]

A new IETF working group has been proposed in the Transport Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list ([e-mail]) by Tuesday,
October 6, 2009.

Multipath TCP (mptcp)
===========================================
Current Status: Proposed Working Group
Last updated: 2009-09-28

Chair(s):
 
    * To be decided

Transport Area Director(s):

    * Magnus Westerlund <[e-mail]>
    * Lars Eggert <[e-mail]>

Transport Area Advisor:

    * Magnus Westerlund <[e-mail]>

Mailing List:
To subscribe: https://www.ietf.org/mailman/listinfo/multipathtcp
Archive:      http://www.ietf.org/mail-archive/web/multipathtcp/

Description of Working Group:

The Multipath TCP (MPTCP) working group develops mechanisms that add 
the capability of simultaneously using multiple paths to a regular TCP 
session. The primary output of the group will be the protocol 
extensions needed to deploy MPTCP, and adaptations to congestion 
control to safely support multipath resource sharing. Initially the WG 
will only produce documents that are experimental or informational. 

Key goals for MPTCP are: to be deployable and usable without 
significant changes to existing Internet infrastructure; to be usable 
by unmodified applications; and to be stable and congestion-safe over 
the wide range of existing Internet paths. That will include handling 
MTU discovery on a per path basis and NAT interactions. The design's 
success in meeting the goals should be determined through experiments. 
However, it is expected that some results from large scale experiments 
can only be achievable after the publication of the initial design. 

The working group will provide a modular architecture that is designed 
to be easily extensible and adaptable. In particular, the congestion 
control mechanism is separated from the mechanisms for identifying and 
using multiple paths. The working group will focus on a solution 
requiring modification of both peers. One or both peers are expected to 
have multiple addresses, which often results in different network paths 
that are at least partially divergent. However, multiple addresses, 
even on different network interfaces, are no guarantee that the paths 
are divergent at all. The design needs to address the issues associated 
with fully or partially joint paths and shared bottlenecks. The design 
should allow for future extensions to handle cases where path diversity 
is attempted through other means than using different addresses. The 
design must also consider what happens when end-point pairs become 
unavailable during an ongoing session, especially pairs used to 
establish connections between additional end-point pairs. 

Whilst MPTCP will require modifications to the TCP stack at both the 
peers, all existing applications should be able to use the new MPTCP 
stack without modification and gain benefits from multipath usage. The 
impact on different classes of applications will be considered and 
documented. An extended API will be defined to allow applications to 
express particular preferences for how MPTCP operates, and to get 
additional information about MPTCP-specific run-time events. 

The WG will carefully analyze and address in the appropriate protocol 
documents all new security threats introduced by MPTCP.

The following items will be worked on:

a. An architectural framework for congestion-dependent multipath 
transport protocols. This is an overview document which tracks the 
technical documents, describing how the modular components fit 
together, and will describe the motivations and the general approach 
that should be followed to enable congestion-dependent multipath 
transport. It will also analyze how MPTCP interacts with existing 
infrastructure elements and other address agility mechanisms, such as 
Mobile IP, HIP and SHIM6. The results of any experiment performed 
during the development should also be included or referenced in this 
document. 

b. A security threat analysis for multipath TCP. The ability to change 
the addresses used during a TCP session opens up new types of 
vulnerabilities and attacks. These and their mitigations will be 
documented. 

c. A coupled multipath-aware congestion control algorithm. This 
algorithm is the multipath equivalent of SACK/NewReno congestion 
control. As experience is gathered from implementations of various 
congestion control algorithms, it is expected that the working group 
will be rechartered to pursue additional work in these areas. 

d. Extensions to current TCP to support multi-addressed multipath TCP. 
This covers all on-the-wire changes required to create a two-ended 
MPTCP solution using multiple addresses at one or both ends. It will be 
designed in a modular fashion to allow alternative address management 
schemes to be explored in future. This document will also include a 
basic security model.

e. An application considerations document, presenting the impacts that 
MPTCP may have on applications, such as performance changes, and 
including an extended API describing how applications can exploit 
additional features of multipath transport. While MPTCP needs to be 
usable without any application changes, this API should be an optional 
extension that provides access to multipath information and enables 
control over the usage of multipath. 

Where appropriate, this group is expected to coordinate with, and will 
use input from, the MIF working group to support the use of multiple 
interfaces.

Goals and Milestones:

Mar 2010 - Established WG consensus on the Architecture
Aug 2010 - Submit to IESG architectural guidelines and security threat
           analysis as informational RFC(s)
Mar 2011 - Submit to IESG basic coupled congestion control as an 
           experimental RFC
Mar 2011 - Submit to IESG protocol specification for MPTCP extensions 
           as an experimental RFC
Mar 2011 - Submit to IESG application considerations and API as an 
           informational RFC
Mar 2011 - Recharter or close WG
_______________________________________________
New-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
[e-mail]
https://mailman.mit.edu/mailman/listinfo/secdir