Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late September

From: <[email-masked]>
Date: Wed, 4 Sep 2013 08:31:19 +0100

Just to let you know. The Security Ads are kindly finding us a security advisor, but no luck yet. So we may have to delay this slightly.
Also, it would be good if there was some discussion on the mailing list before the call.

phil

From: Eardley,PL,Philip,TUB8 R
Sent: 21 August 2013 08:36
To: Eardley,PL,Philip,TUB8 R; [email-masked]
Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Just a reminder, as I know a lot of people have been on holiday, please fill in the doodle

Thanks
phil

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 06 August 2013 13:49
To: [email-masked]<mailto:[email-masked]>
Subject: [multipathtcp] MPTCP interim (audio) meeting on security, late September

We think it would a good idea to have an interim (audio) meeting, in order to make progress on advancing RFC 6824 on the standards track.

We will discuss the security of the MPTCP protocol. The aim is to reach consensus on what security improvements are needed - and what are not needed - in order to progress MPTCP on the Standards track. We hope to cover both the threat(s) that we will handle and, at a high-level, the solutions that will be defined.

Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table

For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if the time is no good for you.

In the meantime, please keep discussing MPTCP's security on the list!

Thanks,
Best wishes
Phil & Yoshifumi

---

From: Edward Lopez <[email-masked]>
Date: Thu, 5 Sep 2013 17:24:54 +0000

Phil,

I'm aware that I am relatively new to the WG and IETF as a whole (IETF 87 Berlin was my first meeting).  But I do have a long history of security and networking protocols, currently working and having worked for a number of security appliance (middlebox) vendors.

My initial review of MPTCP is that I would have to consider it an evasion technique from a content inspection standpoint.  Generally, content inspection engines are designed to operate as either flow-based or transparent-proxy.  A flow-based engine is generally used by IPS systems, but has now expanded to support many types of content inspection, most notably application control functionality of next-generation firewalls (NGFWs).  The limitation of a flow-based engine is that it looks at data in as a stream, generally without reordering and limited data reassembly.   A transparent proxy engine fully buffers and reassembles the data in the context of specific protocols, then inspects this traffic in context.  Transparent proxies are useful when the inspection device has to interact within the protocol, such as in web-filtering solutions where a block message is sent back to an offending user.  However, both of these content inspection engine types have a general model centered around the session paradigm.  an MPTCP session is in effect an aggregate of multiple TCP sessions (sub flows), so in effect has characteristics of a protocol-based application, similar to FTP, VoIP, etc.

The effect of MPTCP on content inspection engines is that it can be used as an evasion technique.  For example, I could envision the use of multi-homed MPTCP-based proxy engines out on the Internet, such that MPTCP based hosts in net repressive countries could evade state-imposed web-filters, or school kids could evade their school system's web-filters, etc.  The initial reaction from content inspectors would be do develop capabilities to detect MPTCP (likely based on options usage), and to either block or force fallback to standard TCP.  A significant concern is that this is where the incentive ends.  MPTCP is an evasion method, so mitigate the vulnerability.

I would prefer to consider how to support MPTCP, perhaps in the form of an application-layer gateway and/or modification of content-inspection engines to deal with aggregation of sub-flows for inspection.  This line of thought lends itself to a philosophical discussion, as to if we intend MPTCP to be used to evade content inspection, or if we are looking to improve the performance of TCP-based applications.  I mention this because it would be desirable for the protocol to assist, or at least not hinder, the ability to identify the multiple sub-flows that create an MPTCP session.

Eventually, I see the rise of middleboxes as MPTCP proxies, whether they are TCP-to-MPTCP or MPTCP-to-MPTCP, perhaps analogous with the methodologies of SSL inspection today.  I am interested in these use-cases because without them, the default will be to block/fallback, which ultimately isn't useful relative to MPTCP.

My US $.02
Ed Lopez

On Sep 4, 2013, at 3:31 AM, [email-masked]<mailto:[email-masked]> wrote:

phil

From: Eardley,PL,Philip,TUB8 R
Sent: 21 August 2013 08:36
To: Eardley,PL,Philip,TUB8 R; [email-masked]<mailto:[email-masked]>
Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security, late September

Thanks
phil

In the meantime, please keep discussing MPTCP’s security on the list!

Thanks,
Best wishes
Phil & Yoshifumi
_______________________________________________
multipathtcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/multipathtcp

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Scott Brim <[email-masked]>
Date: Sun, 8 Sep 2013 07:13:28 -0400

It doesn't look like anyone replied to this.  Yes there's an issue with
multipathing and IPS. But rather than isolate MPTCP to a single
interconnection point, why not get IPSs to coordinate with each other? That
way you're opening the door to the future instead of trapping the Internet
in the past.
On Sep 5, 2013 1:25 PM, "Edward Lopez" <[email-masked]> wrote:

>  Phil,
>
>  I'm aware that I am relatively new to the WG and IETF as a whole (IETF
> 87 Berlin was my first meeting).  But I do have a long history of security
> and networking protocols, currently working and having worked for a number
> of security appliance (middlebox) vendors.
>
>  My initial review of MPTCP is that I would have to consider it an
> evasion technique from a content inspection standpoint.  Generally, content
> inspection engines are designed to operate as either flow-based or
> transparent-proxy.  A flow-based engine is generally used by IPS systems,
> but has now expanded to support many types of content inspection, most
> notably application control functionality of next-generation firewalls
> (NGFWs).  The limitation of a flow-based engine is that it looks at data in
> as a stream, generally without reordering and limited data reassembly.   A
> transparent proxy engine fully buffers and reassembles the data in the
> context of specific protocols, then inspects this traffic in context.
>  Transparent proxies are useful when the inspection device has to interact
> within the protocol, such as in web-filtering solutions where a block
> message is sent back to an offending user.  However, both of these content
> inspection engine types have a general model centered around the session
> paradigm.  an MPTCP session is in effect an aggregate of multiple TCP
> sessions (sub flows), so in effect has characteristics of a protocol-based
> application, similar to FTP, VoIP, etc.
>
>  The effect of MPTCP on content inspection engines is that it can be used
> as an evasion technique.  For example, I could envision the use of
> multi-homed MPTCP-based proxy engines out on the Internet, such that MPTCP
> based hosts in net repressive countries could evade state-imposed
> web-filters, or school kids could evade their school system's web-filters,
> etc.  The initial reaction from content inspectors would be do develop
> capabilities to detect MPTCP (likely based on options usage), and to either
> block or force fallback to standard TCP.  A significant concern is that
> this is where the incentive ends.  MPTCP is an evasion method, so mitigate
> the vulnerability.
>
>   I would prefer to consider how to support MPTCP, perhaps in the form of
> an application-layer gateway and/or modification of content-inspection
> engines to deal with aggregation of sub-flows for inspection.  This line of
> thought lends itself to a philosophical discussion, as to if we intend
> MPTCP to be used to evade content inspection, or if we are looking to
> improve the performance of TCP-based applications.  I mention this because
> it would be desirable for the protocol to assist, or at least not hinder,
> the ability to identify the multiple sub-flows that create an MPTCP session.
>
>  Eventually, I see the rise of middleboxes as MPTCP proxies, whether they
> are TCP-to-MPTCP or MPTCP-to-MPTCP, perhaps analogous with the
> methodologies of SSL inspection today.  I am interested in these use-cases
> because without them, the default will be to block/fallback, which
> ultimately isn't useful relative to MPTCP.
>
>  My US $.02
>  Ed Lopez
>
>  On Sep 4, 2013, at 3:31 AM, [email-masked] wrote:
>
>   Just to let you know. The Security Ads are kindly finding us a security
> advisor, but no luck yet. So we may have to delay this slightly.****
>  Also, it would be good if there was some discussion on the mailing list
> before the call.****
>
>  phil****
>
>   *From:* Eardley,PL,Philip,TUB8 R
> *Sent:* 21 August 2013 08:36
> *To:* Eardley,PL,Philip,TUB8 R; [email-masked]
> *Subject:* RE: [multipathtcp] MPTCP interim (audio) meeting on security,
> late September****
>   ** **
>  Just a reminder, as I know a lot of people have been on holiday, please
> fill in the doodle****
>
>  Thanks****
>  phil****
>
>   *From:* [email-masked] [
> mailto:[email-masked] <[email-masked]>] *On
> Behalf Of [email-masked]
> *Sent:* 06 August 2013 13:49
> *To:* [email-masked]
> *Subject:* [multipathtcp] MPTCP interim (audio) meeting on security, late
> September****
>   ** **
>  We think it would a good idea to have an interim (audio) meeting, in
> order to make progress on advancing RFC 6824 on the standards track.****
>
>  We will discuss the security of the MPTCP protocol. The aim is to reach
> consensus on what security improvements are needed - and what are not
> needed - in order to progress MPTCP on the Standards track. We hope to
> cover both the threat(s) that we will handle and, at a high-level, the
> solutions that will be defined.****
>
>  Please fill in the doodle at http://doodle.com/xdf8eaiavvna9bcy#table****
>
>  For previous MPTCP WG interims, ~3pm GMT has been OK. Please shout if
> the time is no good for you.****
>
>  In the meantime, please keep discussing MPTCP’s security on the list!****
>
>  Thanks,****
>  Best wishes****
>  Phil & Yoshifumi****
> [email-masked]
> *
> ------------------------------
> *** Please note that this message and any attachments may contain
> confidential and proprietary material and information and are intended only
> for the use of the intended recipient(s). If you are not the intended
> recipient, you are hereby notified that any review, use, disclosure,
> dissemination, distribution or copying of this message and any attachments
> is strictly prohibited. If you have received this email in error, please
> immediately notify the sender and destroy this e-mail and any attachments
> and all copies, whether electronic or printed. Please also note that any
> views, opinions, conclusions or commitments expressed in this message are
> those of the individual sender and do not necessarily reflect the views of
> Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
> only a writing manually signed by Fortinet's General Counsel can be a
> binding commitment of Fortinet to Fortinet's customers or partners. Thank
> you. ***
> ------------------------------
> *
>
> [email-masked]

---

From: Edward Lopez <[email-masked]>
Date: Sun, 8 Sep 2013 15:22:08 +0000

It's exceedingly difficult to sync memory buffer states at anything other than short distances if at all, and still have an IPS perform in-line protection.  However, I will concede the possibility for IDS (just detection) to possibly do this.

This is not just a technical issue, but rather a compliance/political one.  Consider PCI, HIPPA, etc. which mandate the use of IPS.  It is inevitable that IPS systems will learn to detect and mitigate MPTCP, just as it is that third-party MPTCP proxies will be built solely to evade content filters.  I for one would hate to see MPTCP relegated to intradomain use, because we failed to foresee the perceived security issues.

Ed Lopez

Sent from my iPhone ... Sorry for any auto-correct errors

On Sep 8, 2013, at 7:13 AM, "Scott Brim" <[email-masked]<mailto:[email-masked]>> wrote:

It doesn't look like anyone replied to this.  Yes there's an issue with multipathing and IPS. But rather than isolate MPTCP to a single interconnection point, why not get IPSs to coordinate with each other? That way you're opening the door to the future instead of trapping the Internet in the past.

On Sep 5, 2013 1:25 PM, "Edward Lopez" <[email-masked]<mailto:[email-masked]>> wrote:
Phil,

My US $.02
Ed Lopez

phil

Thanks
phil

Thanks,
Best wishes
Phil & Yoshifumi

________________________________
*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
________________________________

---

From: Scott Brim <[email-masked]>
Date: Sun, 8 Sep 2013 14:17:07 -0400

I look forward to the interim call.
On Sep 8, 2013 11:22 AM, "Edward Lopez" <[email-masked]> wrote:

>  It's exceedingly difficult to sync memory buffer states at anything
> other than short distances if at all, and still have an IPS perform in-line
> protection.  However, I will concede the possibility for IDS (just
> detection) to possibly do this.
>
>  This is not just a technical issue, but rather a compliance/political
> one.  Consider PCI, HIPPA, etc. which mandate the use of IPS.  It is
> inevitable that IPS systems will learn to detect and mitigate MPTCP, just
> as it is that third-party MPTCP proxies will be built solely to evade
> content filters.  I for one would hate to see MPTCP relegated to
> intradomain use, because we failed to foresee the perceived security issues.
>
> Ed Lopez
>
> On Sep 8, 2013, at 7:13 AM, "Scott Brim" <[email-masked]> wrote:
>
>>  The effect of MPTCP on content inspection engines is that it can be
>> used as an evasion technique.  For example, I could envision the use of
>>   I would prefer to consider how to support MPTCP, perhaps in the form
>> of an application-layer gateway and/or modification of content-inspection
>>  Eventually, I see the rise of middleboxes as MPTCP proxies, whether
>> they are TCP-to-MPTCP or MPTCP-to-MPTCP, perhaps analogous with the
>>   Just to let you know. The Security Ads are kindly finding us a
>> security advisor, but no luck yet. So we may have to delay this slightly.
>> ****
>> *Subject:* [multipathtcp] MPTCP interim (audio) meeting on security,
>> late September****
>>   ** **

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 8 Sep 2013 14:57:12 -0700

Hi Edward,

I'm trying to understand evasion scenarios since you have raised
interesting points.
In my understanding, it will be something like this.

case 1: There're two networks (say ISP1, ISP2) at the server side.
            ISP1 enforces IPS, but ISP2 doesn't.
            In this case, MPTCP can establish initial subflow through ISP1,
but all contents can go through other subflows through ISP2. So, the
traffic of this connection can evade IPS at ISP1

case 2: There're two networks (say ISP1, ISP2) at the server side.
           Both ISP1, ISP2 enforce IPS,
           In this case, MPTCP can split the contents into small chunks and
distributes them through multiple subflows.
           So, IPSs cannot perform inspection properly.

case 3: similar to case2, but use only one ISP.

Are those closed to what you mentioned? Or, am I thinking about totally
different things?
Please correct me if I miss something.

Thanks,
--
Yoshifumi

On Thu, Sep 5, 2013 at 10:24 AM, Edward Lopez <[email-masked]> wrote:
> Phil,
>
> I'm aware that I am relatively new to the WG and IETF as a whole (IETF 87
> Berlin was my first meeting).  But I do have a long history of security
and
> networking protocols, currently working and having worked for a number of
> security appliance (middlebox) vendors.
>
> My initial review of MPTCP is that I would have to consider it an evasion
> technique from a content inspection standpoint.  Generally, content
as
> an evasion technique.  For example, I could envision the use of
multi-homed
> MPTCP-based proxy engines out on the Internet, such that MPTCP based hosts
> in net repressive countries could evade state-imposed web-filters, or
school
> kids could evade their school system's web-filters, etc.  The initial
> reaction from content inspectors would be do develop capabilities to
detect
> MPTCP (likely based on options usage), and to either block or force
fallback
> to standard TCP.  A significant concern is that this is where the
incentive
> ends.  MPTCP is an evasion method, so mitigate the vulnerability.
>
> I would prefer to consider how to support MPTCP, perhaps in the form of an
> application-layer gateway and/or modification of content-inspection
engines
> to deal with aggregation of sub-flows for inspection.  This line of
thought
> lends itself to a philosophical discussion, as to if we intend MPTCP to be
> used to evade content inspection, or if we are looking to improve the
> performance of TCP-based applications.  I mention this because it would be
> desirable for the protocol to assist, or at least not hinder, the ability
to
> identify the multiple sub-flows that create an MPTCP session.
>
are
> TCP-to-MPTCP or MPTCP-to-MPTCP, perhaps analogous with the methodologies
of
> SSL inspection today.  I am interested in these use-cases because without
> them, the default will be to block/fallback, which ultimately isn't useful
> relative to MPTCP.
>
> My US $.02
> Ed Lopez
>
> advisor, but no luck yet. So we may have to delay this slightly.
> before the call.
> Subject: RE: [multipathtcp] MPTCP interim (audio) meeting on security,
late
> September
fill
> in the doodle
>
> Thanks
> phil
>
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> To: [email-masked]
> We think it would a good idea to have an interim (audio) meeting, in order
> to make progress on advancing RFC 6824 on the standards track.
>
needed
> - in order to progress MPTCP on the Standards track. We hope to cover both
> the threat(s) that we will handle and, at a high-level, the solutions that
> will be defined.
>

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 9 Sep 2013 10:38:43 +0300

Can I ask what such boxes do with TLS connections?
Costin

On 5 Sep 2013, at 20:24, Edward Lopez wrote:

>> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 10 Sep 2013 06:08:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Costin Raiciu
> Sent: Monday, September 09, 2013 1:09 PM
> To: Edward Lopez
> Cc: [email-masked]
> Subject: Re: [multipathtcp] MPTCP interim (audio) meeting on security, late
> September
> 
> Can I ask what such boxes do with TLS connections ?

Firewalls (FW) typically perform the actions with HTTPS connection:

[1] FW only perform L4 inspection of HTTPS traffic -> Such FW should permit MPTCP sub-flows destined to 443.
[2] FW in addition to L4 also inspect the TLS handshake for example validate the certificate etc -> Such FW would block MPTCP sub-flows because of lack of TLS handshake in the sub-flows.
[3] FW act as TLS Proxy -> Such FW may not support MPTCP and hence in the SYN_ACK will not signal any MPTCP capability forcing the MPTCP client to move to regular TCP connection.

-Tiru.

> Berlin was my first meeting).  But I do have a long history of security and
> technique from a content inspection standpoint.  Generally, content inspection
> engines are designed to operate as either flow-based or transparent-proxy.  A
> flow-based engine is generally used by IPS systems, but has now expanded to
> support many types of content inspection, most notably application control
> functionality of next-generation firewalls (NGFWs).  The limitation of a flow-
> based engine is that it looks at data in as a stream, generally without
> reordering and limited data reassembly.   A transparent proxy engine fully
> buffers and reassembles the data in the context of specific protocols, then
> inspects this traffic in context.  Transparent proxies are useful when the
> inspection device has to interact within the protocol, such as in web-
> filtering solutions where a block message is sent back to an offending user.
> However, both of these content inspection engine types have a general model
> centered around the session paradigm.  an MPTCP session is in effect an
> aggregate of multiple TCP sessions (sub flows), so in effect has
> characteristics of a protocol-based application, similar to FTP, VoIP, etc.
> >
> > The effect of MPTCP on content inspection engines is that it can be used as
> an evasion technique.  For example, I could envision the use of multi-homed
> MPTCP-based proxy engines out on the Internet, such that MPTCP based hosts in
> net repressive countries could evade state-imposed web-filters, or school kids
> could evade their school system's web-filters, etc.  The initial reaction from
> content inspectors would be do develop capabilities to detect MPTCP (likely
> based on options usage), and to either block or force fallback to standard
> TCP.  A significant concern is that this is where the incentive ends.  MPTCP
> is an evasion method, so mitigate the vulnerability.
> >
> application-layer gateway and/or modification of content-inspection engines to
> deal with aggregation of sub-flows for inspection.  This line of thought lends
> itself to a philosophical discussion, as to if we intend MPTCP to be used to
> evade content inspection, or if we are looking to improve the performance of
> TCP-based applications.  I mention this because it would be desirable for the
> protocol to assist, or at least not hinder, the ability to identify the
> multiple sub-flows that create an MPTCP session.
> >
> > Eventually, I see the rise of middleboxes as MPTCP proxies, whether they are
> TCP-to-MPTCP or MPTCP-to-MPTCP, perhaps analogous with the methodologies of
> fill in the doodle
> consensus on what security improvements are needed - and what are not needed -
> in order to progress MPTCP on the Standards track. We hope to cover both the
> threat(s) that we will handle and, at a high-level, the solutions that will be
> defined.
> >>
> dissemination, distribution or copying of this message and any attachments is
> strictly prohibited. If you have received this email in error, please
> immediately notify the sender and destroy this e-mail and any attachments and
> all copies, whether electronic or printed. Please also note that any views,
> opinions, conclusions or commitments expressed in this message are those of
> the individual sender and do not necessarily reflect the views of Fortinet,
> Inc., its affiliates, and emails are not binding on Fortinet and only a
> writing manually signed by Fortinet's General Counsel can be a binding
> commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Edward Lopez <[email-masked]>
Date: Tue, 10 Sep 2013 08:48:32 +0000

This problem exists on either the client or server side, and is based on the fact that content inspection engines deal with traffic from a session-based paradigm.  Since an MPTCP session is really an aggregate of TCP sessions (sub-flows), the inspection engine is not seeing the content in the correct context, and is likely to increase its false-negative rate.

If the inspection engine is a transparent-proxy (such as used in anti-malware and web-filtering), it is buffering and reassembling traffic within its supported protocol types, then looking at the reassembled traffic in context.  But if the content is split over multiple TCP sessions, the proper content reassembly does not take place.

If the inspection engine is a flow-based engine (such as used in intrusion prevention and application control), since the traffic is streaming across separate sessions, the signature (and likely pre-cursor) engines can fail to detect.  Flow-based engines have a better likelihood of detection if the patterns are small, and thus within the bounds of a single packet.  But the actions taken will impact only the sub-flow the pattern was detected on.

The impact on the client or server depends on the actions configured to be taken by the middlebox.  For example, a strict web-filter may block all sub-flows if it cannot properly detect a URL via reassembly within a transparent proxy.

By the way, topology is irrelevant.   Consider the following:

Host A ===== Switch ----- Middlebox A ----- Internet ----- Middlebox B ----- Switch ===== Host B

Even though all traffic is completely routed through both middleboxes, the problem remains.  As I've noted, this is a consequence of the session-based bias of the inspection engine designs.  There will still be up to four subflows (A.1>B.1, A.1>B.2, A.2>B.1, A.2>B.2)

Have there been other multi-session based evasion attempts ... sure.  Many botnets make use of multiple sessions.  However, their pattern of session creation can be detected and blocked.  This is the problem that we face here.  I predict that the initial reaction will be to detect and block MPTCP sessions as an evasion technique.  This is because the pattern of sub-flow creation can be detected, and this does not require modification of the inspection engine designs.  Enlightened firms may try to modify their engine designs to accommodate MPTCP, if it can be done predictably and reliably.

I hope this helps your understanding

Ed Lopez

Sent from my iPad

On Sep 8, 2013, at 6:07 PM, "Yoshifumi Nishida" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Edward,

I'm trying to understand evasion scenarios since you have raised interesting points.
In my understanding, it will be something like this.

case 1: There're two networks (say ISP1, ISP2) at the server side.
            ISP1 enforces IPS, but ISP2 doesn't.
            In this case, MPTCP can establish initial subflow through ISP1, but all contents can go through other subflows through ISP2. So, the traffic of this connection can evade IPS at ISP1

case 2: There're two networks (say ISP1, ISP2) at the server side.
           Both ISP1, ISP2 enforce IPS,
           In this case, MPTCP can split the contents into small chunks and distributes them through multiple subflows.
           So, IPSs cannot perform inspection properly.

Are those closed to what you mentioned? Or, am I thinking about totally different things?
Please correct me if I miss something.

Thanks,
--
Yoshifumi

On Thu, Sep 5, 2013 at 10:24 AM, Edward Lopez <[email-masked]<mailto:[email-masked]>> wrote:
> in net repressive countries could evade state-imposed web-filters, or school
> reaction from content inspectors would be do develop capabilities to detect
> MPTCP (likely based on options usage), and to either block or force fallback
> to standard TCP.  A significant concern is that this is where the incentive
> application-layer gateway and/or modification of content-inspection engines
> to deal with aggregation of sub-flows for inspection.  This line of thought
> desirable for the protocol to assist, or at least not hinder, the ability to
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> On Behalf Of [email-masked]<mailto:[email-masked]>
> consensus on what security improvements are needed - and what are not needed

---

From: Edward Lopez <[email-masked]>
Date: Tue, 10 Sep 2013 08:57:26 +0000

Generally there are two functions relative to TLS ... offload (server) and intercept (client).

For TLS offload, the middlebox is provided with the certificates of the server(s) it will protect.  TLS sessions are terminated on the middlebox, inspected, and forwarded to the server (optionally put into another TLS session between the middlebox and the server)

For TLS intercept, the middlebox generally performs a proxy function, and has a certificate that is accepted by the hosts it is inspecting (or the client otherwise receives a bad certificate warning).  The TLS sessions from the host are terminated on the middlebox, which in turn inspects this traffic, and repackages it into a new TLS session to its intended recipient.

In either case, once the traffic is decrypted, a whole range of content inspection functions can be performed on the traffic.

Ed Lopez

Sent from my iPad

---

From: Anumita Biswas <[email-masked]>
Date: Fri, 13 Sep 2013 11:52:38 -0700

Hi,

> Have there been other multi-session based evasion attempts ... sure.  Many botnets make use of multiple sessions.  However, their pattern of session creation can be detected and blocked.  This is t…

Completely agree. Also, this could be viewed largely as an administrative/configuration policy. If an inspection engine does not support MPTCP and must inspect all data in a particular stream that could potentially get split over multiple TCP connections, then the engine must strip MPTCP options. This allows MPTCP to seamlessly fall back to TCP. Yes the benefits of MPTCP are lost, but certainly noone wants to see MPTCP used as an evasion technique.

Going forward, deep packet inspection engine designs must accommodate MPTCP so as to enable the e2e benefits of MPTCP. There are potentially several uses of MPTCP and it would be nice to not have them undermined by equally critical middlebox functionality. 

So as to allow MPTCP to work with middleboxes that do SSL termination, these middleboxes must also support MPTCP.

Cheers,
Anumita

On Sep 10, 2013, at 1:48 AM, Edward Lopez <[email-masked]> wrote:

> On Sep 8, 2013, at 6:07 PM, "Yoshifumi Nishida" <[email-masked]> wrote:
> 
>> Hi Edward,
>>