Did anyone already think about how to analyze MPTCP with Argus?

[Carter Bullard]

The real difficult situation is the multiple address support.  But that really isn't much different than finding stepping stones.  The MPTCP TCP options do give you a clue that you normally wouldn't have.

Since all the TCPs that are coupled are all operating at the same time, and generally at the same rate, as you imagine they should be Segment Load Balancing , you can find the ones that are related to each other through clustering / sorting.  And the user data can provide good clues !!!

Argus theoreticlly will not be fooled, and should help.

If the TCP Option reporting doesn't do it, we'll add specific option parsing for MPTCP in 3.1.0.

Carter

> On Jul 31, 2014, at 10:13 AM, el draco <eldraco at gmail.com> wrote:
> 
> Thanks Carter.
> So, we can look at the options to know MPTCP is being used and with
> the user data we may analyze what we can get from all the flows that
> are captured.
> Nice to know argus can deal with it.
> thanks!
> sebas
> 
>> On Thu, Jul 31, 2014 at 4:00 PM, Carter Bullard <carter at qosient.com> wrote:
>> Hey Sebas,
>> Argus will report the existence of all the TCP connections that
>> exist, but it will not indicate that MTCP TCPs are related.
>> 
>> Argus will report the use of the TCP option that is used to
>> negotiate MTCP, so you’ll know that the TCPs are using MTCP,
>> (TCP option kind 30) but you won’t know which ones are
>> bound to which.
>> 
>> So MTCP doesn’t break Argus.
>> 
>> The Argus user data buffers between all the related TCPs will
>> reveal the “stripping” effect that MTCP generates, so you
>> will be able to figure it out, if your capturing user data.
>> 
>> Carter
>> 
>> 
>>> On Jul 31, 2014, at 9:31 AM, el draco <eldraco at gmail.com> wrote:
>>> 
>>> Hi list.
>>> Reading about next weekend BlackHat talk about MultiPath TCP protocols
>>> breaking traffic inspection and trust models, I started wondering if
>>> any of you though about how would Argus deal with this.
>>> 
>>> I don't have any implementation yet, so I can not try it. There should
>>> be a way to detect that MPTCP is at least being used right? If you can
>>> not see the other 'new' flows... maybe you can detect that the
>>> protocol seems to be broken but is not retransmitting? I'm imaging
>>> some type of anomaly detection algorithm may be able to catch this.
>>> 
>>> http://labs.neohapsis.com/2014/07/29/multipath-tcp-blackhat-briefings-teaser/
>>> 
>>> 
>>> See you
>>> sebas
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2443 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20140731/6b38f04b/attachment.bin>