Subject: Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 5 May 2003 16:47:53 -0400

> From: David Conrad <[email-masked]>

    > All the GSE-like solutions discussed to date that I am aware of have
    > assumed the first 48 bits (the locator) are globally unique. ... the
    > last 80 bits may or may not be unique depending on what you want to do.

There's not much point to separating location and identity if the portion of
the name which is the identity is not globally unique *by itself*.

	Noel

---

From: David Conrad <[email-masked]>
Date: Mon, 5 May 2003 14:20:12 -0700

Noel,

I agree.

However, I have been told that ensuring the global uniqueness of the 
last 80 bits is non-trivial because people like the stateless 
auto-configuration stuff that has been defined for v6.

One way of addressing this particular concern is to say the top 48 bits 
are mutable from one globally unique value (a "site identifier") to 
another globally unique value (an "aggregation locator") via some 
mapping function at both exit from the source site as well as entry at 
the destination site.

In this case, the identity portion of the name (the first 48 bits 
within a site) is globally unique by itself.

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2003 09:51:28 +0200

If the prefix is mutable en route, it doesn't matter that it's
globally unique: the end points can't use it as part of any checksum,
so either you have to add HIP, or the 64 bit suffix has to be
unique enough for checksum purposes. (You might be prepared to
accept an RFC 3041 suffix as unique enough, if you think that
network level privacy is more important than the chance of a checksum
coincidence.)

   Brian

---

From: David Conrad <[email-masked]>
Date: Tue, 6 May 2003 20:04:35 -0700

> unique enough for checksum purposes.

Or you simply rewrite the first 48 bits when the packet traverses the 
border into the destination site with the same value the packet had 
prior to traversing the border of the source site.

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 May 2003 11:08:23 +0200

> prior to traversing the border of the source site.

This was not part of any GSE proposal I ever saw, and it involves stateful
distribution of mapping information. A very different beast from GSE,
and it sets off my stateful=bad alarm.

  Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 May 2003 22:49:52 +0200

On woensdag, mei 7, 2003, at 11:08 Europe/Amsterdam, Brian E Carpenter 

> This was not part of any GSE proposal I ever saw,

True enough, but I think there was reasonable consensus that GSE as-is 
wouldn't be very useful as it requires changes to too many things and 
doesn't implement important multihoming functionality such as failover. 
We need to come up with some new names though, to avoid confusion.

> and it involves stateful distribution of mapping information. A very 
> different beast from GSE, and it sets off my stateful=bad alarm.

Actually this wouldn't be a problem at all since we have to keep this 
exact same state anyway in order to map the other way around for 
sending packets back.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 May 2003 11:50:04 +0200

> exact same state anyway in order to map the other way around for

Again, not in GSE as I understand it. In MHAP or map-and-encap, yes.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 8 May 2003 12:33:09 +0200

On donderdag, mei 8, 2003, at 11:50 Europe/Amsterdam, Brian E Carpenter 

> Again, not in GSE as I understand it.

I don't think it's a coincidence that there hasn't been any progress 
with GSE for five years or so. In theory, GSE can work without a 
mapping mechanism, but this opens the door to security problems. So in 
practice we need to keep state to know whether there is a valid locator 
<-> identifier mapping to avoid trivial identity theft. And if we 
accept that, we may as well remove the whole globally unique lower 64 
bit thing as it just breaks too much stuff without any real benefits at 
this point.

Aside from that, not having a mapping mechanism makes failover very 
difficult: the only way that still works is if the border router at the 
source sees the problem. This works for last mile problems, but not for 
routing problems further upstream. I know others have different 
experiences, but for me routing problems are the number one cause of 
outages.

Is there anyone who wants to stick with GSE without a mapping mechanism?

---

From: marcelo bagnulo <[email-masked]>
Date: 08 May 2003 13:10:45 +0200

I guess that what Brian means is that this (what you are describing) is
not GSE anymore, since it is not stateless (which is a fundamental
feature of GSE, as i see it)

It is just a matter of name.

what you are describing sounds more like MHAP...

So as someone suggested earlier, i think i would be better to find a new
name (or just avoid mentioning GSE) in order to avoid misunderstandings.

Regards, marcelo  

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 8 May 2003 13:30:55 +0200

On donderdag, mei 8, 2003, at 13:10 Europe/Amsterdam, marcelo bagnulo 

> feature of GSE, as i see it)

No disagreement there.

> what you are describing sounds more like MHAP...

Originally, I wanted to write something that encompasses both MHAP and 
GSE. But:

   "The original GSE and 8+8 drafts split the IPv6 address in two 64-bit
    parts. The lower part is used within the site or subnet. Routers add
    the higher 64 bits as packets leave the site. Since hosts don't know
    the higher 64 bits their correspondent will see, they must disregard
    these bits, which has the relatively minor consequence that the TCP
    and UDP pseudo header used in checksum calculations must be changed.
    A more severe consequence is that the lower 64 bits must now be
    globally unique. This in turn makes it very easy to perform spoofing
    attacks, as an attacker can simply present arbitrary lower bits,
    thereby assuming any desired identity, while setting the higher bits
    such that the packets are routed back to the attacker and not to the
    host identified by the lower 64 bits. This vulnerability, breaking
    autoconfiguration and, to a lesser degree, the transport layer
    checksums, make adopting GSE or 8+8 unfeasible and undesirable."

Is there anyone who disagrees and feels stateless GSE is still viable?

The letter combination "GSE" will not appear in the title. The 
preliminary title is "Multihoming in IPv6 by Rewriting Addresses".

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 May 2003 14:13:23 +0200

Iljitsch,

As I've said before, the actual requirement is that the lower 64 bits
be mutually unique among the set of correspondents (two for normal cases,
N for p2p cases). But indeed it is a general point that non-topological
fields are more readily spoofed than topological fields, since
ingress filtering and RPF checks don't apply.

The consequence is not automatically that they can't be used, but that
if they are used, an additional layer (such as HIP) is needed. I think
that is what you should say.

   Brian

---

From: marcelo bagnulo <[email-masked]>
Date: 08 May 2003 14:29:36 +0200

> Is there anyone who disagrees and feels stateless GSE is still viable?

I think that the statless condition of GSE is really valuable and
perhaps we can come up with a solution that can preserve it. 

As you mention, security issues need to be solved somehow in order to
enable this solution.

A possibility would be to use crypto identifiers such as in HIP but
included in the 64 lower bits of the address (CGAs)

I guess that this could provide the security needed and it would also
preserve middle boxes stateless as in GSE.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 8 May 2003 16:36:50 +0200

On donderdag, mei 8, 2003, at 14:13 Europe/Amsterdam, Brian E Carpenter 
wrote:

> N for p2p cases).

Is it useful to define the requirement this narrow? For a server, I 
would think it's hard to work with non-globally unique correspondents 
as potentially every host connected to the network can open a session 
at any time, creating a collision where there wasn't one previously.

> But indeed it is a general point that non-topological

Don't forget return routability. Ingress filtering and RPF checks 
aren't done everywhere, but return routability protection is relatively 
good except when the attacker shares a subnet.

> if they are used, an additional layer (such as HIP) is needed.

So we agree that breaking return routability and not repairing the 
resulting gap with something else isn't an option?

Wouldn't such an additional layer always carry even more state with it? 
The only advantage is that this kind of state is kept in the endpoints. 
However, then we end up with the requirement that endpoints must 
implement the solution, which leads to deployment problems and 
management difficulties in some networks.

This leaves us with:

1. do it with unmodified hosts in a proxy multihoming agent and eat the 
state
2. do it in modified hosts and don't involve the routers
3. 1. on on end an 2. on the other

I don't feel the GSE way of doing it in modified hosts and then expect 
routers to do some additional work provides benefits over one of the 
above options.

> I think that is what you should say.

I'm getting there... It's still more than a month before the draft 
cutoff for Vienna.  :-)

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 May 2003 17:44:27 +0200

> at any time, creating a collision where there wasn't one previously.

I think it's a footnote on the word "global". You can say global, but 
add a note that mathematically that is not a necessary condition, although
it may be the most practical solution.

> good except when the attacker shares a subnet.

Sure

> resulting gap with something else isn't an option?

I think so.

> management difficulties in some networks.

Right, except that we have to solve key management anyway, to make any
kind of security scale. Which as we know is hardly trivial.

> I'm getting there... It's still more than a month before the draft

Lots of time to solve a problem that was discovered around 1992 :-)

   Brian

---

From: David Conrad <[email-masked]>
Date: Thu, 8 May 2003 11:28:31 -0700

Brian,

> This was not part of any GSE proposal I ever saw,

Different terminology would be helpful.  Of course, this implies my 
messages on this topic have been whistling past people for the last two 
months.

> and it involves stateful
> distribution of mapping information.

Yes.  In one approach, a mapping of a globally unique 48 bit value to a 
set of other globally unique 48 bit values where that distributed 
lookup of that mapping occurs at the source border only.

> A very different beast from GSE,

Your alarm must go off continually today,  as the mapping is more or 
less equivalent to either the DNS or routing tables, depending on your 
point of view.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 8 May 2003 21:40:18 +0200

On donderdag, mei 8, 2003, at 17:44 Europe/Amsterdam, Brian E Carpenter 

> kind of security scale. Which as we know is hardly trivial.

What I was talking about wasn't key management, but the problem that if 
each individual host makes its own decisions it's hard to implement 
traffic engineering and other policies. Rewriting the source address 
helps some here as this makes return traffic take a certain path, but 
the problem remains for destination address selection.

Deployment is problematic because GSE hosts will have to communicate 
with non-GSE hosts, in which case the border routers must leave the 
source address alone. Source rewriting is really only an optimization: 
with some extra effort, the source host can find out which source 
address it should use. It's starting to look like this optimization is 
more expensive than simply doing it the hard way and let the host 
figure out the source address it has to use by trial and error (for 
"GSE"-enabled sessions), possibly aided by ICMP messages.

> Lots of time to solve a problem that was discovered around 1992 :-)

I'm flattered that you assume my draft will be the one to solve this 
problem.  (-:

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 May 2003 10:10:53 +0200

> less equivalent to either the DNS or routing tables, depending on your

Right, and we know that faulty DNS setups cause connectivity glitches
on a daily basis - because DNS state is created and managed by every site
worthy of the name, and mistakes are inevitable. We also had years of 
connectivity glitches caused by BGP4 configuration errors - most operators 
seem to have that figured out now, but it was bad for a while. Introducing 
a third distributed state mechanism that will be critical for connectivity 
is indeed a big step. 

   Brian