[core] [Technical Errata Reported] RFC7252 (5429)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 18 July 2018 14:48 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94871311B7 for <core@ietfa.amsl.com>; Wed, 18 Jul 2018 07:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcep5SrEB59V for <core@ietfa.amsl.com>; Wed, 18 Jul 2018 07:47:59 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFA2131188 for <core@ietf.org>; Wed, 18 Jul 2018 07:47:59 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 8CFA2B810BB; Wed, 18 Jul 2018 07:47:54 -0700 (PDT)
To: zach.shelby@arm.com, hartke@tzi.org, cabo@tzi.org, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, cabo@tzi.org, jaime.jimenez@ericsson.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: marian.buschsieweke@ovgu.de, core@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180718144754.8CFA2B810BB@rfc-editor.org>
Date: Wed, 18 Jul 2018 07:47:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/FeKXd9d3Tkrwju0azwvwKiM3GyM>
X-Mailman-Approved-At: Thu, 19 Jul 2018 08:02:56 -0700
Subject: [core] [Technical Errata Reported] RFC7252 (5429)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 14:48:12 -0000
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/eid5429 -------------------------------------- Type: Technical Reported by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Section: 4.4 Original Text ------------- An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient. The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is changed each time a new Confirmable or Non- confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely. Corrected Text -------------- An Acknowledgement or Reset message is related to a Confirmable message or Non-confirmable message by means of a Message ID along with additional address information of the corresponding endpoint. The Message ID is a 16-bit unsigned integer that is generated by the sender of a Confirmable or Non-confirmable message and included in the CoAP header. Message IDs of subsequence messages send to the same endpoint within EXCHANGE_LIFETIME MUST be strictly ascending (wrapping around at a value of 65535). Additionally, two subsequently send Message IDs to the same endpoint SHOULD have a difference of at most 16. The Message ID MUST be echoed in the Acknowledgement or Reset message by the recipient. The same Message ID MUST NOT be reused (in communicating with the same endpoint) within the EXCHANGE_LIFETIME (Section 4.8.2). Implementation Note: Several implementation strategies can be employed for generating Message IDs. In the simplest case, a CoAP endpoint generates Message IDs by keeping a single Message ID variable, which is incremented each time a new Confirmable or Non- confirmable message is sent, regardless of the destination address or port. Endpoints dealing with large numbers of transactions could keep multiple Message ID variables, for example, per prefix or destination address. (Note that some receiving endpoints may not be able to distinguish unicast and multicast packets addressed to it, so endpoints generating Message IDs need to make sure these do not overlap.) It is strongly recommended that the initial value of the variable (e.g., on startup) be randomized, in order to make successful off-path attacks on the protocol less likely. Notes ----- Without any restrictions on how Message IDs are generated, an implementation of CoAP duplication detection must be prepared to receive a random sequence of Message IDs. One simple implementation strategy would be to store the received Message IDs along with a timestamp when they were received. If a 16 bit time stamp would be used, 4 Bytes per tracked Message ID would be required. If additionaly a CoAP server expects requests to be received at a rate of 1 message per second, at least 247 * 4 Byte or approximately 1 KiB have to be allocated per client. A class 1 (see RFC 7228 Section 3) server could handle at most 10 clients in parallel, if anything apart duplicate detection could be implemented without using any memory at all. If instead Message IDs have to be generated by incrementing a (global or per endpoint/network prefix/...) counter variable, duplicate detection can be implemented in a time and memory efficient way without limiting the rate of the message exchange between to nodes. 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
- [core] [Technical Errata Reported] RFC7252 (5429) RFC Errata System
- Re: [core] [Technical Errata Reported] RFC7252 (5… Christian Amsüss
- Re: [core] [Technical Errata Reported] RFC7252 (5… Marian Buschsieweke
- Re: [core] [Technical Errata Reported] RFC7252 (5… Carsten Bormann
- Re: [core] [Technical Errata Reported] RFC7252 (5… Achim Kraus