[Info-vax] HP's Partner Virtualization Program

[John Wallace]

On Aug 16, 1:37 am, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> Michael D. Ober wrote:
> > "Richard B. Gilbert" <rgilber... at comcast.net> wrote in message
> >news:yJ-dnb4DHoqzSxvXnZ2dnUVZ_i1i4p2d at giganews.com...
> >> R.A.Omond wrote:
> >>> Richard B. Gilbert wrote:
> >>>> [...big snip...]
> >>>> In twenty years as a system manager, VMS and several flavors of
> >>>> Unix, I NEVER used, or even encountered, IPSEC!  We've all gotten
> >>>> along without it somehow.  I never missed it!  Why has it suddenly
> >>>> become a sine qua non?
>
> >>> Richard, please use some of the next twenty years to learn how to snip.
>
> >> Please try to answer the question!
>
> > Richard - there are a two problems that IPSec supposedly solves.
>
> > First, packets are encrypted in transit.  There is a growing realization
> > that packets in the clear are large enough to carry a lot of personal
> > data. Credit card data, including name, address, card number, and card
> > security number, for instance, can be fully stored inside the 1500 or so
> > byte limit imposed by most routers.  So to steal your credit card, a
> > packet sniffer only needs to grab a single packet.  You don't have to
> > defeat security on the OS to steal credit cards.  Transmission security
> > is a necessary, but not sufficient requirement, for internet commerce of
> > any sort.  Yes, IPSec isn't the only method, but it's well understood
> > and relatively easy to implement on most routers and OSs.
>
> ISTR that all such transactions for the last eight or ten years have
> used HTTPS.  I've learned the check for thehttps://mumblein my
> browser.  Is this some form of IPSEC?

No https is not some form of IPsec although the goals are perhaps
broadly similar. https needs both of the communicating apps to be
coded to understand https (or to use a library that understands
https); obviously browsers and webservers generally can do https (or
should do). However, at the risk of repeating myself: IPsec works
transparently with existing (pre-IPsec, pre-https) applications, no
application code changes should be necessary, just network tinkering
by the system mangler(s).

Consider a multi-system application suite which is tried tested proven
and as old as the hills. "Security" has traditionally been provided by
physically preventing access to the network. Well, that's what the
management told the auditors anyway, and for years, the auditors have
accepted it. However, last year, the auditors said "physical security
isn't enough, your traffic should be secure as well". Now what? Recode
(re-test, re=certify) the app to use SSL? At what cost? Or leave the
apps untouched and use IPsec to secure the traffic, at a cost of (?).