Subject: [core] [Technical Errata Reported] RFC7252 (5284)

From: RFC Errata System <[email-masked]>
Date: Fri, 9 Mar 2018 01:34:25 -0800 (PST)

The following errata report has been submitted for RFC7252,
"The Constrained Application Protocol (CoAP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5284

--------------------------------------
Type: Technical
Reported by: Mohamed Boucadair <[email-masked]>

Section: 5.3.1

Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique.

Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently
in use for a given source/destination endpoint pair are unique per
request.

Notes
-----
Multiple requests may be active for a given source/destination
endpoint pair.  The OLD text is thus broken.

The NEW text is aligned with the definition of the Token:

  A token is intended for use as a client-local identifier for
  differentiating between concurrent requests (see Section 5.3); it
  could have been called a "request ID".

Further, using the same token for a given source/destination endpoint
pair have some implications, for example, for applications which
require the support of multiple observe queries because RFC7641
states the following:

   The entry in the list of observers is keyed by the client endpoint
    and the token specified by the client in the request.  If an entry
    with a matching endpoint/token pair is already present in the list
    (which, for example, happens when the client wishes to reinforce
    its interest in a resource), the server MUST NOT add a new entry
    but MUST replace or update the existing one.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7252 (draft-ietf-core-coap-18)
--------------------------------------
Title               : The Constrained Application Protocol (CoAP)
Publication Date    : June 2014
Author(s)           : Z. Shelby, K. Hartke, C. Bormann
Category            : PROPOSED STANDARD
Source              : Constrained RESTful Environments APP
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Wed, 14 Mar 2018 11:58:51 +0000

Hi,

if the current definition "tokens currently in use" is interpreted as for "all pending requests", I can't see, that adding "per request" improves the RFC. 
If something is added, I would recommend to precise that also with the time-scope, 
e.g. "per simultaneous request".

Mit freundlichen Grüßen / Best regards

 Achim Kraus

(INST/ECS4) 
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of RFC Errata System
Sent: Freitag, 9. März 2018 10:34
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [core] [Technical Errata Reported] RFC7252 (5284)

The following errata report has been submitted for RFC7252, "The Constrained Application Protocol (CoAP)".

Section: 5.3.1

Original Text
-------------
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique.

Corrected Text
--------------
The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique per request.

Notes
-----
Multiple requests may be active for a given source/destination endpoint pair.  The OLD text is thus broken.

Further, using the same token for a given source/destination endpoint pair have some implications, for example, for applications which require the support of multiple observe queries because RFC7641 states the following:

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. 

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: <[email-masked]>
Date: Wed, 14 Mar 2018 12:23:27 +0000

Hi Achim,
(ccing DOTS WG)

Thank you for sharing your thoughts.

I'm personally OK with any wording which makes clear that distinct tokens are generated to differentiate among concurrent requests involving the same source/destination endpoints.  

I'm not sure to understand what you meant by "per simultaneous request", though.  

Cheers,
Med

> -----Message d'origine-----
> De : Kraus Achim (INST/ECS4) [mailto:[email-masked]]
> Envoyé : mercredi 14 mars 2018 12:59
> À : RFC Errata System; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: [core] [Technical Errata Reported] RFC7252 (5284)
> 
> Hi,
> 
> if the current definition "tokens currently in use" is interpreted as for
> "all pending requests", I can't see, that adding "per request" improves the
> RFC.
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> The client SHOULD generate tokens in such a way that tokens currently in use
> for a given source/destination endpoint pair are unique.
> 
> Corrected Text
> --------------
> The client SHOULD generate tokens in such a way that tokens currently in use
> for a given source/destination endpoint pair are unique per request.
> 
> Notes
> -----
> Further, using the same token for a given source/destination endpoint pair
> have some implications, for example, for applications which require the
> support of multiple observe queries because RFC7641 states the following:
> 
> This erratum is currently posted as "Reported". If necessary, please use
> "Reply All" to discuss whether it should be verified or rejected. When a
> decision is reached, the verifying party can log in to change the status and
> edit the report, if necessary.
>

---

From: Göran Selander <[email-masked]>
Date: Wed, 14 Mar 2018 16:23:13 +0000

Hello,

Please note there is also a security issue with re-use of tokens. The
following formulation is used in
https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-01#section-5

"When CoAP is used with a security protocol not providing bindings
   between requests and responses, the client MUST NOT reuse tokens
   until the traffic keys have been replaced.  The easiest way to
   accomplish this is to implement the Token as a counter, this approach
   SHOULD be followed."

Regards
Göran

On 2018-03-14 13:23, "core on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>I'm personally OK with any wording which makes clear that distinct tokens
>are generated to differentiate among concurrent requests involving the
>same source/destination endpoints.
>
>> If something is added, I would recommend to precise that also with the
>>time-
>> scope,
>> Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332
>>Waiblingen |
>> GERMANY | www.bosch-si.com
>> 
>> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung:
>>Dr.
>> Stefan Ferber, Michael Hahn
>> 
>> The following errata report has been submitted for RFC7252, "The
>>Constrained
>> Application Protocol (CoAP)".
>> 
>>in use
>>in use
>> Multiple requests may be active for a given source/destination endpoint
>>pair.
>> The OLD text is thus broken.
>> 
>>pair