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

From: Christian Amsüss <[email-masked]>
Date: Sun, 18 Jul 2021 22:25:17 +0200

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.

See also GENERIC-SHORT-ECHO[1].

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

> -- 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
in GENERIC-SHORT-ECHO.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/SIHjiM5AjFRZJRZGUjf3cW1sUu4

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