Next Article in Journal
Popularity Prediction of Instagram Posts
Next Article in Special Issue
Botnet Defense System: Concept, Design, and Basic Strategy
Previous Article in Journal
Decision-Making for Project Delivery System with Related-Indicators Based on Pythagorean Fuzzy Weighted Muirhead Mean Operator
 
 
Article
Peer-Review Record

SlowTT: A Slow Denial of Service against IoT Networks

Information 2020, 11(9), 452; https://doi.org/10.3390/info11090452
by Ivan Vaccari 1,2,*, Maurizio Aiello 1 and Enrico Cambiaso 1
Reviewer 1: Anonymous
Reviewer 2:
Reviewer 3: Anonymous
Reviewer 4: Anonymous
Information 2020, 11(9), 452; https://doi.org/10.3390/info11090452
Submission received: 18 August 2020 / Revised: 11 September 2020 / Accepted: 15 September 2020 / Published: 18 September 2020
(This article belongs to the Special Issue Security and Privacy in the Internet of Things)

Round 1

Reviewer 1 Report

In this manuscript, the authors introduced weaknesses in the MQTT protocal and  explained possible attacks targeting those weaknesses, which is interesting and important. The writting is generally good enough and easy to follow. The experiment is also convincing.

This manuscript proposed a kind of slow DoS attack (called SlowTT attack) targeting the broker of the MQTT protocol that is widely used in IoT environments. The authors pointed out the vulnerability of this protocol for the broker, that is, the two parameters of WaitTimeout and KeepAlive can be determined by the clients. Based on this vulnerability, the attacker as a client can send the ping packet to the broker just before KeepAlive is used up. In this way, the attacker can keep the connections alive all the time just by sending some pings at a very low frequency, which may make the detection of those attacks very difficult. This proposal is an extension to the previous work from the same authors [13].

I think the proposed attack is interesting and important because
1) this attack is based on the nature of the MQTT protocol;
2) this attack is low-rate one, which makes it difficult to detect.

It is generally well-written. However, some problems exist including the following
1) The two parameters: WaitTimeout and KeepAlive seem to be related to each other. WaitTimeout can be determined from the other? If so, only one is necessary. If not, their relation should be discussed.
2) In Line 207, "1,5 times" should be "1.5 times", right?
3) In Line 284, what do you mean by "more or less 1024"?
4) In Lines 297 and 371, why 1016 rather than 1024? They are seemingly typos. If not, this number should be explained.
5) In Figure 2, "WT" should be explained. Although it is explained in the later part.
6) Figures 6 and 7 are identical?
7) There are seemingly some references not being cited in the text. Please make sure all the listed references are necessary.
8) The formats of the references are not unified. For example, the order of the YEAR and the Page. Please check them carefully.

 

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 2 Report

The research work is very interesting.

The commented PDF is attached herewith.

The manuscript requires professional editing.

Comments for author File: Comments.pdf

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 3 Report

The paper proposes of a SlowTT as a solution to a slow denial of service against MQTT attacks. The proposal is the next version of their previous work on SlowITe which has the limitations around the duration of the connection and the connection value. In general, the paper is well written with a clear problem definition of what the proposal is trying to solve along with a clear description of the proposal and its feasibility through a set of extensive experiments. However, this paper can be improved if the following is provided further.

  1. A clear set of contributions of the SlowTT that is different from SlowITe.
  2. What is the implication of extending the connection duration to infinite and set a lower value of KeepAlive? Exactly what problem does it solve in terms of MQTT attacks and if these are significant.
  3. What are the limitations of the current proposal?

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Reviewer 4 Report

This is a practical and interesting work against IoT security. The authors exploited the weaknesses to set the Keep-Alive parameter of the server from the client itself and to adopt PING
 packets to keep a connection alive by avoiding the connection closure by the server. This approach could achieve DOS attacks against plain MQTT broker. The testing on the implementation shows the effectiveness of the attack.

However, even though  the work is practical and useful to the IoT community, the depth of the work should be further improved.

There are several weaknesses of this submission to be addressed and improved.

1) The description of the attack and the experiment is too lengthy and tedious. The rationale of the attack is so simple, and it could be described in  a much simpler paragraph. 

2) The rationale is the same with other DOS attacks against other communication protocols. They all try to build TCP connections and keep them alive. Since these DOS attacks all share the same core ideas, the detection methods and prevention methods used in other protocols could be applied or considered in this MQTT DOS attacks. However, the authors address very little about this part. Therefore, I would suggest the authors do a sound review and discussion of these works, and evaluate their effectiveness on mitigating the proposed attacks. Right now, the submission seems to be a preliminary and partial study to me.

 

Author Response

Please see the attachment

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

on line 380 "Timeout value of 60 seconds and several connections equal to 1024. The results obtained are shown in Figure ??. ", correct and provide figure number.

rest, the authors have nicely addressed all the reviewers' comments.

Just double check for any typo.

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 4 Report

The authors have addressed some of my concerns from the previous review.

Some typos are listed as follows.

1) page 12, line 450, Fourier transform and "Mutual Information". What is mutual information here?

2) page 11, line 415, figures 6 and ??,

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Back to TopTop