[core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 17 February 2021 20:54 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 855E63A1D0E; Wed, 17 Feb 2021 12:54:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-echo-request-tag@ietf.org, core-chairs@ietf.org, core@ietf.org, Marco Tiloca <marco.tiloca@ri.se>, marco.tiloca@ri.se
X-Test-IDTracker: no
X-IETF-IDTracker: 7.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <161359527152.11372.63177839446582675@ietfa.amsl.com>
Date: Wed, 17 Feb 2021 12:54:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/OT7VGt6tSBjhsq5D1h7Gi1WnNE0>
Subject: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Feb 2021 20:54:32 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-core-echo-request-tag-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this mitigation for draft-mattsson-core-coap-actuators. ** Section 5. Per “As each pseudorandom number most only be used once …”, how will that be possible when echo values as small are 1-byte are possible? ** Section 5. However, this may not be an issue if the communication is integrity protected against third parties and the client is trusted not misusing this capability. -- Why is the use of integrity presented as only a possibility here? Didn’t Section 2.3 require it when assuring the freshness requirement – “When used to serve freshness requirements including client aliveness and state synchronizing), the Echo option value MUST be integrity protected between the intended endpoints ...” -- Would it be clearer here to say that this is mitigation against an on-path attacker, not against rogue/compromised clients? ** Appendix A helpfully tries to lay out recommendations. A few comments: -- all of the recommendations here have option values much larger than the permitted minimum of 1-byte. In addition to the recommendations, could the circumstances of the lower bound also be discussed -- it would be helpful to explicitly state which methods apply to the specific use cases (client aliveness, request freshness, state synchronization, network address reachability). For example, method 3 (persistent counter) notes that it can be used for state synchronization but not client aliveness
- [core] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
- Re: [core] Roman Danyliw's No Objection on draft-… Christian Amsüss
- Re: [core] Roman Danyliw's No Objection on draft-… Roman Danyliw