Re: An idea: GxSE

[Brian E Carpenter <brian@hursley.ibm.com>]

Not all applications are TCP or SCTP. UDP applications don't
(in principle at least) have enough state to respond to
an address update, do they?

   Brian

Mohan Parthasarathy wrote:
> 
> 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