Re: ops-operator-req-mgmt-01

[john heasley <heas@shrubbery.net>]

Wed, Dec 26, 2001 at 11:22:12PM -0700, Steve Scheck:
> On Wed, 26 Dec 2001, Bill Woodcock wrote:
> 
> >     > i completely disagree with omission of FTP.  ftp is an excellent method
> >     > to upload router core dumps that exceed the size capabilities of tftp.
> >     > just as it a good way to download images, while tftp is udp and i sure
> >     > dont want scp logins from routers to my config servers.  ftpd can be run
> >     > anonymous only and can use tcp_wrapper like filtering features.  ftp
> >     > client should be a requirement.
> >
> > Why would you prefer unencrypted ftp logins to encrypted scp logins?
> >
> > Can you find a significant number of people who are in agreement with you
> > and are willing to tell me so?
> >
> >                                 -Bill
> 
> Gack, my apologies for the previous, incomplete response.
> 
> In the event Mr. Heasley finds more in support of his position, here is
> one more in disagreement with him :)
> 
> I completely disagree with including ftp client support as a requirement.
> FTP is a flawed, insecure protocol and its further acceptance should not

yes, it is insecure.  but please tell me why it is flawed (ie: does not
work)?  what about core dumps of cisco linecards (256M+) to an scp (ssh)
account without a password?  no thanks.

> be validated by having it required in this or any future standards
> document. A reasonable compromise is to omit any language
> specifically requiring its omission (that would be my preference), thereby
> allowing vendors to include it if they see fit, but also requiring them
> to include SCP/SFTP or a reasonable alternative.

ditch tftp?  not something i'd expect to be an omission by requirement;
its very simple to implement and thus can be in bootproms, etc.  note
that tftp is very insecure.  to not allow any of these is a step backward;
if you wish not to use ftp, tftp, or whatever that is fine, but dont
oppress others.  the tool with the most "features" is not necessarily the
right tool.

> IMO, there is no reason why we can't settle on existing secure protocols,
> or if they are deemed insufficient, spawn a new working group and come up
> with something else. Can't we move beyond "almost secure" and choose
> something which we have no doubts about?
> 
> -sjs
> 
> --------------------------------------------------------------------------
> The opinions expressed are not necessarily congruent with those of my
> employer.
>