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

joel jaeggli <> Tue, 15 July 2014 02:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 52CB01B27E7; Mon, 14 Jul 2014 19:19:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yTUwTAxzazlP; Mon, 14 Jul 2014 19:19:45 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CDB101B27F4; Mon, 14 Jul 2014 19:19:45 -0700 (PDT)
Received: from mb-aye.local ( []) (authenticated bits=0) by (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
Message-ID: <>
Date: Mon, 14 Jul 2014 19:19:39 -0700
From: joel jaeggli <>
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." <>, "" <>, "" <>, "" <>
References: <> <> <>
In-Reply-To: <>
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 ( []); Tue, 15 Jul 2014 02:19:45 +0000 (UTC)
Subject: Re: [secdir] secdir review of draft-masotta-tftpexts-windowsize-opt-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.
> 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.


> Thanks, Dave
> -----Original Message----- From: joel jaeggli
> [] Sent: Monday, July 14, 2014 8:42 PM To:
> Waltermire, David A.;;;
> 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