Moving Target Defense Router: MaTaDoR

Berkan Ufuk

1,2 a

and Mehmet Tahir Sandikkaya

1 b

Computer Engineering Department, Istanbul Technical University, TR34469, Turkey

Aselsan Inc., Ankara, Turkey

Keywords:

Moving Target Defense, TCP-authentication Option, Transparent Routing, Message Authentication, DoS,

Honeynets, Honeypot.

Abstract:

The continuous increase in network attacks and the complexity of the available offensive technologies enforces

novel defensive mechanisms. Moving Target Defense (MTD) is a recent family of approaches for network

defense. This study proposes MaTaDoR, which utilizes message authentication akin to TCP Authentication

Option (TCP-AO) in a MTD setting to mitigate a wide range of attacks, including Denial of Service (DoS). The

purpose of MaTaDoR is averting unauthenticated packets from reaching protected assets. When many other

MTD approaches aim to delay adversaries, MaTaDoR strictly protects networked assets from unauthenticated

access. MaTaDoR is transparent, stateless and scalable. The efﬁciency of this combination is demonstrated

by the results of a simulation. The proposed approach is capable of blocking every DoS packet with an

insigniﬁcant trade-off increase in end-to-end delay.

1 INTRODUCTION

Although there are numerous network defense mech-

anisms, the number of attacks is increasing. New de-

fense mechanisms evolve hand in hand with new at-

tack strategies. Generally, the motivation behind a de-

fense mechanism is to make an attack relatively costly

for an adversary. Moving Target Defense (MTD)

is one of the mechanisms in order to protect a net-

worked service from attacks. MTD aims to confuse

adversary by manipulating network attributes in order

to render attacks infeasible. This study contributes

by proposing eager message authentication for net-

works that utilize MTD. The proposed solution is es-

sentially similar to chafﬁng and winnowing (Rivest

et al., 1998). Host-independent message authentica-

tion chaffs stray TCP connections. TCP Authenti-

cation Option (Touch et al., 2010) has common us-

age in networks linked with Border Gateway Protocol

(BGP). The hypothesis is that considerable amount of

unnecessary requests could be prevented prior to es-

tablishing connections if MTD with an authentication

header (abbreviated as MaTaDoR – Moving Target

Defense Router) is utilized. Selection and elimination

of packets are possible in the beginning of the TCP-

handshake step by inspecting how the SYN packets

are constructed. Therefore, only genuinely message-

https://orcid.org/0000-0002-1416-2866

https://orcid.org/0000-0002-9756-603X

authenticated SYN packets would be apt to be pro-

cessed and other packets would be directed to a decoy

network. The proposed mechanism resides in a trans-

parent box to route the trafﬁc to either the genuine or

the decoy network that have equivalent structure. The

deployment of the proposed mechanism is shown in

Figure 1.

The mechanism is effective against all kinds of

unauthorized access attempts. DoS, where such be-

havior is observed frequently, forms a valid demon-

stration. Therefore, the effectiveness of the hypoth-

esis is shown by simulating the mechanism with re-

generated real-world network trafﬁc which is known

to include DoS attacks.

MaTaDoR is a router, rather than a gateway. It

does not keep the state of the connections that are

passing through so that how the unwanted connec-

tions could be relayed or dropped before handshakes

are completed. Therefore, MaTaDoR itself is resistant

against overﬂows. Since the transparent entry point in

the proposed mechanism acts as a router, it does not

form a single point of failure. Scalability is achieved

by adding or removing MaTaDoR boxes. Central key

management is not necessary as MaTaDoR is state-

less.

The proposed approach is compared with ongoing

research in Section 2. Section 3 sketches a typical use

case of the proposed solution. Re-generation of the

publicly available real-world trafﬁc for the conducted

Ufuk, B. and Sandikkaya, M.

Moving Target Defense Router: MaTaDoR.

DOI: 10.5220/0011306500003283

In Proceedings of the 19th International Conference on Security and Cryptography (SECRYPT 2022), pages 649-654

ISBN: 978-989-758-590-6; ISSN: 2184-7711

649

Legitimate client with

correct message

authentication key

tries to connect

genuine server at

address 1.2.3.4

Adversary without correct

message authentication

tries to connect genuine

server at address 1.2.3.4

MaTaDoR boxes

are transparent

routers that can

be scaled easily

Genuine web server

with IP address 1.2.3.4

Decoy web server with

IP address 1.2.3.4

Legitimate client s messages

are relayed to the genuine

subnet

Adversary s messages are

relayed to the decoy subnet

GENUINE SUBNET

DECOY SUBNET

INTERNAL PROTECTION DOMAIN

Figure 1: MaTaDoR is able to distinguish the legitimate

packets from malicious ones even though their observable

behavior is the same for an external observer.

simulation and reproducible experimental steps are

explained in Section 4. The results of the conducted

simulations for the proposed cost-effective mecha-

nism are tabulated in Section 5. Section 6 concludes

the paper with a summarizing discussion.

2 RELATED WORK

Hong, et al. classiﬁes MTD techniques into three cat-

egories: Shufﬂe, Redundancy and Diversity (Hong

and Kim, 2015). Shufﬂing moves or re-arranges the

resources to be protected. Redundancy replicates the

resources to enhance availability. Diversity places dif-

ferent variants of a resource with the same function-

ality. According to this taxonomy, proposed mecha-

nism is a diversity mechanism as the adversary is di-

verted to a non-functional decoy.

Chafﬁng and winnowing is a technique for

sharing conﬁdential information in an untrusted

medium (Rivest et al., 1998). Chafﬁng and win-

nowing was not designed as a MTD approach. It is

designed to provide conﬁdentiality through message

authentication instead of encryption. The proposed

mechanism was inspired by chafﬁng and winnowing

as message authentication is used as an effective ﬁlter

to distinguish legitimate or malicious trafﬁc.

Bogosyan et al. uses MTD to do defend against

spooﬁng and replay attacks to Controller Area Net-

work (CAN) bus during electric vehicle charging pro-

cess (Bogosyan et al., 2020). This study also estab-

lishes redundancy MTD by multiplying resources.

Jenkins et al. design a MTD algorithm for real

time networks in space systems (Jenkins et al., 2021).

This study makes use of authentication bytes and dis-

tributes correct shufﬂing keys to authenticated clients.

This study designs a shufﬂing MTD.

Park, et al. propose Ghost MTD, where pre-

shared one time bit sequences are distributed and

non-conforming sequences are directed to some de-

coy module (Park et al., 2020). Park, et al.’s approach

resembles the proposed mechanism; however, distri-

bution and management of one time bit sequences for

each host seems impractical.

Kampanakis et al. implement Moving Target

Defense mechanism in a Software-Deﬁned Network

(SDN) environment, then evaluate the performance

of the system with Cisco’s One Platform Kit (Kam-

panakis et al., 2014). Even though the authors effec-

tively use SDN’s ﬂexibility, it is difﬁcult to adopt this

approach to traditional networks.

Openﬂow Random Host Mutation (OF-RHM) is

also based on SDN (Jafarian et al., 2012). Virtual ad-

dresses of network resources are continuously mod-

iﬁed by the SDN controller via Openﬂow protocol.

This is an example of a shufﬂing mechanism. The

IP conﬁguration of the network domain is constantly

changing. On the other hand, the proposed mecha-

nism has two different domains which have the same

conﬁguration from an outsider’s point of view.

Network-based MTD (NMTD) constantly

changes the network conﬁguration such as IP ad-

dresses and ports that are used by the protected

applications (MacFarland and Shue, 2015). This

setup requires a centralized conﬁguration to follow.

However, this might introduce a single point of

failure. On the other hand, MaTaDoR could be

multiplexed without burden.

Luo, et al. proposed Random Port and Address

Hopping (RPAH) scheme that predeﬁnes the active

ports (Luo et al., 2017). A gateway handles the gen-

eration and management of virtual IP addresses. Luo

et al.’s NAT implementation is similar to the proposed

mechanism. However, the transparent entry point in

the proposed mechanism acts as a router and does not

form a single point of failure.

3 PROPOSED MECHANISM:

MaTaDoR

The users of a network expect availability. A network

is constantly subject to attacks that jeopardize avail-

ability. Therefore, networks should distinguish adver-

saries from legitimate users. In the proposed mecha-

nism adversarial packets are routed to a decoy net-

work right after they are distinguished. Thus, even if

an attack is going on, legitimate users are served. Per-

ceiving a decoy but equivalent service is confusing for

adversary.

Considering these, MaTaDoR is designed as a

SECRYPT 2022 - 19th International Conference on Security and Cryptography

650

transparent router. The decoy network in this study is

presented as a placeholder and is not detailed. Else, it

is possible to use this network to redirect adversaries

or observe their actions further on a honeynet.

Slowloris and similar DoS attacks harm the avail-

ability of a web server even before connections are es-

tablished. Since the attack trafﬁc will not include the

correct message authentication keys, MaTaDoR for-

wards this trafﬁc into a decoy server. Even if the de-

coy server rendered unavailable, the legitimate users

of the genuine server are not affected. However, from

the adversary’s point of view, disrupting the service of

the website make them think their attack is success-

ful at ﬁrst sight. Such additional confusion is another

layer of ambiguity for the adversary.

The relaying nature of MaTaDoR is transparent as

seen in Figure 1. The sole functionality of MaTaDoR

is to verify the message authentication header and de-

termine the future ﬂow of the trafﬁc. A realistic sce-

nario is to place MaTaDoR in between two organiza-

tions that share non-public network services without a

dedicated VPN (Virtual Private Network) or a leased-

line. Message authentication key is assumed to be

set up during initialization. Further key management

issues are deliberately keep out of the scope of the

discussion. A second, decoy server is also placed in

Figure 1 to handle attacker attention whenever MaTa-

DoR fails to authenticate the message. Moreover, the

decoy server could be replaced with an honeynet that

logs attacker behavior or non-veriﬁed segments could

simply be dropped.

The network topology presented in Figure 1 rep-

resents the aforementioned scenario with two clients,

two web servers and MaTaDoR. One of the clients

(marked red in Figure 1) represent the malicious IP

space where DoS attack is originating from. The

packets from the malicious IP space have missing or

incorrect MAC. The other client (marked blue in Fig-

ure 1) represent the benign users who want to use

the web server. The genuine web server represents

the protected resource. Finally, the decoy web server

is equivalent to the genuine resource, but consists of

mechanisms to distract adversarial efforts. As in ev-

ery other MTD solution, the adversary is hopefully

tricked to think that no defense mechanism exists to

protect the asset.

The ﬂow is shown in Figure 2a when a segment

is authenticated. MaTaDoR veriﬁes the authentica-

tion header, then directs the trafﬁc to the web server

if the MAC veriﬁcation is successful. The genuine

web server gets the segments and continues by send-

ing an acknowledge message to establish TCP hand-

shake with the authenticated client. The genuine web

server can directly see the initiator IP address of the

client, as MaTaDoR is transparent. Thus, the server

can directly send the response to that client. There-

fore MaTaDoR allows to establish the communication

of legitimate users and the genuine web server.

Whenever a packet authentication fails, MaTaDoR

redirects the packet to the decoy server. The ﬂow of

unauthenticated segments is shown in Figure 2b. De-

coy server can also see the IP address of the initiat-

ing client. Therefore, the adversary might believe as

if they are directly connected to the server, without

any interceptors. Thus, unauthenticated or unwanted

messages are directed to the decoy server and genuine

server can continue its normal operation.

A DoS attack example in which the adversary

never ﬁnishes TCP handshake to waste the resources

of benign servers is shown in Figure 2c. In this sce-

nario, like in Slowloris attacks, the adversary sends

only “SYN” packets of the handshake and never re-

sponds to incoming “SYN/ACK” packets. This be-

havior makes serving computers to wait for an incom-

ing connection, by allocating some of its resources

to keep state. The increase of such requests makes a

web server to allocate more resources and eventually

the server becomes unavailable. Since MaTaDoR for-

wards the requests to an actual, yet decoy web server,

the decoy server becomes unavailable. Thus, MaTa-

DoR serves its purpose by confusing the adversary ei-

ther the web server is on or off. Genuine server oper-

ates normally in the meantime.

Note that, both benign and malicious trafﬁc is han-

dled the same from the external network’s point of

view. Therefore, it is not possible to detect either the

genuine or decoy server is active. This attribute al-

lows users to be unaware of that there is a protection

mechanism in place.

4 METHODOLOGY

MaTaDoR’s feasibility is validated by a simulation

setup similar to Figure 1. A real network dump is re-

generated with Scapy (Rohith et al., 2018) to build

experimental trafﬁc. Scapy is a packet manipula-

tion program that enables real time header processing.

Since popular operating systems like GNU/Linux, OS

X and Windows do not support TCP-AO message au-

thentication header is added at the client side with

Scapy. Then, MaTaDoR handles these headers via

custom iptables rules.

The original trafﬁc data is named “SUEE1”

, in-

cludes both wireless and wired interfaces, and col-

lected by Lukaseder et al. (Lukaseder et al., 2018).

https://github.com/vs-uulm/2017-SUEE-data-set

Moving Target Defense Router: MaTaDoR

651

SYN + Correct

MAC

SYN

LEGITIMATE

CLIENT

MaTaDoR

GENUINE

SERVER

Time

SYN/ACK

ACK

DATA

1 - MaTaDoR verified the segment and forwarded

the client to the genuine server

2- Handshake with the genuine server is

completed

(a) Communication ﬂow of

authenticated messages that are

destined to genuine server.

SYN +

Incorrect/Nonexistent

MAC

SYN

ADVERSARY MaTaDoR

DECOY

SERVER

Time

SYN/ACK

ACK

DATA

1 -MaTaDoR did not authenticatethe message and

forwardedthe client to the decoy server

2-Handshake with thedecoy server is completed

(b) Communication ﬂow of

unauthenticated messages that are

destined to genuine server.

SYN +

Incorrect/Nonexistent

MAC

SYN

ADVERSARY MaTaDoR

DECOY

SERVER

Time

SYN/ACK

1 -MaTaDoR cannot authenticatethe segment and

forwardedthe adversary to the decoy server

2- Decoy Server responds to SYN packets

3- Decoy Server becomes unavailable so that the

adversary believes the attack has succeded. In

the meantime, MaTaDoR is still available as it is

stateless. Legitimate users are able to use the

genuine server.

SYN

SYN +

Incorrect/Nonexistent

MAC

SYN/ACK

Attack.

Figure 2: Characteristic packet ﬂows of MaTaDoR.

The trafﬁc includes both incoming and outgoing

HTTP/S packets. The malicious packets are sepa-

rately generated by running slowloris and slowhttptest

DoS attacks. The malicious source addresses are cho-

sen from a pre-determined IP space during the experi-

ments so that trafﬁc statistics could be compiled easily

at the target.

The experimental trafﬁc uses exact packet timing,

order and size of the original. Besides, the packet con-

tents are masked and the trafﬁc is directed to the target

host either with enabled authentication or not. The

included malicious trafﬁc is also an exact copy of a

pre-recorded DoS attack.

The overall trafﬁc data includes a total of

2 089 436 packets, where 1 962 955 of them are be-

nign requests and 126 481 of them are DoS attempts.

When the DoS attack is conducted for any of the

web servers, it takes about 15 seconds to disrupt their

services. It is possible to observe this by not receiv-

ing any acknowledgment messages from the servers.

MaTaDoR does not alter the original packet, it only

marks these packets based on the hash-based mes-

sage authentication codes (HMACs) (Krawczyk et al.,

1997). Then the marked packets are forwarded to

genuine or decoy server depending on its authentic-

ity. The proposed approach is suitable and compatible

to be used by utilizing the optional TCP-AO header.

However, it is omitted for two resasons. First, it is

known that BGP frequently uses this option in be-

tween autonomous systems (ASs) and this may cause

that the proposed message authenticated packets be

ﬁltered via BGP routers. This is the main reason

that the provided implementation allocates another

optional header area. Still, MaTaDoR could safely

be used via TCP-AO header within the same AS. Sec-

ond, end user devices do not support TCP-AO by de-

fault. It is more practical to utilize optional additional

header.

In the ﬁnal design, benign and malicious trafﬁc

are processed together, both with message authenti-

cation header and not, to measure the overhead gener-

ated by the proposed solution. In order to observe the

efﬁciency of the mechanism and observe the effects

of the attacks in the experiments, the server software

chosen to be vulnerable against DoS attacks. This is

a natural requirement that should be satisﬁed to see

that unwanted or unauthenticated packets never reach

the genuine server. In this expreriment, unwanted

trafﬁc is the slowhttptest, slowloris and slowloris-ng

packets from the SUEE1 dataset. The DoS vulnera-

ble server software is chosen as the built-in Python2

module called SimpleHTTPServer. As this software

has limited connection capabilities, it is easy to know

that if it is disrupted by simply checking its status or

by observing whether it returns an acknowledgment

packet.

MaTaDoR’s source code is available on Github.

5 RESULTS

The overhead of using authentication header and the

additional redirection is measured to present the per-

formance of the proposed solution. Built-in time com-

mand is utilized to measure the execution time of

authentication veriﬁcation. Moreover, the additional

https://github.com/BerkanUfuk/MaTaDoR

SECRYPT 2022 - 19th International Conference on Security and Cryptography

652

load of the veriﬁcation to the CPU is collected.

The experiment is conducted on a Raspberry Pi

3 Model B Plus Rev 1.3 and two regular personal

computers with Intel Core i7-7700HQ CPU and 8 GB

RAM. One of the computers have the web servers and

named as server computer, and the other computer

has client software and named as client computer.

Raspberry Pi resides as the MaTaDoR in the experi-

ments. The server computer has 2 virtual machines

which have identical web servers constructed with

python’s http.server module. Also, these two virtual

machines have the same operating system and conﬁg-

uration. The only difference is that they are on differ-

ent interfaces and on different physical sub-nets that

have the same network conﬁguration. client comput-

ers also have the same operating systems and placed

at the other end of MaTaDoR. The clients in the exper-

iments are GNU/Linux virtual machines with Scapy

to send packets.

Two scenarios are tested to point out the perfor-

mance difference of using authentication or not. The

experiment is repeated ﬁve times and results are pro-

vided as the arithmetic mean of each. Table 1 sum-

marizes the perspective of the client computers. Ac-

cording to the table, the proposed solution has limited

effect on the CPU load. The overall delay is notice-

able but the slight increase seems acceptable.

The columns shown on the Table 1 are as follows:

The Real column indicates the total amount of time

to process the trafﬁc during the experiment. Simi-

larly, User and Kernel indicate the amount of time

consumed in user and kernel space. CPU indicates

the mean of additional CPU load throughout the ex-

periment. Finally, RTT is the round trip time to send

request from the client to the either of the servers, and

receive a response. Recall that, there are 1 962 955

benign and 126 481 malicious packets exist in the re-

generated pre-recorded real world trafﬁc.

The total time spent for each benign packet is

around 25 ms. This is around 7 ms for each mali-

cious packet. This difference is due to the additional

response originated from the application layer pro-

cessed for benign packets. Therefore, this difference

cannot be considered as an additional cost of MaTa-

DoR, but as the natural outcome of using the network

resources.

The overhead of additional message authentica-

tion header for benign trafﬁc is approximately 8% and

the difference in the CPU load is negligible. The over-

head is approximately 2% for malicious trafﬁc. These

results indicate that MaTaDoR effectively and efﬁ-

ciently ﬁlters out the malicious or benign trafﬁc and

the overhead is depend mostly on the packet size. The

accuracy of this ﬁltering is 100% as MaTaDoR relies

on cryptography unless a noise disrupts a packet.

Table 2 represents the average CPU load and addi-

tional CPU loads as observed from the MaTaDoR. In

order to measure the CPU load, the built-in top com-

mand is used in the MaTaDoR. As it can be seen,

MaTaDoR brings up an extra 4.3% CPU cost. This

is due to IPTables rules that MaTaDoR builds.

MaTaDoR also has an insigniﬁcant effect in

packet delays. The average time of packet delays with

MaTaDoR is 597 microseconds, while the average

packet delay is 487 microseconds without MaTaDoR.

The RTT delay is measured with Scapy by subtracting

acknowledgment response time from packet sending

time. Additionally, 90 microseconds of RTT differ-

ence seems unnoticeable by the users of a network. It

could be speculated that this difference mainly roots

from the additional router hop. This slight differ-

ence better demonstrates the undetectability of the

proposed solution. It could be seen that the transpar-

ently MaTaDoR barely effects the network behavior.

Therefore, it is very hard to notice if an additional de-

fense mechanism is in use in the network. It could

also be seen that, MaTaDoR has a very limited CPU

usage

Table 3 presents a comparison of the pro-

posed scheme with GhostMTD (Park et al., 2020).

GhostMTD is chosen as its quantitative experimental

results are available. Note that, GhostMTD is similar

to MaTaDoR as both relies on message authenticat-

ing bit streams at the network border and they both

forward invalid packets to decoy servers. However,

GhostMTD requires a connection to be established to

analyze incoming packets and keeps local state, so it

is not scalable.

The results presented in the table are normal-

ized as experimental setups are different. MaTaDoR

introduces around 2.86 % throughput performance

loss while GhostMTD decreases the performance by

3.84 %. MaTaDoR’s efﬁciency is likely to be the re-

sult of its use of authentication via TCP header early

before establishing the connections. Thus, packets are

handled early without further inspection in the pay-

load.

6 CONCLUSION

In addition to conventional network security prac-

tices, availability is a critical and expected fea-

ture. MaTaDoR chaffs away unauthenticated traf-

ﬁc smoothly by introducing message authentication.

Therefore, it provides strict access control and avail-

ability at the same time. MaTaDoR acts as a trans-

parent router with authentication key based ﬁltering

Moving Target Defense Router: MaTaDoR

653

Table 1: End to end performance metrics of the client computers.

Trafﬁc Real [s] User [s] Kernel [s] CPU [%] RTT [µs]

Benign w/o MaTaDoR 49159 827 4803 13 512

Benign w/ MaTaDoR 52647 1534 5132 14 598

Malicious w/o MaTaDoR 1332 12 186 16 462

Malicious w/ MaTaDoR 1467 32 365 17 631

Table 2: CPU load comparison.

Trafﬁc CPU [%] CPU Difference [%]

w/ MaTaDoR 0.7 4.25

w/o MaTaDoR 0.7 none

Table 3: Throughput comparison of GhostMTD vs. MaTa-

DoR.

GhostMTD MaTaDoR

Loss [%] 3.84 2.86

capabilities. As a result, it is stateless and easily scal-

able. This feature could be helpful to interconnect two

semi-trusted organizations without the necessity of a

leased-line or a VPN. Moreover, such a mechanism is

not directly detectable. This is useful to lure adver-

saries to honeynets, which is not discussed in depth in

the paper and left as a future work.

It is obvious that a practical authentication key ex-

change will be necessary to increase the usability of

the proposed mechanism. The authors aim to conduct

a complexity study after further reﬁning the provided

code.

REFERENCES

Bogosyan, S., Akgul, T., and Gokasan, M. (2020). Mtd

based novel scheme for bms security against can

bus attacks during bev charging. In 2020 9th

Mediterranean Conference on Embedded Computing

(MECO), pages 1–7. IEEE.

Hong, J. B. and Kim, D. S. (2015). Assessing the effective-

ness of moving target defenses using security models.

IEEE Transactions on Dependable and Secure Com-

puting, 13(2):163–177.

Jafarian, J. H., Al-Shaer, E., and Duan, Q. (2012). Openﬂow

random host mutation: Transparent moving target de-

fense using software deﬁned networking. In Proceed-

ings of the First Workshop on Hot Topics in Software

Deﬁned Networks, HotSDN ’12, pages 127–132, New

York, NY, USA. Association for Computing Machin-

ery.

Jenkins, C., Vugrin, E., Manickam, I., Troutman, N., Hazel-

baker, J., Krakowiak, S., Maxwell, J., and Brown,

R. (2021). Moving target defense for space systems.

In 2021 IEEE Space Computing Conference (SCC),

pages 60–71. IEEE.

Kampanakis, P., Perros, H., and Beyene, T. (2014). Sdn-

based solutions for moving target defense network

protection. In Proceeding of IEEE International Sym-

posium on a World of Wireless, Mobile and Multime-

dia Networks 2014, pages 1–6.

Krawczyk, H., Bellare, M., and Canetti, R. (1997). HMAC:

Keyed-Hashing for Message Authentication. Request

for Comments 2104, Fremont, CA, USA: Internet En-

gineering Task Force.

Lukaseder, T., Maile, L., Erb, B., and Kargl, F. (2018).

Sdn-assisted network-based mitigation of slow ddos

attacks. In International Conference on Security and

Privacy in Communication Systems, pages 102–121.

Springer.

Luo, Y.-B., Wang, B.-S., Wang, X.-F., Zhang, B.-F., and Hu,

W. (2017). Rpah: A moving target network defense

mechanism naturally resists reconnaissances and at-

tacks. IEICE Transactions on Information and Sys-

tems, E100.D(3):496–510.

MacFarland, D. C. and Shue, C. A. (2015). The sdn shufﬂe:

Creating a moving-target defense using host-based

software-deﬁned networking. In Proceedings of the

Second ACM Workshop on Moving Target Defense,

MTD ’15, pages 37–41, New York, NY, USA. Asso-

ciation for Computing Machinery.

Park, J.-G., Lee, Y., Kang, K.-W., Lee, S.-H., and Park,

K.-W. (2020). Ghost-mtd: Moving target defense via

protocol mutation for mission-critical cloud systems.

Energies, 13(8).

Rivest, R. L. et al. (1998). Chafﬁng and winnowing: Conﬁ-

dentiality without encryption. CryptoBytes (RSA lab-

oratories), 4(1):12–17.

Rohith, R., Moharir, M., Shobha, G., et al. (2018). Scapy-

a powerful interactive packet manipulation program.

In 2018 international conference on networking, em-

bedded and wireless systems (ICNEWS), pages 1–5.

IEEE.

Touch, J., Mankin, A., and Bonica, R. P. (2010). The tcp

authentication option. Request for Comments 5925,

Fremont, CA, USA: Internet Engineering Task Force.

SECRYPT 2022 - 19th International Conference on Security and Cryptography

654