[OASIS Issue Tracker] (MQTT-326) Consolidate Handling for NAKs, Protocol Errors and

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64621#comment-64621 ] 

Ken Borgendale commented on MQTT-326:
-------------------------------------

We have a section on error handling and a lot more should be added there.  I am concerned that some of this is not editorial but core in nature.

We have defined two significant error categories for spec violations.  I am not fully clear the value of separating these out, but this is my understanding of them now:

Malformed packet: The packet is not valid in any context in that if violates the requirements of the spec.  These errors might cause the receiver to stop parsing as it is not clear that we are parsing the correct data, or parsing it correctly.  

Protocol error: The packet can be sufficiently enough parsed to determine that it is not valid in this context.  This does not guarantee that it is fully parsed and would not be malforrmed when fully parsed.  All of the context checked to determine a protocol error should exist within a single connection and should be deterministic based on the control packet flow previous in this connection.  This excludes errors which could be based on a mismatch between client and server session state.

The response to either of these is before a CONNACK is sent is to optionally send a CONNACK, and after the CONNACK is sent to optionally send a DISCONNECT.  In either case the receiver must close the network connection.  

If the control packet is sufficiently messed up it might not be advisable to send the DISCONNECT first, and if the network is messed up the DISCONNECT might well never be received anyway.  However in general the server should send the DISCONNECT.  In the case of any response to a non-authorized connection, the Server must decide whether it should send the CONNACK based on security concerns.  For instance on a private network it might always send CONNACK, but on a public network it might decide to not send a CONNACK.

We have a number of return codes which are essentially subclasses of protocol error.  These include Retain unavailable, Maximum QoS, Shared subscription not supported, and Subscription Identifier not supported.  These exist to give more information about what we wrong so that the sender of the control packet can correct the protocol error.  This again could well be a case where the receiver of the packet does not wish to disclose the exact reason if there is a concern about a man in the middle attack.  Therefore we should not require the receiver to use a specific return code but should allow a generic return code to be used.

We specify the action for protocol error in many places in the spec.  I would propose elevating the section on error handling to somewhere more prominent in the spec and then make it clear that any statement that something is a malformed packet or protocol error implies the actions on closing the network connection. 

> Consolidate Handling for NAKs, Protocol Errors and 
> ---------------------------------------------------
>
>                 Key: MQTT-326
>                 URL: https://issues.oasis-open.org/browse/MQTT-326
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: edits
>    Affects Versions: 5
>            Reporter: Ed Briggs
>            Assignee: Ed Briggs
>              Labels: editorial
>
> The text regarding the handling of ACKs, NAKs, and protocol errors needs to be unified so that a single, consistent approach is used throughout (to the extent possible.)  There also needs to be consistency on the sending of DISCONNECT vs transport disconnection in cases of protocol errors (e.g. malformed header).
> This editorial process has already been approved and this issue is resolved from a procedural standpoint.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)