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

[joel jaeggli <[e-mail]>]

Greetings,

An update that attements to address issues surfaced in last call has
been uploaded.

http://tools.ietf.org/html/draft-masotta-tftpexts-windowsize-opt-11

Diff is here.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-masotta-tftpexts-windowsize-opt-11.txt

Some explanatory text has been added to the security considerations section.

On the question of creating and maintaining an IANA registry for option
strings, rfc 2348 elected not to manage "string space" having existed at
a time after tftpext had concluded I think we are better served by
continuing that precedent. I don't see a likelihood that dedicated
resources would be put behind the maintenance and extension of TFTP
notwithstanding RFC 1350s underspecification of some implementation
details which have since become implementation folklore.

I think the nits have been cleared, a language edit performed.

Thanks
joel

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