Re: Rant (Was Re: Our friend FTP, again)

["Ryan Russell" <Ryan.Russell () sybase com>]

> I did a presentation about a year ago at Black Hat in which I
> advocated scrapping the current app base and starting over.

I was there for that, and I have to say I agree.

> Let's take HTTP for another example. It's _proof_ that you
> can massively deploy a whole new protocol in almost no time
> at all. Indeed, it got end users in the habit of downloading
> new code every week. By Jan 1, 2000, I bet that the vast
> majority of people will be running a newer version of a
> browser than they are now. We _can_ ditch old code; we just
> don't choose to ditch _enough_ of it.

Seems clear that the criteria for adopting new standards is
the snazzy factor, not whether they're "better" in any way.

> A few very simple draconian standards would go a long, long
> way.

I think we all realize (as you say later) that we can't force 'em..
we have to trick 'em.  Something akin to getting kids to
eat something because they think they like it, when in
fact it's good for them.

> This would possibly mean a little bit of extra thinking and
> maybe a bit of extra coding (probably not) on the part of
> app developers, but think of the implications! It'd do a
> hell of a lot more for security than IPSEC will, and it'd
> mean that crafting a firewall would be a weekend's work
> for someone who knows how to add lookup tables into a router.

In what way?  Are we assuming crypto everywhere, or just
well-defined, well-implemented standards, and fewer of them?
Are we talking back to the FWTK, and it only needing to know
5 protocols? (see below.)

> Mandating use of some kind of decent API for "Internet Ready"
> apps would also mean that (gosh, darn!) developers would
> not have to re-code their own basic protocol building blocks
> from scratch every time.

Here's what I actually wanted to comment on.  I see only a handful
of basic underlying protocols:  send files (ftp, http, smtp?), ask
a small question (dns, snmp, ntp), stream a media thing (way
too many to bother naming), interactive remote thing (telnet, X,
irc, icq) and that's about it, except for smallish variations
(remote mount as variant of file transfer.. cifs, nfs, afs)

Sounds awfully limiting, doesn't it?  Well.. one would think
that only two transport protocols wouldn't do it, but darn
if you can't implement whatever the heck you like over UDP,
and TCP gets nearly all of the default behaviour right.

Perphaps we need some real APIs for IP at layers 5 and
6 to implement this stuff.

Again, this is a bit idealistic... I question whether IPv6 will
ever be implemented outside of things like the 6bone.

Back to reality.. and the FTP question.  I think this one is actually
(conceptually) do-able.  To kill FTP:

Get three web-server groups (IIS, Netscape, Apache) and
the W3C to add in HTTP 1.2 the upload piece.. go ahead
and throw in all the FTP server options.  Make a command
line http program for Windows and *nix.  Make an http
transfer program for the Mac that isn't a web browser.
Screw the other 10% that's left.  Upload could be
done in web browsers, too, but it's not absolutely
neccessary.

The sad part is that the code could be written by
*1* person, in a couple of months.  Hell, I could
write a FTP upload server replacement for HTTP
as a CGI script, to work with any browser.  The hard
part is getting agreement from groups.  Let's go
throw it into Apache and Mozilla :)

> PS - I am going to exercise moderator's privilege and not
> forward responses to this rant unless they are truly illuminating,
> thought-provoking, and (at least) more interesting than the
> rant itself. ;)

You bastard! :)

                         Ryan

P.S. Remove my last comment there if needed.. or bounce it
and tell me to.  I know for certain that you (Marcus) can take
a joke, but I understand not everyone else on the list can
take one on your behalf.