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

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Wed, 12 October 2016 13:38 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F18129480; Wed, 12 Oct 2016 06:38:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147627951927.24204.5957412872290553453.idtracker@ietfa.amsl.com>
Date: Wed, 12 Oct 2016 06:38:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qZR9K1xvLjRMseesUcaKWFEdjqw>
Cc: draft-ietf-tsvwg-rfc5405bis@ietf.org, david.black@emc.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org
Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-rfc5405bis-18: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2016 13:38:39 -0000

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