UDP Usage Guidelines
RFC 8085

Note: This ballot was opened for revision 18 and is now closed.

Ben Campbell Yes

Comment (2016-10-12 for -18)
Hi, thanks for this document.  I just have a few nit level comments:

- I agree with Benoit that a more detailed "changes since 5405" section would be helpful (separate from the inter-version change section.)

- IDNits points out that RFC  896 is obsoleted RFC 7805. Is the reference to 896 intentional? (The shepherd writeup mentions a different obsolete reference, but not this one.)

- 3, 2nd paragraph:
Is it reasonable to avoid the negation in "not rare" and just say "common"?

-3.1.1, 3rd paragraph: Please expand TFRC on first mention. (I think the original 5405 text that expanded it got moved to later in the document.)

-3.4, paragraph 3: "An application MAY optionally discard UDP datagrams
   with a zero checksum [RFC1122]"
Does this MAY give permission to discard, or state the fact that 1122 gives permission to discard? (If the second, please consider non-2119 language to avoid the ambiguity.)

-3.4.1, last bullet in list: I think there may be an editing or copy/paste error here.  (Limit the usage of what? Is that section 3.6 _of_ RFC7510?)

-3.6: Yay!

- section 6, third paragraph: "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."

Is that MAY intentionally capitalized? Seems like a statement of fact.

-section 6, paragraph 5:  I concur with Kathleen's comment to reference 7525 in the DTLS discussion.

Spencer Dawkins Yes

Mirja K├╝hlewind Yes

Comment (2016-10-13 for -18)
Well written doc! Thanks! One comment, not really an issue, just want to mention it:
Recommendations on "Limited Applicability and Controlled Environments" seem slightly redundant (in section 3.6 but also two times earlier in the doc). Maybe it would be helpful to at least have the definition of 'General Internet' and 'Controlled Enviroment' (currently in section 3.6) earlier in the doc...?

(Jari Arkko) No Objection

Alia Atlas No Objection

Deborah Brungard No Objection

Benoit Claise No Objection

Comment (2016-10-13 for -18)
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"

Alissa Cooper (was Discuss) No Objection

Comment (2016-10-14)
Thank you for addressing my DISCUSS.

(Stephen Farrell) No Objection

Comment (2016-10-12 for -18)
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

(Joel Jaeggli) No Objection

Comment (2016-10-11 for -18)
Tim Chown performed the opsdir review

Suresh Krishnan No Objection

Kathleen Moriarty No Objection

Comment (2016-10-11 for -18)
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