Subject: [core] Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11)

From: Lauri Piikivi <[email-masked]>
Date: Wed, 20 Jan 2021 09:34:50 +0000

Hi alls,

I read the new block with interest and started wondering about the request tag. Why do we need new tag, when we have the basic COAP token. Token is used to match request and response, and in doing that it does identify the request blocks and response blocks to be part of the same request and response.

In blocwise transfer 7959 , the message IDs change but token combines them together. Same seems usable in the new-block approach. It is the same request, so they should have the same token. RFC 7959 does not say a whole lot about tokens "As a general comment on tokens, there is no other mention of tokens in this document, as block-wise transfers handle tokens like any other CoAP exchange. As usual, the client is free to choose tokens for each exchange as it likes.” This could be clarified. My understanding is that the token is the same for all blocks of a request and response.  This is shown for example in the Figure 13 of 7959.

My wondering started from reading the  draft-ietf-core-new-block-06. It states then need for request tag, and in example 9.1.1  shows the basic tokens as different for the fragmented request. Is that an error? Should the basic tokens be the same? And if the tokens are the same, the request-tag seems unnecessary.

I did read the draft-ietf-core-echo-request-tag-11 to understand the request-token better, but I found the description a bit hard to follow. It says in in chp 3.2 that  "The Request-Tag is intended for use as a short-lived identifier for keeping apart distinct block-wise request operations on one resource from one client”

But on the wire there is already the token specified in 7252 chp 5.3.1 "A token is intended for use as a client-local identifier for  differentiating between concurrent requests (see Section 5.3<https://tools.ietf.org/html/rfc7252#section-5.3>)”.

I do not understand exactly what is meant by  "The block-wise functionality does not support the detection of interchanged blocks between different message bodies to the same resource having the same block number” in  tag-11 chp 3.1. Is the message body the payload?  If the requests come from same client, they must have different tokens, per rfc 7252.

Is there some problem in token that I fail to understand now — necessitating the request-token?

In similar vein, and as a use case where request token seems good, is the understanding correct that for block1 requests all the request options are duplicated in all the blocks? I could not find a clear statement, but once again the figures in 7959 show the URI for each block. The URI path and query options can be long, and take considerable space in each block.

Could request token be the identifier for request options, so that only 1st block would have full options and later ones only the the request tag?

Sincerely,
- Lauri

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: <[email-masked]>
Date: Wed, 20 Jan 2021 10:08:16 +0000

Hi Lauri,

Thank you for the comment.

draft-ietf-core-echo-request-tag-11#section-4 describes the reasons why token handling of 7252 should be updated. Please look at those. With that update in mind, token will need to be updated for each request with a new block.

Requests-Tag is used in the new-block to bind blocks of the same fragmented request. Section 5 of the new-block I-D calls out that the authoritative behavior is the updated one in draft-ietf-core-echo-request-tag.

Please let us know if any clarification is needed to the new-block I-D.

Cheers,
Med

De : core [mailto:[email-masked]] De la part de Lauri Piikivi
Envoyé : mercredi 20 janvier 2021 10:35
À : [email-masked]
Objet : [core] Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11)

Hi alls,

Sincerely,
- Lauri

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Lauri Piikivi <[email-masked]>
Date: Wed, 20 Jan 2021 14:31:31 +0000

Hi Med,

Thank you for a very fast answer.

My concern here is that we do not make CoAP stand for Complex Application Protocol. And I think these are not issues in the new block, but in the tag itself.

First of all the request-tag it is defined to overcome the weaknesses of token — but the same specification fixes the token, making it seem like the “suspenders and belt” approach. I would like to avoid the complexity if at all possible, There are good definitions there, make them for the token, and use that existing mechanisms. Some of the problems in the draft-mattsson-core-coap-actuators-06 are missing token or assuming naive reuse of the same token (especially the 2.5.2 — where client has a concurrent transaction, apples and murderers). We are not really doing anything fundamental change, we are stating that a token is weak, and adding a better defined token. Does that solve the issues? Assuming the kind of replays as in the actuators-08 document, the echo seems the answer, not a token-called-tag to fix an existing token that is then still updated in chapter 4.

As for the new block, If the tokens are used to combine the separate message IDs as in standard COAP and blocklwise — it is a huge change to make the token change for each block for the server. Is this the reason that the document is described as experimental in chp 1.3 — or does that refer only to the rate control "This mechanism is not intended for general CoAP usage, and any use outside the intended use case should be carefully weighed against the loss of interoperability with generic CoAP applications”. Still the document is marked for standards track? Or is it aimed purely for the DDoS Open Threat Signaling
 Use and similar cases?

COMMENT ON TAG-11 Echo
The error code 4.03 seems closer to the echo operation. Authentication is stated outside of RFC 7252, and 403 in http states "The 403 (Forbidden) status code indicates that the server understood

the request but refuses to authorize it.” A new attempt with changed credentials can be made.

ERRORS IN TAG-11
There is some error in the tag-11 document, it has conflicting statements on using the option in responses.
In 3.2 The Request-Tag option is only used in requests that carry the Block1 option, and in Block2 requests following these.
In 3.2.1  The Request-Tag option is only used in the request messages of block-wise operations.

Then on page 14

 When Block1 and Block2 are combined in an operation, the Request-Tag
   of the Block1 phase is set in the Block2 phase as well for otherwise
   the request would have a different set of options and would not be
   recognized any more.

   Clients are encouraged to generate compact messages.  This means
   sending messages without Request-Tag options whenever possible, and
   using short values when the absent option can not be recycled.

   Note that Request-Tag options can be present in request messages that
   carry no Block option (for example, because a Request-Tag unaware
   proxy reassembled them), and MUST be ignored in those.

   The Request-Tag option MUST NOT be present in response messages.

BR
- Lauri

On 20. Jan 2021, at 12.08, [email-masked]<mailto:[email-masked]> wrote:

Hi Lauri,

Cheers,
Med

De : core [mailto:[email-masked]] De la part de Lauri Piikivi
Envoyé : mercredi 20 janvier 2021 10:35
À : [email-masked]<mailto:[email-masked]>
Objet : [core] Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11)

Hi alls,

Sincerely,
- Lauri

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Jan 2021 16:29:40 +0100

On 2021-01-20, at 15:31, Lauri Piikivi <[email-masked]> wrote:
> 
> First of all the request-tag it is defined to overcome the weaknesses of token 

Well, the CoAP Token isn’t weak, it is solving a different problem.

A request tag is not needed if there is some other way to differentiate different block-wise interactions, but if there isn’t, it can serve as the no-op cache-key.

Grüße, Carsten