Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?)

From: [email-masked] (Michel Py)
Date: Wed Sep 17 11:32:01 2003

Pekka,

>> Michel Py wrote:
>> Note that I do not intend to be negative, but this will likely be
>> an issue with systems such as credit card transactions and other
>> real-time on-demand transactional systems, for two reasons:

> Pekka Nikander wrote:
> Thanks for point this out.  It may be that we need to think
> about this more.  It has been clear from the very beginning
> that you can't apply HIP to DNS transactions.

At the risk of sounding negative again: (I can hear it already: who's
this jerk that never contributed anything significant to HIP that comes
posting telling us what we screwed up :-)

This is an issue you might have to address. What follows is mostly
sales/marketing droid BS, but you do have to think about it.

When you look where HIP stands on the map of multihoming solutions, your
strong point is that you have the best security and your weak point is
that you have a deployment problem that can be solved only by some large
organizations adopting HIP to give it a shot in the arm.

The best target for adoption you have are "secure" transactional
systems, both because of the high availability aspect of multihoming (if
the credit card system is not working, you're just flushing money in the
toilet) and because of the security requirements associated with
financial transactions.

Without breaking NDA I can tell you that a significant number of them
are based on very short transactions. Today, one of the leading issues
is modem training: it can take more than 60 seconds to train a modem to
connect at 56k and it takes way less than one second to transmit the
mighty 16-digit credit card number. Which is why you will find number of
dial pools for credit card train only at 2400 baud. And yes it is in the
year 2003; saving 40 seconds on modem training offsets by two orders of
magnitude the time it takes to push a few bytes over the line at 2400
baud compared to the time it takes to push the same few bytes at 49,999.
Been there, done that.

One day, all of these credit card gizmos will use IPv6 over
{broadband|wireless|foo} instead of using a dedicated copper pair; when
that day comes, if it takes 20kByte of HIP overhead to push 50 bytes of
data, you do have a problem.

Again, this is not an anti-HIP rant; just trying to give you a taste of
what's ahead.

Michel.

---

From: [email-masked] (Tim Shepard)
Date: Wed Sep 17 12:19:01 2003

> toilet) and because of the security requirements associated with

I do not imagine that everything will use HIP.

I have thought (since this idea was planted in my head by Steve
Bellovin when spoke at the microphone at the HIPSEC BOF at the London
IETF) that the best path for adoption for HIPSEC is along a path
similar to the path that ssh took.

My favorite target for adoption is personal: I imagine that with my
HIP-enabled notebook computer and the various HIP-enabled servers that
I depend upon, I'll be able to suspend-to-disk my notebook, hop on a
plane to IETF, resume my notebook, and TCP connections will still be
open and functional, even if my connectivity was IPv6-only at home and
IPv4-only at the meeting (or vice versa).      (I know this will
also require some tweaking to improve the persistence of TCP on many
operating systems.)

If HIP ever becomes as popular as ssh, I think that would be a big
success.  I don't know if that will happen.  I think HIP has potential
to be much more widely used than ssh will ever be (since ssh is mostly
used as a remote system administration tool as far as I can tell).

> data, you do have a problem.

Well, what exactly do you think is the competitor to HIP for this story? IKE?

In either case, a per-transaction key exchange would be silly.  If its
going to run over IPSEC transport (ESP of some flavor) then I expect
that longer-term associations will be held.  I don't see how this
scenario is a challange to HIP any more than it is a challenge to
IPSEC in general (IKE in particular).

HIP, if it catches on, will be one more tool in the tool box.
There will still be work to do in designing a credit card verification
system like you described.

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Andrew McGregor)
Date: Wed Sep 17 17:34:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

>> toilet) and because of the security requirements associated with

Possibly, possibly not.  I have an application in power grid management, 
where the mobility is important as well as the availability.  HIP is at 
least as applicable as any other way of initialising ESP, and, imho, more 
so than most.

> also require some tweaking to improve the persistence of TCP on many

Well, I doubt it would cope with my IETF flights, but even just coping with 
the drive home from the office would be good.

> used as a remote system administration tool as far as I can tell).

Well, many folks like to use ssh as a VPN, since often they have situations 
that don't suit IPSEC or they can't be bothered with the pain (sticks own 
hand in the air; damn NAT).  We use ssh that way, and every user who reads 
mail from offsite uses it (via the Windows SFTP client), even though most 
of them have no clue how to use a unix command line; and in fact we don't 
even give them a shell.

>> data, you do have a problem.

Actually, it's about 2k, including IPv6 headers.

> IPSEC in general (IKE in particular).

In this country, most credit/debit card authorisation machines are 
permanently connected; the operator signs them on once per day (and each 
time the connection drops, but that's rare) and logs off at closing time. 
(People actually get a little irritated with the dial-on-demand sort.) 
This is exactly analogous to holding a HIP session open all day, for 
exactly that same application.

Andrew

- --------
Andrew McGregor
Director, Scientific Advisor
IndraNet Technologies Ltd
http://www.indranet.co.nz/
Office: +64 3 3656485
Mobile: +64 21 898856