Multinet's _BG: Driver and IPsec
Richard Maher
I just had a disappointing glance through the latest VMS road map, and once
again found UCX's IPsec capability still some way off :-(
Having said that, I've just (today) realized that Process Software's
Multinet already advertises this functionality for VMS.
When was the release date?
Is anyone out there using it?
Does anyone have VMS/Multinet/IPsec applications talking transparently over
TCP/IP sockets to Windows/IPsec?
Is it truly transparent to the application/socket programmer? (these ports,
these addresses, GO!)?
Is a simple configuration script available?
Why didn't they do the same thing with TCPware?
I've tested my software with UCX and TCPWare but not Multinet, but I'm sure
Process Software would rather die then allow a behavioural inconsistency
between their various BG: offerings on VMS?
Is anyone else as ignorant as me?
Cheers Richard Maher
PS. Is some smart arse would like to chime in with "The documentation is
quite clear on the subject" or "I found it with only one finger" or "I just
wait for posts like yours so I can, once more, sing 'I'm too sexy for my
shirt!'" then if you could take the time to mention chpt and verse of
provide a pointer then that would be just peachy.
Richard Whalen
news:ebpkl6$lsi$1...@news-02.connect.com.au...
> Hi,
>
> I just had a disappointing glance through the latest VMS road map, and
once
> again found UCX's IPsec capability still some way off :-(
>
> Having said that, I've just (today) realized that Process Software's
> Multinet already advertises this functionality for VMS.
>
> When was the release date?
IPSEC was included as part of MultiNet 5.0; the release notes are dated
June, 2004.
>
> Is anyone out there using it?
I believe that some customers may be using it because we have had some
questions about it.
>
> Does anyone have VMS/Multinet/IPsec applications talking transparently
over
> TCP/IP sockets to Windows/IPsec?
One of the things that makes IPSEC in MultiNet 5.0 difficult is that only
static keys are
supported. Windows/IPsec requires automatic keying.
We have done some work on automatic key exchange, but there was not
sufficient time to get it tested and documented for MultiNet 5.1; it will be
part of MultiNet 5.2.
>
> Is it truly transparent to the application/socket programmer? (these
ports,
> these addresses, GO!)?
Yes, it is transparent to the application/socket programmer, especially with
the automatic
key exchange program in place. An administrator still has to set up the
security policies
(which systems require which types of security), and set up the key exchange
program, but
once that is done the key exchange program will securely negotiate and
exchange keys
with the remote system when a connection is opened, then the key will be
used for the
communication for that connection. The only thing that the application may
notice is a
delay at connection initation time.
>
> Is a simple configuration script available?
The documentation and examples for MultiNet V5.2 will include a simple
configuration
script for the key exchange program (racoon) that will work between any two
systems that
have had security policies defined. The current documentation shows how to
set up
security policies and how to do manual keying. See chapter 31 of the
Installation and
Administrator's Guide.
http://www.process.com/tcpip/mndocs51/multinet_admin_guide.pdf
>
> Why didn't they do the same thing with TCPware?
>
> I've tested my software with UCX and TCPWare but not Multinet, but I'm
sure
> Process Software would rather die then allow a behavioural inconsistency
> between their various BG: offerings on VMS?
Process Software tries to keep the BG: device offered in both MulitNet and
TCPware compatible with what is in TCP/IP Services. When an incompatibility
is
discovered we work to fix the problem in both products.
>
> Is anyone else as ignorant as me?
>
> Cheers Richard Maher
>
> PS. Is some smart arse would like to chime in with "The documentation is
> quite clear on the subject" or "I found it with only one finger" or "I
just
> wait for posts like yours so I can, once more, sing 'I'm too sexy for my
> shirt!'" then if you could take the time to mention chpt and verse of
> provide a pointer then that would be just peachy.
>
>
Richard Whalen
Process Software
David J. Dachtera
>
> "Richard Maher" <mahe...@hotspamnotmail.com> wrote in message
> news:ebpkl6$lsi$1...@news-02.connect.com.au...
> > Hi,
> >
> > I just had a disappointing glance through the latest VMS road map, and
> once
> > again found UCX's IPsec capability still some way off :-(
> >
> > Having said that, I've just (today) realized that Process Software's
> > Multinet already advertises this functionality for VMS.
> >
> > When was the release date?
>
> IPSEC was included as part of MultiNet 5.0; the release notes are dated
> June, 2004.
>
> >
> > Is anyone out there using it?
>
> I believe that some customers may be using it because we have had some
> questions about it.
>
> >
> > Does anyone have VMS/Multinet/IPsec applications talking transparently
> over
> > TCP/IP sockets to Windows/IPsec?
>
> One of the things that makes IPSEC in MultiNet 5.0 difficult is that only
> static keys are
> supported. Windows/IPsec requires automatic keying.
>
> We have done some work on automatic key exchange, but there was not
> sufficient time to get it tested and documented for MultiNet 5.1; it will be
> part of MultiNet 5.2.
Now, if PSC could get Multinet doing Buffered I/O instead of Direct I/O,
you'd stand a chance to get back some sites that were forced to moved to
UCX due to performance demands.
Something else that makes Multinet more desirable (in addition to
IPsec):
ECO-5 to UCX V5.4 "broke" dynamic ("virtual") IP addressing
("failSAFE-IP" in UCX parlance). (Dunno if this is fixed in V5.5 or V5.4
ECO 6(?).)
Multinet's "PD" interface strategy was still working, last I heard.
...and, of course, Multinet's IPL usage remains an issue (V5.0 got
sufficiently knotted on our site that I saw something I'd never seen
before: a cascade cluster crash!).
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Richard Maher
Really appreciate the detailed reply! Thanks for that.
> One of the things that makes IPSEC in MultiNet 5.0 difficult is that only
> static keys are
> supported. Windows/IPsec requires automatic keying.
Are your "static keys" equivalent to their "pre-shared secrets"? (The
terminology drives me nuts over there. Although, I'm actually in love with
the idea of an "ambient transaction". The "Default transaction" is like
soooo 90s :-)
> We have done some work on automatic key exchange, but there was not
> sufficient time to get it tested and documented for MultiNet 5.1; it will
be
> part of MultiNet 5.2.
Do you have a "Road Map" or ETA for 5.2? Admittedly, the pressure's off as
UCX IPsec will be held up indefinitely while Nurse Ratched and her cronies
have had a chance to vet it for C conformity and a total absence of
inner-mode interfaces, but it always helps be first-to-market in these
situations. (Then they'll have to kiss BEA's and IBM's collective arses and
decide it's prudent to cancel the whole thing, so you should be OK this
century!)
Look, I know it's been said (more than once) that I'm slightly prone to
superlative (Pig's arse :-), but IPsec *is* the mut's nuts! It's what real
infrastructure is all about. IMHO "Connection-Oriented IPsec" has a big part
to play in the future of application development and the internet in
general. Bending over backwards trying to shoe horn some contextless "Web
Page Browser" into the guise of a middleware backbone is always going to
stumble.
> security policies and how to do manual keying. See chapter 31 of the
> Installation and
> Administrator's Guide.
> http://www.process.com/tcpip/mndocs51/multinet_admin_guide.pdf
A couple of quick observations/questions (I didn't look through the manual
in detail): -
Do you provide "From any port" - "To this port" functionality?
"At the moment IPsec can't be invoked with setsockopt()" Will this be done
anytime soon? You still support per-port configuration, right?
Cheers Richard Maher
"Richard Whalen" <Wha...@process.com> wrote in message
news:ebpu23$fp7$1...@news.process.com...
Richard Whalen
> Hi Richard,
>
> Really appreciate the detailed reply! Thanks for that.
>
> > One of the things that makes IPSEC in MultiNet 5.0 difficult is that
only
> > static keys are
> > supported. Windows/IPsec requires automatic keying.
>
> Are your "static keys" equivalent to their "pre-shared secrets"? (The
> terminology drives me nuts over there. Although, I'm actually in love with
> the idea of an "ambient transaction". The "Default transaction" is like
> soooo 90s :-)
Yes, "static keys" can be considered to be "pre-shared secrets". With
static keying system management needs to administer the distribution of
keys, keep them secure, and coordinate which keys are used when if keys
are changed on any sort of regular basis.
Even when the key exchange program is in place systems need to have a
method of proving that they are who they say they are during the negotiation
process. This may also be done with a "pre-shared secret", but since it is
used in a more limited manner keeping it secure is an easier task. When
the key exchange program is in use the actual keys that are used to encrypt
or authenticate packets are changed more frequently which provides
better security.
>
> > We have done some work on automatic key exchange, but there was not
> > sufficient time to get it tested and documented for MultiNet 5.1; it
will
> be
> > part of MultiNet 5.2.
>
> Do you have a "Road Map" or ETA for 5.2?
We have some estimates, but I don't know what is being told to customers.
I would recommend talking with sales or marketing for this information.
>
> A couple of quick observations/questions (I didn't look through the manual
> in detail): -
>
> Do you provide "From any port" - "To this port" functionality?
>
> "At the moment IPsec can't be invoked with setsockopt()" Will this be done
> anytime soon? You still support per-port configuration, right?
>
Yes, a security policy can specify a particular port:
spdadd src-ip dst-ip[port] ...
will provide security between the specified source to the particular port on
the specified destination. The ip addresses can include a prefix length,
so you can get large groups of addresses with a few rules. The
documentation
is primarily a specification of the syntax and hence it can be easy to miss
some of the functionality.
We have not documented the programming mechanism for setting
security policy. If customers need access to security policies from an
application, then they should contact Process Software so that we can
work with them and we can iron out some of the rough points in the
programming interface before we publish it.