UDP Usage Guidelines
draft-ietf-tsvwg-rfc5405bis-19

Thank you for addressing my DISCUSS.

Before starting to read this document, a first reaction: let me stress that this type of document should really benefit from a "changes since RFC5405" section.

I see in the abstract:

   This document obsoletes RFC5405 and adds guidelines for multicast UDP
   usage.


I see in the intro section:

   [RFC5405] was scoped to provide guidelines for unicast applications
   only, whereas this document also provides guidelines for UDP flows
   that use IP anycast, multicast, broadcast, and applications that use
   UDP tunnels to support IP flows.

Looking at the diffs, there is certainly more than this
	https://www.ietf.org/rfcdiff/rfcdiff.pyht
	=> https://tools.ietf.org/rfc/rfc5405.txt
	=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt

Background: 
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the related discussion on having a "changes since RFCxxxx", even for obsolete.

=================================
Now the review.

Like Stephen, I was wondering about the QUIC involvement and awareness.

- TCP-Friendly Rate Control (TFRC) on the first occurence
- Section 3.1.1 might refer to active probing in IPPM, RFC 7679
- Section 3.1.5: Question: instead of implementing a congestion control scheme, is this valid to limit the UDP traffic to a certain value, such as a fraction of the outgoing link bandwidth? At least, that should be true for the section 3.6 "controlled environment"

Tim Chown performed the opsdir review

Thank you for a very well-written draft!  When DTLS is discussed in the security considerations section, could you include a pointer to the best practices: https://tools.ietf.org/html/rfc7525

Thank you for also for addressing the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/fOv00Tugy6CjPOuoReu2jHKS38k

Thanks for updating this. I have one real question to
ask, and a few nitty things...

Some of the text in section 6 seems outdated, e.g. I'm
not sure we'd recommend GSS-API or AH these days. I
wonder would that section be worth running by the saag
list to see if anyone has time and interest to offer
better text? (I would be happy to try write such text
myself but other than the bit below, don't have time 
right now, sorry.) 

Note that my review is based on the diff from 5405 [1]

- General: I wondered if the folks interested in QUIC
have been involved with this? I assume they have and that
this update won't cause issues with the just-formed QUIC
WG. (If we did expect such issues, then we probably ought
be explicit about that and I didn't see any mention of
QUIC in this document.)

- 3.1.1: "Latency samples MUST NOT be derived from
ambiguous transactions" - I don't understand how that
MUST NOT can be universally applied, maybe that's just a
use of 2119 terms for emphasis?

- 3.1.2: I wondered if there's anything useful to say
about LPWAN applications that may meet the "don't send
much" criterion, but I assume it's too early to say most
likely. 

- (some text that moved, which I why I noticed it:-)
section 6 says: "Applications that respond to short
requests with potentially large	responses are vulnerable
to amplification attacks, and SHOULD authenticate the
sender before responding. The source IP address of	a
request is not a useful authenticator, because it can
easily be spoofed. Applications MAY also want to offer
ways to limit the number of requests they respond to in a
time interval, in order to cap the bandwidth they
consume." 

I think that's a bit wrong and a bit out of date. I'd
suggest instead maybe something more like: 

"Applications that respond to short requests with
potentially large responses are a potential vector for
amplification attacks, and SHOULD take steps to minimize
their potential for being abused as part of a DoS attack.
That could mean authenticating the sender before
responding noting that the source IP address of	a request
is not a useful authenticator, because it can easily be
spoofed. Or it may mean otherwise limiting the cases
where short unauthenticated requests produce large
responses. Applications MAY also want to offer ways to
limit the number of requests they respond to in a time
interval, in order to cap the bandwidth they consume."

[1] https://tools.ietf.org/rfcdiff?url1=rfc5405&url2=draft-ietf-tsvwg-rfc5405bis-18.txt