Re: An idea: GxSE

[Mohan Parthasarathy <Mohan.Parthasarathy@eng.sun.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?
>
Some UDP applications do a connect(). In this case there is state
in the kernel which can react to an address update. In other
cases it would be a problem. Do you mean to say that UDP
applications might remember about destinations it needs
to communicate with, for a long time ?

Most of the documents about renumbering talks only about
TCP connection surviving and so we are a bit carried
away here i guess..

-mohan

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