Subject: RE: tunneling [Was: Agenda for Vienna]

From: "Tony Li" <[email-masked]>
Date: Tue, 20 May 2003 19:08:09 -0700

|    > Meta note: if we're trying to talk architecture, I'd say that
|    > dealing with the identifier/locator relationship is secondary.
|    
|    I don't think we can make informed decisions about the 
|    architectural 
|    approach unless we know how well each approach is going to 
|    work out. 
|    That's why I keep going into detail.

This is a common trap.  Some detail causes someone else to go into
further detail and then we end up arguing about the details.  Bzzt.

We need to understand at the very top level how things are going
to work.  Then we flesh out details.  If things aren't going to
work at the top level, then the details are a waste of time.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 May 2003 09:23:21 +0200

On woensdag, mei 21, 2003, at 04:08 Europe/Amsterdam, Tony Li wrote:

> |    work out. That's why I keep going into detail.

> This is a common trap.

So then there must be a reason why it's hard to avoid it.  :-)

> Some detail causes someone else to go into

> work at the top level, then the details are a waste of time.

Didn't we kinda sorta agree that loc/id is our collective favorite 
architecture and that the rest is either flawed, should be worked on 
elsewhere or no interest in working on it as a group?

Even though we get a bit sidetracked from time to time, I think we're 
having a very useful discussion on the identifier semantics and mapping 
mechanisms right now.

---

From: Tim Chown <[email-masked]>
Date: Wed, 21 May 2003 09:23:03 +0100

> elsewhere or no interest in working on it as a group?

So if you were drawing out a multihoming roadmap, where would loc/id
be on that roadmap?

I ask because we should consider what we can do short-term and long-term.
Is the loc/id approach long-term?   Christian's multi-address "challenge"
is much more short-term, and I think is something we should push forward
on now.   

The question then is whether we need to create any swamp in the interim
for large enterprises for which Christian's approach is out of scope and
where loc/id (in the host or at the edge) is too far off.

Might we for example agree what the multi6 group can do now to assist
multihoming for new IPv6 deployments, and then "split off" long term
approaches (either within the group or out to IRTF if long-term really
is just that)?   Should multi6 focus on what can be done now, or what
can be done in 3+ years?

> having a very useful discussion on the identifier semantics and mapping 

This is the sort of thing that should be on the Vienna agenda.

Tim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 May 2003 00:22:11 +0200

> So if you were drawing out a multihoming roadmap, where would loc/id

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'm not entirely sure how long it takes from draft to 
implementation but I think a couple of years should be doable with some 
tail wind so in that sense intermediate term. After that another few 
years before general adoption. I don't think any solution that needs 
changes on both ends can do much better.

> where loc/id (in the host or at the edge) is too far off.

I hear some people mention giving /32s to large enterprises. I'm not 
going to bore you with rants about why this is morally reprehensible 
but rather observe that if we give the big boys a portable prefix they 
won't have any reason to support loc/id, and the single homed crowd 
doesn't either because they don't need it to talk to the big multihomed 
sites, so that leaves the small multihomers without anyone to talk to 
multihomedly. We have to all be in the same boat to get this off the 
ground.

> is just that)?   Should multi6 focus on what can be done now, or what

Well, if you really want to start multihoming quickly you should do 
geo.  :-)

Changing protocols takes time. The correlation between the amount of 
change and the amount of time is well below 1. Since there isn't any 
IPv6 deployment to speak of and there are much bigger fish yet to be 
fried before that will happen (where is my IPv6 root and TLD 
delegations?) I think we can afford to take the time to get it right. 
Or rather, we can't afford not to.

If we can steer clear of stuff like what the next generation namespace 
should look like I see no reason to involve the IRTF.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 07:51:14 +0300 (EEST)

On Thu, 22 May 2003, Iljitsch van Beijnum wrote:
> long term. [...]

I disagree: I don't think loc/id, a solution like HIP for instance, would 
solve the whole problem.  Care to elaborate?

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 May 2003 09:40:11 +0200

On donderdag, mei 22, 2003, at 06:51 Europe/Amsterdam, Pekka Savola 

> solve the whole problem.  Care to elaborate?

Elaborate why you disagree? That's going to be hard...

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, the most obvious way is to 
have different addresses that are each tied to a path. But then we're 
changing addresses in mid-session, which our transport protocols can't 
handle. 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, this should solve the 
multihoming problem once and for all.

Locator/identifier separation is also very useful if we want to 
implement a new namespace. Loc/id in itself doesn't require a new 
namespace. Either locators and identifiers can overlap (i.e., any IPv6 
address can be either or even both) or we split the IPv6 address space 
in two, with parts for both purposes. This is mostly a deployment 
tradeoff.

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.

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.

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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 11:29:22 +0300 (EEST)

> Elaborate why you disagree? That's going to be hard...

Hmmm..  See below..

> 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 
> 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 
> locator<->identifier mapping is set up, 

Sure.

> this should solve the 

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

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

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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 May 2003 10:43:50 +0200

> is much more short-term, and I think is something we should push 

I used to be a strong proponent of the road-map and gradual migration 
approach. That is also why I wrote the road-map draft. However, I am no 
longer sure that is a good approach. As was pointed out here, that 
risks distracting us. Also, the goal of multi6 is to come up with the 
solution. Not the protocol details, and probably not the migration 
scenarios. If we start looking at this now there is a risk that we will 
dug into all kind of side issues. This might be a role for multi6 in 
the future, but I would say not now.

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2003 10:44:38 +0200

Iljitsch van Beijnum wrote:
...
> packet or once every 5 seconds or so should be more than enough.

We can just use fairly standard approaches to smart compression. If the 
same bit pattern appears in the same place in every packet of a flow, 
it is well known how to save the bits. Probably, most of the hosts we 
would care about will be using ROHC anyway.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 May 2003 10:23:36 +0100

> the future, but I would say not now.

OK, so I shouldn't have used the R-word.  The point is to focus on what
we can meaningfully do now to address certain scenarios, and what
(architecture-wise) we would like to work on longer term.   Multi-addressing
can be tackled now for some scenarios, in particular the SOHO/SME v6 networks
which will account for a big chunk of all v6 networks.  We have many of the 
pieces we need.   

I don't see that it needs a spin-off WG, but if that gets us some focus 
that we otherwise will not get in multi6, it's worth considering, in which 
case we'd want a BoF slot for a multi-addressing charter bashing in Vienna.

We have two sessions.  Multi-addressing and loc/id seem to be the two main
consensus topics to work on?

Tim

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 12:41:25 +0300 (EEST)

On Thu, 22 May 2003, Tim Chown wrote:
[...]
> consensus topics to work on?

I'm not sure if a split would be meaningful.

Host-based loc/id requires multi-addressing.

And host-based loc/id is probably the simplest of the solutions to
achieve.

(Damn.. we really should have some better, more exact terminology here.)

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 May 2003 11:11:47 +0100

> (Damn.. we really should have some better, more exact terminology here.)

That would be useful :)

Tim

---

From: marcelo bagnulo <[email-masked]>
Date: 22 May 2003 12:48:33 +0200

Hi Pekka,

> locators") when the ISP's are changing.

A comment about the renumbering issue.
First i do not think this is part of the multi-homing issue, so if we
find a solution that does not solve this i would say it is ok.
However, i do think that it is a related problem and it would be
interesting to find a solution that also support this (just as it would
be nice that the split loc/id provides support for mobility)

In the particular case of HIP, i think that it does facilitates
renumbering. Renumbering involves changing addresses in hosts but it
also involves changing ACLs and other configurations that involve IP
address as identifier.
Since HIP provides a stable identifier, those configurations could use
the stable identifier instead of the address. I agree that this does not
completely solve the issue. The cost of this is that the identifier has
to be carried in every packet, i guess.

regards, marcelo

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 May 2003 13:05:06 +0200

> should look like I see no reason to involve the IRTF.

Even then I would say we can stay clear.

- kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 14:27:28 +0300 (EEST)

> find a solution that does not solve this i would say it is ok.

Well, I think it is, practically, to an extent.  If Site is multihomed 
using two prefixes to two providers, and wishes to switch the second one 
to a better one, this should not be an overwhelming task (otherwise folks 
might not want a multi-address solution in the first place).

> be nice that the split loc/id provides support for mobility)

Yep.
 
> also involves changing ACLs and other configurations that involve IP

Yes, HIP makes it much easier.  However, the backward 
interoperability might require checking for locators anyway, or 
a way to ensure that bad guys don't spoof identifiers.

> to be carried in every packet, i guess.

Of course, many of those ACL's could be obsolete by then, right..

Or one could have locator-to-identifier and identifier-to-locator mapping
functions.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 22 May 2003 09:19:47 -0400 (EDT)

Pekka,

> might not want a multi-address solution in the first place).

How is the scenario you describe (switching one of two prefixes)
different - in its effect on renumbering - from switching a site's only
prefix?

Multi-homing might make renumbering *easier* - providing one reliable
address while renumbering the second...

---

From: Tim Shepard <[email-masked]>
Date: Thu, 22 May 2003 10:31:45 -0400

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

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

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

> 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
			 [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 May 2003 18:10:04 +0300 (EEST)

> address while renumbering the second...

This depends on what you count in in the renumbering issue.

There are two cases when you switch one ISP:
 1) completely removing the first ("disconnecting from the Internet"), 
then adding the second, and
 2) trying to run the first simultaneously with the second, and when the 
second works, disconnect the first.

1) above is "easier" to accomplish as the connections will die by 
definition, you have to spend time with configuration etc. -- but more 
harmful for the network.  You really don't have to care about complex 
things such as which prefixes are used etc.

2) is actually quite similar to "multihomed continuum" where you change 
only one of them, with the difference that you're not going to remove the 
first prefix in the end.

After some thinking, I can't quickly find major differences between 
multihomed renumbering and 2).

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 26 May 2003 09:11:02 +0200

> , so I shouldn't have used the R-word.  The point is to focus on what

In many cases I would assume that we even don't have to do anything, or 
very little for multiaddressing to work. AMS-IX are already running 
their services in this fashion....

> case we'd want a BoF slot for a multi-addressing charter bashing in 

I seriously think that having multiple WGs working on the same problem 
is a mistake.

> consensus topics to work on?

Yes. And I hope that we will have both discussed at the first session 
and then continue this at the second session (that is with focus on the 
architecture at the second session).

- kurtis -