HDTenEightyP/NetNews huggingface dataset:
Organisation: European Space Operation Centre (E.S.O.C)
Date: Wednesday, 29 Jul 1992 09:25:48 CET
From: Karl Keyte <KKEYTE@ESOC.BITNET>
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SMTP mail
 <1992Jul29.021534.6708@mp.cs.niu.edu>

  14rticle <1992Jul29.021534.6708@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil
Rickert) says:
>
>In article <92209.190519KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET>
>writes:
>>
>>The SMTP has recently been removed at our site because of its well-known
>>security hole.
>
>  Would you like to enlighten us as to the nature of this "well known
>security hole".
>
>  It is well known that email can be forged.  Most people don't consider
>this a security problem, although it may present an identification
>problem.  If you consider email forgery a security hole, then I presume
>you have also shut off all paper mail, which can just as easily be
>forged.
>

& that's not a security hole?  It is if you want to believe mail that you
receive.  Paper mail is usually signed.  The point is, SMTP is stupidly
simple (as we all know) in it's "authentication".  My question still
stands.

Karl
Newsgroups: comp.protocols.tcp-ip,comp.dcom.lans
From: fillmore@emr1.emr.ca (Bob Fillmore 992-2832)
Subject: Re: SLIP over a TELNET Link?
Organization: Energy, Mines, and Resources, Ottawa
Date: Fri, 24 Jul 1992 14:25:54 GMT

In article <CKD.92Jul20140814@loiosh.eff.org> ckd@eff.org (Christopher Davis) writes:
>David> == David Barr <barr@darwin.psu.edu> 
>
> David> And I thought it was sick when the College of Engineering
> David> decided to use DECNET to encapsulate IP packets so they could
> David> have one virtual ethernet spanning buildings.  (It was
> David> apparently the only solution.  I still can't believe it)
>
>Sickest of all was the "proposal" to put IP packets in MIME-format
>multimedia messages.  That gives you IP over UUCP, even over a
>multiple-hop UUCP path.
>

How about IP-over-SLIP-over-DECNETsethost-over-X.25?
Somebody here is actually using that in a production network!

-- 
Bob Fillmore, Technical Services Division          email: fillmore@emr.ca
  Information Management Branch,                   BIX:   bfillmore      
  Energy, Mines, & Resources Canada                Voice: (613) 992-2832
  580 Booth St., Ottawa, Ontario, Canada  K1A 0E4  FAX:   (613) 996-2953
From: art@acc.com (Art Berggreen)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: satellite link file transfers
Date: 27 Jul 92 21:51:51 GMT
Organization: ACC, Advanced Computer Communications

In article <1992Jul27.194447.23444@Arco.COM> Gary White writes:
>In article <1992Jul27.190345.22868@Arco.COM> Gary White <gwhite@arco.com>
>writes:
>>Hi-
>>Between Texas and Alaska via a satellite -linked communications link, we 
>>find that FTP goes awfully slowly.  Has anybody learned how to tune FTP,
>>or come up with some other software, to go fast on a satellite link?
>>
>>Thanks-
>>Gary White
>>
>More information:  this is with a T1 link with two RS/6000 560 machines
>both running AIX 3.2;  FTP performance is similar to a 56Kb terrestial
>hookup.

Do you have any idea what the TCP window size is on the RS/6000s?
Assuming a single satellite hop, that's about 1/2 sec. RTT.
This requires a window of 96KB at full T1 (24X64Kbps).  Since the best
you can do with TCP (without the large window option) is 64KB,
the T1 will max around 128KBps.  With a default window size of 4KB,
you should see about 8KBps (64Kbps).  This is close to what you appear
to be getting.

Art

KBps = KiloBytes/sec
Kbps = KiloBits/sec
From: dorl@vms.macc.wisc.edu (Michael (NMI) Dorl)
Newsgroups: comp.protocols.tcp-ip
Subject: wanted, traffic monitor with snmp access
Date: 28 Jul 92 13:21:17 GMT
Organization: University of Wisconsin Academic Computing Center

I have a need for a ethernet monitor that would gather
statistics on all traffic to or from a given ethernet
address for IP traffic with a given IP network number. 
Information must be retrievable with snmp. 

What I have in mind would be something like a PC or a
Unix worskstation with an ethernet interface.  The PC
would spy on all traffic on the ethernet and would
select traffic to or from a given set of ethernet
addresses. It would examine the source and destination
IP numbers of this traffic for a set of IP network
numbers (IP addresses anded with a mask would be nice)
and accummulate in/out tarffic stats (bytes plus
packets) for each IP network number.   It would be 
great if the device made this information available via 
snmp router interface mib variables (each network would
be a kind of pseudo interface) but other snmp access 
would be acceptable.

The application is to measure the traffic passing
through a router for a set of IP network numbers. 

Is there such a thing?  If not, is there any software
available in source that might make it's developement 
easier?

Replies by email please.

Michael Dorl              (608) 262-0466  fax (608) 262-4679
dorl@vms.macc.wisc.edu    MACC / University of Wisconsin - Madison
dorl@wiscmacc.bitnet      1210 W. Dayton St. / Madison, WI 53706
From: smb@ulysses.att.com (Steven Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Firewall usage
Date: 28 Jul 92 19:13:56 GMT

In article <Bs3vCz.K13@cs.columbia.edu>, ji@cs.columbia.edu (John Ioannidis) writes:
[lots of reasons why firewalls are a bandaid, and how we should fix the
real problem, including getting vendors to ship secure systems]

John is, of course, absolutely right (except where he called firewall
users ``communist'', which may or may not be true (the Internet reaches
lots of places these days...), but is irrelevant and seemed to be
intended as an insult).  Vendors should ship secure systems, internal
security measures are necessary in any event, and users and system
administrators should do a better job.  I strongly suspect that every
firewall developer is fighting all of those battles, and many more.  I
certainly do -- when I worry about TCP/IP security, for example, it's
because AT&T uses it internally, and wants to secure its internal
networks and products.

The problem with John's conclusions are that I have to live in the real
world, which includes people who *must* run old versions of various
operating systems, users who don't pick good passwords, and
administrators who are careless.  I can't do anything about any of
those things, except to exhort people to do better.  In the mean time,
I try to keep the dragons away from their doors, while hoping for a
better world tomorrow.


		--Steve Bellovin

P.S.  It occurs to me that John is also wrong when he says that firewalls
only defend against known problems.  That's precisely wrong.  Fixing holes
only works until some chracker finds a new hole.  A good firewall keeps out
anything but a very few services.  The network behind the firewall can
be attacked, but only through bugs in either those few services or in
the firewall itself.

While host security can -- and should -- be improved, I'm quite dubious
that it can ever be made good enough.  Never mind bad administration --
I don't think the state of the art of software engineering is up to the
task.  I take it as axiomatic that all large programs have bugs, and
that therefore security servers will have security bugs.  Yes, good design
can minimze the odds and/or the impact -- but I doubt that the holes
can ever be eliminated completely.  Looking at it another way, firewalls
are precisely an example of good software engineering practice -- they're
(presumably) small, simple pieces of code, and hence are much less likely
to have bugs.
Newsgroups: comp.protocols.tcp-ip
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Fri, 31 Jul 1992 14:00:39 GMT

>The meaning I infer for "piggy-back blockin" seems formally
>impossible.  Does it mean preventing people from using permitted
>facilities for impermissible things?  Such as piggy-backing a full
>featured "gateway" on top of rlogin?

	Right. I was referring to using one service to piggy-back another
one. Such as running an interactive login session over an FTP command
stream. ;) Or tunnelling X-windows packets in a telnet session. In general
one may need to block that kind of thing, especially in the case where
the piggy-backing is being done to make an unsecure protocol (like X)
available.

	I'm not a theorist of any type, so I can't say anything about
formalisms. ;) On the other hand, I do know that ad hack methods can
go a long way towards preventing these kinds of things, *if it is necessary*.
Not all sites will *care* about preventing people from tunnelling X over
telnet, for example. At that point the problem ceases to be a technical
one, and becomes a policy matter - and many of the gateway admins I know
don't set the policy; they are just stuck with enforcing it.

	My telnet application gateway, for example, has a rate limiter
in it that will adjust the baud rate of an outgoing telnet session to
a (low) settable value. That way you can run an interactive session nicely,
but if you try to run kermit over it, it'll be unacceptably slow. My
FTP application gateway has rate limiting on the command stream, and also
fires off warnings if commands are sent over the command stream that are
not recognizable telnet commands. Yes, one could encode X packets in the
pathnames of "GET" commands, but then the rate limiter will choke you.
All these interesting events are logged.

	The main thing here is not to subscribe to some (imho useless)
formal model of security, but to just try to be reasonable and to make
sure that if someone does Something Bad to your gateway, it leaves
tracks that you can follow. Gateway admins are often in a really nasty
spot - they have to enforce sets of rules that sometimes don't make
a whole lot of sense. I try to enforce them sensibly, and to do anything
I can to make sure that if someone launches a *real* attack on my gateway,
I'll have a chance of catching them, or at least I'll have enough
information about what happened that I can deduce what they were
trying to do, and check for holes.

mjr.
Newsgroups: comp.protocols.tcp-ip
From: wrl@wdl1.wdl.loral.com (Bill Lewandowski)
Subject: ATT 3B2 Hop Counter
Organization: Loral Western Development Labs
Date: Mon, 27 Jul 1992 16:11:24 GMT

Hi,

We have a user with a ATT 3B2 computer. We think we have a problem
with data packets taking more than 16 hops through the NSFNET
T3 network and the MILNET and the 3B2 is ignoring them because >16.

Anyone know how I can increase the hops to a normal 32 or so.

I don't have the computer here so I can't read any manuals so
any help is really appreciated.

Bill
Newsgroups: comp.protocols.tcp-ip
From: pmetzger@snark.shearson.com (Perry E. Metzger)
Subject: Re: SMTP mail
Organization: /usr/local/lib/news/organization
Date: Wed, 29 Jul 1992 15:23:51 GMT

In article <92211.092548KKEYTE@ESOC.BITNET> Karl Keyte <KKEYTE@ESOC.BITNET> writes:
>
>& that's not a security hole?  It is if you want to believe mail that you
>receive.  Paper mail is usually signed.

And you are enough of an expert on handwriting that you can check the
signatures of all the mail you get and know its really from the
person, eh? Keep reference signatures for everyone you correspond
with, too, I assume. Good trick. I can forge most people's signatures
with about 2 minutes of practice, not significantly more effort than
it takes to forge SMTP mail. Paper mail is just as insecure as EMail,
if not more so because almost anyone can forge paper mail but it takes
someone who groks SMTP to forge email.

>The point is, SMTP is stupidly simple (as we all know) in it's
>"authentication".

Relying on paper signatures is also stupidly simple. Signatures are
not there on legal documents as an identity verification, you know,
but as proof of concent; if you sign (and its shown that you indeed
were the one who signed) its taken to mean that you understood you
were entering in to a contract. If you want identity verification you
are supposed to go to a notary public.

>My question still stands.

Look, if you want real authentication, you need to go to public key
cryptography. You won't find any other technique that really works,
and you aren't going to find PEM implementations that interoperate on
your platforms. Fine, shut off SMTP and deprive your users of a
valuable service if you like, but you aren't doing them any favors.
--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.
Newsgroups: comp.protocols.tcp-ip
From: gmarzot@mitre.org (G. S. Marzot)
Subject: Re: satellite link file transfers
Organization: MITRE Corp.
Date: Thu, 30 Jul 1992 15:55:26 GMT

In article <1992Jul28.223621.12550@Arco.COM>, Gary White <gwhite@arco.com>
writes:
> 
> Well, it has turned out that we had two problems.  First, 
> some bridge and  router setup problems.  Secondly, the buffer 
> size for TCP/IP on the RS/6000 was too low by default.  RS/6000's 
> have a command "no" for network options that allows the 
> "tcp_sendspace" and "tcp_recvspace" settings to be adjusted;  
> changing from the default 16K to 56K improved performance
> from 25KBytes/s to 70KB/s.
> 
> There are still some things to check for better performance, 
> but this is a big step up from yesterday's 5KB/s.
> 
> Thanks to all who wrote in!!!
> 
> -Gary
> 

This discussion has been very helpful. I do have one follow-up question.

Is there a simple ROM way to calculate TCP/IP throughput given say
bit rate = 256Kb/s, transmit/receive delay = 250 msec and varying buffer
size.
This would assume a fairly solid link and no other traffic. Thanks for any
help. -GSM
Newsgroups: comp.protocols.tcp-ip
From: vadim@cix.compulink.co.uk (Vadim Lebedev)
Subject: No subject 
Cc: vadim@cix.compulink.co.uk
Reply-To: vadim@cix.compulink.co.uk
Date: Mon, 27 Jul 1992 00:47:28 +0000


Hello Everybody...

I'm looking for the way to retrieve couple of old Usenet messages,
one is:
 Message-ID: <8807200426.AA01221@helios.ee.lbl.gov> 
        Newsgroup: comp.protocols.tcp-ip
        July 1988

The second one is:
 Message-ID: <881231121.AA19744@helios.ee.lbl.gov> 
        Newsgroup: comp.protocols.tcp-ip
        July 1988
 

Do you have any ideas?

 Vadim.
-----------------------------------------------------------------------
Vadim Lebedev                      |   Kortex International
vadim@cix.compulink.co.uk          |   139-147 av. Paul-Vaillant Couturier
                                   |   93126 La Courneuve - CEDEX, France


Newsgroups: comp.protocols.tcp-ip
From: gary@sci34hub.sci.com (Gary Heston)
Subject: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Reply-To: gary@sci34hub.sci.com (Gary Heston)
Organization: SCI Systems, Inc., Huntsville, Al.
Date: Thu, 23 Jul 1992 14:20:26 GMT

In article <BrsM1C.36v@cs.columbia.edu> ji@cs.columbia.edu (John Ioannidis) writes:
>In article <BrruC8.FEo@spock.dis.cccd.edu> markb@spock.dis.cccd.edu (Mark Bixby) writes:
>>Why would I be able to ping a site OK, but when I try to ftp or telnet to it
>>I receive a "no route to host" error?  ....

>The site you are trying to ping is running a firewall gateway, because
>they're too lazy to beef up their host security and are relying on the
>firewall to protect themselves against external attacks.

I have to take exception to this remark. Use of a firewall doesn't indicate
laziness on the part of a site; it most probably means that the persons
responsible for the Internet connection and security of the sites' net are
either too understaffed to maintain all the hosts on their site, or they
don't have control over all the hosts, and are therefore not able to make
them secure. And there are doubtless many sites that suffer from both 
problems.

>I wish I had a transcript of Dave Clark's talk at the IETF last week.
>He said some great things about firewall gateways and mailbridges, and
>how they've essentially destroyed the whole purpose of having an IP
>internet, and have forced a lot of us to use mail as a transport-level
>protocol.

Yeah, I'd probably enjoy reading it myself. Unfortunantly, with the explosive
growth of the net, it's no longer an approximation of an ideal world. In
an ideal world, we wouldn't need locks on our doors, keyswitches in our 
cars, or firewalls on our nets. 

There are other considerations, too; accounting for net traffic (it does 
cost someone money somewhere down the line), maintaining security of
proprietary, sensitive, confidential, or classified information, and 
insuring that resorces are used for the intended purpose by the people
they're provided for.

Flaming admins as being "lazy" because a firewall is in place is *way*
out of line.


-- 
Gary Heston    SCI Systems, Inc.  gary@sci34hub.sci.com   site admin
The Chariman of the Board and the CFO speak for SCI. I'm neither.
"Always remember, that someone, somewhere, is making a product that will
make your product obselete." Georges Doriot, founder of American R & D.
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Firewall usage
Date: 30 Jul 1992 20:03:41 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: telecaster.think.com

In article <l7g11bINNlib@pollux.usc.edu> tsudik@pollux.usc.edu (Gene Tsudik) writes:
>I see. So, to be a true capitalist I would have to padlock the doors to
>individual rooms (end-systems or hosts) and let the sh*t fly in the corridors,
>right? 

I think this analogy to a home and rooms is very poor.  The same people
live in a home and the rooms, so it's usually reasonable to have the locks
just on the main doors.  Then again, my parents did have a lock on their
bedroom door.

But I think better analogies would be to apartment buildings, dormitories,
or hotels.  It's usual to have locks on the individual apartments or rooms.
But whether there's a lock on the main entrance, or perhaps a doorman
screening visitors, is a matter of policy.  Some people prefer
high-security apartment buildings with a doorman.  Hotels, on the other
hand, often don't have much entrance security, so you should lock your
door if you want any expectation of privacy.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.protocols.tcp-ip
Subject: Using SLIP on Sparcstn
From: <PVJQC@CUNYVM.BITNET>
Date: Thursday, 30 Jul 1992 09:28:50 EDT
Organization: City University of New York/ University Computer Center

I recently downloaded `slipware' from one of the archives.  It includes
Slip for different Sun OS releases, tip with slip option, and some patches.
I was able to configure Slip as per the instructions for Sun Sparcstn2
running 4.1.1 but do not have any further info. on making proper use of it.
I basically have a `sliplogin' program which has a syntax of
`sliplogin <dest. addr> <local Addr>' .  I understand that Slip is
meant for point to point communication over serial lines.  I am not
sure how I exactly use this?  What I wish to do is to configure this Sparc2
for dial-in on /dev/ttya with slip, and then to configure other Suns, PCs
at remote sites (like faculty homes) for dialing out using slip so
that telnet/ftp would be possible from the home PCs (running CUTCP), and
Suns to the Sparc2 in the Dept.
Any suggestions or any documentation you can refer me to?
Thanks a lot.
Prashant Joshi
Newsgroups: comp.protocols.tcp-ip
From: smj@beta.lanl.gov (Stephen M. Johnson)
Subject: TCP/IP Addressing in Large Networks
Organization: Savannah River Site
Date: Wed, 29 Jul 1992 19:18:29 GMT

I work for a large Department of Energy facility (325 square miles, 23,000 
people) with a large IP population. Most of the machines running IP are
personal computers, split evenly between IBM PCs and Macs. We have a great 
deal of trouble maintaining an accurate host database because PCs are easily
moved, etc. We are struggling internally with how to manage IP addresses
so that we maintain an accurate database and consume minimal people resources
doing so. We have discussed dynamic allocation of addresses and server-based
allocation using RARP or BOOTP. What are other organizations with large
IP populations doing to solve this problem? 

If there seems to be sufficient interest I'll summarize to the net.

thanks

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
smj@lanl.gov			| Aiken, South Carolina
-- 

Mark Johnson			| Westinghouse Savannah River Company
				| (803) 644 1494
smj@lanl.gov			| Aiken, South Carolina
From: mandell@bach.helios.nd.edu (Dan Mandell)
Newsgroups: comp.protocols.tcp-ip
Subject: FTP's Kernel and Ipx/Netx compatibility
Keywords: ethdrv, FTP, WD8003e, netx
Date: 22 Jul 92 03:10:48 GMT
Organization: Saint Mary's College, Notre Dame, In

We currently use Hummingbird's Exceed Xwindows product with FTP's TCP/IP
ethdrv kernal running on top of the wd8003e packet drivers. Works great.
Except, that I don't seem to be able to run ipx/netx while FTP's ethdrv 
kernel is loaded.  I have been asked if it is possible to do this - and 
seem to recall being told by FTP tech support that it can't be done.  But 
I thought one of the motivations for the packetdrivers was to allow several 
protocoll stacks to use the same ethernet card (Western Digital) -
simultaneously, if need be.  Is there something we could do to make this work?
Is theresomething that would replace the packetdriver that would support 
a connection to both a unix host and a novell server at the same time.
Is anybody doing this?
 
Dan Mandell

Dan Mandell (mandell@saintmarys.edu)
Saint Mary's College, Computer Services 
Notre Dame, Indiana 46556  -  Phone: (219) 284-4610
Newsgroups: comp.protocols.tcp-ip
From: werme@alliant.com (Ric Werme)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: Alliant Computer Systems Corp.
Date: Mon, 27 Jul 1992 19:29:45 GMT

In article <17008@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:

>Let me very strongly second what Marcus Ranum said about the need for
>firewalls.  No, I don't want to run one.  However, given the
>abominable state of host security, I have no choice.  You can blame
>software designers for not paying enough attention to the problem or
>you can blame the current state of software engineering, or you can
>blame lax administration by folks who are more interested in getting
>their own work done.

Hey, no one has mentioned retraining all the local users who use their
initials for a password!  Until we got on the Internet here I was
rather fond of my old password.  A little embarassed that it was on
the Robert T Morris short list, but my coworkers are pretty trustworthy.

I *was* somewhat more embarrassed when I discovered my old password was
on a machine here that did not use the yellow plague, but I think things
are under control now, thank you.
-- 
| A pride of lions               | Eric J Werme                 |
| A gaggle of geese		 | 77 Tater St			|
| An odd lot of programmers      | Mont Vernon NH  03057	|
| A Constitution of Libertarians | Phone: 603-673-3993		|
Newsgroups: comp.protocols.tcp-ip