Subject: [multipathtcp] WG Last call for Multipath TCP API doc

From: <[email-masked]>
Date: Fri, 3 Feb 2012 13:26:36 +0000

This is to announce the WG last call for "MPTCP Application Interface Considerations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03

Since we are WG last calling the protocol doc as well, we will run until the end of Feb (Wed 29th).
Please send comments to the list

The purpose of a WGLC is to provide a final check that the WG has rough consensus to advance the document:
- The WG believes that this document is technically sound
- The WG believes that this document is useful
- The WG believes that this document is ready to go to the IESG

Please reply with positive support, as well as any comments /questions

Thanks
Phil & Yoshifumi

--

Abstract

   Multipath TCP (MPTCP) adds the capability of using multiple paths to
   a regular TCP session.  Even though it is designed to be totally
   backward compatible to applications, the data transport differs
   compared to regular TCP, and there are several additional degrees of
   freedom that applications may wish to exploit.  This document
   summarizes the impact that MPTCP may have on applications, such as
   changes in performance.  Furthermore, it discusses compatibility
   issues of MPTCP in combination with non-MPTCP-aware applications.
   Finally, the document describes a basic application interface for
   MPTCP-aware applications that provides access to multipath address
   information and a level of control equivalent to regular TCP.

---

From: John Leslie <[email-masked]>
Date: Fri, 3 Feb 2012 11:28:22 -0500

[email-masked] <[email-masked]> wrote:
> 
> This is to announce the WG last call for "MPTCP Application Interface
> Considerations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03

] 7. Security Considerations
] 
] Will be added in a later version of this document.

   I don't think this is appropriate.

   It's not that I think a _discussion_ of requirements for some future
API needs much in the way of Security Considerations; but this should
not be punted to "some future version".

] 5.2. Requirements on the Basic MPTCP API
]...
] REQ1: Turn on/off MPTCP: An application should be able to request to
]       turn on or turn off the usage of MPTCP.  This means that an
]       application should be able to explicitly request the use of
]       MPTCP if this is possible.  Applications should also be able
]       to request not to enable MPTCP and to use regular TCP
]       transport instead.  This can be implicit in many cases, since
]       MPTCP must disabled by the use of binding to a specific
]       address.  MPTCP may also be enabled if an application uses a
]       dedicated multipath address family (such as AF_MULTIPATH,
]       [9]).

   I stumbled over this: what should happen if an application _both_
requests to enable MPTCP _and_ to bind to a specific address?

   (I don't care a lot, and it's even OK with me to leave this poorly
defined; but if we have a strong opinion it's better to make it
explicit.)

--
John Leslie <[email-masked]>

---

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 10 Feb 2012 00:17:33 +0100

>    I don't think this is appropriate.

Yes, fully agreed. Sorry for that. I'll submit an update that fixes this
ASAP.

As a starting point, my first draft for that section would be:

<new_section>

This document defines a backward-compatible API for MPTCP-unaware
applications. As the function offered by this interface is equivalent to
existing APIs and doesn't offer additional functionality, the interface
design does not result in new security issues. In general, enabling
MPTCP has some security implications for applications, which are
introduced in Section 3.2.3, and these threads are further detailed in
RFC 6181. The protocol specification of MPTCP [5] defines several
mechanism to protect MPTCP against those attacks.

In addition, the basic MPTCP API for MPTCP-aware applications defines
functions that provide an equivalent level of control and information as
exists for regular TCP. New  functions enable adding and removing local
addresses from an MPTCP connection (TCP_MULTIPATH_ADD and
TCP_MULTIPATH_REMOVE). These functions don't add security threads if the
MPTCP stack verifies whether the addresses provided by the application
are indeed assigned to local interfaces. However, applications should
use the TCP_MULTIPATH_ADD function with care, as new subflows might get
established to those addresses. Furthermore, it could result in some
form of information leakage since MPTCP might advertise those addresses
to the other connection endpoint, which could learn IP addresses of
interfaces that are not visible otherwise.

MPTCP-aware applications should also take care when querying and using
information about the addresses used by subflows
(TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close
subflows, a list of addresses queried once can get outdated during the
lifetime of an MPTCP connection. Then, the list may contain invalid
entries, i. e., addresses that are not used any more or that might not
even be valid. Applications that want to ensure that MPTCP only uses a
certain set of addresses should explicitly bind to those addresses.

</new_section>

Of course, I'd also welcome further suggestions.

>    It's not that I think a _discussion_ of requirements for 
> some future API needs much in the way of Security 
> Considerations; but this should not be punted to "some future 
> version".
> 
> ] 5.2. Requirements on the Basic MPTCP API ]...
>    I stumbled over this: what should happen if an application 
> _both_ requests to enable MPTCP _and_ to bind to a specific address?
> 
>    (I don't care a lot, and it's even OK with me to leave 
> this poorly defined; but if we have a strong opinion it's 
> better to make it
> explicit.)

In that case, the general rule from Section 4.2.1 should apply: "If an
application uses a specific address or binds to a specific interface,
then MPTCP MUST respect this and not interfere in the application's
choices."

In other words, if the application does not explicitly add other local
addresses by TCP_MULTIPATH_ADD, MPTCP must only use this specific local
address. Obviously, if the remote peer has several addresses, several
subflows to those different addresses may be used, since MPTCP is
explicitly enabled.

Given that binding is a legacy function call and thus discussed in
Section 4, I thought that this is clear. If not, we can think of adding
a sentence in Section 5 as well.

Thanks for the feedback!

Michael

---

From: John Leslie <[email-masked]>
Date: Fri, 10 Feb 2012 05:21:41 -0500

SCHARF, Michael <[email-masked]> wrote:
> 
>>> http://tools.ietf.org/html/draft-ietf-mptcp-api-03
>> 
                                                            ^^^^^^^
   did you mean "threats"?

> certain set of addresses should explicitly bind to those addresses.

   WFM

>> better to make it explicit.)
> 

   I merely "stumbled" -- this wasn't obvious to me when I read it.
Presumably if I were implementing, I'd read Section 4 again. As I recall,
I got to Section 5.2 with an impression than "bind to specific address"
_implied_ disabling MPTCP, rather than allowing MPTCP but limiting this
end to the specific address.

   Alas, I have no specific text to offer...

---

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 10 Feb 2012 13:27:39 +0100

> > functions that provide an equivalent level of control and 
> information 
> > as exists for regular TCP. New  functions enable adding and 
> removing 
> > local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and 
> > TCP_MULTIPATH_REMOVE). These functions don't add security 
> threads if 
> > the
>                                                             ^^^^^^^
>    did you mean "threats"?

Yes, this is obviously a spelling error (actually, it occured even more
than once).

Thanks for pointing that out!

Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Feb 2012 12:00:37 -0800

On 2/10/2012 2:21 AM, John Leslie wrote:
> SCHARF, Michael<[email-masked]>  wrote:
>>
>> are indeed assigned to local interfaces.

It's worth noting here that this decision may be impossible, esp. given 
the prevalence of network and host virtualization and remote interface 
support.

It might be useful somewhere here to also remind users that this isn't a 
path separation mechanism; it is an *address* separation one. Addresses 
should be used to assume path differentiation, esp. for security reasons.

Joe

---

From: "SCHARF, Michael" <[email-masked]>
Date: Sun, 12 Feb 2012 12:18:24 +0100

> >> applications. As the function offered by this interface is 
> equivalent 
> >> to existing APIs and doesn't offer additional functionality, the 
> >> interface design does not result in new security issues. 
> In general, 
> >> enabling MPTCP has some security implications for 
> applications, which 
> >> are introduced in Section 3.2.3, and these threads are further 
> >> detailed in RFC 6181. The protocol specification of MPTCP 
> [5] defines 
> >> several mechanism to protect MPTCP against those attacks.
> >>
> >> as exists for regular TCP. New  functions enable adding 
> and removing 
> >> MPTCP stack verifies whether the addresses provided by the 
> >> application are indeed assigned to local interfaces.
> 
> It's worth noting here that this decision may be impossible, 
> esp. given the prevalence of network and host virtualization 
> and remote interface support.

The key point of this sentence is that providing hints for additional
"local" addresses doesn't really result in security issues.

But, right, the term "local interface" might be misleading. One
alternative could be: "These functions don't add security threats if the
MPTCP stack verifies whether the addresses provided by the application
are indeed available as source addresses for subflows."

Does this sort out your concern? A TCP stack can today determine what
addresses it can use as source for TCP connections, and this text
suggests basically the same check.

> It might be useful somewhere here to also remind users that 
> this isn't a path separation mechanism; it is an *address* 
> separation one. Addresses should be used to assume path 
> differentiation, esp. for security reasons.

I don't fully understand how this relates to security considerations.
The basic API only allows to add/remove "local" addresses, which
inherently doesn't provide path control. The interface doesn't enable an
app to ask for a "remote" address to be added to the connection. Do you
have a specific suggestion for a sentence to be added?

Personally, I think that the distinction between "address" and "path"
could instead be discussed in Section 5.1 "Design Considerations". We
could explain there that adding/removing addresses doesn't provide a
path selection mechanism, and that applications cannot assume that using
different addresses indeed result in different path. It may be quite
obvious, but we could explain it just to be on the safe side.

Thanks!

Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Feb 2012 09:22:50 -0800

Hi, Michael,

> suggests basically the same check.

Yes - the point being that 'available as source addresses' isn't the 
same thing as "local interface".

> have a specific suggestion for a sentence to be added?

"Addresses should not be used to assume path differentiation, especially 
for security purposes."

> obvious, but we could explain it just to be on the safe side.

It's not at all obvious; I gave this as a reason this variant has a 
misleading name back in its BOF days. It's multi-address TCP, not multipath.

The longer the inaccurate name persists, the more important it is to 
note the difference *in every place it is relevant*.

Joe

---

From: Scott Brim <[email-masked]>
Date: Mon, 13 Feb 2012 14:19:04 -0500

On Mon, Feb 13, 2012 at 12:22, Joe Touch <[email-masked]> wrote:
> Yes - the point being that 'available as source addresses' isn't the same
> thing as "local interface".

Is there a case where "available as a source address" does not imply
"assigned to a local interface", whether real or virtual?

> "Addresses should not be used to assume path differentiation, especially for
> security purposes."

imho: "Use of different addresses should not be assumed to lead to use
of different paths, especially for security purposes."

> The longer the inaccurate name persists, the more important it is to note
> the difference *in every place it is relevant*.

Since the inaccurate name will last until research brings network
capabilities up to a level where we can match the name :-), I agree.

Scott

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Feb 2012 11:56:50 -0800

On 2/13/2012 11:19 AM, Scott Brim wrote:
> On Mon, Feb 13, 2012 at 12:22, Joe Touch<[email-masked]>  wrote:
>> Hi, Michael,
>>

Sure - where addresses are assigned to multiple interfaces (either 
inside a single machine or on different machines), where addresses are 
deliberately used that are not on the local machine (e.g., "spoofing", 
where legitimate use of spoofing exists inside an organization that owns 
both the box that's spoofing and the IP address), etc.

> of different paths, especially for security purposes."

WFM.

> capabilities up to a level where we can match the name :-), I agree.

Single pairs of addresses can use multiple paths (dynamic routing), and 
different addresses can use the same path. Is this research for, e.g., 
geographic addressing (IPv9?)

Joe

---

From: <[email-masked]>
Date: Thu, 23 Feb 2012 14:36:40 +0000

Thanks for your comments so far on this. just a reminder that we're now in the final week for the WGLC
The comments so far have already been addressed in a slightly revised v-04 on 16th Feb, http://tools.ietf.org/html/draft-ietf-mptcp-api

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 03 February 2012 13:27
To: [email-masked]
Subject: [multipathtcp] WG Last call for Multipath TCP API doc

Thanks
Phil & Yoshifumi

--

Abstract