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

[Roman Danyliw <[e-mail]>]

Hi Christian!

Sincere apologies for this tardy response.  Thank you for this detailed explanation and the pointer to the generic-short-echo.  This works for me.  Please consider my comments resolved.

Roman

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Christian Amsüss
> Sent: Sunday, July 18, 2021 4:25 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]; [e-mail]; The IESG
> <[e-mail]>; [e-mail]
> Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-echo-
> request-tag-12: (with COMMENT)
> 
> 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