HP3000-L Archives

December 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sletten Kenneth W KPWA <[log in to unmask]>
Reply To:
Sletten Kenneth W KPWA <[log in to unmask]>
Date:
Fri, 22 Dec 2000 16:20:48 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (97 lines)
Wirt writ after Mark Bixby rightly wrote after Jeff (sorry......):

> > The problem with SSH is that special clients and servers
> > are required.
> >
> > It's a far cleaner solution to do security transparently at
> > the IP transport layer so that no applications have to be
> > modified.  This is the VPN approach.
>
> That is exactly correct. This is the right and proper place to
> put the security process: at the transport layer. Security
> should be a process that is completely invisible to everything
> above it ........ This is the the simple and elegant solution.
>
> > .... I think IPsec will eventually predominate here, and that
> > it would be cool if MPE could support IPsec some day.
>
> I wholly agree.

Even at my admittedly limited level of expertise in this area, so
do I:  "Special clients and servers" quickly brings on unhappy
visions of major re-writes to complex com systems....  Doing
IPsec at transport layer and maintaining complete segregation
of apps and security code seems to be much preferable....


I also go back and pull out last sentence from Mark's email;
that Wirt did not include:

> FWIW, Windows 2000 supports IPsec, so I want to applaud
> Microsoft (gasp!) for doing the right thing in this area.


Especially since Win2K handles IPsec out of the box, from
our perspective getting IPsec support on the e3000 would be
big step forward......  maybe even a giant leap....  A little site-
specific background on why this is so;  without (for obvious
reasons) getting too detailed (expect many on this list could tell
similar variations on this theme):

Our organization thinks we have a pretty good active firewall
between our intranet and the outside world.  FTP, TELNET, and
"other" access is more-or-less controlled;  email viruses are
pretty routinely stripped before they get to me.  But as long as
we are linked to the internet, there is always some level of real
risk that a deviously cunning being from the dark side will make
it thru the firewall (may or may not ever have happened in the
past:  don't ask:  Only allowable answer is "no comment"..  :-) ).
If that happens, then we've got at least 2 problems:

(1)   The specific machine that is the initial target of the attack.

(2)   All the other machines that might be internally visible to
the compromised machine in (1) above....  If the (1) machine
is a UNIX box that has (or "obtains") sniffer software and the
hacker can make him/herself root, then BIG TIME trouble:  A
"large number" of end user PCs & servers may be vulnerable.

So just from our intRAnet perspective, being able to run IPsec
between generic Win2K boxes and our e3000 would give us a
major "secondary line of defense" behind our firewall:  With a
reasonable level of IPsec encryption, as long as an attack on
our intranet did not progress to the point where it takes Cisco
head-end router off-line or totally chokes up bandwidth, our
3000 users should be able to keep operating within a "security
island" (our core functions need no outside services while
running; other than head-end router & functioning local subnet).


But there is a 2nd (and perhaps soon to be even more urgent)
reason:  We have a growing need for off-site users to access
our HP 3000;  said users are spread out all over North America;
a few are even on other continents.  The cost for "fast enough"
dedicated links to these sites quickly becomes prohibitive (at
least in our current paupery state (if that's not a real word, close
enough).  Using the intERnet is obvious, cost-effective solution..
EXCEPT:  We just CANNOT send data (let alone logon and
password info) in the clear over the internet on a routine basis.

Our in-house client-server software that links our vanilla end-
users to our 3000 already incorporates encryption.  But there
are still system operation and maintenance tasks that require
logging on to MPE.  If IPsec was available on the 3000 and
QCTerm supported it from the PC, I would consider that close
enough to nirvana from both intranet *and* internet security
point of view....   :-)

...  leading of course to the "big question" for any porting guru
who might want to take a stab at it:   Engineering guesstimate of
level-of-effort to port IPsec to latest release of MPE is:

(a)  LOW (no known missing key functionality;  fairly easy port).
(b)  MEDIUM (might be some functionality issues; pretty big job).
(c)  HIGH (major missing functionality;  and / or major re-write).

Ken Sletten

ATOM RSS1 RSS2