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

From: Jim Schaad <[email-masked]>
Date: Sat, 15 Aug 2020 14:50:02 -0700

Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
session number/  - I think it should be stated that the session number is
provided, which is what the state is associated with.

Section 2.2.4 - Last sentence.  There is a difference between the connect
and re-auth flows in that the first and last messages are going to be AUTH
'25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
Might just want to say a similar flow and point forward.

Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
different in MQTT v5.0, the Broker is allowed to process AUTH packets even
if the Broker rejects the CONNECT)."  I think that if the broker rejects the
connect it must CONNACK and disconnect.  

Section 3.1 - Missed a case of "publish_+/topic3"

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Sun, 16 Aug 2020 20:13:44 +0100

Hello Jim,
Responses inside.

> provided, which is what the state is associated with.
To the best of my knowledge, and from what I read from the MQTT v5 spec:
The ClientID MUST be used by Clients and by Servers to identify state that
they hold relating to this MQTT Session between the Client and the Server.
I do not think the server uses anything other than the Client ID to look up
the state.

> Will clarify that this is only for CONNECT as it is under section 2- Authorizing
Connection Requests.
Will direct to section 4 for re-authentication.

> connect it must CONNACK and disconnect.

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].

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and
servers to process AUTH after CONNECT (before CONNACK I suppose).

I agree the wording may  be confusing:
What I want to say is that: the servers in our profile do not process
anything after CONNECT before CONNACK.
So, the AUTH flow is strictly initiated by the server during the connection
handshake.
After that, the client may do AUTH first, for re-authentication.

> Section 3.1 - Missed a case of "publish_+/topic3"
Yes, in previous version, example was for publish only for topic3.
I thought I should give a pub/sub, pub only, and sub only examples.
Is that OK?

Thanks,
--Cigdem

>
> Jim
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Jim Schaad <[email-masked]>
Date: Sun, 16 Aug 2020 13:10:27 -0700

From: Cigdem Sengul <[email-masked]> 
Sent: Sunday, August 16, 2020 12:14 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; Ace Wg <[email-masked]>
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

Hello Jim, 

Responses inside. 

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

The ClientID MUST be used by Clients and by Servers to identify state that they hold relating to this MQTT Session between the Client and the Server. 

I do not think the server uses anything other than the Client ID to look up the state.  

[JLS] I got the name wrong, the need for the identifier remains.

Will clarify that this is only for CONNECT as it is under section 2- Authorizing Connection Requests. 

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]

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and servers to process AUTH after CONNECT (before CONNACK I suppose). 

What I want to say is that: the servers in our profile do not process anything after CONNECT before CONNACK. 

So, the AUTH flow is strictly initiated by the server during the connection handshake.

[JLS] Given that a client may only send an AUTH in response to an AUTH, I don’t know how much this is needed.

[JLS]  I think if you just delete the aside (in parens) then it says what needs to be said and is not confusing.

Is that OK?

Yes, I was just pointing out that this was using the old syntax.  Nothing more.

Jim

Thanks,

--Cigdem 

Jim

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 17 Aug 2020 16:49:33 +0100

Hello Jim,
Responses inside.

> [JLS] I got the name wrong, the need for the identifier remains.
[CS] I see - I realise I did a shortcut to say MQTT broker keep session
state.
Actually, I think I should give examples of session state as I need to
explain what could be problematic by identifying state only with client-id
as discussed in the last IETF meeting.
(i.e.,

The Session State in the Client consists of:

·         QoS 1 and QoS 2 messages which have been sent to the Server, but
have not been completely acknowledged.

·         QoS 2 messages which have been received from the Server, but have
not been completely acknowledged.

The Session State in the Server consists of:

·         The existence of a Session, even if the rest of the Session State
is empty.

·         The Clients subscriptions, including any Subscription Identifiers.

·         QoS 1 and QoS 2 messages which have been sent to the Client, but
have not been completely acknowledged.

·         QoS 1 and QoS 2 messages pending transmission to the Client and
OPTIONALLY QoS 0 messages pending transmission to the Client.

·         QoS 2 messages which have been received from the Client, but have
not been completely acknowledged.The Will Message and the Will Delay
Interval

·         If the Session is currently not connected, the time at which the
Session will end and Session State will be discarded.

)

> 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].
>
>
>
> CONNECT à
> PUBLISH à
>                 ß AUTH
> AUTH à
>                 ß CONNACK fail

[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.

> needs to be said and is not confusing.
[CS] OK, agreed, less is more in this case. Will delete the parentheses
text.

> Yes, I was just pointing out that this was using the old syntax.  Nothing

[CS] Found it. OK, that was very buggy. Will change to:
 Following the example in the previous section,
   a client sending a SUBSCRIBE message to 'a/topic3' would be allowed to
   subscribe, as the scope includes  "["+/topic3",["sub"]]".

Thanks again for catching it.
--Cigdem

---

From: Jim Schaad <[email-masked]>
Date: Mon, 17 Aug 2020 09:31:08 -0700

Sent: Monday, August 17, 2020 8:50 AM

Hello Jim, 

Responses inside.

[CS] I see - I realise I did a shortcut to say MQTT broker keep session state. 

Actually, I think I should give examples of session state as I need to explain what could be problematic by identifying state only with client-id as discussed in the last IETF meeting. 

(i.e., 

*         QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.

*         QoS 2 messages which have been received from the Server, but have not been completely acknowledged.

*         The existence of a Session, even if the rest of the Session State is empty.

*         The Clients subscriptions, including any Subscription Identifiers.

*         QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.

*         QoS 1 and QoS 2 messages pending transmission to the Client and OPTIONALLY QoS 0 messages pending transmission to the Client.

*         QoS 2 messages which have been received from the Client, but have not been completely acknowledged.The Will Message and the Will Delay Interval

*         If the Session is currently not connected, the time at which the Session will end and Session State will be discarded.

)

 and:

CONNECT -->

PUBLISH -->

                <-- AUTH

AUTH -->

                <-- CONNACK fail

[/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, agreed, less is more in this case. Will delete the parentheses text.  

Is that OK?

--Cigdem 

Jim

Thanks,

--Cigdem 

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 17 Aug 2020 18:45:24 +0100

> 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".

--Cigdem

---

From: Jim Schaad <[email-masked]>
Date: Mon, 17 Aug 2020 11:16:37 -0700

Sent: Monday, August 17, 2020 10:45 AM

 and:

CONNECT -->

PUBLISH -->

                <-- AUTH

AUTH -->

                <-- CONNACK fail

[/JLS]

 

[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].

[JLS] Looks like there might be some conflicting statements here.  I don’t know the best way to resolve it.

Jim

--Cigdem

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 17 Aug 2020 22:25:04 +0100

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 <[email-masked]> wrote:

>
>
>
>
> *From:* Cigdem Sengul <[email-masked]>
> *Sent:* Monday, August 17, 2020 10:45 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]; Ace Wg <[email-masked]>
> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
>
>
>
>
>
>
>
> 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].
>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 17 Aug 2020 16:14:07 -0700

Sent: Monday, August 17, 2020 2:25 PM

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...

-> 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

[JLS] I think that not catering to these cases is just fine.  People who really expect them to work probably shouldn’t.

Jim

 

On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

From: Cigdem Sengul <[email-masked] <mailto:[email-masked]> > 
Sent: Monday, August 17, 2020 10:45 AM
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Ace Wg <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

 and:

CONNECT -->

PUBLISH -->

                <-- AUTH

AUTH -->

                <-- CONNACK fail

[/JLS]

 

Jim

--Cigdem