Subject: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Nov 2012 12:30:19 -0500

-------- Original Message --------
Subject: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS
and COMMENT)
Date: Thu, 15 Nov 2012 08:05:25 -0800
From: Sean Turner <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Sean Turner has entered the following ballot position for
draft-ietf-mptcp-api-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) s3.2.*: I'm keying here on the multiple IP bit, so if I'm
misunderstanding something just let me know:

- There's got to be a logging/storage impact based on mptcp?  If servers
were tracking source IP addresses and now instead of one coming from a
client there's two that means at least a double - right?

- There's protocols that include things like IP addresses in the received
from header will it now need to include one for each subflow?

- If certificates are used by an application and the certificates include
an IP address, how many need to be included in the certificate?  Will the
application know how many subflows are going to get started?  It's going
to have know which subflow to give which cert?

2) I echo Stephen's concerns wrt TLS.  TLS explicitly discusses a DoS
attack based on an attacker who initiates a large number of TCP
connections (F.5 of RFC 5246).  Are we now making lots of people
potential attackers?  Should some guidance on the # of connections to
open be given?  Also, isn't this worth a mention in the security
considerations.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) s3.1.1: The throughput assertion isn't always true -right? If you have
one of the two links splitting what would have gone down one link go down
then don't you have less than half the throughput of the original link -
at least until the now combined subflow ramps back up?

2) s3.1.1: Should you also point out that if all the subflows collapse in
to one that the overhead actually lowers the throughput compared to
regular TCP?

3) s3.1.2: Wouldn't there also be a delay with the collapse of a subflow?

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 26 Nov 2012 00:42:57 +0100

Sean,
 
Thanks for your feedback! Please find some comments inline, marked by [MSC].
 
Michael

________________________________________
Von: [email-masked] [[email-masked]] im Auftrag von Wesley Eddy [[email-masked]]
Gesendet: Donnerstag, 15. November 2012 18:30
An: multipathtcp; Sean Turner
Betreff: [multipathtcp] Fwd: Sean Turner's Discuss on draft-ietf-mptcp-api-06: (with DISCUSS and COMMENT)

-------- Original Message --------

[MSC] Valid point. We should mention that logging MPTCP results in differences compared to TCP. Probably this is not only about storage. If a logging wants to keep track of the subflow dynamics, it may even need several log entries per connection. My suggestion would be to add a short paragraph on the logging implications of MPTCP.

[MSC] No, I don't think that an application will have to care of subflows at all. It can always refer to the addresses of the initial subflow and exchange them in an application protocol. This is the most reasonable behavior as of now. If an application uses IP addresses in an application protocol, the key question is whether 'fate-sharing' is required, as explained in the document. This question requires further studies, as also stated in the draft. In a draft revision, we could elaborate a bit more on how the use of IP addresses in applications could interact with MPTCP. But given the potential dynamics of subflows, this can become arbitrarily complex for an app. Thus, my recommendation would be that apps should stay away from that as far as possible.

[MSC] This question has also been raised in a similar way by Stephen (cf. my response there). I currently assume that certificates do hot have to change if the application uses the 'legacy API'. But it is a very valid question and I'd be interested in further insights. If certificates have to change, specifying that seems to be outside the scope of this document. Also, feedback from the MPTCP working group suggested that the basic API should not contain a tight control of subflow management. Without that, an application will not know in advance how many subflows will get started; this is left for further study. In summary, I think that a legacy application will not and does not have to care about these questions. But we probably have to explain more explicitly that MPTCP-aware applications may need changes in the application protocols running on top if they want indeed to handle subflow addresses.

[MSC] I am not sure if I fully understand how that attack works and how it actually relates to MPTCP. In theory, MPTCP allows any number of subflows, but their handling and authentication is handled internally in the MPTCP stack. I think subflows should be transparent to TLS (in legacy mode). For instance, MPTCP should determine itself whether a subflow is valid or not, before TLS crypto gets involved. MPTCP has own internal security features for that, in order to get a security level somehow similar to TCP. If MPTCP uses crypto inside the stack, MPTCP can itself be attacked as described in F.5 of RFC 5246. However, this is independent of the API document, as far as I can tell. Obviously, if TLS had to check whether a certificate exists for each new subflow, this would result in a significant DoS issue. But this in fact yet another reason why TLS might want to stay away from caring about MPTCP internals? 

[MSC] I don't fully understand the scenario. It is clear that in the short-term reaction to a network change the throughput can be worse, depending on how the traffic is split, what the congestion control state is, etc. The short-term dynamics of (MP)TCP are very complex. Furthermore, if the baseline TCP connection runs over the path that breaks, MPTCP will be tremendously better than TCP ;) We could certainly mention dynamics more explicitly, but long-term the text should be correct.

[MSC] Yes, TCP option overhead reduces the throughput for a single subflow compared to a TCP connection. This overhead depends on several paremeters, but it should be small. Actually, this overhead is already explicitly mentioned at the end of section 3.1.1.

[MSC] Again, yes, transport protocol dynamics can result in all kinds of short-term effects. But, imho, the order of magnitude should not be much different to what TCP does from time to time, e. g., if some packets get lost. I think that these sections mainly talk on the macroscopic effects. We could make this more explicit in the next version.

_______________________________________________
multipathtcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: "Alan Ford (alanford)" <[email-masked]>
Date: Mon, 26 Nov 2012 10:35:29 +0000

Some further comments line....

Regards,
Alan

On 25/11/2012 23:42, "Scharf, Michael (Michael)"
<[email-masked]> wrote:
>[MSC] Valid point. We should mention that logging MPTCP results in
>differences compared to TCP. Probably this is not only about storage. If
>a logging wants to keep track of the subflow dynamics, it may even need
>several log entries per connection. My suggestion would be to add a short
>paragraph on the logging implications of MPTCP.
>
>[MSC] No, I don't think that an application will have to care of subflows
>at all. It can always refer to the addresses of the initial subflow and
>exchange them in an application protocol. This is the most reasonable
>behavior as of now. If an application uses IP addresses in an application
>protocol, the key question is whether 'fate-sharing' is required, as
>explained in the document. This question requires further studies, as
>also stated in the draft. In a draft revision, we could elaborate a bit
>more on how the use of IP addresses in applications could interact with
>MPTCP. But given the potential dynamics of subflows, this can become
>arbitrarily complex for an app. Thus, my recommendation would be that
>apps should stay away from that as far as possible.

I think both this and the previous comment are pure application-level
decisions. This document is specifying the API through which the relevant
information can be acquired by an application.

As well as the API content, this document is discussing application
considerations. These are the kinds of things that an application
certainly should consider - we should emphasise some of these fundamental
"your higher layers might need to adapt to the presence of multiple
addresses" in S3.2.2.

>[MSC] This question has also been raised in a similar way by Stephen (cf.
>my response there). I currently assume that certificates do hot have to
>change if the application uses the 'legacy API'. But it is a very valid
>question and I'd be interested in further insights. If certificates have
>to change, specifying that seems to be outside the scope of this
>document. Also, feedback from the MPTCP working group suggested that the
>basic API should not contain a tight control of subflow management.
>Without that, an application will not know in advance how many subflows
>will get started; this is left for further study. In summary, I think
>that a legacy application will not and does not have to care about these
>questions. But we probably have to explain more explicitly that
>MPTCP-aware applications may need changes in the application protocols
>running on top if they want indeed to handle subflow addresses.

And again, this is essentially an application-layer decision.

We are trying to present both a backwards-compatible API (with the same
semantics as TCP) as well as the minimum extensions to acquire the
additional information that provides completeness of the single-path
semantics.

The WG has had many long discussions about assumptions that can be made
about IP addresses, and we reached the decision that once a MPTCP session
is established with one particular IP address, that initial subflow
provides an identity "anchor" for the remote host. If a user/system
administrator does not trust this assumption, then the fate-sharing that
we have mentioned in the document can be used.

The upper layers (in this case, TLS) could use an extended API to find out
additional IP addresses (and this would be a good use of Robert's
suggested "push" API) and do its own analysis of the additional IP
addresses. Maybe some X509 field could allow a certificate to have
multiple IP address aliases listed. This kind of discussion is, however,
out of scope for this API document.

>[MSC] I am not sure if I fully understand how that attack works and how
>it actually relates to MPTCP. In theory, MPTCP allows any number of
>subflows, but their handling and authentication is handled internally in
>the MPTCP stack. I think subflows should be transparent to TLS (in legacy
>mode). For instance, MPTCP should determine itself whether a subflow is
>valid or not, before TLS crypto gets involved. MPTCP has own internal
>security features for that, in order to get a security level somehow
>similar to TCP. If MPTCP uses crypto inside the stack, MPTCP can itself
>be attacked as described in F.5 of RFC 5246. However, this is independent
>of the API document, as far as I can tell. Obviously, if TLS had to check
>whether a certificate exists for each new subflow, this would result in a
>significant DoS issue. But this in fact yet another reason why TLS might
>want to stay away from caring about MPTCP internals?
>
>[MSC] I don't fully understand the scenario. It is clear that in the
>short-term reaction to a network change the throughput can be worse,
>depending on how the traffic is split, what the congestion control state
>is, etc. The short-term dynamics of (MP)TCP are very complex.
>Furthermore, if the baseline TCP connection runs over the path that
>breaks, MPTCP will be tremendously better than TCP ;) We could certainly
>mention dynamics more explicitly, but long-term the text should be
>correct.
>
>[MSC] Yes, TCP option overhead reduces the throughput for a single
>subflow compared to a TCP connection. This overhead depends on several
>paremeters, but it should be small. Actually, this overhead is already
>explicitly mentioned at the end of section 3.1.1.
>
>[MSC] Again, yes, transport protocol dynamics can result in all kinds of
>short-term effects. But, imho, the order of magnitude should not be much
>different to what TCP does from time to time, e. g., if some packets get
>lost. I think that these sections mainly talk on the macroscopic effects.
>We could make this more explicit in the next version.