Re: [Nmlrg] Review for draft-jiang-nmlrg-traffic-machine-learning-00.txt

[Albert Cabellos <[e-mail]>]

Hi Jérôme

Please see inline:

On Sun, Jul 17, 2016 at 11:03 PM, Jérôme François <[e-mail]>
wrote:

> Hi Albert,
>
> 4.1.  HTTPS Traffic Classification
>
>
> [snip]
>
>    As a concrete example, Google, Facebook or Amazon are service
>>    providers while maps, drive, gmail are services of Google.  To
>>    identify them when they are accessed by a user, IP addresses and DNS
>>    (Domain Name System) names based identification is not reliable as
>>    the users can relies on intermediates to respectively serve as proxy
>>    or resolve DNS requests.  The SNI (Server Name Indication) [RFC5246]
>>    is an extension of HTTPS which is indicated by the user when
>>    initiating the TLS handshake (Client Hello).  SNI actually contains
>>    the hostname to which the request is addressed.  Such an hostname is
>>    significative of the service and service provider name.  However, SNI
>>    is an optional field and can be easily forged to circumvent HTTPS
>>    filtering without impacting service use [bypasssni].  More advanced
>>    mechanisms are hence necessary to improve the robustness of
>>    identification even in the case of non collaborative users.
>
>
> I suggest being vendor-agnostic in the examples, the specific examples do
> not improve the draft by any means.
>
> I guess that the examples helps to understand what we mean by service
> provider and service, i.e. to illustrate that having two levels is
> something common nowadays.
>
>
I think that everyone understands this, I suggest to have a vendor-neutral
document.

>
> [snip]
>
>>
>>
>>      HTTPS Connection
>>            +
>>            |(1)
>>    +-------v------+
>>    |TLS Connection|
>>    |Reconstruction|
>>    +-------+------+
>>            |(2)
>>    +-------v------+    (3')                    (4')
>>    |  Features    +-------------+----------------------------+
>>    |  Extraction  |             |                            |
>>    +-------+------+     +-------v---------+             +----v----+
>>            |            |Service Provider +------------->Services |
>>            |(3)         |L1 model         |   Load      |L2 model |
>>            |            +-------^---------+   services  +----^----+
>>    +-------v------+             |             model X        |
>>    |SNI Labelling |             +----------------------------+
>>    +-------+------+                         |(5)
>>            |            +-----------------------------------------+
>>            +------------>              Training and               |
>>                    (4)  |              Models building            |
>>                         +-----------------------------------------+
>>
>>    Two-levels HTTPS traffic classification
>>
>>    In figure above, step(1) consists in reconstructing the HTTPS
>>    connection and retrieving packets on top of which the following
>>    metrics are observed (2):
>>
>>    o  Inter Arrival Time
>>
>>    o  Packet size
>>
>>    o  Encrypted data size: this feature has the advantage to be strongly
>>       related to the service accessed instead of the packet size which
>>       is biased by other lower layer headers
>>
>>    Based on these values, aggregated features are computed: average,
>>    minimum, maximum, 25th percentile, median, 75th percentile.
>>
>>
> Does the authors see value on listing all the traffic features in an ANNEX?
>
> All can be found in the referenced paper and those that contribute to a
> good classification
> are the ones given in the draft. So, as the author, I would say "no".
>
>
Thanks! In any case, can the authors try to put together the features that
they are using and see if there are any common ones? The document should be
-to a reasonable extent- self-contained.

cheers

Albert


> Best regards,
> Jérôme
>