Subject: Re: updating GSE for the new millennium

From: David Conrad <[email-masked]>
Date: Wed, 30 Apr 2003 22:53:37 -0700

On Wednesday, April 30, 2003, at 07:27  PM, Peter Tattam wrote:
>> Depending on your approach, it may not be necessary to rewrite the
>> source address.
>
> I don't think it's necessary.  The less changes to the packet, the 
> better in my
> opinion.  Just map the N bit label at whatever point a decision has to 
> be made
> to forward the packet outside the site.  I think only one relabelling 
> should be
> allowed and the decision to relabel be based on on the pre-labelled 
> address.

Agreed.

> I would presume that a MH address be identifiable by just looking at 
> the address
> (i.e. the top M (where M < N) bits represent a particular class of MH
> addresses).

Why would you not want all addresses to be multi-homable?  Why add the 
complexity of figuring out whether an address is multi-homable or not?

> Once the labelling is done, it can be sent all the way to the end
> host.  If one retains the prelabelled source address, this is an 
> additional tag
> to the end point that the packet can have it's label removed.

Right.  To put one approach I've been toying with in more concrete 
terms:

Inside the site, call the first 48 bits of the address the 'site 
identifier'.  These are globally unique, permanently assigned 
identifiers which are used as the prefix for all devices within the 
site.  Outside the site, call the first 48 bits the 'aggregation 
locator'.  These are globally unique, transitory (for the duration of 
the connectivity contract between the site and the ISP) routing 
locators assigned by ISPs out of blocks they announce to their peers as 
aggregates.  At the border, the 'site identifier' is used as a key into 
a table of site identifier/aggregation locator mappings.  In the DNS, 
AAAA rdata is a site identifier and all hosts within a site use the 
site identifier as the prefix for their source address(es).

Packet sent and arrives at a border device.  First 48 bits of the 
destination address are stripped off, used as a key into a table of 
site identifier/aggregation locator key/value pairs to get back one or 
more aggregation locators, one of the aggregation locators is chosen 
and written into the first 48 bits of the destination address.  
Packeted is forwarded on to the next hop according to the value of the 
aggregation locator.

On reception at the destination site, the first 48 bits of the 
destination address are stripped off.  The aggregation locator value is 
then looked up in the manually configured set of aggregation locators 
on the border device that handles the inverse mapping to get the site 
identifier.  The site identifier is then written into the destination 
addresses and the packet is forwarded onto the destination within the 
site.

Advantages that I can see:
- multi-homing is 'easy', simply add new provider's aggregation locator 
to your site identifier
	- no need to inform ISPs of each other's existence
	- no negative impact on global routing tables
- re-homing is a special case of multi-homing (only one aggregation 
locator associated with the site identifier)
	- renumbering becomes trivial
- no modification necessary to existing v6 stacks or applications
- no modification necessary to the DNS
- all v6 stateless/statefull auto-config stuff continues to work
	- privacy is no more of a concern than it is in existing v6 addressing 
arch
- mapping of site identifier/aggregation locator is done at the edges 
where performance is less of a concern
	- mapping is managed by site administrator so no need for new trust 
relationships
- end-to-end transparent
- traceroute still works

Disadvantages that I can see:
- Assumes the boundary of a site is distinct enough to install a (set 
of) device(s) at it
- Implies a site is internally connected
- Needs a globally distributed key/value lookup table
	- Data integrity of the table must be assurable
- Requires mucking about with the packet in flight.  Twice.
- Needs a border device (or process) at both source and destination
- Need at least two globally unique prefixes per site (one site 
identifier, one or more aggregation locators)
- Doesn't provide host multi-homing unless a host is also a site
- traceroute still works

I'm sure I'm missing some.  I'm equally sure people will tell me why 
this won't work... :-)

> The main issues I can see behind restoring the original packet would 
> be TCP/UDP
> checksums and IPSec.

Perhaps I misunderstand.  If the original values are restored before 
delivery at the final destination, the TCP/UDP checksums would compute 
correctly and IPSec would not be affected.

> One issue I just thought of is what happens if a physical site 
> represents
> multiple logical MH sites.

Not an issue (given oodles of address space) -- use multiple site 
identifiers and aggregation locators.

> When there are several possible MH
> site addresses, one would have to match the post labelled transit 
> addresses to
> the MH site prefix that they pertain to.

The key would be to maintain a mapping between each and every site 
identifier and the aggregation locators providing service to that site 
identifier.

Just some thoughts...

Rgds,
-drc

---

From: Peter Tattam <[email-masked]>
Date: Thu, 1 May 2003 16:42:28 +1000 (EST)

> > allowed and the decision to relabel be based on on the pre-labelled 

Additionally, I think it is a bad idea to relabel the source as the label
supplied is unlikely to be the best path.  The other end needs to determine
this. 

> complexity of figuring out whether an address is multi-homable or not?

it probably doesn't matter - I was suggesting it as a method of determining if
the packet was clean or dirty.  It would be important if dirty packets end up
at the destination host.

> correctly and IPSec would not be affected.

For a TCP connection, the srce/dest part of checksum can be cached.  One just
has to agree on knowing when to include the srce/dest pair in the checksum.
Another reason for determining if the packet is clean or dirty.  Minor
optimization that's all.  Don't forget that in Ipv6 we don't do IP header
checksumming any more.

We need to search for protocols that depend on the addresses in the header
being intact and work out whether the packet needs to be reconstructed or
cached values can be used instead.  If we are considering very high speeds,
this could be important.  Messing with the packet in transit could be a
performance hit and if we can get away without doing it, all the better.

> identifier and the aggregation locators providing service to that site 

This is the really tough bit.  Maintaining an accurate and secure database of
mappings is non-trivial.  Each site has their own specific view of the network
topology which makes this quite different to the DNS system.

The only other issue I wonder about is using single box to do translations at
the site boundary.  Because such a box is an insertion, it could be a single
point of failure, and could well have scalability issues.  I would see it as an
interim step towards a later solution where end hosts are able to mange the
translations themselves.  At least it should be a stateless translation which
makes it relatively scalable.

> Just some thoughts...

Some good ones.  Glad to see others recognizing the benefits of the GSE style
of doing stuff.

> -drc

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: David Conrad <[email-masked]>
Date: Thu, 1 May 2003 00:34:22 -0700

Peter,

Agreed.

> optimization that's all.  Don't forget that in Ipv6 we don't do IP 

Right.  Not convinced this would be necessary, but understand what 
you're saying.

> cached values can be used instead.

This would be the same set that is sensitive to NAT.

> If we are considering very high speeds,

As the rewriting occurs only at the edges, I don't believe extreme 
performance is that critical (relative to the core).

> topology which makes this quite different to the DNS system.

Sorry, don't follow.  The mapping table (in my view) is independent of 
topology -- it is a simple key/value pair where the key is the site 
identifier and the value is the set of one or more ISP provided 
aggregation locators from ISPs providing service to that site.  The 
border device at the source fetches the appropriate value based on the 
first 48 bits of the destination address and rewrites the destination 
address with (one of) the aggregation locator(s).  Where a destination 
is multi-homed, the policy determining which out of a set of 
aggregation locators is chosen would be administratively defined by the 
source site administrator (although I can imagine some sort of 
preference information being provided by the destination in the mapping 
table).

I gather your view is different?

With regards to maintaining the mapping table, I see two generic ways 
of doing this, either pushing data out like routing protocols or 
pulling data in on demand like the DNS.  Both are (obviously) tractable 
and both have advantages and disadvantages.  For obvious reasons I like 
the DNS model (not necessarily the DNS itself), but I see this is a 
side (albeit important) issue to the underlying architecture.

> point of failure, and could well have scalability issues.

In as much as the existing border router is a single point of failure 
or potential bottleneck, yes.  In my view, the mapping/re-mapping 
functionality could easily be integrated into the site border router.  
A separate box would also make sense.  Note that if it is a separate 
box, you can have more than one.

Rgds,
-drc

---

From: Peter Tattam <[email-masked]>
Date: Thu, 1 May 2003 20:36:58 +1000 (EST)

> This would be the same set that is sensitive to NAT.

agreed.

> performance is that critical (relative to the core).

not at this stage.  It will however introduce some latency even if the boxen
can keep up.

> I gather your view is different?

yes, radically.  What you describe is a semi static view of the network.  In
reality, you have to pick which one of the mappings is suitable to translate.
It is not possible for the advertising site to determine this because the
best path to reach that site will depend on where you are in the internet.
This choice can only be made based on either tracing all possible paths to the
site, or relying on information gathered about the network.  I think this is a
point which is constantly overlooked in the debate over MH solutions which
rely on some kind of mapping tables.

> side (albeit important) issue to the underlying architecture.

Try a few examples of a complex MH network with both ends being nulti homed and
on opposite sides of the DFZ and you should understand what I am getting at.  I
have mention the push vs pull approaches to distributing the MH information.  I
still contend that because of routing topology, a simplistic view like DNS
won't fly IMHO.

> box, you can have more than one.

I agree that because it will be stateless so theoretically you could do load
balancing with parallel boxes or have a standby box for emergency use.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 1 May 2003 12:47:26 +0200

On donderdag, mei 1, 2003, at 04:27 Europe/Amsterdam, Peter Tattam 
wrote:

> I think only one relabelling should be allowed

Apart from the question if this is what we want, is this something we 
can enforce? Or should care to enforce? This would give ISPs the option 
of relabeling just so their customers can't do it themselves.

> the address (i.e. the top M (where M < N) bits represent a particular 
> class of MH addresses).

Doing this has the advantage we can always easily recognize an 
unrewritten multihomed address, but is that a big enough advantage to 
require this? I can imagine a situation where hosts use a regular 
prefix as long as this prefix works and only rewrite with a secondary 
prefix when the first one fails.

> checksums and IPSec.  If the two end points are labelling aware, 
> measures can
> be taken to ignore the label from the checksums or replace it for 
> IPsec,
> otherwise it would be up to labelling boxen (border routers or other) 
> to do
> this on behalf of the hosts which are unaware of the labelling 
> possibility.

Sure, if an end-host implements this itself it can optimize its 
internal processing to avoid doing unnecessary work. This is going to 
help even more with reachability detection.

> multiple logical MH sites.

Then we're right back at the source address selection problem.  :-(

However, in this case the source multihomed address would presumably 
always be chosen based on policy/application requirements rather than 
reachability status, so it shouldn't be as much of a problem.

For incoming traffic it's just a matter of keeping the mappings 
straight.

> I wonder if these ideas might receive more support if the terminology 
> of
> labelling were used instead of GSE.  We'd be more likely to draw in 
> some
> support from the MPLS mob.

It's probably too confusing. MPLS is all about very small labels that 
are attached and removed without touching the IP packet. What we're 
doing here involves globally unique values inside IP packets. I used 
the word "label" to avoid saying "address" or "name". We probably need 
something better for this.

Now using MPLS infrastructure to build a multihoming solution would be 
an interesting idea in it's own right.

---

From: David Conrad <[email-masked]>
Date: Thu, 1 May 2003 23:10:48 -0700

Peter,

> reality, you have to pick which one of the mappings is suitable to 

Yes.  Even in the semi static view (as you put it), you need to pick 
one out of set of potential locators provided to you by the destination 
site.

> best path to reach that site will depend on where you are in the 

True.  I would think, since the destination site is doing the 
advertising, it would be useful to include some 'advisory' information, 
e.g., if all other things are equal, choose locator X instead of Y (or 
choose X for 60% of flows, Y for the rest, or whatever).  Of course, 
this is just advisory information.  It is the source site which is 
making the decision as to what aggregation locator is chosen and there 
can be numerous contributing factors to that decision depending on what 
information is available to the chooser.

> site, or relying on information gathered about the network.

Of course, by the time you have traced all possible paths, it is 
possible new paths have been established, old paths are out of date, 
etc.  Information gathered about the network can be out of date by the 
time it is collected.  Etc.  In other words, it is simply impossible to 
know the full state of the network at any given point in time.  The 
_only_ thing you can know is what a snapshot of the network looked like 
within some window of time.

Pragmatically speaking, at any given instant, I would argue that the 
vast majority of the end to end connectivity states, that is, whether A 
can reach B regardless of the path between A and B, do not change.  We 
should optimize for that.  A simple, easily implementable solution that 
optimizes for the normal case but continues to work, albeit potentially 
sub-optimally, in the exceptional cases is, I believe, what we should 
be aiming for.

> I think this is a

I am not overlooking it.  I have made a conscious decision to focus on 
pragmatism instead of trying to come up with a generic optimal solution 
as I would contend people have been looking for generic optimal 
solutions for a decade now and we have gotten nowhere.

SIP (not Session Initiation Protocol) could have included a wide 
variety of bells and whistles to try to address every possible new and 
sexy idea people had come up with (53 byte packets anyone?).  The 'S' 
in SIP didn't stand for "Steve's", after all...

> on opposite sides of the DFZ and you should understand what I am 
> getting at.

I have.  I'd be very interested in discussing (perhaps offline) the 
scenarios you believe wouldn't work with this model.

As an aside, whether a source is multi-homed is, I would argue, 
irrelevant.  A packet hits the border, a lookup in the mapping table 
(however it is propagated/fetched) is done to translate the 
_destination_ site identifier into an aggregation locator.  The source 
address is ignored.

> I have mention the push vs pull approaches to distributing the MH 
> information.  I

I am not religious.  I think simple is good, but if it can be 
demonstrated it isn't sufficient, then more complex alternatives should 
be explored.

Again, these are just some back-of-envelope type thoughts.  I'm sure 
there are holes here.  Pointers to them would be appreciated...

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 May 2003 16:28:49 +0200

David Conrad wrote:
...
> side (albeit important) issue to the underlying architecture.

No, I don't think it's a side issue. DNS brings the risk of a big-time 
circular dependency. In fact, Jon Postel thought about this one: he 
contributed the following to RFC 1958:

   3.11 Circular dependencies must be avoided.

      For example, routing must not depend on look-ups in the Domain
      Name System (DNS), since the updating of DNS servers depends on
      successful routing.

   Brian

---

From: David Conrad <[email-masked]>
Date: Fri, 2 May 2003 09:26:52 -0700

Brian,

There would only be a dependency if the servers providing the mapping 
lookup table were inside the site being mapped.  This is probably 
something it would be best to avoid (as the doctor says, "don't do 
that").  Numbering the device that provides the mapping out of 
aggregation locator space would be a way to avoid this.  Other ways 
exist.

Note that I am not against using some other mechanism than something 
like the DNS that provides the same "data pull" functionality.  Nor am 
I against "data push".  As I said, both have advantages and 
disadvantages.  What is more interesting to me is whether or not the 
idea of implementing identity/locator separation by rewriting at the 
borders has legs.

Rgds,
-drc

---

From: Joe Abley <[email-masked]>
Date: Fri, 2 May 2003 14:22:10 -0400

On Friday, May 2, 2003, at 10:28 Canada/Eastern, Brian E Carpenter 

>       Name System (DNS), since the updating of DNS servers depends on

Some circular dependencies can be managed, however.

The DNS itself contains a circular dependency; a resolver can't find a 
true current set of authoritative nameservers for the root without 
asking a question of a root server. In this case we make do with a 
hints file which doesn't need to contain a true current set of NS 
records; it just needs a set which is good enough to find at least one 
root nameserver.

So a solution which provided basic connectivity and sub-optimal routing 
for bootstrap purposes might be ok, if that connectivity and routing 
could be subsequently refined and optimised by some dependent 
infrastructure.

For example, a site might bootstrap itself as single-homed, ignoring 
all but one of the diverse paths available to connect itself to the 
rest of the world, and only become really multi-homed once it had used 
its single-homed access to look up some supporting data (using the DNS 
or something).

Joe

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 May 2003 17:33:19 -0400

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

Joe is absolutely on the right path.

>       successful routing

And if you change this to:

>       For example, core default free routing must not depend on look-ups in
>       the Domain Name System (DNS), since the updating of DNS servers depends
>       on successful defaul free routing

Long ago there was a discussion about whether or not DNS servers were 
things that needed to be multihomed - the answer was that they were not.

One does far better with multiple DNS servers on unique PA addresses.
DNS already deals with failover, etc...

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [