Re: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)

["Eggert, Lars" <[e-mail]>]

Hi,

On 2016-10-12, at 15:38, Stephen Farrell <[e-mail]> wrote:
> 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.) 

so we did have a sec-dir review, and nothing was flagged :-)

I'm happy to take out the references to GSS-API and/or AH, but note that they are only listed as options. I also note that they are not historic or obsolete, AFAICT.

> - 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.)

Spencer answered this. I expect that QUIC would describe how it relates to the guidelines in this doc, but that will probably/thankfully be a very boring description (due to using standard CC).

> - 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?

I don't follow. Of course this can be universally applied?

> - 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."

Applied.

Lars