Re: An idea: GxSE

[Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.com>]

Paul,

TCP endpoint being associated with multiple addresses was
discussed in draft-nikander-mobileip-homelessv6-01.txt.
Isn't renumbering equivalent to a mobile node moving to
a new foreign link ? In that case why can't renumbering
event trigger all the TCP connections to generate a
new secure message (known as binding update in mobile IPv6)
to tell its peer about the new address ? After sending
this message, TCP connections start using the new address.
Why wouldn't this work ? 

If we are looking for a solution that would not change
the end host's implementation, then the above is not
suitable. So, is the requirement that the
renumbering event should be completely transparent to
the end hosts ?

-mohan
> 
> I've been tossing around the following basic approach to the
> multihoming/renumbering problem, and am wondering if folks think it is worth
> pursuing.
> 
> Like GSE, the basic idea is to isolate site numbering from global numbering
> by allowing site border routers to rewrite prefixes as packets pass in and
> out of a site.  Unlike GSE, however, the ID is not the sole identifier of
> the host.  The full address is still the identifier, but multiple (full)
> addresses are used to identify the host.  A packet received with any of the
> set of addresses identifies the host.  In this sense, the idea is like
> SCTP's use of multiple addresses.
> 
> I call this approach GxSE, to convey the idea that like GSE the address has
> global, site, and end-system address elements, but unlike GSE, addresses
> with multiple globals are used to identify a host (thus the 'x' after the G
> conveys a multiplier).
> 
> There are multiple ways one could design GxSE.  Here are the primary aspects
> of what I have in mind:
> 
> Every host knows at least one (and typically only one) address for itself,
> called the self-known address (SK address).  The SK address may or may not
> be globally routable, but must be globally unique.
> 
> In addition to the SK address (from here on I talk as though there is only a
> single SK address---it should be understood that there can be multiple of
> them), there is a set of one or more globally routable addresses (GR
> addresses) for every host.  The host does not need to know its GR addresses
> (nor do site-internal routers).  All of the addresses (GR and SK) for a host
> have the same "site" and "ID" parts, but different "global" parts (aka
> "prefix").  An SK address may also be a GR address.  The (publicly
> reachable) DNS entry for a host will typically contain all of the hosts' GR
> addresses.
> 
> Each of the GR address prefixes of course represents that assigned by an
> ISP.  There is a site border router attached to that ISP with that GR
> prefix.  The site border router knows the SK prefixes for the site.  (All
> hosts in a site do not necessarily have the same SK prefix, but if they
> don't then the site border router must know the SK prefix for every host.)
> The site border router knows all of the GR prefixes for the site, not just
> its own.  (Again, all hosts in a site do not necessarily "have" the same GR
> prefixes, but if they don't then the site border router must know the GR
> prefixes for every host.  Clearly it is better if all hosts have the same SK
> and GR prefixes, and this should be normal operation.)
> 
> For every "connection" (where a connection is defined as a distinct
> address/protocol/port 5-tuple), the host keeps a list of (globally unique)
> addresses of the destination (or partner) host.  It knows which of these is
> the SK address, and whether theSK address is routable or not.  This full
> list identifies the host (not just the SK address).  Two connections with
> partner hosts with different lists, even if they use the same SK address,
> are considered to be different hosts.
> 
> Packets transmitted by a host contain its SK address as the source address,
> and one of the GR addresses of the partner host as the destination address.
> Typically the destination address will be that of the most recently received
> source address, but not necessarily.  When the packet passes through the
> site border router, the router replaces the global prefix part of the SK
> address with that of the ISP to which it will route the packet.
> 
> When a packet is received by a site border router incoming, the site border
> router replaces the GR prefix with the SK prefix of the destination host,
> and forwards the packet into the site.
> 
> The list of addresses (GR and SK) is conveyed to partner hosts by an IPv6
> extension header---the address-list extension.  This header is typically
> added by the site border router as the packet exits the site.  (It could
> also be added by the source host, but this would require the host to know
> its GR addresses which is the thing GxSE is trying to avoid.  Nevertheless,
> a site could choose to operate this way.)  The header is added typically
> only for the first packet sent in either direction (with the return header
> indicating whether the forward header was received).  A GxSE-aware host
> would tell the site border router to add the address-list extension by
> attaching a different extension header (the "please add the address-list
> extension" extension, or address-list-trigger extension).  Both extension
> headers are of the "if unknown, skip over this option and continue
> processing the header" type.
> 
> The typical exchange would go like this:
> 
> SH-->SSBR: |IPv6 head|ALT ext head|transport|
> SSBR->DH:  |IPv6 head|ALT ext head|AL ext head|transport|
> DH->DSBR:  |IPv6 head|ALT ext head (acks first ALT)|transport|
> DSBR->SH:  |IPv6 head|ALT ext head|AL ext head|transport|
> SH->DH:    |IPv6 head|transport|
> DH->SH:    |IPv6 head|transport|
> 
> (where SH=source host, SSBR=source site border router, DH and DSBR are same
> for destination, ALT=address-list-trigger, AL=address-list)
> 
> 
> This is the basic idea.  Lots of unworked details....
> 
> For API, I imagine that the full list of addresses (GR+SK) gets handed up to
> the upper layer, if it cares to know.
> 
> Pseudo-header checksums and IPsec would I suppose be based on the SK address
> only (not the GR addresses).
> 
> Not sure how to deal with IPsec regarding the extension headers---due to
> inadequate understanding of this stuff.
> 
> The extension header "handshake" needs to be worked through...might need to
> be 3-way etc.
> 
> There are some destination address selection issues, to deal with the fact
> that SK addresses work within a site but not necessarily outside the site.
> Two hosts in the same site would want to use the SK address, not a GR
> address, when talking to each other.  One approach is two-faced DNS.
> Another might be to go ahead and have DNS return the GR addresses, but after
> the address-list extension headers are exchanged, the hosts would recognize
> that they share the same SK prefix and could start using that (and
> subsequently bypassing the site border router).  Note that IPv6 with
> site-local prefixes has the same sorts of issues.
> 
> As for transition, site border routers need to know which hosts are GxSE
> aware and which aren't.  For those that aren't the baseline behaviour would
> be for site border routers would agree to all use the same GR prefix on
> outgoing packets for each host.  Obviously if the site border router with
> that GR crashes, then communications breaks, but this is no different from
> today's situation.  The site border routers could potentially also try to
> proxy GxSE on behalf of the non-GxSE aware hosts (for the case where the
> partner host is GxSE aware).  In this case, the site border router would
> need to keep enough state to know to attach the address-list extension on
> the initial packet only. (An address-list extension minus the
> address-list-trigger extension would convey to the destination host that the
> source host is non-GxSE aware, but the site border router is.)
> 
> As for the issues brought up by draft-ietf-ipngwg-esd-analysis-05.txt, they
> largely don't apply because GxSE uses fully overloaded addresses, just more
> of them.  For instance, there is no ID-to-address mapping issue because the
> ID is never used alone as the identifier.  A host cannot pretend to be
> another host, in essence because the full set of addresses is what
> "identifies" a host, not a single address (and certainly not an ID alone).
> So, for instance, if a rogue host tries to pass itself off as having another
> host's SK address but its own GR address, it won't matter because the
> "identity" of the rogue host would be considered to be the whole list of
> addresses, and so wouldn't be confused with the "true" host (with the same
> SK address but the correct GR address).
> 
> Note that GSxE doesn't prevent renumbering altogether---it would still be
> required when two sites merge.  But renumbering would not be necessary
> because of changing providers.
> 
> Comments?
> 
> PF
> 
> 
>