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

From: <[email-masked]>
Date: Mon, 3 Oct 2016 15:36:03 +0000

I didn’t see any more emails in this thread. Stephen, are you happy with the proposed text? 

The proposed text works for me and I think is an interesting point to add - but I'm not sure it directly answers your point (I guess the answer is something like 'No information about MPTCP-tailored attacks' or 'no information that can be shared')

Olivier & authors - is it possible to do a new version of the document please - I think the Discuss and the other comments are quite easy to resolve, and it would be good to publish the document (finally!)

Thanks!
phil

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: 14 September 2016 18:55
To: Stephen Farrell <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Eardley,PL,Philip,TUB8 R <[email-masked]>
Subject: Re: Stephen Farrell's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)

Hello,

>>
>> 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.
>
> 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.

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 3 Oct 2016 16:42:56 +0100

Hiya,

Sorry, didn't think you were waiting on me. My comment
was non-blocking so going ahead as you consider best is
the right thing to do,

Cheers,
S.

On 03/10/16 16:36, [email-masked] wrote:
> The proposed text works for me and I think is an interesting point to
> add - but I'm not sure it directly answers your point (I guess the
> answer is something like 'No information about MPTCP-tailored
> attacks' or 'no information that can be shared')
> 
> Olivier & authors - is it possible to do a new version of the
> document please - I think the Discuss and the other comments are
> quite easy to resolve, and it would be good to publish the document
> (finally!)
> 
> Thanks! phil
> 
> 
> -----Original Message----- From: Olivier Bonaventure
> [mailto:[email-masked]] Sent: 14 September 2016
> 18:55 To: Stephen Farrell <[email-masked]>; The IESG
> <[email-masked]> Cc: [email-masked];
> [email-masked]; [email-masked];
> Eardley,PL,Philip,TUB8 R <[email-masked]> Subject: Re: Stephen
> Farrell's No Objection on draft-ietf-mptcp-experience-06: (with
> COMMENT)
> 
> Hello,
> 
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> 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.
>> 
>>  it. I'm happy that the AD/chairs/editors and WG figure that out.
>> I'm equally happy to review if someone proposes text.
> 
> Here is a proposed text
> 
> TCP, those middleboxes may not observe anymore all packets since
> some of them may follow a different path.  The two examples below 
> 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  -------------+
> 
> 
> 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 -----+
> 
> 
> [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
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 3 Oct 2016 17:43:23 +0200

Phil,

> The proposed text works for me and I think is an interesting point to add - but I'm not sure it directly answers your point (I guess the answer is something like 'No information about MPTCP-tailore…

I haven't seen reports of actual attacks that tageted MPTCP or used 
MPTCP to perform an attack. The closests discussions that I'm aware of 
are the two references that I mentioned in the updated text

    [PT14]     Pearce, C. and P. Thomas, "Multipath TCP Breaking Today's
               Networks with Tomorrow's Protocols", Proc. Blackhat
               Briefings , 2014, <http://www.blackhat.com/docs/us-14/
               materials/
               us-14-Pearce-Multipath-TCP-Breaking-Todays-Networks-With-
               Tomorrows-Protocols-WP.pdf>.

    [PZ15]     Pearce, C. and S. Zeadally, "Ancillary Impacts of
               Multipath TCP on Current and Future Network Security",
               IEEE Internet Computing, vol. 19, no. 5, pp. 58-65 , 2015.

> Olivier & authors - is it possible to do a new version of the document please - I think the Discuss and the other comments are quite easy to resolve, and it would be good to publish the document (f…

We have an updated text but I was expecting comments on this security 
part which is the main change that was requested by the reviewers

Olivier