TFTP Windowsize Option
draft-masotta-tftpexts-windowsize-opt-13

Thanks for the effort on this document and for going the extra mile. I agree with Spencer that this version is much easier to read, and I find it clear and have no objection to its publication.

I support the discusses (Martin's, Spencer's, and Kathleen's).

I support point #1 in Martin's DISCUSS. I don't think saying where the protocol is currently used or not is the same as saying where it should not be used. And the reasons it should not be used on some networks are not confined to security, so I don't think the security considerations section should be the only place where this is discussed.

I agree that in addition to or instead of specifying where it *is* appropriate to use this extension, the document should say where it's *not* appropriate.

I support Spencer Dawkin's current Discuss, and Martin's Discuss item #1. I am sympathetic to the change that Kathleen proposes, although it is perhaps more with TFTP than this extension. Finally, I'm also sympathetic to Ted's issue, but I think it is easily fixable. 

Some comments. These are all comments, something you might consider but none of the issues are serious enough to block the document. Fixing them might improve readability, however.

   Note that all fields
   except "opc" MUST be NULL-terminated.

   +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+
   |  opc  |filename| 0 |  mode  | 0 | windowsize | 0 | #blocks| 0 |
   +-------+---~~---+---+---~~---+---+-----~~-----+---+---~~---+---+

I thought this was a bit unclear, should I include a zero byte in the windowsize field for instance, or is the zero byte the one in above diagram already? One or two zero bytes.

   The number of blocks in a window MUST be specified in ASCII.

MUST be specified in decimal in ASCII.

   The rate at
   which TFTP UDP datagrams are sent SHOULD follow the CC guidelines in
   Section 3.1 of RFC 5405 [RFC5405].

It would be REALLy helpful if you pointed directly to the one that should be implemented, e.g., Section 3.1.1. Which I think is the right one.

Thanks for your work on this draft.  Since the draft is an extension, I'll move my discuss points to a "No Objection".  The reasons for the discuss was the way in which the Security Considerations section was written.  It was written with the full text that you'd expect to see in the TFTP RFC itself as opposed to a pointer to that section and a statement that no additional considerations are added.  If the text stays in the draft, I'd really like to see the considerations include the lack of both authentication and integrity protections.

I'm copying my proposed text here so you have it in an easy to access place and do appreciate that you have already agreed to change out 'login' for 'authentication'.  I am fine with you leaving out confidentiality (although there are no protections if there were any concerns along those lines).  The same idea is covered in the second change proposed.

Security Considerations section:

Propose the following change to the first sentence:
From: "TFTP includes no login or access control mechanisms."
To: "TFTP includes no authentication, integrity protection, confidentiality, or access control mechanisms."

Propose text for the first sentence of second paragraph:
From: "TFTP includes no protection against an on-path attacker, care must be
   taken in controlling windowsize values according to provider,
   requester, and network environment capabilities. "
To: "TFTP also does not support session encryption and therefore does not protect against an on-path attacker from active (session hijacking) or passive (monitoring) attacks.  Care must be
   taken in controlling windowsize values according to provider,
   requester, and network environment capabilities. "

I think it's enough to just list monitoring as an example as with TFTP, as it's likely to be a targeted attack and unlikely to be privacy related since it is typically used to do things like update firmware on a local network, etc.  Those attacks fit into the general category of monitoring.

Thank you for addressing the comments received in the SecDir review.  From the SecDir review, there was a recommendation to include other references in the the security considerations section of this document.  One of those was from RFC5405.  The first paragraph of that section (altered a bit) could be helpful in the set of warnings given here - basically, use something else if you need any security.  I don't think the rest really applies because you'd switch to SFTP or something else rather than layer on security to TFTP in reality.

Here is a link to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg04922.html

Thank you for addressing my concerns!

Thank you for addressing my Discuss point.

I had one sentence in my proposed text that I didn't see in -12, that I wish was in there:

“The windowsize extension is intended for use in managed networks, where any
instances of sustained congestion loss will be noticed and corrected."

But the text you did use is sufficient to resolve the Discuss.

Section 7 says: "The use of TFTP is appropriate on networks
where the inherent protocol limitations are not a liability."
I think that would be better as a negative myself, e.g. maybe
something like "The use of TFTP is inappropriate on networks
where confidentiality, authentication or access control are
needed." (And note that I personally don't think that that
means TFTP is safe on all LANs.) However, just deleting the
sentence would be fine, since it has little or nothing to do
with this extension. Note: I don't feel that strongly about
this, so feel free to ignore me.

Nothing to do with this draft, but it would be a fine thing
if someone were interested doing the work to improve the
security of TFTP.

The new text is clearer—thanks!