Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
From: Cigdem Sengul Sent: Monday, August 17, 2020 2:25 PM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg Subject: Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06 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 [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 mailto:i...@augustcellars.com> > wrote: From: Cigdem Sengul mailto:cigdem.sen...@gmail.com> > Sent: Monday, August 17, 2020 10:45 AM To: Jim Schaad mailto:i...@augustcellars.com> > Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org <mailto:draft-ietf-ace-mqtt-tls-prof...@ietf.org> ; Ace Wg mailto:ace@ietf.org> > 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
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 wrote: > > > > > *From:* Cigdem Sengul > *Sent:* Monday, August 17, 2020 10:45 AM > *To:* Jim Schaad > *Cc:* draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg > *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 > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
From: Cigdem Sengul Sent: Monday, August 17, 2020 10:45 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
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". --Cigdem ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
From: Cigdem Sengul Sent: Monday, August 17, 2020 8:50 AM To: Jim Schaad Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 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 mailto:i...@augustcellars.com> > wrote: 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. 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. [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. ) 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. 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. 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. 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. 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
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 > wrote: > > 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. > > > > 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. > > [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. ) > > 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. > > 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. > > > > 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. > > > > 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. > > > 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. > > [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. > > > [CS] OK, agreed, less is more in this case. Will delete the parentheses text. > > > > 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? > > > > Yes, I was just pointing out that this was using the old syntax. Nothing
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 wrote: > 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. > > 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. > 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. > > 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. > 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. > 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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
