Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10

joel jaeggli <joelja@bogus.com> Tue, 15 July 2014 02:19 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52CB01B27E7; Mon, 14 Jul 2014 19:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTUwTAxzazlP; Mon, 14 Jul 2014 19:19:45 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB101B27F4; Mon, 14 Jul 2014 19:19:45 -0700 (PDT)
Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s6F2JipP003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 02:19:45 GMT (envelope-from joelja@bogus.com)
Message-ID: <53C48FBB.8000802@bogus.com>
Date: Mon, 14 Jul 2014 19:19:39 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0
MIME-Version: 1.0
To: "Waltermire, David A." <david.waltermire@nist.gov>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org" <draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org>
References: <ffc89df7bd104e038ebdc25c5d8ac654@DM2PR09MB0224.namprd09.prod.outlook.com> <53C478E7.2030902@bogus.com> <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com>
In-Reply-To: <25df6a98f9de45a1bfbc54153db42584@DM2PR09MB0224.namprd09.prod.outlook.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CLekxGVf7I3RvLmEB7pEwQ4VR9AEqTJdv"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 15 Jul 2014 02:19:45 +0000 (UTC)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/B9FmJNgfUyazc4g8dVwFl_zs764
Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jul 2014 02:19:51 -0000

On 7/14/14, 5:53 PM, Waltermire, David A. wrote:
> Joel,
> 
> Thanks. I was just looking at the email threads pertaining to this
> draft and there was a concern about registering the "windowsize"
> option string with IANA.
> 
> http://www.ietf.org/mail-archive/web/tsv-area/current/msg01102.html
> 
> This seems like a reasonable request, but there doesn't seem to be an
> associated IANA registry defined in RFC2347. I'm not sure if this
> should be a going forward concern or not, but it is worth
> highlighting.

Yeah it's a standards track document at this point so I'm ok with the
idea of it creating a registry, I'd probably adjust the iana
considerations section accordingly, but I expect both the IESG review
and the IANA review to clarify how we should approach that, or if we should.

regards
joel

> 
> Thanks, Dave
> 
> -----Original Message----- From: joel jaeggli
> [mailto:joelja@bogus.com] Sent: Monday, July 14, 2014 8:42 PM To:
> Waltermire, David A.; iesg@ietf.org; secdir@ietf.org;
> draft-masotta-tftpexts-windowsize-opt.all@tools.ietf.org Subject: Re:
> secdir review of draft-masotta-tftpexts-windowsize-opt-10
> 
> Thanks!  I think these are reasonable suggestions and will confer
> with the author.
> 
> joel
> 
> On 7/14/14 5:32 PM, Waltermire, David A. wrote:
>> I have reviewed this document as part of the security directorate's
>> ongoing effort to review all IETF documents being processed by the
>> IESG.  These comments were written primarily for the benefit of the
>> security area directors.  Document editors and WG chairs should
>> treat these comments just like any other last call comments.
>> 
>> Status: Almost ready - There are a few security and other related
>> concerns with this draft summarized below.
>> 
>> The draft defines a method for overriding the default step-wise
>> acknowledgement (ACK) behavior of TFTP. This extension suppresses
>> the standard step-wise ACK response until a negotiated window size
>> of blocks have been sent. A single ACK is then sent indicating that
>> all blocks in the window were transmitted. This results in a
>> general reduction in the number of ACKs over the exchange, allowing
>> for higher transfer rates than using block size negotiation alone
>> (RFC2348).
>> 
>> Security Concerns:
>> 
>> The specific security considerations statement appears to be copied
>> from RFC2347. It acknowledges that TFTP does not have any explicit
>> security mechanism and that the extension does not add any
>> additional security risk beyond the base specification. Instead of
>> copying the text from the other RFCs, this text should be replaced
>> with text that references the security considerations from RFC1350,
>> RFC2347, and probably RFC5405.
>> 
>> Additionally, it seems like this option requires a state machine,
>> involving both the client and server, to track the exchange of
>> blocks within a window to support retransmission of failed blocks.
>> If I am understanding this correctly, it looks like a potential
>> attack vector exists where a malicious client (or server) could
>> cause abnormal consumption of system and network resources through
>> the use of large window sizes across a number of sessions. This
>> malicious actor would need to selectively cause retransmission of
>> blocks that still conform with max retry, timeout, and delay
>> constraints. In part, the second paragraph (and the following
>> example) in the "Congestion and Error Control" section provide some
>> error handling guidance that also addresses this security
>> consideration. At minimum a discussion of this attack vector and a
>> reference back to this explanation should be included in the
>> security considerations section. It would also be valuable to
>> include some discussion on reasonable limits for window sizes,
>> retry, timeout, and delay parameters, or at least some guidelines
>> around determining them based on the characteristics of the data
>> link layer protocol used.
>> 
>> Other concerns:
>> 
>> In the abstract:
>> 
>> - The abstract should mention that this memo extends RFC1350 by
>> adding a new option extension for ... based on RFC2347.
>> 
>> In section "Windowsize Option Specification":
>> 
>> - The text in this section should be updated to make use of RFC2119
>> capitalized keywords. - A specification for the Read and Write
>> requests is provided along with an example. The specification of
>> the corresponding OACK should be provided with the same degree of
>> rigor. - The draft describes the ACK behavior for data exchange in
>> the definition of the windowsize "#blocks" field. The actual
>> requirements should be defined using RFC2119 language in a new
>> paragraph after the discussion of option negotiation. This new text
>> should express the actual windowing behavior requirements for
>> implementations of the protocol extension. It should also make
>> explicit which block number to send in the ACK, which I infer to be
>> the last block sent in the window.
>> 
>> General nits:
>> 
>> There are a number of grammatical and punctuation issues throughout
>> the document. Some of these make it more difficult to understand
>> the document. A quick editorial pass through the document should
>> address this concern. I am happy to provide a few
>> specifics/suggestions in this regard if the author would like.
>> 
>> Also, the nits tool reported: - An issue with 3 pages being longer
>> than the required 58 lines per page. - The abstract contains
>> bracketed references. See previous comment. - Whitespace warnings
>> 
>> Regards, Dave Waltermire
>> 
>> 
> 
> 
>