Re: loc/id vs HIP (was: tunneling [Was: Agenda for Vienna])

[Tim Shepard <shep@alum.mit.edu>]

I'm a big fan of HIP, and your comments about HIP in the context of
multi6 have prodded me into speaking up...


> About HIP. I've been reading the new architecture document. It seems it 
> pretty much does the whole loc/id thing, although it doesn't really 
> mention failover. The problem however is that HIP does much more than 
> just multihoming. Maybe there is some synergy between multihoming and 
> mobility, but I don't see the advantages of leaping multihoming, 
> mobility and encryption on one big pile. In the end, that's going to 
> mean you're going to do at least one of those not very well.

I think your understanding may be accurate.  Those of us who are fond
of HIP like it because we think it knocks off a bunch of problems
together.  But while we already have implementations that do
substantial parts of HIP, I don't believe we have any automatic
handling of failover or switchover implemented yet, and we're still
imagining how some of the details will be handled.  (And I understand
that we've recently realized that there's a lot more to document about
how mutihoming and mobility will be handled by HIP that in the next
round of HIP drafts, and these details will be split out into multiple
drafts.)

The fact that we're still imagining the details and that the drafts
don't tell you exactly how everything will be done could be considered
a problem or a feature.  rfc793.txt (September 1981) has perhaps
lasted as long as it has without being obsoleted precisely because it
is somewhat vague about some areas of implementation behavior.  I
doubt we have any hope of doing as well as it did, but it does serve
as an example of where providing a solid framework while leaving some
details to the implementor's imagination and creativity can be useful.


Regarding "you're going to do at least one of those not very well",
It seems to me that by starting with security and using it to boostrap
identity, it will make the securing of all "of those" much easier.
We'll see.

Perhaps HIP is not *the* solution for the internet, but I believe it
has the potential to become very popular if we can get freely
available (hopefully open-source) implementations available for all
the popular platforms, and HIP is usable between consenting end-nodes
(without requiring the network to explicitly support HIP).

> And then there is simple economics: how are you going to convince 
> someone who multihomes in IPv6 to switch to IPv6 and then adopt HIP to 
> retain multihoming functionality? This means lots of additional 
> expenses because of the crypto hardware (if you can't do line rate 
> crypto you're a sitting duck for crypto DoS) and the additional 
> bandwidth for all the extra headers. Don't think it's so bad? I think 
> it is. The HIP header is at least 40 bytes. Then you need ESP, which is 
> at least 8 bytes (probably more like 16), an initialization vector and 
> padding. But of course just encrypting isn't enough, you really should 
> be doing authentication as well... Ignoring that for a moment the total 
> is 64 - 95 bytes when using a block cipher with 16 byte blocks. This 
> makes a TCP ACK 136 bytes. In plain IPv4 it's only 40 bytes... The 
> average pacet size is typically around 500 bytes. With HIP and IPv6 
> adding some 92 bytes, this eats away 16% of the available bandwidth.

Note that the HIP header, for most all of the traffic after the first
2 round trips, is ommitted entirely.   This is because its contents
are completely implied by the SPI in the ESP header.   So the
per-packet HIP overhead is a non-issue.   The larger IPv6 headers and
the ESP overhead (both in bytes and in crypto work) are not HIP
problems per-se.

Your comments about the need for fast crypto (whether it be seperate
hardware, or just a screamingly fast main CPU which I understand will
be available at your nearby discount store sometime late next year)
are right on.  But that again is a problem with doing ESP or any other
crypto, and is not unique to HIP.

Regarding the adoption of HIP, I expect (hope) that it will become
popular like ssh became popular: end users adopting it by grabbing
free software and adding it to their systems.  I personally want HIP
on the computer I carry around with me so that I can suspend, walk to
a different network (perhaps an IPv6-only network), resume, and have
all my connections continue (perhaps having been migrated from IPv4 to
IPv6 (or vice versa)).  The hope of being able to do this is what
first drew me into HIP a couple of years ago.  I expect I'll have this
functionality for myself by the end of the year if not before Vienna.

> On a related note, I've been thinking about ways to do something about 
> all this outrageous overhead but being able to have some per-packet 
> additional info at the same time. It occurs to me that much of the 
> stuff we're thinking about putting in each packet really doesn't have 
> to be in _each_ packet. Having identifiers and such in every 32th 
> packet or once every 5 seconds or so should be more than enough.

That's already sort of what HIP does, since it uses the SPI in the ESP
header to lookup the (unchanging) HIP header and (conceptually)
reinsert it.  (In practice, you don't need to reinsert it, because the
SPI in the ESP header tells you what ESP transform (and with what
parameters) to stuff the packet through, and whatever pops out the
other side of the ESP transform is what you continue processing in the
stack.   So even though you conceptually put the HIP header back on
the packet, in the actual code,  you don't do anything at all.)


			-Tim Shepard
			 shep@alum.mit.edu