Re: [core] I-D Action: draft-ietf-core-echo-request-tag-09.txt

[Christian Amsüss <[e-mail]>]

Hello CoRE,

On Mon, Mar 09, 2020 at 09:57:30AM -0700, [e-mail] wrote:
>         Title           : CoAP: Echo, Request-Tag, and Token Processing
>         Authors         : Christian Amsüss
>                           John Preuß Mattsson
>                           Göran Selander
> 	Filename        : draft-ietf-core-echo-request-tag-09.txt
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/

The recent changes in particular:

*  Make amplification attack mitigation by Echo an RFC7252
   updating recommendation

   (see https://mailarchive.ietf.org/arch/msg/core/wy5bOuXaupfSY9u_hY99U9BDLZ0)

*  Give some more concrete guidance to that use case in terms of
   sizes and message types

   (ibd, using numbers from CoAP-over-UDP-over-IPv6)

*  Allow short (1-3 byte) Echo values for deterministic cases,
   with according security considerations

   (from implementation experience)

*  Point out the tricky parts around Request-Tag for stateless
   proxies, and make that purely an outlook example with out-of-
   scope details

   (see https://mailarchive.ietf.org/arch/msg/core/5Pc92j3uriocjRVjyeo90fySEwc
   and https://mailarchive.ietf.org/arch/msg/core/IoIhwW6qUKmq85S2xMOjYUY5i0g)

*  Lift ban on Request-Tag options without Block1 (as they can
   legitimately be generated by an unaware proxy)

   (from processing an open point in Francesca's review)

*  Suggest concrete numbers for the options

   (from implementations needing them)

I believe this addresses the issues that were raised during the WGLC as
well as two points stemming from an implementation of the Echo
application for OSCORE sequence number recovery.

Kind regards
Christian

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn