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

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 22 May 2003, Iljitsch van Beijnum wrote:
> On donderdag, mei 22, 2003, at 06:51 Europe/Amsterdam, Pekka Savola 
> wrote:
> 
> >> I don't really want to use the words "long term" as that might make
> >> people think there is no point in working on it / waiting for it. But
> >> it should solve the problem rather definitively, so in that sense it 
> >> is
> >> long term. [...]
> 
> > I disagree: I don't think loc/id, a solution like HIP for instance, 
> > would
> > solve the whole problem.  Care to elaborate?
> 
> Elaborate why you disagree? That's going to be hard...

Hmmm..  See below..

> Multihoming works by having two or more valid paths through the network 
> between two hosts. (Valid = no administrative blocks, just having some 
> wire isn't enough, you must also be able to route over it.) Then if one 
> path disappears, the communication continues over the other. If we 
> can't have routing take care of this switch, 

So far so good.

> the most obvious way is to 
> have different addresses that are each tied to a path. 

Again: this doesn't solve the whole problem.  Consider e.g. Craig's
traffic engineering requirements, or (to a lesser degree) requirements
that the nodes should not have to renumbered ("deploying/retiring
locators") when the ISP's are changing.

> But then we're 
> changing addresses in mid-session, which our transport protocols can't 
> handle. 

Sure, but that's only one part of the problem: ensuring that connections
do not break.  In some cases it may be completely acceptable to have
connections break (e.g. outbound connections to the Internet) -- due to
the nature of traffic, the failure events happening so infrequently, etc.

Of course, connection survivability is very desirable.  Especially if
switchovers are frequent, or happen during important "business" hours. For
example, in home/SOHO use, it might be completely acceptable. It's just
tradeoffs.

> Enter the loc/id separation: the transport protocols and 
> applications get a stable identifier to work with, but we get to change 
> the underlying locator when there are outages. Assuming we take care of 
> details such as how outages are detected and how the 
> locator<->identifier mapping is set up, 

Sure.

> this should solve the 
> multihoming problem once and for all.

No, it would "only" take care of "connection survivability" once and for
all.
 
[snip]
> 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.

Yes, it may be a problem -- I could easily imagine there being resistance
to full cryptography, but there are workarounds for that.

> 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.

Perhaps someone better versed in HIP or IPsec could correct the above, but
on a quick glance there seem to have been a few things (at least) to note:

1) HIP header (~40B) is used only in the four-way handshake

2) when you start using ESP, it already includes everything needed
(material needed was established using HIP), so you don't send HIP headers
then.

3) ESP already includes authentication

4) it may be possible to include data in the parts of the HIP exchange by 
piggybacking (TBD)

5) only authenticated users could create an encryption DoS attack, because 
in the HIP handshake, the initiator has to solve a puzzle before the 
responder ("server") commits any resources to anything.  But that's bad 
thing too, because it could happen unintentionally too.

> 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.

Welcome to the world of connectionless protocols. :-)

But seriously, you really can't drop out stuff like IP addresses without
major changes.  Not without any assumptions that is.  If we could assume
all traffic is encrypted (or something), we might be able to drop off some
data and replace them with some sort of labels (so that the spoofing and
data injection, etc. problems would not be an issue), but I'm a realist
and don't expect much...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings