Internet DRAFT - draft-jiang-nmlrg-traffic-machine-learning
draft-jiang-nmlrg-traffic-machine-learning
Network Machine Learning Research Group S. Jiang, Ed.
Internet-Draft B. Liu
Intended status: Informational Huawei Technologies Co., Ltd
Expires: December 5, 2016 P. Demestichas
University of Piraeus
J. Francois
Inria
G. M. Moura
SIDN Labs
P. Barlet
Network Polygraph
June 3, 2016
Use Cases of Applying Machine Learning Mechanism with Network Traffic
draft-jiang-nmlrg-traffic-machine-learning-00
Abstract
This document introduces a set of use cases in which machine learning
technologies are applied to network traffic relevant activities,
including machine learning based traffic classification, traffic
management, etc.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Jiang, et al. Expires December 5, 2016 [Page 1]
Internet-Draft Network Machine Learning June 2016
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Methodology of Learning from Traffic . . . . . . . . . . . . 4
3.1. Data of the Network Traffic . . . . . . . . . . . . . . . 4
3.2. Data Source and Storage . . . . . . . . . . . . . . . . . 5
3.3. Architecture Considerations . . . . . . . . . . . . . . . 5
3.4. Closed Control Loop . . . . . . . . . . . . . . . . . . . 6
4. Use Cases Study of Applying Machine Learning in Network . . . 6
4.1. HTTPS Traffic Classification . . . . . . . . . . . . . . 6
4.2. Malicious Domains: Automatic Detection with DNS Traffic
Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Machine-learning based Policy Derivation and Evaluation
in Broadband Networks . . . . . . . . . . . . . . . . . . 10
4.4. Traffic Anomaly Detection in the Router . . . . . . . . . 11
4.5. Applications of Machine Learning to Flow Monitoring . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 16
9. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Machine learning technology has been successful in solving
complicated issues. It helps to make predictions or decisions based
on large datasets. It could also dynamically adapt to varying
situations and response to real-time issues. Therefore, more and
more research starts on applying machine learning in the network
area.
Among many aspects of networks, the network traffic is one of the
most complicated managed objectives. Its volume is rapidly growing
along with the Internet explosion. It is always dynamically
changing. Most network traffic flows only last a few minutes, or
even shorter. And the user contents within traffic is becoming more
diverse due to the development of various network services, and
increasing use of encryption. Consequently, it is more and more
Jiang, et al. Expires December 5, 2016 [Page 2]
Internet-Draft Network Machine Learning June 2016
challenging for administrators to get aware of the network's running
status and efficiently manage the network traffic flows. Although
more and more data regarding network traffics are generated,
traditional mechanisms based on pre-designed network traffic patterns
become less and less efficient.
It is natural to utilize powerful machine learning technology to
analyze the large mount of data regarding network traffic, to
understand the network's status, such as performance, failures,
security, etc. It is a big advantage that machines can measure and
analyse the network traffic, then report the results and predictions
to humans for further decision. The machines could handle vast
amounts of data which is almost impossible for humans to deal with,
in close to real time. Even more, if the speed and accuracy of the
prediction is high enough, it is possible that the subsequent action
based on the prediction result could form a closed control loop to
achieve autonomic management. However, the maturity of latter might
be far in the future. Today, the traditional control programs still
look more reliable than machine learning based control mechanisms.
This document firstly analyzes the data of the network traffic from
various perspectives; and also discusses several important practical
considerations, including the training data source, data storage and
the learning system architecture. It then introduce a set of use
cases, which have been shown to work well although there is large
scope for improvements, including ML-based traffic classification,
traffic management, interface failure prediction, etc.
Editor notice: this document is in the primary stage. It collects
the use cases presented in the proposed Network Machine Learning
Research Group (NMLRG) session in IETF95 meeting.
2. Terminology
The terminology defined in this document.
Machine Learning A computational mechanism that analyzes and learns
from data input, either historic data or real-time feedback data,
following a set of designed features and algorithms. It can be
used to make analysis, predictions or decisions, rather than
following strictly static program instructions.
Network Traffic The amount of data moving across a network at a
given point of time. They are mostly encapsulated in network
packets.
Traffic Flow A sequence of packets from a source computer to a
destination [RFC6437]. It is the unit of network traffic.
Jiang, et al. Expires December 5, 2016 [Page 3]
Internet-Draft Network Machine Learning June 2016
Feature (machine learning) In machine learning and pattern
recognition, a feature is an individual measurable property of a
phenomenon being observed. Choosing informative, discriminating
and independent features is a crucial step for effective
algorithms in pattern recognition, classification and regression.
Algorithm (machine learning) Machine learning algorithms operate by
building a model from example inputs in order to make data-driven
predictions or decisions expressed as outputs, rather than
following strictly static program instructions. A incomplete list
of machine learning algorithms includes supervised learning,
unsupervised learning, semi-supervised learning, reinforcement
learning, deep learning, etc.
3. Methodology of Learning from Traffic
3.1. Data of the Network Traffic
There is plenty of valuable data related to the network traffic.
These data are raw features in learning process. Following is a
simple classification of network traffic data.
Measurable properties There are many measurable properties of
network traffic, such as latency, number of packets, duration,
etc. These properties are also very essential features,
especially for use cases relevant to performance, QoS (Quality of
Service), etc.
Data within communication protocols The user contents are
encapsulated in layered communication protocols. Many information
are contained within the protocol headers, for example the source
and destination IP addresses in the IP header, the port numbers in
the TCP/UDP header, etc. Transport layer protocols are often
related to the type of applications, such as FTP (File Transfer
Protocol) for file transfer, HTTP (Hyper Text Transfer Protocol)
for web, etc; and many application-relevant data are embedded
within these protocols. These could also be essential data for
classification or application-oriented analysis. However, some
traffic will not provide transport or application information, due
to unknown protocols or encryption.
User content User contents are the payload of packets, which might
be obtained by DPI (Deep Packet Inspection) within the transit
network if the packets are unencrypted, or they could be analyzed
by the source or destination nodes.
Data in network signaling protocols Traffic flows are managed or
indirectly influenced by various network signaling protocols. For
Jiang, et al. Expires December 5, 2016 [Page 4]
Internet-Draft Network Machine Learning June 2016
example, the routing protocols determine the next hop of a
specific network traffic flow, or even the traffic path (by some
sophisticated routing protocol such as MPLS-TE (Multi-Protocol
Label Switching - Traffic Engineering), segment routing, etc.);
the P2P (Peer to Peer) protocol can even decide the destination of
a specific content traffic. They are relevant and are potential
features for traffic analysis. Furthermore, the traffic of these
signaling protocols themselves may also be learning objectives.
3.2. Data Source and Storage
Within networks, forwarding devices such as routers, switches,
firewalls, etc., are the entities that directly handle the network
traffic. Thus, they could collect network traffic data, such as
measurable properties, protocol information, etc. Source nodes or
destination nodes, particularly servers, could also be the source of
network traffic data. They could either report the collected data to
a central repository for storage and learning, or collect and store
the data by themselves for local learning. This depends on the
learning architecture, which is discussed in the following section.
3.3. Architecture Considerations
Global learning vs. local learning
* Global learning refers to the tasks that are mostly network-
level, so that they need to be done in a global viewpoint. In
this case, the learning entity is normally centralized and is
different from the data source entities.
* Local learning is more applicable to the tasks that are only
relevant to one or a limited group of devices, and they could
be done directly within that one node or that limited group of
nodes. In this case of grouped nodes, the data may also need
to be transited from the data source entity to learning entity.
Offline & online learning
* Co-located mode: training (offline, based on historic data) and
prediction (online, based on real-time data) are both done
within the same entity. The entity could be a central
repository or a specific node.
* De-coupled mode: training is done in the central repository,
and prediction is made by the routers/switches/firewalls or
other devices that directly process the network traffic.
Jiang, et al. Expires December 5, 2016 [Page 5]
Internet-Draft Network Machine Learning June 2016
Central learning & distributed learning Central learning means the
learning process is done at a single entity, which is either a
central repository or a node. Distributed learning refer to
ensemble learning that multiple entities do the learning
simultaneously and ensemble the results together to sort out a
final results. Since network devices are naturally distributed,
it could be foreseen that ensemble learning is a good approach for
a certain of use cases.
3.4. Closed Control Loop
The prediction made by machine learning mechanism could be directly
used on manipulating the network traffic, or other relevant actions,
such as changing the device configuration, etc.
However, as the introduction section said, this kind of utilization
might be suitable only for a small set of the use cases, due to the
limited accuracy of machine learning technologies. Besides, some
critical usages simply cannot tolerate any false decision.
4. Use Cases Study of Applying Machine Learning in Network
Editor notes: This section is a collection of the work presented in
the proposed NMLRG session in IETF95 meeting. More contributions on
use cases are welcome.
4.1. HTTPS Traffic Classification
Managing network traffic requires a good understanding of the content
of traffic flows for various purposes. Indeed, enhancing the QoS by
prioritizing or scheduling the flows or enforcing security policies
by filtering some of them cannot solely on rely protocol headers like
IP, TCP or UDP headers. Analyzing the user content with DPI is so
necessary. However, this poses serious concerns regarding the user
privacy. In addition, OTT (Over-the-Top) actors would prefer to
fully control their network traffic rather than being subject to any
intermediaries policies. As a result, encrypting the traffic has
been widely adopted in last years.
In that context, traffic management is facing to severe difficulties
since DPI is not efficient anymore. Using an intermediary service or
proxy are the only ways to analyze the content of encrypted traffic
but it requires a high trustfulness in the intermediaries and so not
always guaranteed, for example with end-users of an operator
networks.
Therefore, new techniques wit the ability to extract knowledge and
insight from encrypted flows is necessary. Especially HTTPS
Jiang, et al. Expires December 5, 2016 [Page 6]
Internet-Draft Network Machine Learning June 2016
[RFC2818] is now a major protocol use over Internet because it
provides secure Web communication while Web is now embracing various
services which have been provided apart in the past: email, video
streaming, chat, VoIP, file sharing, etc. It relies on TLS
(Transport Layer Security) [RFC5246], [RFC6066] to encapsulate HTTP
requests.
Being able to identify the service and the providers of an HTTPS
connection would help in applying different strategies for managing
the corresponding flow. For instance, VoIP (Voice over IP) and email
do not require the same QoS or some service use might be prohibited
like file sharing to avoid data leakage in a company.
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.
Because the objective is to automatically label an HTTPS connection
by the service and service provider associated with. The TLS
handshake is not encrypted but data exchanged during this phase
(random number, selected ciphers,...) is not distinctive of the
accessed service. However, the nature of accessed service directly
impacts on user content transmitted through the secure channel
especially on the type, size and way to transmit those data. Such
metadata are still measurable properties.
Jiang, et al. Expires December 5, 2016 [Page 7]
Internet-Draft Network Machine Learning June 2016
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.
Because different providers may offer a similar service, a single
classifier could fail to to distinguish them. A multi-level machine
learning approach has been proposed. For learning, a dataset without
forged SNI is used (3) to build the classifiers (4). The result is
(5):
o a first level model (L1 model) whose the goal is to identify the
service provider,
Jiang, et al. Expires December 5, 2016 [Page 8]
Internet-Draft Network Machine Learning June 2016
o a set of second level models (L2 models), one for each service
provider to identify specific service of a service provider
Once all classifiers are trained, a new unknown HTTPS connection is
first matched against the LV1 model (3'). The output is the
predicted service provider but also leads to load the corresponding
LV2 model (4') to determine the specific service of this service
provider.
This framework is independent of the ML technique. being used. Each
model could be also built with a different technique but our study
have shown that best results are obtained with Random Forest.
The HTTPS classification framework has been tested over 288,901
connections from lab users. Standard evaluation procedure have been
applied. Less representative features have been automatically
discarded. Using a ten-fold cross-validation, each tested connection
has been marked as perfect identification (both the service provider
and the service name are rightly identified), partial identification
(only the service provider is identified) or invalid (none of them).
93.1% falls in the first category, 2.9% in the second and the rest in
the third. Full results are available in [httpsframework].
Although results are promising, the current method can only be
applied at the end once the HTTPS connection, i.e. after being
reconstructed. This avoids to apply any kind of policies to the
corresponding traffic flow. Future challenge is thus to classify the
connection before it ends in order to apply.
4.2. Malicious Domains: Automatic Detection with DNS Traffic Analysis
Since their inception, domain names have been used to provide a
simple identification label for hosts, services, applications, and
networks on the Internet [RFC1034]. In the same way, domains and the
DNS infrastructure have also been misused in various types of abuses,
such as phishing, spam, malware distribution, among others.
Newly registered malicious domain names are well-know to a very
distinct initial DNS lookup pattern than legitimates ones: typically,
they exhibit an abnormally higher number of lookups [Hao2011]. One
of the reasons is that malicious domains tend to rely upon spam
campaigns within the first ours after the registration of these
domains in order to maximize the number of victims before the domain
is detected and taken down.
In order to protect users from such domains, nDEWS (New Domains Early
Warning System) [Moura2016], a tool that classifies the newly
registered domains based on their initial lookup pattern, has been
Jiang, et al. Expires December 5, 2016 [Page 9]
Internet-Draft Network Machine Learning June 2016
proposed. To perform that, it is required to have access to (i) a
domains registration database and (ii) authoritative DNS server
traffic data, which is typically the case for Top-Level Domains (TLD)
registries. These domains are classified using k-means as a
clustering method into two clusters using four features extracted
from the analyzed DNS traffic: # DNS queries, # IP addresses, #
Autonomous Systems (ASes), and # Countries, which were chosen
empirically.
As a result, in an automated fashion, a large variety of suspicious
domains can be detected, including phishing, malware, but also other
types, such as fake pharmaceutical shops as well as counterfeit
sneakers. In this particular case, the responsible registrars are
notified in this pilot study about these websites. Ultimately, it
allows these websites to be taken down, minimizing the potential
number of victims.
4.3. Machine-learning based Policy Derivation and Evaluation in
Broadband Networks
Service provisioning is becoming more complex. For instance, there
are services having diverse quality requirements, there is variance
of the requirements in time and space, and there is the need for
utmost resource efficiency. Moreover, full agility in time and space
(in order to accomplish resource efficient service provisioning)
requires the solution of computationally intensive tasks. In this
respect, policies can play a role: specify the network behaviour in
time periods and service area regions.
In this direction, machine learning can have a fundamental role,
e.g., for learning situations encountered and "good" ways (policies)
for handling them. The contribution addresses the role that machine
learning can play for policy derivation and evaluation. In more
detail it addresses the requirements on the role of machine learning,
including potential inputs and outputs.
Knowledge and machine learning can be an important aspect of wireless
networks. Knowledge is created both regarding the contexts and their
occurrence, as well as on the association of the context with
specific actions and its scoring. The latter encompasses development
of knowledge on how to handle acquired contexts; this knowledge will
include the contexts encountered, the corresponding handlings done
(decisions applied), the potential alternative handlings, and the
respective efficiency of each handling (actually applied or
alternate).
Reinforcing "good" solutions per each encountered context (e.g.
reinforcement learning) can be a vital and unique element of a
Jiang, et al. Expires December 5, 2016 [Page 10]
Internet-Draft Network Machine Learning June 2016
knowledge-based management system. Machine learning can be realized
through clustering to discover underlying structures in data,
regression to identify patterns and predict values in cell and
network usage, classification to classify first-seen unknown users,
and density estimation to model complex user behavior and network
usage. Several deep architectures and techniques (such as pre-
training) can be utilized, in order to generalize better on complex
data with underlying information and be able to make accurate
predictions, even on unseen data.
As a result, depending on what we want to achieve, the proper machine
learning approach can be used.
Through machine learning it will be possible to provide faster and
targeted solutions to specific network problems. Moreover, it is
possible cluster various usage profiles and prioritize the traffic
according to the criticality level. For instance, mission critical
services need special attention with respect to latency and
prioritization, compared to plain services which may tolerate a bit
of delay without jeopardizing the overall quality. In addition,
machine learning can lead to improved results in KPIs (Key
Performance Indicator) such as end-user throughput, latency, energy
consumption and overall cost effectiveness. Moreover, reliability
can be increased since certain problematic situations may be
predicted before happening, hence it will be possible to act pro-
actively and alleviate the negative impact of a problem in the
network.
It is evident that machine learning can have significant importance
in policy derivation and evaluation in broadband networks, especially
towards in 5G infrastructures which will be complex, heterogeneous
and need to accommodate multi-services ranging from mobile broadband
to massive machine type, mission critical and vehicular
communications.
4.4. Traffic Anomaly Detection in the Router
Modern routers usually have the capability that makes alarms of high
bandwidth usage rate of a specific interface. When network traffic
exceeds a certain threshold, the router will consider it as an
anomaly event and report it to the NMS (Network Management System).
For instance, in some routers/switches, there exists configuration
such as "trap-threshold { input-rate | output-rate }" to trigger
traffic alarms, which is statically configured by experienced
administrators. However, network traffic is usually not static and
even changes significantly due to the changes of carried services,
residential situation, and etc. Thus, static configuration could not
effectively identify the traffic anomaly events.
Jiang, et al. Expires December 5, 2016 [Page 11]
Internet-Draft Network Machine Learning June 2016
To address above issue, machine learning technologies are applied for
routers/switches to learn local traffic pattern and detect the
traffic anomaly events based on the learning results.
Wavelets are employed to analyze time-series network traffic for
anomaly detection. In some certain interval, the routers measure,
record, and analyze the input and output traffic rates respectively,
or in the form of rate sums. (The former is recommended for a finer
granularity analysis.)
Running for some time, the router would get a set of "time-rate"
data, collected as time-series waves for further wavelet analysis.
Besides wavelets, this use case proposes other machine learning
techniques such as outlier detection. For this way, features are to
be extracted from wavelets for supervised or unsupervised learning.
After data collection, the router would sort up the data and figure
out the alarm threshold statistically based on data distribution, to
discriminate the normal and outlier traffic rates. When interface
traffic exceeds the threshold, the router would make alarms to the
NMS. The router could dynamically adjust the alarm threshold with
new coming data, by periodical anomaly analysis. This approach helps
devices detect traffic anomaly more efficiently and effectively,
compared to traditional way of learning at the central repository
that collects traffic information from various devices.
This use case could be extended from single interface to multiple
ones, that is, device scope of multiple traffic waves, and even wider
scope of multiple devices in a certain domain. Thus would make the
analysis more comprehensive.
Besides wavelet analysis, there might be more techniques to explore,
such as correlation analysis of traffic anomaly events among multiple
devices.
4.5. Applications of Machine Learning to Flow Monitoring
A commercial cloud-based flow monitoring service from Network
Polygraph [polygraph] has used Machine Learning analysis as a cost-
effective alternative to DPI for traffic classification, which
identifies the application responsible for each network traffic flow.
Nowadays, DPI is considered as the standard technology for traffic
classification. However, DPI is generally expensive as it requires
the analysis of the payload of every single packet. This usually
involves the use of powerful, specialized hardware appliances, which
need to be deployed in every link to obtain full coverage of the
network. In the case of Network Polygraph, the use of DPI is
Jiang, et al. Expires December 5, 2016 [Page 12]
Internet-Draft Network Machine Learning June 2016
impractical, because the volume of data to be exported to the cloud
would be overwhelming (i.e., all traffic should be replicated). A
more viable alternative is the use flow-based monitoring
technologies, such as NetFlow [RFC3954] or IPFIX [RFC7011], where the
volume of exported data is significantly lower. Flow-based
monitoring technologies provide summarized information (e.g.,
duration, traffic volume) for every connection (or "traffic flow")
handled by a router. The information available in flow records is
more limited compared to DPI (e.g., packet payloads are not
available). As a result, most flow-based monitoring tools base their
classification on the port numbers or simple heuristics, which are
known to be highly unreliable.
To address this problem, Network Polygraph uses a traffic
classification approach based on ML. Several studies showed that
supervised learning can achieve similar classification accuracy to
DPI at a fraction of its cost. However, supervised methods suffer
from some practical limitations that make them very difficult to
deploy and maintain in production environments. For example, they
require a costly training phase prior to its deployment and need to
be frequently retrained, every time there is a change in the network
or in the network applications.
This section describes the ML approach used by Network Polygraph for
online classification of NetFlow/IPFIX traffic. To solve the
practical limitations of supervised learning, Network Polygraph
incorporates an automatic retraining system. Figure 1 shows the
components and data flow of the classification engine, which is
divided in two parts:
o The classification path (Figure 1, top) is in charge of the
classification of the traffic online using ML. The input of the
classification path are the NetFlow/IPFIX flows exported by the
routers, while the output are the classified flows. Several
traffic features are extracted from each flow, including the
information directly available in the flow records (e.g.,
addresses, ports, packet and byte counts) together with some
features we construct (e.g., average packet size, rate and
interarrival time). The traffic features are the input of the
traffic classification algorithm, whose function is to identify
the application that generated the flow. Among the different
supervised algorithms, a C5.0 decision tree was selected, because
it has been shown to present the best accuracy/cost ratio for
traffic classification. Other supervised methods, e.g., Support
Vector Machine (SVM) and Artificial Neural Network (ANN), obtain
similar accuracy, but classification and training times are faster
with decision trees. In Network Polygraph, training times are
Jiang, et al. Expires December 5, 2016 [Page 13]
Internet-Draft Network Machine Learning June 2016
critical as the training path is continuously updating the
classification model in the background.
o The training path (Figure 1, bottom) implements the automatic
retraining system, which is responsible of automatically updating
the classification model when it becomes obsolete. To that end, a
random packet-level sample of the network traffic is continuously
collected using flow-based sampling. Sampled flows are then
labeled using DPI. It is possible to use DPI in the training path
because training can be performed only with a small data sample
(e.g., 1/1000 flows). This significantly reduces the
computational overhead and volume of data to be exported. The
labeled sample is used to verify the accuracy of the
classification model. The system accuracy is estimated by
comparing the output of DPI (training path) and C5.0
(classification path) for those flows sampled in the training
path. If the estimated accuracy falls below a configurable
threshold, the labeled sample is used to generate an updated model
using only those features available in NetFlow/IPFIX (IP Flow
Information Export) records. This training process can also be
performed in few vantage points, and use it for other networks
where only NetFlow/IPFIX monitoring data is available.
CLASSIFICATION PATH
NetFlow/ +----------+ +----------+ Classified
IPFIX | Feature | | C5.0 | flows
+-------->|Extraction+------------------------>|Classifier+----------->
| | | |
+----------+ +----------+
^
|
TRAINING PATH +----------+ +----------+ |
| NetFlow/ | | Feature | | Retraining
+-->| IPFIX +-->|Extraction+--+ |
Packet stream | |Generation| | | | |
(flow sampling) | +----------+ +----------+ | |
+--------------->| +--+ DPI-labeled
| +----------+ | NetFlow/
| | DPI | | IPFIX
+---------->| App. +---------+
| Labeling |
+----------+
Network Polygraph classification engine data flow
Figure 1
Jiang, et al. Expires December 5, 2016 [Page 14]
Internet-Draft Network Machine Learning June 2016
In order to validate the performance of the described ML approach,
the accuracy of Network Polygraph was measured using a complete
14-day trace from the 10-Gigabit link that connects the Catalan
Research and Education Network (Anella Cientifica) to its Spanish
counterpart (RedIRIS). The trace contained about 70 million flows
with a flow sampling rate of 1/400. The experimental results showed
that, with a 96% retraining threshold, the system sustained an
average classification accuracy of 97.5%, needing only 15 retrainings
during the 14 days, which were performed automatically without
requiring any human intervention. When the retraining threshold was
decreased to 94%, the accuracy was slightly reduced to 96.76% with
only 5 retrainings.
The target objective is to progressively reduce the dependence on DPI
technologies, which are expensive, difficult to deploy, not scalable,
and not robust against encryption, in favor of flow-based machine
learning approaches that are more cost-effective and can be easily
offered as a cloud service. In this direction, some research
challenges include the classification of web services and CDN traffic
from flow-based measurements, and the combination of multiple ground
truths obtained from vantage points in different networks.
5. Security Considerations
This document is focused on applying machine learning in network,
including of course applying machine learning in network security, on
higher-layer concepts. Therefore, it does not itself create any new
security issues.
6. IANA Considerations
This memo includes no request to IANA.
7. Acknowledgements
The authors would like to acknowledge Josep Sanjuas, Andreas
Georgakopoulos, Kostas Tsagkaris, Valentin Carela, Wazen M. Shbair,
Thibault Cholez, and Isabelle Chrisment for their contributions.
The author would like to acknowledge the valuable comments made by
participants in the IRTF Network Machine Learning Research Group,
particular thanks to Lars Eggert, Brian Carpenter, Albert Cabellos,
Shufan Ji, Susan Hares, Rudra Saha, and Dacheng Zhang.
Jerome Francois was partly funded by Flamingo, a Network of
Excellence project (ICT-318488) supported by the European Commission
under its 7th Framework Programme.
Jiang, et al. Expires December 5, 2016 [Page 15]
Internet-Draft Network Machine Learning June 2016
This document was produced using the xml2rfc tool [RFC7749].
8. Change log [RFC Editor: Please remove]
draft-jiang-nmlrg-traffic-machine-learning-00: original version,
2016-06-03.
9. Informative References
[bypasssni]
Shbair, W., Cholez, T., Goichot, A., and I. Chrisment,
"Efficiently Bypassing SNI-based HTTPS Filtering", IFIP/
IEEE International Symposium on Integrated Network
Management (IM2015) , 2015.
[Hao2011] Hao, S., Feamster, N., and R. Pandrangi, "Monitoring the
Initial DNS Behavior of Malicious Domains", Proceedings of
the 2011 ACM SIGCOMM Conference on Internet Measurement
Conference (IMC 2011) , Nov 2011.
[httpsframework]
Shbair, W., Cholez, T., Francois, J., and I. Chrisment, "A
Multi-Level Framework to Identify HTTPS Services", IEEE/
IFIP Network Operations and Management Symposium , 2016.
[Moura2016]
M. Moura, G., Mueller, M., Wullink, M., and C. Hesselman,
"nDEWS: a New Domains Early Warning System for TLDs",
IEEE/IFIP International Workshop on Analytics for Network
and Service Management (AnNet 2016), co-located with IEEE/
IFIP Network Operations and Management Symposium (NOMS
2016) , 04 2016.
[polygraph]
"Network Polygraph", <https://polygraph.io>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
<http://www.rfc-editor.org/info/rfc3954>.
Jiang, et al. Expires December 5, 2016 [Page 16]
Internet-Draft Network Machine Learning June 2016
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<http://www.rfc-editor.org/info/rfc7749>.
Authors' Addresses
Sheng Jiang (editor)
Huawei Technologies Co., Ltd
Q 22, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
Bing Liu
Huawei Technologies Co., Ltd
Q 22, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: leo.liubing@huawei.com
Jiang, et al. Expires December 5, 2016 [Page 17]
Internet-Draft Network Machine Learning June 2016
Panagiotis Demestichas
University of Piraeus
Piraeus
Greece
Email: pdemestichas@gmail.com
Jerome Francois
Inria
615 rue du jardin botanique
54600 Villers-les-Nancy
France
Email: jerome.francois@inria.fr
Giovane C. M. Moura
SIDN Labs
Meander 501
Arnhem, 6825 MD
The Netherlands
Email: giovane.moura@sidn.nl
Pere Barlet
Network Polygraph
Edifici K2M - Parc UPC
Jordi Girona, 1-3, Barcelona 08034
Spain
Email: pbarlet@polygraph.io
Jiang, et al. Expires December 5, 2016 [Page 18]
