OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (MQTT-505) Denial of Service Attacks possible

     [ https://issues.oasis-open.org/browse/MQTT-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-505:

    Fix Version/s: 5
Add a non-normative comment at the end of section 3.1.4 AONNECT Actions:

The Server can limit reading from the Network Connection or to close the Network Connection if the Client sends too much data before authentication is complete.  This is suggested as a way of avoiding denial of service attacks.
      Component/s: edits
                       (was: core)

> Denial of Service Attacks possible 
> -----------------------------------
>                 Key: MQTT-505
>                 URL: https://issues.oasis-open.org/browse/MQTT-505
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: edits
>    Affects Versions: 5, CSD01
>            Reporter: Dominik Obermaier
>             Fix For: 5, wd16
> The current state of the MQTT 5 specification states in Line 1007:
> {quote}
> Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait (sic!) for a CONNACK packet to arrive from the Server. If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets.
> {quote}
> This behavior may be used for Denial of Service attacks. Consider the following scenario:
> 1. A malicious client connects to the Broker and sends an invalid CONNECT packet
> 2. The server has a complex authentication mechanism and it may take up to several seconds (or even longer!) until the validity of the CONNECT can be determined
> 3. The malicious client bombards the server with PUBLISH packets
> 4. The broker must queue all these messages until the CONNECT returns. The broker implementation *can't* stop to read from the socket (and thus apply TCP backpressure to the client) since an AUTH packet could be sent by the client.
> MQTT 3.1.1 also allowed unauthenticated clients to send data, the broker implementation could stop to read from the socket until the CONNACK packet is produced.
> To solve the issue, a proposal could be: 
> {quote}
> The Server MAY discard any packets sent by the Client prior to a successful authentication.
> {quote}
> A non-normative comment could be added, that a broker may decide to use a bounded queue for "holding back" the data. If the queue is full, the PUBLISH messages (or other packets) could be dropped and an error code "0x97 - Quota exceeded" could be included in the ACK (e.g. PUBACK, ...). 
> A slightly better approach to fix this problem would be to disallow the sending of any packets before all AUTH packets are exchanged.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]