Subject: New file transfer protocol: FSP
Please read The Standard Disclaimer regarding information found in these pages.
To return to the top of the Corcoran document archives Click Here
If you came here directly from a search engine, and would like to
view these pages in the proper frames from the top,
Start Here
Or start at the very top of
Mike Corcoran's home page
Date: Thu, 06 May 93 22:54:37 -0700
From: Brent Chapman
Sender: Firewalls-Owner@GreatCircle.COM
There's apparently a new file transfer system, called FSP, gaining
acceptance on the Internet as an alternative to anonymous FTP. The
salient characteristics from a Firewalls point of view are that it is
a connectionless service (it uses UDP rather than TCP), and that there
is apparently no single widely-used well known port for FSP servers.
The software is available for anonymous FTP on ftp.uu.net, file
"networking/archival/fsp.25.tar.Z". I've appended the "INFO" file
for review.
Has anybody had any experience with this yet, particularly from a
Firewalls and network security point of view?
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
Interested party please email
wen-king@vlsi.cs.caltech.edu
What is the purpose of FSP (V2.5):
FSP is a set of programs that implements a public-access archive
similar to an anonymous-FTP archive. It is not meant to be a
replacement for ftp; it is only meant to do what anonymous-ftp
does, but in a manner more acceptible to the provider of the
service and more friendly to the clients.
Providing anonymous-FTP service can be costly --- each active
session consumes one process slot in the OS and one stream socket
entry in the network sub-system. The servers can also run
concurrently, adding to the system load. A popular archive site
can easily be overwhelmed as a result. Some were forced to
shutdown or and some impose inconvienent access restrictions.
Unlike FTP, FSP is connection-less and virtually state-less. One
server handles requests from all clients machines. Each active
client machine takes up 16-bytes in a dynamically extensible
table. Since only one server runs at any time, the load added
to the server machine is no more than one.
In exchange for allowing site operators to keep their sites open
and do away with cumbersome access restrictions, this is what the
clients accept with FSP:
1) Lower transfer rate. The maximum rate is 1 kbyte per UDP
message round-trip time between the client and the server.
Return-Path: Firewalls-Owner
Return-Path:
From: chk@alias.com (C. Harald Koch)
Message-Id: <9305071448.AA07727@dino.alias.com>
Subject: Re: New file transfer protocol: FSP
To: brent@GreatCircle.COM (Brent Chapman)
Date: Fri, 7 May 1993 11:48:03 -0400
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9305070554.AA04741@mycroft.GreatCircle.COM> from "Brent Chapman" at May 7, 93 01:54:37 am
X-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1233
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> There's apparently a new file transfer system, called FSP, gaining
> acceptance on the Internet as an alternative to anonymous FTP. b
1) FSP has mainly been used for 'underground' purposes, i.e. GIFs, pirated
software, and so on. (That may have changed). Many sites disallow it on
this basis.
2) The major design issue of FSP, namely that it uses UDP instead of TCP, is
flawed. UDP doesn't have any of the congestion control or avoidance
systems that have been placed into TCP over the years. FTP is just fine
on modern IP systems, since network transients don't tear down a TCP
connection anymore (That was a BSD bug, and has slowly been eradicated).
Apparently, FSP has started causing problems already on some slower IP
links, since it doesn't do any congestion control. It's only a matter of
time before the larger network providers notice it, and take steps.
>From a security point of view, it's like any other UDP service, i.e.
impossible to control. :-)
--
C. Harald Koch, Network Manager | "Procrastination is just another technique
Alias Research Inc. Toronto, ON | for planning ahead!"
chk@alias.com |
chk@gpu.utcc.utoronto.ca | -Steve Seargeant
From Firewalls-Owner Fri May 7 20:27:17 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12614; Fri, 7 May 93 20:27:17 GMT
Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12605; Fri, 7 May 93 13:27:11 PDT
Message-Id: <9305072027.AA12605@mycroft.GreatCircle.COM>
To: Firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
Date: Fri, 07 May 93 13:27:09 -0700
From: Brent Chapman
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Everything I've heard about FSP so far (particularly about how it seems
to be being used) leads me to the conclusion that it's yet another reason
to sharply limit UDP (except for server-to-server DNS and NTP) through a
firewall.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
From Firewalls-Owner Fri May 7 20:57:25 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12732; Fri, 7 May 93 20:57:25 GMT
Received: from kahala.soest.hawaii.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12725; Fri, 7 May 93 13:57:16 PDT
Date: Fri, 7 May 93 10:58:14 HST
From: "Bob Cunningham"
Message-Id: <9305072058.AA06993@kahala.soest.hawaii.edu>
Received: by kahala.soest.hawaii.edu (4.1/kahala-MX-3.3)
id AA06993; Fri, 7 May 93 10:58:14 HST
To: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
There may be benign uses of fsp, but personally I've not seen it used
EXCEPT by crackers. It appears to be their tool of choice for
transferring file in a relatively untraceable manner.
One person who has "visited" some of the systems around here has about
12MBytes of compressed tar files containing virtually all the cracking
tools you could imagine (and more) that he transfers all around using fsp.
From Firewalls-Owner Fri May 7 22:55:16 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA13407; Fri, 7 May 93 22:55:16 GMT
Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA13399; Fri, 7 May 93 15:55:07 PDT
Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI)
for brent@GreatCircle.COM id AA16212; Fri, 7 May 93 15:56:06 -0700
Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI)
for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA06944; Fri, 7 May 93 15:56:06 -0700
Date: Fri, 7 May 93 15:56:05 PDT
From: Eliot Lear
To: chk@alias.com (C. Harald Koch)
Cc: brent@GreatCircle.COM (Brent Chapman), firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of Fri, 7 May 1993 11:48:03 -0400
Message-Id:
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> 2) The major design issue of FSP, namely that it uses UDP instead of TCP, is
> flawed. UDP doesn't have any of the congestion control or avoidance
> systems that have been placed into TCP over the years. FTP is just fine
> on modern IP systems, since network transients don't tear down a TCP
> connection anymore (That was a BSD bug, and has slowly been eradicated).
UDP is extremely useful if an individual is sending TCP resets to your
FTP server/and or/client. FSP conveniently gets around such bit
watchers, and is likely the result of overly draconian usage
enforcement policies.
Eliot Lear
[lear@sgi.com]
From Firewalls-Owner Fri May 7 21:53:26 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA13009; Fri, 7 May 93 21:53:26 GMT
Received: from lbl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA12995; Fri, 7 May 93 14:52:54 PDT
Received: from ccsun.unicamp.br (obelix.unicamp.br) by lbl.gov (4.1/1.39)
id AA21988; Fri, 7 May 93 14:54:55 PDT
Received: from dcc.unicamp.br by ccsun.unicamp.br (4.1/SMI-4.0)
id AA14535; Fri, 7 May 93 18:35:34 BSC
Received: from iguacu (iguacu-gw) by dcc.unicamp.br (4.1/SMI-4.1) id AA15438; Fri, 7 May 93 18:40:33 EST
Date: Fri, 7 May 93 18:40:33 EST
From: paulo@dcc.unicamp.br (Paulo Licio de Geus)
Message-Id: <9305072140.AA15438@dcc.unicamp.br>
Received: by iguacu (4.1/SMI-4.1)
id AA25559; Fri, 7 May 93 18:40:31 EST
To: "Bob Cunningham"
Cc: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
References: <9305072058.AA06993@kahala.soest.hawaii.edu>
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
"Bob Cunningham" writes:
> There may be benign uses of fsp, but personally I've not seen it used
> EXCEPT by crackers. It appears to be their tool of choice for
> transferring file in a relatively untraceable manner.
>
> One person who has "visited" some of the systems around here has about
> 12MBytes of compressed tar files containing virtually all the cracking
> tools you could imagine (and more) that he transfers all around using fsp.
Correction. We live on a very low speed link to the rest of the
world, where ftp usually never finishes for anything >500KBytes. In
that situation FSP is the only thing that allows us to transfer data
when anyone else would just do ftp. There are very few sites
supporting the protocol, but these sometimes saves your day.
Facts: this country relies on two 64Kbits/s links to the rest of the
world, and this place is connected to the main country backbone
through a combo of 9.6+4.8 kbits/s. And, surprise, we maintain
everything here up to date.
Yes, *there are* benign uses of FSP. Just remember that.
--
postmaster/manager
Paulo Licio de Geus INTERNET: paulo@dcc.unicamp.br
Depto de Ciencia da Computacao voice: +55 192 39-3115/8695/8442
DCC - IMECC - UNICAMP fax: +55 192 39-7470/5808
caixa postal: 6065
13081 Campinas SP Brazil
From Firewalls-Owner Mon May 10 14:03:36 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20448; Mon, 10 May 93 14:03:36 GMT
Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20441; Mon, 10 May 93 07:03:27 PDT
Received: from alias by yonge.csri.toronto.edu with UUCP id <14407>; Mon, 10 May 1993 10:04:18 -0400
Received: from dino.alias.com by barney.alias.com with SMTP id AA25399
(5.65a/IDA-1.4.2 for paulo@dcc.unicamp.br); Mon, 10 May 93 10:00:02 -0400
Received: by dino.alias.com id AA17886
(5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Mon, 10 May 93 10:00:00 -0400
From: chk@alias.com (C. Harald Koch)
Message-Id: <9305101400.AA17886@dino.alias.com>
Subject: Re: New file transfer protocol: FSP
To: paulo@dcc.unicamp.br (Paulo Licio de Geus)
Date: Mon, 10 May 1993 10:59:59 -0400
Cc: firewalls@GreatCircle.COM
In-Reply-To: <9305072140.AA15438@dcc.unicamp.br> from "Paulo Licio de Geus" at May 7, 93 07:40:33 pm
X-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1268
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> Yes, *there are* benign uses of FSP. Just remember that.
Hmm. I suspect this is going to end up just like the pay-phones argument in
the U.S.:
1) Many payphones in downtown areas in U.S. cities are being removed or
severely disabled, because their main use was by drug-trafficers. This
often removes the only telephones accessible by people in those
neighbourhoods who can't afford their own phones.
2) Many payphones (esp. in airports) are no longer able to make calling-card
calls to many foreign nations, because most of the calls to those places
were being made using stolen cards. This also impacts people who are
legitimately calling those countries using credit cards.
The question is, is it 'right' to disable a useful tool just because most of
that tools common usage is anti-social? Should we ban FSP just because it's
most commonly a cracker's tool?
(Y'all know already that my answer is a firm "Yes!"...)
--
C. Harald Koch, Network Manager | "Cable is not a luxury, since many areas have
Alias Research Inc. Toronto, ON | poor TV reception". - Mayor, Tucson AZ, 1989
chk@alias.com | [ apparently, good TV reception is a basic
chk@gpu.utcc.utoronto.ca | necessity -- at least in Tucson -kl ]
From Firewalls-Owner Mon May 10 15:47:09 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20600; Mon, 10 May 93 15:47:09 GMT
Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20592; Mon, 10 May 93 08:46:11 PDT
Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1)
id AA11204; Mon, 10 May 93 11:14:19 EDT
Received: from lehman.com by shearson.com (4.1/LB-0.6)
id AA13613; Mon, 10 May 93 11:08:11 EDT
Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1)
id AA11173; Mon, 10 May 93 11:08:09 EDT
Received: from snark.shearson.com by shearson.com (4.1/LB-0.6)
id AA13609; Mon, 10 May 93 11:07:33 EDT
Received: by snark.shearson.com (4.1/SMI-4.1)
id AA14651; Mon, 10 May 93 11:07:31 EDT
Message-Id: <9305101507.AA14651@snark.shearson.com>
To: paulo@dcc.unicamp.br (Paulo Licio de Geus)
Cc: "Bob Cunningham"
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of "Fri, 07 May 1993 18:40:33 EST."
<9305072140.AA15438@dcc.unicamp.br>
Reply-To: pmetzger@lehman.com
X-Reposting-Policy: redistribute only with permission
Date: Mon, 10 May 1993 11:07:31 -0400
From: "Perry E. Metzger"
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Paulo Licio de Geus says:
> "Bob Cunningham" writes:
> > There may be benign uses of fsp, but personally I've not seen it used
> > EXCEPT by crackers. It appears to be their tool of choice for
> > transferring file in a relatively untraceable manner.
> >
> > One person who has "visited" some of the systems around here has about
> > 12MBytes of compressed tar files containing virtually all the cracking
> > tools you could imagine (and more) that he transfers all around using fsp.
>
> Correction. We live on a very low speed link to the rest of the
> world, where ftp usually never finishes for anything >500KBytes. In
> that situation FSP is the only thing that allows us to transfer data
> when anyone else would just do ftp. There are very few sites
> supporting the protocol, but these sometimes saves your day.
> Facts: this country relies on two 64Kbits/s links to the rest of the
> world, and this place is connected to the main country backbone
> through a combo of 9.6+4.8 kbits/s. And, surprise, we maintain
> everything here up to date.
This sounds dubious. FSP doesn't do proper backoff on a link because
it uses udp, so its probably far worse for a slow unreliable link than
FTP. Furthermore, you can get FTP clients that will properly restart
aborted transfers where you left off -- its all part of the FTP
protocol. Furthermore, even if the line is slow, FTP shouldn't be
dropping things -- I suspect you have a buggy system if it is.
Everything should just transfer very slowly, thats all -- in practice
the line shouldn't be going down. Seems to me that using FSP can only
make things worse, not better, by clogging the line.
Perry Metzger
From Firewalls-Owner Mon May 10 18:33:11 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA21539; Mon, 10 May 93 18:33:11 GMT
Received: from uu3.psi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA21528; Mon, 10 May 93 11:33:01 PDT
Received: from bacon.UUCP by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AB18241 for ; Mon, 10 May 93 14:07:41 -0400
Received: from stimpys.imsi.com by bacon.IMSI.COM (4.1/SMI-4.1)
id AA14492; Mon, 10 May 93 13:57:36 EDT
Received: from localhost by stimpys.imsi.com (4.1/SMI-4.1)
id AA07274; Mon, 10 May 93 13:54:53 EDT
Message-Id: <9305101754.AA07274@stimpys.imsi.com>
To: pmetzger@lehman.com
Cc: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of "Mon, 10 May 1993 11:07:31 EDT."
<9305101507.AA14651@snark.shearson.com>
Reply-To: rens@imsi.com
Date: Mon, 10 May 1993 13:54:51 -0400
From: Rens Troost
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
>>>>> On Mon, 10 May 1993 11:07:31 -0400, "Perry E. Metzger"
pmetzger> This sounds dubious. FSP doesn't do proper backoff on a
pmetzger> link because it uses udp, so its probably far worse for a
pmetzger> slow unreliable link than FTP. Furthermore, you can get
Perry-
Actually, FSP uses a rather agressive exponential backoff scheme. I
have ascertained this by asking around quite a bit -- it would seem
that most FSP users are pretty ignorant of how it works -- see below.
But it seems designed to avoid NFS-style meltdowns under congestion.
Of course, TCP is better at this, since it uses an adaptive
retransmission scheme and not crude exponentiation.
pmetzger> FTP clients that will properly restart aborted transfers
pmetzger> where you left off -- its all part of the FTP protocol.
[ Wasn't this the subject of a mini flamewar on the ietf list? It
would seem restarting FTPs are not very widely distributed, or
particularly well understood by the public.]
pmetzger> to me that using FSP can only make things worse, not
pmetzger> better, by clogging the line.
I agree with the prognosis, but not the diagnosis. FSP seems to handle
congestion fine. It's got a lot of other problems, IMHO. These center
around
- who is using it (lots of fairly ignorant cracker types (c.f.
the discussion in alt.comp.fsp) who don't even know how to register
an assigned port number)
and
- why do we need another protocol which gives no real added value over
FTP, whose implementations are devoid of logging and security
features, and which suffers from an architecture apparently designed
to resist the inclusion thereof.
-Rens
--
o===============================================================o
| J. Laurens Troost - UNIX Systems | At Work: rens@imsi.com |
| Investment Management Svcs, Inc. | At Play: rens@century.com |
| 12 East 49th Street, 35th floor | Phone: (212) 339-2823 |
| New York, New York 10017 | Fax: (212) 444-1980 |
o===============================================================o
-- IMS is unlikely to share any of the above opinions --
From Firewalls-Owner Mon May 10 21:11:21 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22262; Mon, 10 May 93 21:11:21 GMT
Received: from cruskit.aarnet.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA22255; Mon, 10 May 93 14:10:51 PDT
Received: by cruskit.aarnet.edu.au id AA13584
(5.65c/IDA-1.4.4 for firewalls@greatcircle.com); Tue, 11 May 1993 07:04:37 +1000
From: Geoff Huston
Message-Id: <199305102104.AA13584@cruskit.aarnet.edu.au>
Subject: Re: New file transfer protocol: FSP
To: pmetzger@lehman.com
Date: Tue, 11 May 1993 07:04:36 +1000 (EST)
Cc: paulo@dcc.unicamp.br, bob@kahala.soest.hawaii.edu,
firewalls@GreatCircle.COM
In-Reply-To: <9305101507.AA14651@snark.shearson.com> from "Perry E. Metzger" at May 10, 93 11:07:31 am
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 619
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
I'd have to agree with Perry Metzger from a perspective of operational
experience....
FSP does not perform effective backoff within a congested environment,
causing increased router load through forcing the routers to undertake
extensive packet discards. The damage caused effects all sessions
through the congested link as the imposed load from FSP causes
increased variation of TCP round trip timers which in turn throws
the TCP sessions into a mode of extremely poor performance.
As a network operator, the perspective on FSP is that the currently
deployed versions of FSP are simply a pain!
Geoff Huston
AARnet
From Firewalls-Owner Tue May 11 14:59:14 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA25673; Tue, 11 May 93 14:59:14 GMT
Received: from heifetz.msen.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA25666; Tue, 11 May 93 07:59:07 PDT
Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11)
id
Received: by lokkur.dexter.mi.us
(5.65c/IDA-1.2.8) id AA02319; Tue, 11 May 1993 10:24:06 -0400
From: Steve Simmons
Message-Id: <199305111424.AA02319@lokkur.dexter.mi.us>
Subject: Re: New file transfer protocol: FSP
To: lokkur!greatcircle.com!firewalls
Date: Tue, 11 May 1993 10:24:06 -0400 (EDT)
In-Reply-To: <9305101754.AA07274@stimpys.imsi.com> from "Rens Troost" at May 10, 93 01:54:51 pm
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 147
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
If restart/recovery has been implemented in some generally available FTP
clients, I'd love get my hands on one. Perry, you made the statement....
From Firewalls-Owner Tue May 11 18:40:15 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26286; Tue, 11 May 93 18:40:15 GMT
Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26277; Tue, 11 May 93 11:40:06 PDT
Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI)
for brent@GreatCircle.COM id AA16124; Tue, 11 May 93 11:40:44 -0700
Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI)
for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA18320; Tue, 11 May 93 11:40:43 -0700
Date: Tue, 11 May 93 11:40:42 PDT
From: Eliot Lear
To: Brent Chapman
Cc: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of Mon, 10 May 93 10:47:03 -0700
Message-Id:
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> I think it's the responsibility of the folks promoting a
> tool to take at least simple steps to limit its susceptibility to misuse.
Were this the attitude long held to by society, we would have never
allowed the use of round wheels, rocks, or forks.
> The problem is, this tool has made it trivial to bypass established
> packet filtering mechanisms. Even the simple step of hard-coding a
> well-known-port into the software would have improved the security.
> Sure, it's trivial to edit the source and change the port, but I think
> most crackers wouldn't even go to that much effort.
The point was to bypass a recalcitrant administrator who went
overboard, snooping at people's packets. The tool wouldn't be useful
if the normal mechanisms were allowed to function for the desired
transfers.
Eliot Lear
[lear@sgi.com]
From Firewalls-Owner Tue May 11 22:41:51 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26937; Tue, 11 May 93 22:41:51 GMT
Received: from lokkur.dexter.mi.us (dexter-gw.dexter.msen.com) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26930; Tue, 11 May 93 15:41:25 PDT
Received: by lokkur.dexter.mi.us
(5.65c/IDA-1.2.8) id AA01101; Tue, 11 May 1993 18:39:35 -0400
From: Steve Simmons
Message-Id: <199305112239.AA01101@lokkur.dexter.mi.us>
Subject: Re: New file transfer protocol: FSP
To: lear@yeager.corp.sgi.com (Eliot Lear)
Date: Tue, 11 May 1993 18:39:35 -0400 (EDT)
Cc: brent@GreatCircle.COM, firewalls@GreatCircle.COM
In-Reply-To:
X-Mailer: ELM [version 2.4 PL11]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 743
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
I know Eliot didn't mean it this way, but conversations about this item
seem to have gone around both end and are meeting in the middle. Eliot
says:
>The point [of using FSP] was to bypass a recalcitrant administrator who went
>overboard, snooping at people's packets. The tool wouldn't be useful
>if the normal mechanisms were allowed to function for the desired
>transfers.
While someone else claims that we should consider banning it because it
is a common hackers tool.
What we have here is a tool developed to bypass the misuse of other tools
which is now itself being used for misuse. We should keep it because it
can bypass the misuse of the other tools, but should ban it because it
is primarily used for misuse.
I need a beer.
From Firewalls-Owner Tue May 11 23:45:21 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA27354; Tue, 11 May 93 23:45:21 GMT
Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA27341; Tue, 11 May 93 16:45:07 PDT
Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI)
for brent@GreatCircle.COM id AA05445; Tue, 11 May 93 16:46:11 -0700
Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI)
for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA19408; Tue, 11 May 93 16:46:10 -0700
Date: Tue, 11 May 93 16:46:10 PDT
From: Eliot Lear
To: Steve Simmons
Cc: lear@yeager.corp.sgi.com (Eliot Lear), brent@GreatCircle.COM,
firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of Tue, 11 May 1993 18:39:35 -0400 (EDT)
Message-Id:
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> I know Eliot didn't mean it this way, but conversations about this item
> seem to have gone around both end and are meeting in the middle.
Regrettably, this is exactly what I am trying to point out.
[...]
> What we have here is a tool developed to bypass the misuse of other tools
> which is now itself being used for misuse. We should keep it because it
> can bypass the misuse of the other tools, but should ban it because it
> is primarily used for misuse.
Please consider wisely what a firewall is for, and what it is not for.
If a firewall is for keeping the bad guys out, then depending on how
concerned you are with the exposed machines, you may well need to turn
off UDP, because it can effect an attack on random UDP ports
including, I might add, NTP, WAIS, talk, and DNS, just to name a few.
This will keep things `safe', albeit less useful.
However, if your goal is to prevent naughty bits from cutting across
your network, give up now. A new mechanism that circumvents best
efforts to turn off FSP will be along in a few weeks if people find
that they can't get their porn fix. I can see it now- FSP to FTP
application gateways. FSP is a prime example of what happens when one
implements a tyrranical policy ``in code'', when it is best
implemented in management. Remember, just because you *can* do it in
code, doesn't mean that you *should*.
Eliot Lear
[lear@sgi.com]
From Firewalls-Owner Wed May 12 02:13:30 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28847; Wed, 12 May 93 02:13:30 GMT
Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA28840; Tue, 11 May 93 19:13:22 PDT
Received: by TIS.COM (4.1/SUN-5.64)
id AA24576; Tue, 11 May 93 22:15:47 EDT
Date: Tue, 11 May 93 22:15:47 EDT
From: Marcus J Ranum
Message-Id: <9305120215.AA24576@TIS.COM>
To: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
FSP isn't for us to ban or not ban. It's something to understand
and be aware of in the context of whatever network security policy each
of us is tasked with enforcing. Clearly, if you're at one end of the
spectrum, and are concerned with unauthorized and untraceable export of
data, then FSP's probably something you want to block. If you're not too
concerned about data control it's less of a problem.
Most of the firewalls I've done in the past fell farther towards
the "control everything" side of the spectrum. To me "control everything"
implies "block everything" and that tends to lead towards non-routed
firewalls. Stuff like FSP and IP-over-IP tunnelling are general problems
with the screening router approach to firewall building. I'm not saying
there's anything wrong with screening routers; it all depends on what
you are trying to accomplish.
FSP is a non-issue. The issue is whether your firewall somehow
permits users to send data directly between networks. Implementing a
simple, inefficient reliable stream protocol on top of another packet
oriented service is left as an exercise to the reader - FSP is just an
example of one such. It happens to be an arguably *useful* example.
mjr.
From Firewalls-Owner Wed May 12 17:46:36 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA00955; Wed, 12 May 93 17:46:36 GMT
Received: from sgigate.sgi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA00948; Wed, 12 May 93 10:46:28 PDT
Received: from yeager.corp.sgi.com by sgigate.sgi.com via SMTP (920330.SGI/920502.SGI)
for firewalls@GreatCircle.COM id AA02926; Wed, 12 May 93 10:46:58 -0700
Received: by yeager.corp.sgi.com (930324.SGI/911001.SGI)
for @sgigate.sgi.com:firewalls@GreatCircle.COM id AA21099; Wed, 12 May 93 10:46:57 -0700
Date: Wed, 12 May 93 10:46:57 PDT
From: Eliot Lear
To: Steve Simmons
Cc: firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
In-Reply-To: Your message of Tue, 11 May 1993 21:28:27 -0400 (EDT)
Message-Id:
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> Re the conflict between capability and restriction, didn't Eliot say
> FSP was implemented because an admin was snooping packets? Not quite
> the same thing as claiming FSP was a way of working around restrictions
> on ftp.
Sorry. He was not only snooping packets, but was also sending TCP
RESETs to offending sites.
> I have real problems with the characterization of restrictive admins
> used as justification for implementing a file transfer protocol that is
> antisocial (no flow control) and deliberately designed to avoid the
> restrictions that the network owner attempts to put on it. If the
> owner decides "no ftp", it's the owners right.
No doubt. But that won't quench people's drive for sex or money.
Thus FSP, and whatever may follow. How much is this battle worth to
you?
Eliot Lear
[lear@sgi.com]
From Firewalls-Owner Wed May 12 23:36:17 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01788; Wed, 12 May 93 23:36:17 GMT
Received: from diemen.utas.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA01781; Wed, 12 May 93 16:35:59 PDT
Received: from bowen.cc.utas.edu.au by diemen.utas.edu.au with SMTP id AA05280
(5.65b/IDA-1.4.3 for Firewalls@greatcircle.com); Thu, 13 May 93 09:36:20 +1000
Received: by bowen.cc.utas.edu.au (4.1/SMI-4.1)
id AA02813; Thu, 13 May 93 09:36:19 EST
Date: Thu, 13 May 1993 09:12:59 +1000 (EST)
From: John Miezitis
Subject: Re: New file transfer protocol: FSP
To: Firewalls@GreatCircle.COM
In-Reply-To: <9305122202.AA01649@mycroft.GreatCircle.COM>
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
On Wed, 12 May 1993, Brent Chapman wrote:
> [ Irrelevant stuff deleted. (Irrelevant to my reply I mean) ]
>
> We now return you to your regularly scheduled ethics debate (honestly, I
> didn't mean to kick that ant hill when I brought up FSP)...
Brent,
I am very pleased that you did kick this ant hill. At this University we
have a problem with a handfull of students using FSP to gain copies of
pirated software. One student was found with a number of pirated games in
his account. The University is concerned about possible action that could
be taken against it and the image it presents by allowing this type of
behaviour.
The student in question had his account suspended but has since been
observed using other peoples accounts. So much for that approach. In
desperation myself and a Systems Programmer have been discussing what
could be done about this.
Suggestions have ranged from denying Internet access to all students, to
blocking all UDP traffic except for essential services. So far no further
action has been taken until we can come up with something that will be
effective. Any suggestions?
For me the most troubling aspect of FSP is that I can't monitor the
traffic to see how much of a problem it really is. Currently I use NNStat
to keep statistics of all traffic to and from our network from which I can
get a breakdown of how much is FTP, SMTP etc. FSP reduces the usefulness
of this data.
Cheers.
JohnM.
John B Miezitis, University of Tasmania, Information Technology Services.
Intl Ph: +61 02 202811, Aus Ph: 002 202811, Email: John.Miezitis@cc.utas.edu.au
Belgium man Belgium!!! - Z. Beeblebrox
_______________________________________________________________________________
From Firewalls-Owner Thu May 13 16:22:35 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA04108; Thu, 13 May 93 16:22:35 GMT
Received: from spock.retix.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA04101; Thu, 13 May 93 09:22:28 PDT
Received: from mproj.retix.com by spock.retix.com (ALPHA-6.56/6.28) id JAA20373; Thu, 13 May 1993 09:23:36 -0700
Received: by mproj.retix.com (5.65a/smail2.5/9-30-90)
id AA05422; Thu, 13 May 93 09:24:22 -0700
Date: Thu, 13 May 93 09:24:22 -0700
From: dspencer@mproj.retix.com (David Spencer)
Message-Id: <9305131624.AA05422@mproj.retix.com>
To: Firewalls@GreatCircle.COM
Subject: Re: New file transfer protocol: FSP
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> On Wed, 12 May 1993, Brent Chapman wrote:
>
> ...
>
> Suggestions have ranged from denying Internet access to all students, to
> blocking all UDP traffic except for essential services. So far no further
> action has been taken until we can come up with something that will be
> effective. Any suggestions?
Yeah you can block UDP traffic but then 'v2' of FSP will
be developed which you use a non-hardcoded TCP port and
then won't you be back in the same boat? Or a cloaking
version of FSP which uses multiple TCP ports...
From Firewalls-Owner Thu May 13 20:47:08 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05132; Thu, 13 May 93 20:47:08 GMT
Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA05125; Thu, 13 May 93 13:47:01 PDT
Received: by TIS.COM (4.1/SUN-5.64)
id AA11699; Thu, 13 May 93 16:49:27 EDT
Date: Thu, 13 May 93 16:49:27 EDT
From: Marcus J Ranum
Message-Id: <9305132049.AA11699@TIS.COM>
To: Firewalls@GreatCircle.COM, vince@dsi.unimi.it
Subject: Re: New file transfer protocol: FSP
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
If you're really torqued off about FSP, stop using screening
router based firewalls and/or put a system with ipforwarding turned
off between them. That'll solve the problem by putting a bullet through
it.
Before anyone flames me: Yes, I think this is reasonable,
depending on what your policy is. If, as a firewall administrator,
you have a requirement to block obnoxious traffic, the best way to
do so is to block ALL traffic and force traffic to run through
proxies with logging and authentication. It's draconian, but like
many draconian solutions, it's effective.
mjr.
From Firewalls-Owner Fri May 14 04:42:27 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA07688; Fri, 14 May 93 04:42:27 GMT
Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA07524; Thu, 13 May 93 21:41:31 PDT
Received: by coombs.anu.edu.au (5.61/1.0)
id AA18665; Fri, 14 May 93 14:15:37 +1000
From: avalon@coombs.anu.edu.au (Darren Reed)
Message-Id: <9305140415.AA18665@coombs.anu.edu.au>
Subject: Re: New file transfer protocol: FSP
To: dspencer@mproj.retix.com (David Spencer)
Date: Fri, 14 May 93 14:15:35 EST
Cc: Firewalls@GreatCircle.COM
In-Reply-To: <9305131624.AA05422@mproj.retix.com>; from "David Spencer" at May 13, 93 9:24 am
Reply-To: avalon@coombs.anu.edu.au
X-Mailer: ELM [version 2.3 PL11]
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
In some email I received from David Spencer, Sie wrote:
>
>
>
> > On Wed, 12 May 1993, Brent Chapman wrote:
> >
> > ...
> >
> > Suggestions have ranged from denying Internet access to all students, to
> > blocking all UDP traffic except for essential services. So far no further
> > action has been taken until we can come up with something that will be
> > effective. Any suggestions?
>
> Yeah you can block UDP traffic but then 'v2' of FSP will
> be developed which you use a non-hardcoded TCP port and
> then won't you be back in the same boat? Or a cloaking
> version of FSP which uses multiple TCP ports...
This would at least partially solve the problem of FSP `flooding' network
connections.
Darren
From Firewalls-Owner Sun May 16 23:06:48 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA17895; Sun, 16 May 93 23:06:48 GMT
Received: from antares.mcs.anl.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA17888; Sun, 16 May 93 16:06:38 PDT
Received: from skeeve.mcs.anl.gov by antares.mcs.anl.gov with SMTP id AA07223
(5.65c/IDA-1.4.4 for
Message-Id: <199305162307.AA07223@antares.mcs.anl.gov>
To: firewalls@GreatCircle.COM
Subject: To go with the discussion of FSP and version 2++
Date: Sun, 16 May 1993 18:07:15 -0500
From: Gene Rackow
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
I just found this on the comp.sources.testers news group. Granted he
makes it sound like a good reason to have a "repeater" for fsp, but
merging that with the comments from this list, watch out...
--gene
------- Forwarded Message
> From: pete@sst.icl.co.uk (Pete Bevin)
> Newsgroups: alt.comp.fsp,comp.sources.testers
> Subject: Testers wanted for FSP Repeater Daemon
> Summary: Quick way to get famous
> Message-ID: <1993May16.220329.17540@sst.icl.co.uk>
> Date: 16 May 93 21:06:28 GMT
> Sender: news@dsbc.icl.co.uk
> Followup-To: alt.comp.fsp
> Organization: Bracknell Lonely Hearts Club (Society Flirt)
> Lines: 82
> Nntp-Posting-Host: sst.icl.co.uk
> Originator: pete@jura
>
> [If you're reading comp.sources.testers and you don't know what FSP is,
> then stop reading now!]
>
> I'm looking for people to test a repeater daemon for FSP. Its purpose
> in life is to relay FSP packets between a client and a remote server.
> (There are very good reasons why you might want to do this -- see
> below).
>
> [Someone put some code out last week called fsprep0.1.tar.Z. This code
> has nothing to do with it.]
>
> The code is currently pre-alpha, meaning that it may well not work on a
> wide variety of systems. But the more people who test it, the better...
>
> Please don't volunteer to test the code, unless:
>
> - You're confident hacking C
> - You're prepared not to pass the code on to anyone.
>
> Thanks in advance to all testers!
>
> Pete.
>
>
>
> >From the README file:
> - -------------------------------------------------------------------------
> FSP repeater daemon version 0.0-a (pre-alpha)
> (C) 1993 Pete Bevin. All rights reserved. You are expressly forbidden
> from giving away copies of this code without the author's permission.
>
>
> The FSP Repeater Daemon
> =======================
>
> I wrote this program because my local machine (alice) isn't on the
> internet, but I have an account on another machine (bobby) that is.
> Before I wrote this, to get hold of a file from (say) wuarchive, I'd
> have to get it in two stages: from wuarchive to bobby, and then from
> bobby to alice. Using the repeater daemon, I can fire FSP packets at
> bobby, and have it relay them to and from remote sites.
>
> You could also use this code to hide the real address of an FSP site.
> You'd run the repeater daemon on the site whose address you give out,
> and have it relay packets to the `real' FSP daemon.
>
> The repeater daemon can route to and from multiple FSP sites. I
> currently bag about ten ports on bobby, each corresponding to a
> different site. The daemon reads in a file called ".reprc" on startup,
> which might look a bit like this:
>
> 2000 146.169.2.1 21 # src.doc.ic.ac.uk
> 2001 128.2.206.138 30 # seismo.soar.cs.cmu.edu
> 2002 192.76.144.75 2001 # ftp.Germany.EU.net
>
> Each line has three entries (the comments are ignored because they form
> the 4th, 5th, ... fields). The second and third field are the remote
> site's IP address and port number, and the first field is the port
> number on the local machine which will pretend to be the remote site.
> So connecting to bobby:2000 will get me to the Imperial College archive,
> bobby:2001 will get me to Joseph Traub's site at CMU, and so on.
>
>
>
>
> Bugs, problems, future enhancements, etc
> ========================================
>
> The daemon needs two ports per remote site: one to communicate with the
> remote site, and one to communicate with the client. The port it uses
> for the remote site is arbitrary, but at the moment, it gets it in a
> badly hacked way.
>
> The daemon won't properly handle two clients on the same port. ("I've
> just got a packet from seismo. Now which client do I send it back to?")
> But there isn't any problem with multiple clients on different ports.
>
> Would be nice to have a `configuration' port allowing the daemon to add
> new remote sites dynamically.
>
> Pete Bevin
> 16-May-93
>
>
------- End of Forwarded Message
From Firewalls-Owner Mon May 17 15:40:58 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20937; Mon, 17 May 93 15:40:58 GMT
Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA20930; Mon, 17 May 93 08:40:49 PDT
Received: from alias by yonge.csri.toronto.edu with UUCP id <14424>; Mon, 17 May 1993 11:41:14 -0400
Received: from dino.alias.com by barney.alias.com with SMTP id AA20811
(5.65a/IDA-1.4.2 for rackow@mcs.anl.gov); Mon, 17 May 93 11:27:00 -0400
Received: by dino.alias.com id AA06458
(5.65a/IDA-1.4.2 for firewalls@GreatCircle.COM); Mon, 17 May 93 11:26:57 -0400
From: chk@alias.com (C. Harald Koch)
Message-Id: <9305171526.AA06458@dino.alias.com>
Subject: Re: To go with the discussion of FSP and version 2++
To: rackow@mcs.anl.gov (Gene Rackow)
Date: Mon, 17 May 1993 12:26:54 -0400
Cc: firewalls@GreatCircle.COM
In-Reply-To: <199305162307.AA07223@antares.mcs.anl.gov> from "Gene Rackow" at May 16, 93 07:07:15 pm
X-Mailer: ELM [version 2.4 PL8]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 927
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
> I just found this on the comp.sources.testers news group. Granted he
> makes it sound like a good reason to have a "repeater" for fsp, but
> merging that with the comments from this list, watch out...
Heh. the number two reason for the FSP repeater was site-address hiding...
:-)
> You could also use this code to hide the real address of an FSP site.
> You'd run the repeater daemon on the site whose address you give out,
> and have it relay packets to the `real' FSP daemon.
Overall, it definitely sounds like these guys are re-inventing TCP/IP
(session control/routing) over UDP, badly, for 'nebulous' reasons...
--
C. Harald Koch, Network Manager | "There is no problem, no matter how large or
Alias Research Inc. Toronto, ON | small, that cannot be solved by a suitable
chk@alias.com | amount of high explosives."
chk@gpu.utcc.utoronto.ca | -Leo Graf, USS LaFarge, 2298
From Firewalls-Owner Tue May 18 22:47:39 1993
Return-Path: Firewalls-Owner
Return-Path:
Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26694; Tue, 18 May 93 22:47:39 GMT
Received: from cs.uchicago.edu (gargoyle.uchicago.edu) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)
id AA26686; Tue, 18 May 93 15:47:22 PDT
Received: by cs.uchicago.edu (4.1/2.0)
id AA03692; Tue, 18 May 93 17:48:28 CDT
Date: Tue, 18 May 93 17:48:28 CDT
From: Chris Johnston
Message-Id: <9305182248.AA03692@cs.uchicago.edu>
To: Firewalls@GreatCircle.COM
Subject: Re: To go with the discussion of FSP and version 2++
Sender: Firewalls-Owner@GreatCircle.COM
Precedence: bulk
Hello All,
Let me see if I've got this right. FTP proxy servers are good.
FSP repeaters are bad. :)
IMHO Since neither FTP or FSP use cryptographic authentication,
you can never know who is at the far end. :)
Could the FBI wire tap spread spectrum FSP repeaters? :)
Do the available TCP proxy servers require one side of the
connection be inside the firewall and the other outside?
If both the client and daemon FSP ports were "well known" would it
be secure? Allegedly FSP presents a lighter load to the server and a
heavier load to the network. Can it be fixed?
Packet filtering "established" FTP connections is impossible since
it uses two channels. FTP requires a separate server process for each
connection.
Clearly both FTP and FSP have drawbacks, perhaps it really is time
to reinvent this service. How about a new file transfer service that
only uses one channel, behaves well on slow links, has high
throughput, presents a light load to the server, authenticates the
user and encrypts the payload.
regards,
cj
312-786-4889