Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Cigdem Sengul <[e-mail]>]

Hello Jim,

I understand that it's an optimization to improve message delay. I wonder
also if a client then can do CONNECT - PUBLISH - DISCONNECT before
receiving a CONNACK as a best-effort publish? assuming CONNECT succeeds...
Should we just not cater to those cases?

What about stating in 2.2.6.1 - after "the Broker MUST
   send a CONNACK message to the Client." (or maybe somewhere higher up):

-> The client MUST NOT send any packets other than DISCONNECT or an AUTH in
response to the broker AUTH's message until it has received a CONNACK.
-> The server MUST NOT process any packets other than DISCONNECT or an AUTH
in response to its AUTH message before it has sent a CONNACK.

--Cigdem









On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <[e-mail]> wrote:

>
>
>
>
> *From:* Cigdem Sengul <[e-mail]>
> *Sent:* Monday, August 17, 2020 10:45 AM
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]; Ace Wg <[e-mail]>
> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
>
>
>
>
>
>
>
> I've got that from MQTT v5 spec:
>
> If a Client sets an Authentication Method in the CONNECT, the Client MUST
> NOT send any packets other than AUTH or DISCONNECT packets until it has
> received a CONNACK packet [MQTT-3.1.2-30].
>
>  and:
>
> If the Server rejects the CONNECT, it MUST NOT process any data sent by
> the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].
>
>
>
> [JLS] I read this as the following would not do the publish
>
> CONNECT à
>
> PUBLISH à
>
>                 ß AUTH
>
> AUTH à
>
>                 ß CONNACK fail
>
> The PUBLISH can be received but is not processed unless the CONNACK is
> going to be a success.
>
> [/JLS]
>
>
>
> [CS] I think this sequence should not happen, as Client MUST NOT send
> PUBLISH before CONNACK.
>
> I did not know what brokers do if they receive PUBLISH (and still
> processing a CONNECT) - drop or buffer until process. I quickly browsed
> mosquitto src.
>
> It looks like the broker sets a context flag to mark the session active
> after CONNECT is processed and accepted.
>
> If this flag is not set when processing publish,  it goes to an error
> state and doesn't look like it keeps the packet.
>
>
>
> [JLS] No, Clients are allowed to send further MQTT Control Packets
> immediately after sending a CONNECT packet; Clients need not wait for a
> CONNACK packet to arrive from the Server. – this is the preceding two
> sentences to requirement MQTT-3.1.4-6.  I would agree that this is going to
> be server specific.  The following paragraph suggests that clients SHOULD
> wait for the CONNACK but it is non-normative.  I think that I would write
> my client code to wait.  I would have to work really hard to figure out
> what my code base would do for this as I know it does queue packets for
> later processing but I am not sure what it would do for this case.
>
>
>
>
>
> [CS] Ok, this is confusing.  I assumed that sentence regarding clients
> about not having to wait was when no Authentication Method set.
>
> Because there is: If a Client sets an Authentication Method in the
> CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT
> packets until it has received a CONNACK packet [MQTT-3.1.2-30].
>
>  In the profile, we do set an authentication method in connect to "ace".
>
>
>
> [JLS] Looks like there might be some conflicting statements here.  I don’t
> know the best way to resolve it.
>
> Jim
>
>
>
>
>
> --Cigdem
>