Re: TFTP URL

Hi.

Patrik suggested that I post these notes back to this list.

Quick summary:  TFTP, while useful for some purposes, is not, by
a wide margin, our best example of operationally- or
security-conscious protocol design.  It should not be used
except under carefully-constrained and controlled circumstances
(the RFCs on it say that).  Consequently, unless there is a very
strong argument showing why we need a URL type for it, one of
those (or anything else that encourages "just click here" or
"just execute that line" use should be avoided.  Obviously, we
know how to do a URL for it, but the fact that we can doesn't
indicate that we should.

Just my opinion, but I'm happy to show scars and tell war
stories if needed.

   john

Henning,

While it is necessary (not important enough to try to deploy a
replacement) to other things we do, TFTP is a _bad_ protocol and
several efforts have been made to restrict its use or even to
deprecate it.  The analogy to anonymous FTP in your security
section is not adequate; the other problem is that, in practice,
the TFTP client/receiver has even less assurance that it is
getting the right file, with valid content, than is the case with
anonymous FTP's somewhat more extensive handshaking.  I.e., the
problem is less the public-ness of the file, but confidence about
its contents.   There is also potential for DOS attacks, etc.

We have learned to live with TFTP in, e.g., the DHCP case because
we hope that process of having to configure it into another
protocol will lead to consideration of issues and risks and/or
isolation of client and server into protected LANs.  Providing an
easy, "one-click", URL interface would seem to have negative
value relative to thos considerations.

So, speaking personally, I'd like to see this go away.  If there
is actual need for it, I'd like to see that need documented along
with a security considerations section that really explores the
risks, problems, and alternatives (e.g., in what cases would a
TFTP URL be useful for which an FTP or HTTP URL would not
suffice?).

The fact that we know how to define/specify something doesn't
imply that we should.  The requirement that the IETF approve
these things was intended at least as much to let them apply a
standard of good taste as it was that the documents be reviewed
technically.

    john


--On Monday, 19 November, 2001 07:23 +0100 Patrik Fältström
<paf@cisco.com> wrote:

> --On 2001-11-18 21.02 -0500 "Henning G. Schulzrinne"
> <hgs@cs.columbia.edu> wrote:
> 
>> More than seven months ago, I had sent the following message,
>> but as far as I can tell, received no reply. Should I just
>> send you this as an individual submission? The draft has been
>> at
>> http://www.ietf.org/internet-drafts//draft-schulzrinne-tftp-ur
>> l-00.txt since that time.
>> 
>> Since RFC 2717 requires a standards-track document for most
>> new URL schemes, just submitting this to the RFC editor for
>> publication as informational is not likely to work.
>> 
>> Your help and advice is appreciated.
> 
> Send an announcement to the following lists, where URI's are
> discussed, and request comments:
> 
>    uri@w3c.org
>    discuss@apps.ietf.org

--On Monday, 19 November, 2001 10:10 -0500 "Henning G.
Schulzrinne" <hgs@cs.columbia.edu> wrote:

>> While it is necessary (not important enough to try to deploy a
>> replacement) to other things we do, TFTP is a _bad_ protocol
>> and several efforts have been made to restrict its use or even
>> to deprecate it.  The analogy to anonymous FTP in your security
> 
> However, it remains in extremely wide-spread use for updating
> boot ROMs and configuration files, among other uses.

No question about it.  But your document provides no explanation
as to why those applications require a URL type.  Several have
worked very successfully without one for years.   And I'd argue
that most configuration file uses are ones that IETF should
discourage --and point toward DHCP or something like ACAP--
rather than encouraging more use of TFTP by making it easier to
use.

>> section is not adequate; the other problem is that, in
>> practice, the TFTP client/receiver has even less assurance
>> that it is getting the right file, with valid content, than is
>> the case with anonymous FTP's somewhat more extensive
>> handshaking.  I.e., the
> 
> Could you elaborate on that? That would be a difference worth
> describing in more technical detail. 

Yes, but not at this moment.  I'm trying to get the "DNS search"
materials out, and they are a lot more important.

>> We have learned to live with TFTP in, e.g., the DHCP case
>> because
> 
> I'm not sure I understand the relationship to DHCP (except as an
> "instigator" that triggers tftp), but from all I can tell, tftp
> is used in millions of embedded devices, with and without DHCP.
> Many of these devices won't necessarily even implement TCP.

I need to go back and look at the spec, but I don't recall TFTP
being defined except in TCP terms.

>> we hope that process of having to configure it into another
>> protocol will lead to consideration of issues and risks and/or
>> isolation of client and server into protected LANs.  Providing
>> an easy, "one-click", URL interface would seem to have negative
>> value relative to thos considerations.
> 
> The idea is not to provide a one-click URL on a web page; the
> motivation is to have an easy means to encode this information
> where multiple update protocols can be used, typically in
> configuration files and other similar locations. For example,
> it is rather natural to have
> 
> http://www.someserver.org/config
> or
> ftp://www.someserver.org/config
> or
> tftp://www.someserver.org/config

For the first twenty or so years of the ARPANET and Internet, it
was considered equally natural, or more so, to have "open a TFTP
connection to foo.someserver.org and obtain the file called
"config".

>> So, speaking personally, I'd like to see this go away.  If
>> there is actual need for it, I'd like to see that need
>> documented along with a security considerations section that
>> really explores the risks, problems, and alternatives (e.g.,
>> in what cases would a TFTP URL be useful for which an FTP or
>> HTTP URL would not suffice?).
> 
> One reason is above - many of the devices don't support the
> protocols mentioned.

That explains TFTP, not URLs.

>> The fact that we know how to define/specify something doesn't
>> imply that we should.  The requirement that the IETF approve
>> these things was intended at least as much to let them apply a
>> standard of good taste as it was that the documents be reviewed
>> technically.
> 
> If tftp is so bad, shouldn't it be deprecated as historic
> rather than being STD 33?

It has not been felt, so far, to be bad enough that we have
standardized an alternative.  And other standards depend on it,
as noted above and elsewhere.  But things are standardized within
an applicability context, and I'm reluctant to see the
applicability of TFTP broadened and more reluctant to see it
appear in contexts that seem to encourage general use.

    john