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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 12 Oct 2016 06:38:39 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-rfc5405bis-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc5405bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 14 Oct 2016 13:21:34 +0000

Hi,

> myself but other than the bit below, don't have time 

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.

> be explicit about that and I didn't see any mention of

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

> use of 2119 terms for emphasis?

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

> interval, in order to cap the bandwidth they consume."

Applied.

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Oct 2016 16:46:07 +0100

Hiya,

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

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

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.

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 15 Oct 2016 06:50:19 +0000

Hi,

> if you'd prefer not wait.

if someone from saag can go over the current text by - say - the end of next week, *and* we can be sure that the resulting edits are such that they have obvious consensus in SAAG, TSVWG, the IETF and the IESG (such that we don't need to redo all the consensus calls) - sure. Feasible?

> definition of "ambiguous transaction" and I'm not sure

If you define protocol with transactional semantics (i.e., request/response) you *know* whether you can unambiguously relate request packets with response packets. If there can be ambiguity in some cases (as with TCP), then as long as you can identify those cases, you MUST NOT derive latency samples from them. If you can't relate request and response packets at all, you have designed a protocol that will make it very difficult to do any sort of congestion control for :-) including being able to compute an RTT.

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Oct 2016 13:23:38 +0100

On 15/10/16 07:50, Eggert, Lars wrote:
>>> 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.
> 
> if someone from saag can go over the current text by - say - the end
> of next week, *and* we can be sure that the resulting edits are such
> that they have obvious consensus in SAAG, TSVWG, the IETF and the
> IESG (such that we don't need to redo all the consensus calls) -
> sure. Feasible?

Seems unlikely, but I'll ask and we'll see if we get good
enough text in response. Default being to just stick with
current text.

Cheers,
S.

>> Well, the MUST NOT assumes that there's an unambiguous definition
>> of "ambiguous transaction" and I'm not sure there is, is there?
> 
> If you define protocol with transactional semantics (i.e.,
> request/response) you *know* whether you can unambiguously relate
> request packets with response packets. If there can be ambiguity in
> some cases (as with TCP), then as long as you can identify those
> cases, you MUST NOT derive latency samples from them. If you can't
> relate request and response packets at all, you have designed a
> protocol that will make it very difficult to do any sort of
> congestion control for :-) including being able to compute an RTT.
> 
> Lars
>