Subject: [multipathtcp] Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 14 Sep 2016 03:47:15 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-mptcp-experience-06: No Objection

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/

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

I was a bit sad that there was no reporting of
experiences with the security aspects of MPTCP.  Have
we really learned nothing worth saying about that?
Have we really seen no attacks on, or tailored to,
MPTCP? It seems odd that the answer to both questions
is "no."

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 14 Sep 2016 17:25:50 +0200

Hi,

actually the answer might be 'no'. But I guess the reason why they don't talk 
about it, is because we don't have any reports here.

Mirja

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Sep 2016 16:34:08 +0100

On 14/09/16 16:25, Mirja Kühlewind wrote:
> Hi,
> 
> actually the answer might be 'no'. But I guess the reason why they don't
> talk about it, is because we don't have any reports here.

Hmm, it seems that scholar at least has some references
to stuff [1]. I've no clue if those're useful or not
though - did anyone go looking? Be a shame to not include
some if they were useful/relevant.

Ta,
S.

[1]
https://scholar.google.com/scholar?as_ylo=2015&q=MPTCP+security&hl=en&as_sdt=0,5

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 14 Sep 2016 17:53:38 +0200

With a very quick look, these seems all to be theoretical analysis while this 
draft is documenting actual deployment experience. Further the first hit here 
is an existing RFC, second hit is theoretical, and third hit is from the main 
authors of this draft which is part of the basis of this draft... so still 
the same answer.

Mirja

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 14 Sep 2016 18:13:07 +0200

Stephen,

There are already two RFC on security issues with MPTCP

https://tools.ietf.org/html/rfc6181
https://tools.ietf.org/html/rfc7430

We did not want to rediscuss those issues that are alreayd documented on 
the security of MPTCP itself.

Another point is the impact of MPTCP on existing IDS, firewalls and 
other types middleboxes that could only see a portion of the traffic. 
There have been blackhat presentations on this, e.g.

https://www.blackhat.com/docs/us-14/materials/us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-Tomorrows-Protocols.pdf

I haven't seen deployment of those attacks, but could extend section 3.5 
or discuss this in a bit more details if you think that this would be 
useful.

Olivier

---

From: Anna Brunstrom <[email-masked]>
Date: Wed, 14 Sep 2016 18:41:44 +0200

Hi Olivier, all,

On 2016-09-14 18:13, Olivier Bonaventure wrote:
> We did not want to rediscuss those issues that are alreayd documented 
> on the security of MPTCP itself.
>

In case it is of interest, there is also some academic work measuring 
and evaluating this in: Z Afzal, S Lindskog, "Multipath TCP IDS Evasion 
and Mitigation", International Information Security Conference, 2015, 
Springer

BR,
Anna

>
> I haven't seen deployment of those attacks, but could extend section 
> 3.5 or discuss this in a bit more details if you think that this would 
> be useful.
>
>
> Olivier
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Sep 2016 17:42:08 +0100

Hiya,

> or discuss this in a bit more details if you think that this would be

If such text would be considered useful in the RFC,
then I'd be for it. I'm happy that the AD/chairs/editors
and WG figure that out. I'm equally happy to review if
someone proposes text.

Cheers,
S.

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 14 Sep 2016 19:54:40 +0200

Hello,

> and WG figure that out. I'm equally happy to review if

Here is a proposed text

5.  Security Considerations

    The security considerations for Multipath TCP have already been
    documented in [RFC6181], [RFC6182], [RFC6824] and [RFC7430].

    From a security viewpoint, it is important to note that Multipath
    TCP, like other multipath solutions such as SCTP, has the ability to
    send packets belonging to a single connection over different paths.
    This design feature of Multipath TCP implies that middleboxes that
    have been deployed on-path assuming that they would observe all the
    packets exchanged for a given connection in both directions may not
    function correctly anymore.  A typical example are firewalls, IDS or
    DPIs deployed in enterprise networks.  Those devices expect to
    observe all the packets from all TCP connections.  With Multipath
    TCP, those middleboxes may not observe anymore all packets since some
    of them may follow a different path.  The two examples below
    illustrate typical deployments of such middleboxes.  The first
    example, Figure 8, shows a Multipath TCP enabled smartphone attached
    to both an enterprise and a cellular network.  If a Multipath TCP
    connection is established by the smartphone towards a server, some of
    the packets sent by the smartphone or the server may be transmitted
    over the cellular network and thus be invisible for the enterprise
    middlebox.

      smartphone +----- entreprise net --- MBox----+------ server
                 |                                 |
                 +----- cellular net  -------------+

       Figure 8: Enteprise Middlebox may not observe all packets from
                               multihomed host

    The second example, Figure 9, shows a possible issue when multiple
    middleboxes are deployed inside a network.  For simplicity, we assume
    that network1 is the default IPv4 path while network2 is the default
    IPv6 path.  A similar issue could occur with per-flow load balancing
    such as ECMP [RFC2992].  With regular TCP, all packets from each
    connection would either pass through Mbox1 or Mbox2.  With Multipath
    TCP, the client can easily establish a subflow over network1 and
    another over network2 and each middlebox would only observe a part of
    the traffic of the end-to-end Multipath TCP connection.

      client ----R-- network1  --- MBox1 -----R------------- server
                 |                            |
                 +-- network2  --- MBox2 -----+

         Figure 9: Interactions between load balancing and security
                                 Middleboxes

    In these two cases, it is possible for an attacker to evade some
    security measures operating on the TCP bytestream and implemented on
    the middleboxes by controlling the bytes that are actually sent over
    each subflow and there are tools that ease those kinds of evasion
    [PZ15] [PT14].  This is not a security issue for Multipath TCP itself
    since Multipath TCP behaves correctly.  However, this demonstrates
    the difficulty of enforcing security policies by relying only on on-
    path middleboxes instead of enforcing them directly on the endpoints.

Olivier