[OASIS Issue Tracker] Commented: (MQTT-6) What should a server do if it receives a connect packet with and incorrect protocol name?

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

    [ http://tools.oasis-open.org/issues/browse/MQTT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33668#action_33668 ] 

Peter Niblett commented on MQTT-6:
----------------------------------

This issue is connected with MQTT-8 (which talk about malformed connect packets), MQTT-15 (protocol names and version numbers) and MQTT-5 (reserved bits in Connect).  

It seems to me that we have several kinds of "bad" Connect packet:

i) Something that isn't really an MQTT Connect at all - it's either a packet from a different protocol that arrives because of an innocent configuration error, or it's the result of some kind of malicious DoS attack

ii) An MQTT Connect from a different version of the protocol (either older or newer)

iii) An MQTT Connect that identifies itself as being from this version of the protocol, but has some other syntactic problem in it (e.g. reserved flags bit set non-zero, an error in the client ID, a parameter missing from the payload). 

iv) Something that parses correctly as another MQTT command that is received instead of a Connect. 

I think we agreed that we want the server to disconnect the TCP/IP session in case i) without sending any CONNACK.  However our requirements on servers to trap this case must not be so stringent that they prevent case ii) - we should let servers  handle this case (possibly with an RFC 2119 MAY) accept case ii). 

We might also consider it is helpful to return a negative CONNACK in some instances of case ii), in order to negotiate a level that is acceptable to both client and server. 

There is also the question of whether it's helpful to developers to be able to catch cases iii) and iv) and send a negative CONNACK - this I think is MQTT-8.


So how does a server distinguish case i) from the others?  
- A valid CONNECT packet for this version of the protocol has to start with the byte 0x10 (this is thanks to MQTT-5). So testing this byte has a reasonable chance of catching case i), though it would also catch iv) and some instances of ii) and iii).
- The next thing you encounter is the "RemainingLength" field which uses a special integer encoding. There's a 1in 16 chance that a random message will contain an invalid encoding, and a very high chance that when decoded it won't match the actual amount of data in the packet
- The protocol version is a UTF-8 encoded string (with a 2 byte length prefix).  There's a high chance that a random message would not have a valid encoding for this field.

I suggest rewording Nick's suggestion a bit, and say words to the effect of 

1. A server MUST generate a CONNACK if it receives a syntactically well-formed CONNECT packet. This means a packet in which the first byte is 0x10, the RemainingLength is a valid MultiByte integer (we might want to impose a bound on the value here to catch people who send 256M ), and the protocol and version number are encoded as described in this spec.

2. A server MAY generate a CONNACK if it receives a packet that meets the requirements of 1, but has a different (though correctly encoded) protocol and version. In this case it MAY also accept the CONNECT even if some of the flag bits in the first byte are non-zero. 

3. In all other cases it MUST close the connection without sending a CONNACK.

Note that this means that case iv) results in the connection being closed without a CONNACK, but that's reasonable since it wasn't a CONNECT in the first place. 


> What should a server do if it receives a connect packet with and incorrect protocol name?
> -----------------------------------------------------------------------------------------
>
>                 Key: MQTT-6
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-6
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Andrew Banks
>
> What should a server do if it receives a connect packet with and incorrect protocol name?
> If the server receives a connect packet with no MQIsdp field present ( or its replacement field) The server could.
> 1) Disconnect the Clients TCP session
> 2) Return CONNACK  RC=X01, then disconnect the clients TCP session.
> 3) Return CONNACK with some new return code and then disconnect the clients TCP session.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira