HDTenEightyP/NetNews huggingface dataset:
From: tsudik@pollux.usc.edu (Gene Tsudik)
Newsgroups: comp.protocols.tcp-ip
Subject: Firewall usage
Date: 30 Jul 1992 08:00:59 -0700
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: pollux.usc.edu

In article <Bs3vCz.K13@cs.columbia.edu> ji@cs.columbia.edu
(John Ioannidis) writes:
 
  >* A firewall is no excuse for lax internal security. To wit:
  >  - In a large organization, there are bound to be "bad guys" (either
  >    through malice, negligence, or sheer stupidity) inside the
  >    organization as well. No firewall is going to protect you against
  >    those.

True. But it is safe to assume that there is a much larger and much more
"varied" population of "bad guys" outside than in. 

  >  - A firewall only protects you against *known* external threats.

This is not a convincing point. Any security measure whether implemented in
a firewall gateway or in an end-system is going to protect you only against
*known* attacks.

  >* The network should switch bits and enforce routing policies -- not
  >  cover up for insecure applications.
  > 
  >* Having firewalls reduces the urgency (that is, the pressure on the
  >  vendors) of patching those security holes. It's a vicious cycle.
  > 
  >* We've seen analogies such as putting locks on the front door rather
  >  than each individual room, and that it's perfectly acceptable
  >  capitalist behavior to put a firewall gateway in front of your
  >  network. I claim that this is far from being capitalistic; you're
  >  being communist inside, and hiding behind an Iron Curtain.

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'm afraid that no matter how secure you make the hosts, the problem of 
securing internal links will remain. You are assuming that the only purpose of
firewalls is to protect otherwise vulnerable hosts. 
What about the rest of internal network resources: links, bridges and even 
the network interfaces of the very same hosts? 

Without firewalls, no matter how secure the OS, 
your workstation can be bombarded and flooded with meaningless garbage
traffic from outside of your organization. This can render your 
workstation unusable. Moreover, valuable communication resources, e.g., 
critical internal links, can be similarly flooded with trash from the outside 
thus denying service to legitimate internal users.

I don't think many people (me included) believe that firewalls are elegant. 
They constitute an ugly solution to an even uglier problem.

Cheers,

Gene

gts@zurich.ibm.com

-- 
----------------------
Gene Tsudik, Member FDIC
Newsgroups: comp.protocols.tcp-ip
From: hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
Subject: Digital Pathway ?
Originator: hardiman@csd4.csd.uwm.edu
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: usa
Date: Mon, 27 Jul 1992 13:56:44 GMT

From: nrt@watson.ibm.com (Nicholas R. Trio)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Date: Fri, 24 Jul 1992 20:35:44 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM T.J. Watson Research Center

 >Authentication is possible (many places are using authenticator
 >"smart cards" like the Digital Pathways' Secure-Net Key which allows
 >for authentication of remote users.  However, for the immediate future,
 >I suspect many organizations worried about who's "driving up to their
 >door" will use firewalls.

 >Nick Trio (nrt@watson.ibm.com)
 >IBM T.J. Watson Research Center

Can anyone provide a phone number or address for Digital Pathway?

Thank you.

Paul Hardiman
University of Wisconsin - Milwaukee
hardiman@csd4.csd.uwm.edu
From: tsudik@pollux.usc.edu (Gene Tsudik)
Newsgroups: comp.protocols.tcp-ip
Subject: Firewall usage
Date: 28 Jul 1992 02:44:34 -0700
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: pollux.usc.edu

 
In article <1992Jul28.010344.9414@PA.dec.com> mogul@pa.dec.com (Jeffrey Mogul) 
writes:
   
   >In article <JTW.92Jul27142002@pmws.lcs.mit.edu> jtw@lcs.mit.edu 
   >(John Wroclawski) writes:
   >>Dave [Clark's] second point is that perhaps it is time to rethink the core
   >>architecture of the internet (or its follow-on) to specifically
   >>-include- mechanism to separate organizational policy functions (such
   >>as authentication, logging, and access control) from the actual
   >>service functions running on the typical host.
   > 
   >Actually, I think this approach was (in embryonic form, at least)
   >suggested several years ago by Deborah Estrin, who developed the
   >concept of Visa protocols.  In this model, "border" routers pass

Visa protocol addresses only end-to-end (in terms of domains, not hosts) access 
control/authentication issues. Control of transit traffic is also quite 
important and will (may) become more so in the future. Charging for providing
transit services may well become the chief reason for implementing 
transit "hurdles" (the term "firewall" doesn't really apply here). 
For details, see "Secure Control of Transit Internetwork Traffic" (D. Estrin &
G. Tsudik), Computer Networks and ISDN Systems, October 1991.

   >only those packets deemed allowable by an Access Control Server (ACS).
   >Instead of requiring each packet to pass through an ACS on the way
   >in or out of an organization, the end hosts get cryptographically-
   >sealed thingies (visas) to stick onto their packets.  This allows
   >a distributed implementation, but also allows the ACS to set whatever
   >policy is desired.  The downside is that the cryptographic stuff could
   >be rather costly, and the whole model depends on every external-access
   >host implementing the mechanism.   For details, see
   >    Deborah Estrin, Jeffrey C. Mogul, and Gene Tsudik.
   >    Visa Protocols for Controlling Inter-Organization Datagram Flow.
   >    IEEE Journal on Selected Areas in Communication 7(4):486-498, May, 1989.

A more up-to-date Visa protocol description can be obtained via anonymous
FTP from jerico.usc.edu (pub/gene/new-visa.ps.Z). 

   >.... 
   >From time to time, I (hidden behind a firewall) find Digital's policies
   >to be a major pain; I still don't use services such as WAIS because of

Ditto for IBM (imho). 

   >the extra effort involved.  But, I (and my coworkers) no longer spend
   >a significant part of our time either tracking down intruders, or
   >explaining to the corporate security types why they shouldn't shut down
   >our gateway complex.
   > 
-- 
----------------------
Gene Tsudik
Spiritually at the University of Southern Califlower
Physically at the IBM Zurich Research Laboratory
Newsgroups: comp.protocols.tcp-ip
From: mt@kram.demon.co.uk (Mark Turner)
Subject: Null packet driver?
Distribution: world
Organization: Demon Systems Limited / Demon Internet Services
Date: Thu, 30 Jul 1992 21:19:32 +0000

Is there such thing as a null packet driver?

I have a PC running Windows. ka9q lives in a DOS window and quite
happily answers the phone to recive incoming PPP sessions from my office.

How do I access an IP based process in another DOS session? I can telnet
into the ka9q session and could go through this session to a packet driver,
but I can't use a conventional packet driver from the same end twice.

One (horrible) solution is to go out of a serial port and back into another
one, having separate SLIP drivers on different interrupts for each serial port.

There must be a better way. I'd appreciate any ideas. What I'd really
like is for someone to say "Oh, just use the XYZ null packet driver, which
is available for ftp from...." but I s'pose that's just a dream. :-(

Here's hoping...

Mark.

/\/\ark Turner                               Demon Systems / Demon Internet
Office: mark@demon.co.uk (+44 81 349 0063)       42 Hendon Lane, London
Home: mt@kram.demon.co.uk (+44 831 823 212)         N3 1TT, England
Organisation: European Space Operation Centre (E.S.O.C)
Date: Thursday, 23 Jul 1992 11:56:01 CET
From: Karl Keyte <KKEYTE@ESOC.BITNET>
Newsgroups: comp.protocols.tcp-ip
Subject: RFCs - How do I submit one?

Does anyone know the procedure for submitting an RFC, getting an RFC
number, etc?

Please answer to me directly:  KKEYTE@ESOC.BITNET

Thank-you,

Karl
Newsgroups: comp.protocols.tcp-ip
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" 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, 24 Jul 1992 04:52:28 GMT

>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.

	It also can mean that the site cares about security. There are
loads of sites on the net that run NIS...  A firewall helps. Having a
firewall changes your problem domain. Basically, once you are firewalled,
you presumably *still* have some security - but the firewall acts a
multi-part role as:
	a) shield - making things harder is always better.
	b) fly-paper - detect intrusion attempts, and you *bet* I do.
	c) a logger - it is hard to get through any decent firewall
		without leaving a logged trace. note the phraseology
		here - many firewalls are not what I would call "decent".

mjr.
Newsgroups: comp.protocols.tcp-ip
From: lamy@sobeco.com (Jean-Francois Lamy)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: Sobeco Ernst & Young
Date: Fri, 24 Jul 92 23:50:03 GMT

>>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.

Or have to convince auditors that the advantage the development groups
get by being on the Internet does not compromise the security of the
operational and strategic data on the other sites on the network.  If you're
unable to clearly show that the packets from the outside world aren't touching
the production wires, you may find yourself on the wrong side of an
inquisition real quick...

Jean-Francois Lamy                                        |   lamy@sobeco.com
Computer Networks and Systems				  |   lamy@sobeco.ca
Sobeco Ernst & Young, Montreal, Canada H2Z 1Y7            |   uunet!sobeco!lamy
From: alfonso@mtecv2.mty.itesm.mx
Newsgroups: comp.protocols.tcp-ip
Subject: Information about PCRoute
Date: 28 Jul 92 15:10:37 GMT
Reply-To: alfonso@mtecv2.mty.itesm.mx
Distribution: alt


  I'm sending this information cause I received a mail requesting some information about PCRoute, but I lost the address of that person. I hope he read this.

  PCRoute is a public domain software (at the moment I don't remember the node from which I got it), runs on PC's with a localtalk card and an ethernet card. The main problem I see with this product is that does not provide the KIP protocol in order to assign and IP address to the Macintoshes that connect with it.

  Alfonso
Newsgroups: comp.protocols.tcp-ip
From: mogul@pa.dec.com (Jeffrey Mogul)
Subject: Re: Firewall usage
Organization: DEC Western Research
Date: Tue, 28 Jul 92 01:03:44 GMT

In article <JTW.92Jul27142002@pmws.lcs.mit.edu> jtw@lcs.mit.edu (John Wroclawski) writes:
>Dave [Clark's] second point is that perhaps it is time to rethink the core
>architecture of the internet (or its follow-on) to specifically
>-include- mechanism to separate organizational policy functions (such
>as authentication, logging, and access control) from the actual
>service functions running on the typical host.

Actually, I think this approach was (in embryonic form, at least)
suggested several years ago by Deborah Estrin, who developed the
concept of Visa protocols.  In this model, "border" routers pass
only those packets deemed allowable by an Access Control Server (ACS).
Instead of requiring each packet to pass through an ACS on the way
in or out of an organization, the end hosts get cryptographically-
sealed thingies (visas) to stick onto their packets.  This allows
a distributed implementation, but also allows the ACS to set whatever
policy is desired.  The downside is that the cryptographic stuff could
be rather costly, and the whole model depends on every external-access
host implementing the mechanism.   For details, see
    Deborah Estrin, Jeffrey C. Mogul, and Gene Tsudik.
    Visa Protocols for Controlling Inter-Organization Datagram Flow.
    IEEE Journal on Selected Areas in Communication 7(4):486-498, May, 1989.
I'm sure Dave knows about this stuff; Deborah did her dissertation at MIT.

>I suspect Mr. Denninger will disagree, but I find this to be dangerous
>and depressing thinking. A major strength of the Internet is the
>ability for new services to come into existance when they're needed,
>not several years later when a "nice clean requirement" has been
>formulated, written down, approved, standardized, and poked at by a
>layer or two of beaurocracy. In other words, the internet is strong
>because it can evolve.

Alas, while parts of the Internet can (and should) continue to follow
the "everything not forbidden is permitted" approach, which allows for
evolution, other parts have to follow the "everything not permitted
is forbidden" rule.  The powers-that-be at a company such as Digital
are not going to permit us to run arbitrary experiments across the
boundary between the nasty wide-open Internet and our soft, naive
internal network.  There's nothing intrinsically wrong with this; the
IETF doesn't require that everyone on the Internet experiment with a new
service before blessing it.  Once a new service is properly understood,
we can (if we so choose) cut a hole for it in the firewall.

From time to time, I (hidden behind a firewall) find Digital's policies
to be a major pain; I still don't use services such as WAIS because of
the extra effort involved.  But, I (and my coworkers) no longer spend
a significant part of our time either tracking down intruders, or
explaining to the corporate security types why they shouldn't shut down
our gateway complex.

-Jeff [who accepts the blame for a few of the firewalls out there]
Newsgroups: comp.protocols.tcp-ip
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
Subject: Re: Firewall usage (was: Re: ping works, but ftp/telnet get "no route)
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Tue, 28 Jul 1992 01:09:21 GMT

>Hey, no one has mentioned retraining all the local users who use their
>initials for a password!

	Another excellent case for firewalls. I want those users on the
*in*side of the firewall, where my problem domain becomes simply one of
making sure that the 2 user accounts on my firewall system have good
passwords, rather than having to worry about all the users on 40,000
hosts in Digital.

mjr.
From: zonjic@plains.NoDak.edu (Radivoje Zonjic (CE))
Newsgroups: comp.protocols.tcp-ip
Subject: Looking For a Package (posting for a friend)
Date: 29 Jul 92 15:11:21 GMT
Article-I.D.: plains.19418
Organization: North Dakota State University, Fargo



Dear Netters,

I have just received a request for help from a friend at Belgrade
University (YU) who is currently not hooked up on any net. I would
really appreciate any useful hint.

Rade



-------------------------------------------------------[forw. message]--
Dear networkers,
 
 
     I am interesting in PD TCP/IP for Unix. I would like to connect our 
old unix machines to rest of a local network using SLIP. I have some 
experience with Unix variants of ka9q TCP/IP. They are very pretty, but 
intended only for multitasking, without multiuser capability. I have 
heard something about CMU TCP/IP, but I find it only for VAX/VMS. 
     Now I am still looking for TCP/IP that would satisfy the following 
requirements: 
 
- Public Domain TCP/IP for Unix sysV 3.1 (sysV is important)
- full multiuser support of a telnet and ftp consumers
- telnet, FTP and finger servers
- elementary routing support
 
     I will very appreciate any information related to the software 
name, authors, capabilities, availability and experience in 
exploitation. 
 
 
Sincerely
 
Dr.Bozidar Radenkovic,
Department of information systems, University of Belgrade.
From: Norbert_Papke@mindlink.bc.ca (Norbert Papke)
Newsgroups: comp.protocols.tcp-ip
Subject: NDIS SLIP Driver
Date: 23 Jul 92 15:36:34 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

Hi,

I have a connectivity question that my local DEC office has not been able to
solve.  I am hoping that somebody on the net has an answer.

I need to dial in from my PC at home into our office network via a terminal
server (DECServer 300).  Once connected, I'd like to talk X over TCP/IP to some
of our Unix servers (it will be slow but it will be better than having to go
into the office at 3AM :-).  At the office I run Pathworks over TCP/IP, and
DECwindows or eXcursion.  Rather than go out and buy a different protocol stack
and X Server, I'd like to use the same software.  What I need is something that
will allow me to run IP over a serial line with DEC's TCP/IP for DOS.  This
"something" will probably be SLIP (supported by the terminal server).  Does
anybody know of an implementation of SLIP that works with DEC's TCP/IP?  Maybe
an NDIS SLIP driver?  Or am I totally off the mark and should be approaching
this problem differently?

Any help and suggestions are greatly appreciated,

-- Norbert.

--
Norbert Papke (Norbert_Papke@mindlink.bc.ca)
Prince Rupert Grain Ltd.
900 - 1055 West Hastings St.
Vancouver, BC, Canada
From: mhw@warlord.UUCP (Michael H. Warfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Help wanted: Interlan Ethernet drivers
Date: 28 Jul 92 02:26:05 GMT
Organization: Thaumaturgy & Speculums Engineering

In <1992Jul23.161641.12328@bostech.com> weare@bostech.com (Ged Weare) writes:
>Well, I gotta say, in a pathetic attempt at fairness, that I had nothing but
>good service from both Interlan (Ooops, Racal-Datacom), and from NCM.  They
>did try hard to help me.  I talked to three or four different NCM people,
>including a technical guy.  They even called me back!  In fact, a supervisor
>called me back to ask if I'd been treated right.  I have to admit I was.

	Yeah, I heard from them pretty quickly after my first reply here.
I may have caught somebody on a bad day or something when I contacted them
a few months ago.  They had resonable explanations and were quite forthcoming
on details.  Gang, I really hope my second contact with NCM was more
representative of their level of support than my first.  If so, I'm
impressed.  They do seem to be concerned, interested, and helpful.

>As I said, still no unix.  The only un-explored avenue was that one of
>the NCM people said (or implied, or atleast I inferred) that the NP600
>might work in NI6510 (?) mode, as a dumb card.  That should not need
>bus mastering, so I plan to check it out.  

	Anybody figures out how to get that to work, I want to know.  However,
can it be made to support the higher interrupts.  The NI drivers I have
only support the 8 bit interrupts.  Main reason I wanted to use the cards
to begin with is for the interrupts on the 16 bit interface.  The processor
is actually much slower than my host processor, which is not CPU bound at
this time.  As a result, the intellegent NP card would actually slow network
traffic down.  But since I'm not network traffic bound either, that's not
much of a problem.  I just need more interrupts!   :-( ;-( :-(

	Mike Warfield
	mhw@warlord.uucp
Newsgroups: comp.protocols.tcp-ip
From: scott@DSG.Tandem.COM (Scott Hazen Mueller)
Subject: Re: Confusing SLIP problem
Originator: scott@work
Keywords: SLIP, ping, telnet, modems, T1600, T3000
Reply-To: scott@dsg.tandem.com
Organization: Tandem Computers Inc., Cupertino CA
Date: Fri, 31 Jul 1992 19:01:33 GMT


In article <1992Jul31.052242.19984@dsg.tandem.com>, I wrote:
>[...]
>My best guess is that it's a TCP header compression issue.  I think that
>the Annex supports VJ compression, and from the 84-86 timeframe of the
>dates on my if_sl.c, I gather that Zorch doesn't.

This was indeed the problem; when I turned header compression off in the
Annex and brought the link back up, telnet came to life.  Thanks to Ehud
Gavron for pointing out the clues I had missed.

>If so, how do I go about finding the right modules to update my
>driver and possibly associated header files?

This question still stands, with some elaboration:  Anyone have any idea if
I could use the relevant modules from (say) BSD NET-2?

Thanks again,


-- 
Scott Hazen Mueller              +1 408 285 5762  scott@dsg.tandem.com
Tandem Computers, Unix System Administrator, Email Postmaster and Usenet Admin
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 00:09:24 GMT

drw@euclid.mit.edu (Dale R. Worley) writes:

>I haven't studied the matter, but I believe that the more
>sophisticated firewalling routers actually *do* track connections.

	I prefer to use a somewhat different approach in general. First
you determine the services that your users have a clear business need
for. Then you develop an application gateway that "knows" that protocol
and can give you decent access control, logging, and piggy-back blocking.
This is much more secure (in my opinion) since you preserve the "that which
is not expressly permitted is prohibited" doctrine and you can incorporate
appropriate per-protocol authentication or authorization as needed.

mjr.
Newsgroups: comp.protocols.tcp-ip
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" 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, 24 Jul 1992 04:57:48 GMT

>I was always under the opinion that "firewalls" and "mailbridges" (as they
>were originally proposed for use when the ARPAnet and MILNET split) were a
>Bad Thing.  To a certain extent I still agree.

	Firewalls are a lot like Jersey barriers on a freeway. They keep
the irresponsible drunks in the other lane from being able to hit you
head on.

	Since a firewall is the individual site's decision, it's neither
good nor bad - it's just something you feel you need or not. There are a
LOT of companies on the net who wouldn't be there if they didn't have a
decent firewall.

mjr.

[Incidentally, put some recent stuff about the firewall I run is up for
FTP from decuac.dec.com, /pub/docs/firewall/*]
Newsgroups: comp.protocols.tcp-ip
From: rh0083b@medtronic.COM (Roger-Hunen)
Subject: Re: Stopping only incoming TCP connections (was: Firewall usage)
Organization: Medtronic, Inc.
Date: Fri, 31 Jul 1992 07:41:54 GMT

In article <chrisc.21.712446813@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox) writes:
>>I was under the impression that if you filter all the SYN packets from
>>one direction that aren't SYN ACKs, bingo, you can't initiate any
>>incoming TCP connections.  Nice and stateless. The only flaw is that
>>implementations that seperately ACK the initiating SYN and then send
>>their own SYN won't be able to connect, but they are rare. Connections
>
>That would eliminate your users from starting ftp data sessions (wouldn't 
>it?).

So what you really want is application level proxies in the firewall for
TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
forbidden unless permitted' approach.

Regards,
-Roger

Newsgroups: comp.protocols.tcp-ip