Hello Alfredo, Friends,

Re: NS/VT IP security.

>Would anybody from HP like to comment?

F. Alfredo Rego ([log in to unmask]) wrote:

: >..., with the telnet server you can at least proactively choose
: >which address you'll let connect; though I suspect very few sites do that
: >(yet). VT connections have no such luxury...

: Is there any way to have this "luxury" for NS/VT?  Would anybody from HP
: like to comment?

Well, this is a can of worms....  But I will give you my personal input,
not "HP's" as you see in my disclamer below...

It would be Kewl to see all of the NS services (all the ones you seen when
you perform a :nscontrol status) running under inetd including NS/VT and
NS/NFT (dscopy).  Their are two significant inhibitors in the NS SERVICES
which make this a very expensive solution. .1 The NS SERVICES are written
in SPL & MODCAL (Modified Pascal).  .2 The NS SERVICES are written using
HP NETIPC sockets, not BSD sockets.  The chalange this presents is to start
a server under inetd it is necessary to be able to do a "fork" which does
not work in NETIPC.   The chalange in converting the NETIPC calls to BSD
calls is BSD on the 3000 is only callable from "C".  This is exactly the
chalenge we just completed with FTP/iX now running under inetd on MPE/iX
6.0.  FTP/iX written in Modcal/Pascal now calls stub routines in "C" to
make the calls to BSD so we can start the server under inetd and take
advantage of the standard inetdsec security (Wow, that was a long paragraph
and involved a lot of good work on behalf of the FTP/iX lab).

{have to take a break and listen to the Leno monolog}
...

Ok, back now... It also would be very difficult to break the close ties
between the DSDAD and the various NS services (I am working my way through
a NS/VT SERVER problem now and the communications between the server and
DSDAD at startup and shutdown is very intense).  So, thinking about this
problem, I would suggest a possible solution would be for DSDAD to share
the inetdsec file with inetd (possibly leveraging off the routines inetd
now uses to read the inetdsec file).  If this would meet your security
needs, I would suggest you contact your friends at the RC and submit a
Enhancement Request for this... ALSO as others above have suggested,
bring it to the attention of HP via the various SIG's and other groups
where enhancements can be raised and voted upon.

One other idea I have heard a lot about out here is password encription
for TELNET & NS/VT...  This is a great idea and I suggest you pursue it
as above mentioned.   I am not certain what impact this will have on
TELNET or if it is even possible since the RFC does not specify password
protection/encription for clients...  For NS/VT it is possible to
implement protection/encription, but the impact is also widespread since
it would impact many clients - 3k to 3k - not a big problem vt3k unix to
3000 - not a big problem, ~ 15 Virtual Terminal vendors for various
platforms DOS, WIN, MAC, SUN, etc...  - this could be a significant
problem for some 3rd party vendors...   Anyway I do recommend this
enhancement be submitted and pursued for NS/VT.

As always it is good working with you all.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.
     ***************************************************


Other options...