Internet-Draft malicious_middlebox December 2020
NGUYEN & Park Expires 5 June 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-park-sfc-malicious-middlebox-00
Published:
Intended Status:
Informational
Expires:
Authors:
CT. NGUYEN
Soongsil University
M. Park
Soongsil University

Detecting Malicious Middleboxes In Service Function Chaining

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 5 June 2021.

Table of Contents

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 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.

  +--------+   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 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, , <https://www.rfc-editor.org/rfc/rfc2119>.

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
Minho Park
School of Electronic Engineering
Soongsil University
369, Sangdo-ro, Dongjak-gu
Seoul
Seoul
06978
Republic of Korea