Network Working Group CT. NGUYEN
Internet-Draft M. Park
Intended status: Informational Soongsil University
Expires: June 5, 2021 December 2, 2020
Detecting Malicious Middleboxes In Service Function Chaining
draft-park-sfc-malicious-middlebox-00
Abstract
This document addresses problems caused by malicious middleboxes and
proposes a scheme that can detect them in Service Function Chaining
(SFC) by combining two mechanisms: direct and indirect. The direct
mechanism injects a tool into the middleboxes to observe and report
the state of each middlebox. In contrast, the indirect mechanism
creates a probe service chain, which includes trustful middleboxes,
to investigate the operation of other middleboxes in the network.
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 https://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 June 5, 2021.
Copyright Notice
Copyright (c) 2020 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
(https://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
NGUYEN & Park Expires June 5, 2021 [Page 1]
Internet-Draft malicious_middlebox December 2020
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. Attack Models . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Detection Methods . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Direct Method: Injection of Malicious Detecting Tool . . 4
5.2. Indirect Method: Probe Chain Generation . . . . . . . . . 5
6. Informative References . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Service Function Chaining (SFC) creates on-demand ordered chains of
network services (e.g., the load balancer, firewalls, and network
address translation), and uses the chains to steer the network
traffic to ensure that the network is agile and effective. Service
functions run as middleboxes, which are connected to switches in the
network, and SFC connects these switches to create the required
virtual chains.
Because of the virtual attributes obtained from SDN and NFV, SFC is
prone to encounter various security vulnerabilities, especially
malicious middleboxes. In particular, attackers can modify the
service functions that run on the middlebox or inject malicious code
into the middlebox to perform harmful actions. Malicious middleboxes
can create various attack types that exploit the weaknesses of both
SDN and NFV to disrupt the operation and policy of SFC. With respect
to the SDN, malicious middleboxes can attack the control and data
plane by launching distributed denial-of-service (DDoS) attacks,
abusing computing resources, or incorrectly managing the network
traffic. With respect to the NFV, malicious middleboxes can attack
the infrastructure of other middleboxes, or even user equipment or
the network by injecting malware, spoofing or sniffing data, carrying
out denial-of-service (DoS) attacks, misusing shared resources,
violating the privacy and confidentiality, etc.
Many countermeasures have been proposed to protect the network from
these attacks, by either analyzing the network traffic or by
installing programs in virtual machines (VMs) to collect data
generated by the hardware to discover the attacks. However, in the
SFC environment, these solutions still have limitations and
vulnerabilities because they only focus on a specific type of attacks
NGUYEN & Park Expires June 5, 2021 [Page 2]
Internet-Draft malicious_middlebox December 2020
and their mechanisms can be detected and compromised by attackers.
This document proposes a scheme that can detect malicious middleboxes
in SFC and is able to overcome the limitation of other methods. The
proposed scheme functions by two mechanisms: direct and indirect,
which make it possible to detect attacks launched both from the
inside and outside of middleboxes. The direct mechanism injects a
tool into the middleboxes to observe and report the state of each
middlebox. This tool can discover abnormal action by detecting high
resource consumption processes or determine whether an abnormal
process is installed. On the other hand, the indirect mechanism
creates a probe service chain, which includes trustful middleboxes,
to investigate the operation of other middleboxes in the network.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Attack Models
In a network, a middlebox is typically created with a fresh operating
system and service functions, except when the middlebox is created
from a malicious image. To perform attacks, attackers either need to
compromise the normal service functions or inject malicious programs
into middleboxes. The malicious middleboxes then acquire the ability
to drop received packets, duplicate them to place additional burden
on the next-hop middlebox (packet dropping, multiplying attack) or
forward packets incorrectly to other middleboxes or even to attackers
(eavesdropping, man-in-the-middle attacks). Furthermore, malicious
middleboxes can run redundant processes, which abuses the resources
of the middlebox and affects the operation of other service functions
inside the middlebox. This document focused on solving the following
attack situations: packet dropping, multiplying, eavesdropping, man-
in-the-middle, and resource abusing attacks as shown in Figure 1. We
assume that controllers, switches, and the connections between them
are trustful. Attackers who succeed in gaining access to controllers
or switches could exploit the network information and destroy all the
detection and prevention mechanisms.
NGUYEN & Park Expires June 5, 2021 [Page 3]
Internet-Draft malicious_middlebox December 2020
+--------+ 50% +-----------+ +--------+ 200% +-----------+
| switch |<-------| malicious | | switch |<-------| malicious |
| |------->| middlebox | | |------->| middlebox |
+--------+ 100% +-----------+ +--------+ 100% +-----------+
(a) Packet dropping attack (b) Packet multiplying attack
+----------+ +----------------------------------+
| attacker |<------+ | +-----------+ +---------+ |
+----------+ | | | malicious |-+ | normal | |
| | | | program | |-+ | service | |
+--------+ | +-----------+ | +-----------+ | | | function| |
| switch |<--+ | malicious | | +------------+ | +---------+ |
| |------->| middlebox | | +-------------+ |
+--------+ +-----------+ +----------------------------------+
(c) Eavesdropping, (d) Packet multiplying attack
man-in-the-middle attack
Figure 1: Attack Models
4. Methodology
Our proposed scheme creates and injects a malicious tracking tool
into middleboxes to detect the attacks. By tracking the device
information (the number of processes, CPU and memory usage of each
process, network traffic on a network interface, etc.), the tool can
detect the above types of attacks. It contains the following three
components: (1) Resource Observation Module tracks the number of
processes and resources consumed by each process and sends the
results to the Analyzing Module.; (2) Packet Observation Module
tracks the network traffic on network interfaces (the number of
packets entering and exiting, transmission latency, etc.) and sends
the results to the Analyzing Module.; (3) Analyzing Module, which is
based on the tracking results from other modules, decides and raises
alarms to the controller about any irregularities in the operation of
middleboxes.
5. Detection Methods
5.1. Direct Method: Injection of Malicious Detecting Tool
As mentioned above, a middlebox is normally created or defined with a
fresh operating system. If attackers were to modify the service
function or inject malicious programs into middleboxes to perform
attacks, this action could leave a trace. For example, if an
abnormal process was installed on the middlebox, this process would
consume a significant amount of CPU and memory because of harmful
NGUYEN & Park Expires June 5, 2021 [Page 4]
Internet-Draft malicious_middlebox December 2020
actions (e.g., packet handling or packet forwarding), which would be
easy to detect by observing the resource usage of the computer. On
the other hand, if the service functions were to be modified to
launch attacks, this action could also be detected by comparing the
typical resource consumption between similar middleboxes. Other
malicious actions could be discovered by observing the network
traffic on network interfaces (e.g., packet dropping or multiplying
attacks). Our proposed method is designed to inject and run the
malicious tracking tool on middleboxes to detect the above-mentioned
types of attacks. To reduce the overhead for middleboxes, we can run
this program either in a random period or run it consecutively to
perform real-time detection. All of the detection results are sent
to the controller.
5.2. Indirect Method: Probe Chain Generation
In the event of our malicious tracking tool being detected and even
compromised to spoof the detecting results, our direct method and
other proposed solutions would not be effective. We therefore
decided to use another approach to solve this problem. We created
two trustful middleboxes and connected them to another middlebox to
form a probe service chain. We also installed a malicious tracking
tool in the trustful middleboxes to observe the network traffic.
This approach entails using the malicious tracking tool to analyze
the network traffic to discover attacks. The trustful middleboxes
are regenerated periodically to prevent the potential protection from
being compromised, and the middlebox under testing is also chosen
randomly.
For example, in a chain including Middlebox_1, Middlebox_x, and
Middlebox_2 in a row, 100 packets are sent from trustful Middlebox_1
to under testing Middlebox_x. These packets are intended to be
processed by the service function inside Middlebox_x and then be
forwarded to next-hop trustful Middlebox_2. After a period, if
$Middlebox_2$ receives only 90 packets (packet dropping attack), or
150 packets (packet multiplying attack), or receives a packet after a
longer time than usual, this may be a man-in-the-middle or an
eavesdropping attack. The detection results are also sent to the
controller.
6. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
NGUYEN & Park Expires June 5, 2021 [Page 5]
Internet-Draft malicious_middlebox December 2020
Appendix A. Acknowledgements
This work was supported by Institute for Information & communications
Technology Promotion(IITP) grant funded by the Korea government(MSIT)
(No.2018-0-00254, SDN security technology development).
Authors' Addresses
Canh Thang Nguyen
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul, Seoul 06978
Republic of Korea
Phone: +82 2 828 7175
EMail: nct@ssu.ac.kr
Minho Park
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul, Seoul 06978
Republic of Korea
Phone: +82 2 828 7175
EMail: mhp@ssu.ac.kr
NGUYEN & Park Expires June 5, 2021 [Page 6]