Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)

Christian Amsüss <> Sun, 18 July 2021 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9571D3A0953; Sun, 18 Jul 2021 13:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LTb6wQpDBm-j; Sun, 18 Jul 2021 13:25:29 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E1D03A094E; Sun, 18 Jul 2021 13:25:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 6FCDA4010C; Sun, 18 Jul 2021 22:25:20 +0200 (CEST)
Received: from ( [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id 6C4ECD0; Sun, 18 Jul 2021 22:25:19 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPSA id DB533148; Sun, 18 Jul 2021 22:25:18 +0200 (CEST)
Received: (nullmailer pid 2667889 invoked by uid 1000); Sun, 18 Jul 2021 20:25:17 -0000
Date: Sun, 18 Jul 2021 22:25:17 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Roman Danyliw <>
Cc: The IESG <>,,,
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rWKSF1toZf7YgVp6"
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-request-tag-12: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Jul 2021 20:25:34 -0000

Hello Roman,

thanks for your input on echo-request-tag, and apologies for the delay
in processing them to completion.

Please see [1] for a few general comments; here are individual responses
to your comments:

> ** 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?

Not all applications of Echo depend on pseudorandom numbers. Where they
do not, their construction can ensure that only unique 1-byte values are
used.until these are exhausted.


> ** 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?

In the course of the GENERIC-SHORT-ECHO changes, this has been made more
precise using the concept of "authority over synchronized property"
introduced there.

> ** 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

Item 3 of appendix A can be as short as 1 byte (until it overflows to
2), with a concrete example linked, and includes a requirement for its

> -- 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

These are now tied together by the Characterization chapter introduced

Best regards


This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables