Re: An idea: GxSE

["Jon (Taz) Mischo" <taz@tazlore.com>]

This is a good argument for what I was talking about, actually.  Either
way, though, with UDP you'd just use a tunable timeout parameter.  There
are MANY UDP applications that remember about their destinations for a
long time.  This is the idea behind using RTP for VoIP, as well as how
many network video games, etc work, to give some examples.

UDP doesn't mean short connections, it just means more loss-tolerant or
more time-sensitive connections.  The key difference is that the vast
majority of state for UDP is kept in the client.  In the case of GxSE,
you'd need to implement something closer to what I was talking about for
UDP to work effectively, since the host would not be keeping state, and
you'd have to have the DSBR rewrite the headers since the host wouldn't be
maintaining a list of valid GR/SK pairs.  Again, this is where SK binding
comes into play.

Really, here you would have a lookup that returned the GR addresses and
you'd have your SK address.  One of the GR addresses would then be chosen
to attempt the connection.  Once you reach the far host, you'd request the
SK for that host.  You'd then reference that SK in your packets, with
confidence that your SSBR would map both your SK and his SK to their
appropriate GR/SK pairs.

It may even be appropriate to use the GR returned by the lookup to query
your SSBR for a local SK style address it knows about.  Then you are
sending packets between an SK address and a virtual SK (basically you're
doing reverse NAT here).  The SSBR is then doing all of your remapping.

I think this is right...I really think we're approaching the point where
we should start writing a draft or two just to flesh out the ideas, so we
can all understand them.

On Wed, 20 Jun 2001, Mohan Parthasarathy wrote:

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

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989