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

[Stephen Farrell <[e-mail]>]

Hiya,

On 14/10/16 14:21, Eggert, Lars wrote:
> 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 :-)

Yeah, but then different eyeballs catch different things:-)

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

They're not. But they're probably also not that useful as
they're not much used for UDP applications afaik. Text about
how to successfully use DTLS would be more useful these days
I'd say. Or maybe JOSE or COSE stuff. Sorry no to have good
text.

If you want, I can ask on saag or you can just go ahead
if you'd prefer not wait.

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

Well, the MUST NOT assumes that there's an unambiguous
definition of "ambiguous transaction" and I'm not sure
there is, is there?

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

Cool,
Thanks.

> 
> Lars
>