Subject: [apps-discuss] Missing IANA Considerations for TFTP

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 21 Aug 2011 12:38:35 +0300

Hello all,

Trivial File Transfer Protocol (TFTP), which is defined in RFC 1350 
(that is currently at Full Standard level, BTW), makes use of several 
values which are to be tracked by IANA.  They include: OpCode values, 
transfer modes, error codes, and option numbers (see RFC 2347 for 
description of the latter).  However, currently IANA doesn't maintain 
any registries related to TFTP, neither can I find any in RFC 1700, the 
last of "Assigned Numbers" series.  Correspondingly, the question:  Is 
it useful to write and publish the document defining IANA considerations 
for TFTP?

Mykyta Yevstifeyev

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 21 Aug 2011 19:49:03 +0200

On 21 August 2011 11:38, Mykyta Yevstifeyev wrote:

> currently IANA doesn't maintain any registries related to TFTP

Arguably "bootp-dhcp-parameters" is related, maybe TFTP assignments
could be merged into this existing registry.

> Is it useful to write and publish the document defining IANA
> considerations for TFTP?

The authors of RFCs 2347..2349 apparently decided that it was not
necessary to create TFTP registries in 1998.  Only a wild guess,
"missing" IANA considerations cannot say why they are "missing".
Did you look into old mailing list archives?

If it is a general IANA registry problem let's discuss it on the
"happy IANA" list.  The service-names-port-numbers.xml is *huge*,
but the TFTP ports, four SUBNTBCST_TFTP variants, tftp-mcast,
etftp, and tftps are listed.  But this registry doesn't tell me
what ETFTP, TFTPS, etc. really was or is.

-Frank

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 22 Aug 2011 07:18:25 +0300

> could be merged into this existing registry.

I had a look at this registry - it isn't related to TFTP in any way 
other than listing several DHCP options related to TFTP.

> Did you look into old mailing list archives?

Well, the only WG ever chartered and related to TFTP is some way is 
tftpext, which produced RFCs 1782-1784 
(http://tools.ietf.org/wg/tftpexts/).  IETF site has no archives; 
neither have some non-IETF archives (I found 
http://mirrors.fe.up.pt/pub/rfc/concluded-wg-ietf-mail-archive/tftpexts/ 
and 
http://ftp.sh.cvut.cz/MIRRORS/ietf/concluded-wg-ietf-mail-archive/tftpexts/).  
The original mailing list was hosted at hpindsh.cup.hp.com and original 
archive was placed at 
onet2.cup.hp.com/pub/dist/tftpexts/tftpexts_archive (see 
http://webcache.googleusercontent.com/search?q=cache:xueLfMKFuxoJ:ftp://ftp.ietf.org/ietf-online-proceedings/94dec/area.and.wg.reports/app/tftpexts/tftpexts.malkin.slides.ps+Tftpexts+mailing+archive&cd=1&hl=en&ct=clnk&client=firefox&source=www.google.com).  
However, none of those servers responded to me; so I conclude it is 
impossible to find tftpext archives.

RFCs 2347..2349 were Individual Submissions, and their only purpose, I 
guess, was to advance tftpext stuff to Draft Standard.

IESG "protocol action" message 
(http://www.ietf.org/mail-archive/web/ietf/current/msg05939.html) 
doesn't have the "community consensus" section, which would point me to 
some discussion forum.  It mentions, though, that IESG contact person is 
Harald Alvestrand, whom I'm cc'ing this message to supposing he has some 
additional info for this topic.

So now I have no idea why TFTP IANA considerations are missing.

> what ETFTP, TFTPS, etc. really was or is.

I guess the situation is:

tftp - RFC 1350;
subntbcast-tftp - have no idea what is stands for;
tftps - I suppose this is used with something like an "adaptation of 
4217 for TFTP";
tftp-mcast - 
https://datatracker.ietf.org/doc/draft-koren-tftp-multicast-option/; 
https://datatracker.ietf.org/doc/draft-rfced-exp-yung/;
etftp - RFC 1986; http://www.networksorcery.com/enp/protocol/etftp.htm.

Mykyta Yevstifeyev

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 22 Aug 2011 08:01:24 +0200

TFTP is a protocol of ultimate stupidity^^^^naivete, made for a simpler 
and less paranoid world; why do you want to touch it at all?

As to why the protocol action from May 1998 does not mention IANA 
considerations - this was before the IANA considerations got completely 
institutionalized - RFC 2434 was still 5 months in the future.

My very vague memory of this action was that it was a personal effort 
from Gary Malkin to promote to Draft the useful parts of the results of 
the expired TFTP group, hoping eventually to be on the same level 
(Standard) as the base spec. Note that these are advancement-in-grade 
RFCs; the Proposed Standard versions were published in 1995.

My recommendation: It's been 15 years or more since someone really cared 
about these non-registries. Let this particular corpse sleep in peace.

                         Harald

On 08/22/2011 06:18 AM, Mykyta Yevstifeyev wrote:
> The original mailing list was hosted at hpindsh.cup.hp.com and 
> original archive was placed at 
> doesn't have the "community consensus" section, which would point me 
> to some discussion forum.  It mentions, though, that IESG contact 
> person is Harald Alvestrand, whom I'm cc'ing this message to supposing 
> he has some additional info for this topic.
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Aug 2011 03:27:48 -0400

--On Monday, August 22, 2011 08:01 +0200 Harald Alvestrand
<[email-masked]> wrote:

> TFTP is a protocol of ultimate stupidity^^^^naivete, made for
> a simpler and less paranoid world; why do you want to touch it
> at all?
> 
> As to why the protocol action from May 1998 does not mention
> IANA considerations - this was before the IANA considerations
> got completely institutionalized - RFC 2434 was still 5 months
> in the future.
>...
> My recommendation: It's been 15 years or more since someone
> really cared about these non-registries. Let this particular
> corpse sleep in peace.

+1

I would add two things to Harald's comments:

-- Historically, we rarely created IANA registries for protocol
options unless we expected an ongoing series of added options.
As an example, the FTP registry created by RFC 5797 arguably
should have been created when a formal extension mechanism was
established in RFC 3659, but none was established earlier
despite the fact that the authors of RFC 959 could have
established such a registry with no external approval action
whatsoever.

-- Because TFTP lacks even rudimentary, symbolic, security
mechanisms, it is unsuited for use on the public Internet.  If
it is appropriate for any use at all any more, it is for
well-protected LANs and walled gardens with really high and
effective walls.  If someone wanted to put in energy on TFTP
today, I think that energy would be better spent in a good
security analysis and set of recommendations as to how to use it
safely.   Such a document would probably be difficult to write
unless one took the easy path of a document that, boilerplate
and structure aside, would consist of one line: "Just say 'no'".

   john

---

From: "t.petch" <[email-masked]>
Date: Mon, 22 Aug 2011 09:41:09 +0200

----- Original Message -----
From: "Mykyta Yevstifeyev" <[email-masked]>
To: "Apps-discuss list" <[email-masked]>
Sent: Sunday, August 21, 2011 11:38 AM

> it useful to write and publish the document defining IANA considerations

No.

Dead protocol in the sense that it is not one that the IETF has worked on for
decades.

Now an I-D which declared it Historic, for some meaning of Historic, that might
be interesting ....

Tom Petch

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 22 Aug 2011 10:53:13 +0200

On 22 August 2011 09:27, John C Klensin wrote:

> Historically, we rarely created IANA registries for protocol

Good.  Creating obscure IANA registries and expert review lists
before they are actually needed could be pointless, i.e., as
long as all interesting protocol parameters can be found in one
RFC.  And expert review lists not more working after years when
eventually somebody found something to register would be worse.

> established in RFC 3659

Only four of five stars, because RFC 5797 does not mention the
registry URL.  But the RFC 3659 registry is a dubious example:
<URL:http://www.iana.org/assignments/os-specific-parameters>

> Because TFTP lacks even rudimentary, symbolic, security
> mechanisms, it is unsuited for use on the public Internet.

Maybe the TFTPS in the port registry was meant to improve it.
When a modern BIOS offers a "net boot" it *is* talking about
TFTP, or isn't it?  I'm not planning to implement or test it.

There is even a registered TFTP URI scheme in RFC 3617, and if
I understand RFC 3617 correctly it tried to *deprecate* TFTP
without actually doing it using pre STD 66 terminology.  But I
have an idea what happened, note to self, do not try to update
cram-md5 by scram-md5, or rather, don't try this in the IETF.

> If someone wanted to put in energy on TFTP today, I think
> that energy would be better spent in a good security analysis
> and set of recommendations as to how to use it safely.

"Security" is some IETF stuff that is deprecated before I begin
to grok what it was actually about, I try to avoid it unless it
is a nice test case for an MD5 test suite:  It can now emulate
RFC 2777, did you ever wish to check NomCom random selections
for the years before RFC 3797?  <gd&r>

-Frank