[Info-vax] Still no IPSEC for TCP/IP services?

[Doug Phillips]

On May 23, 12:21 pm, David Froble <da... at tsoft-inc.com> wrote:
> Richard Maher wrote:
> > "David Froble" <da... at tsoft-inc.com> wrote in message
> >news:jpht9p$o3$1 at dont-email.me...
> >> Doug Phillips wrote:
> >>> On May 22, 1:11 pm, Dirk Munk <m... at home.nl> wrote:
> >>>> Doug Phillips wrote:
> >>>>> On May 22, 2:23 am, Dirk Munk<m... at home.nl>  wrote:
> >>>>>> Steven Underwood wrote:
> >>>>>>> "Dirk Munk" wrote in message
> >>>>>>>news:4797c$4fbac358$5ed43999$22551 at cache60.multikabel.net...
> >>>>>>>> I'm planning to set up a couple of new OpenVMS systems, and I was
> >>>>>>>> thinking of using IPSEC as well. I was amazed to find that IPSEC is
> >>>>>>>> not included in the present version of TCP/IP services. It was
> >>>>>>>> included in the Early Adopters Kit for TCP/IP services 5.7 in 2007
> >>>>>>>> (!!!!), but it never made it to the final version and wasn't added
> >> I would be very happy to be able to set up a secure connection, and then
> >> just perform communications without my applications having to know
> >> anything about encryption.  But the capability isn't there.
>
> > Juniper VPN any use?
>
> > Cheers Richard Maher
>
> I honestly don't know.  I'm doubting it.  I'm ASSUMING that any appliance would need any
> connections established directly from the appliance.  I could be wrong.
>

There are many, many different kinds of appliance. Browsing Cisco and
their competitors websites can waste half of my day, reading about all
of the latest gadgets.

> What I envision is having a database of pre-arranged partners and bring up and take down
> specific connections upon demand.  I'm not aware of anything secure that can be set up
> without prior cooperation from the remote end, but maybe I don't get out much.
>

You mean, so I could connect to your webpage, find a part I want and
if you don't have it in stock, your system would connect to your
suppliers and check availability? Or, are you the manufacturer/
distributor that resellers (not the public) need to query?

> As a client I'd expect that required connections would be known.
>

If you're connecting directly to someone's "private" database, then
you would need an arrangement with them and use whatever method they
tell you. Querying a public database is just web traffic.

> As a service I'd expect that new and previously unknown connection requests would be normal.
>

Like from browsers? Most come with SSL/TLS built in, and NATP works
quite well with SSL/TLS. (not so with IPsec.)

> Since most of the data is lawn mower parts, we're rather comfortable with unencrypted
> socket connections.  But when a credit card number is part of the data, things get rather
> ugly.
>

Unless there's a lot more to it than what you're saying, it seems like
that wheel has already been invented many times over. There are many
web merchant providers (paypal & alternatives) that have widgets to
handle that for you, and quite a bit of merchant packages you can buy
and install on your own server if you'd rather. That's a very
competitive market.

> I still haven't found a solution that I like.

There probably are a few out there.