GSE, Six/One, and Beyond --- Re: [RRG] GSE?

[Christian Vogt <[e-mail]>]

Folks,

some of you were wondering about the conceptual differences between
GSE [1] and (host-based) Six/One [2].  Here is a short comparison.

[1]  http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr
[2]  http://tools.ietf.org/html/draft-vogt-rrg-six-one


Six/One addresses four main deficiencies in GSE:

- ID uniqueness -- GSE uses flat 64-bit IDs, for which global
   uniqueness is hard to enforce.  If chosen autonomously and
   randomly, IDs would collide with non-negligible probability given
   only 64 random bits.  Central allocation would help, but would be
   hard to enforce also.  Since IDs don't have topological meaning,
   it would be facile to forgo the allocation procedure.  This is
   exactly what happens today with MAC addresses.

- ID/locator binding -- GSE does not securely bind IDs to locators.
   This enables ID hijacking, even if the attacker is not on the
   path towards the ID.

- Transparency to hosts -- In GSE, hosts are unaware of which
   providers their packets go through.  Provider awareness would
   enable hosts to suggest a provider, or to recognize when a
   provider changes.  E.g., a peer-to-peer application could select
   topologically close peers.  And transport protocols could optimize
   flow/congestion control in the presence of path changes.

- API changes -- GSE changes the properties of addresses, from the
   application perspective, relative to classic IPv6.  It hence
   requires changes to the IPv6 API.


How Six/One mitigates these issues:

- ID uniqueness -- Six/One uses standard IPv6 addresses as IDs, which
   can more easily be kept globally unique:  Centrally allocated
   address prefixes separate the ID spaces of different networks, and
   the address suffixes need to be unique only locally within a
   network.  The ID prefix is either provider-allocated and routable,
   or provider-independent and random (ULA prefix).  In the former
   case, the ID prefix cannot easily be spoofed because it is
   topology-dependent.  Collisions can then occur only between IDs of
   the same edge network, which to avoid is both facile and in the
   very interest of the edge network. In the latter case, the ID
   prefix adds enough random bits to make collisions improbable.

- ID/locator binding -- Six/One secures ID/locator bindings via
   cryptographically generated address bunches.  This is a method for
   self-signing the binding.  Alternatives would be (i) to bind the
   addresses via a certified public-key signature (Noel's proposal),
   or (ii) to store the mappings in a trusted lookup service so that
   a packet receiver can verify the mapping by checking that it
   exists in the lookup service.  Both alternatives allow for
   arbitrary addresses, perhaps assigned by DHCP.

- Transparency to hosts -- Six/One ensures that source and destination
   address prefixes in packets exchanged between edge networks are
   always allocated to the providers through which the packets go.
   (The prefixes may be rewritten by a router in order to achieve
   this.)  This enables hosts to suggest providers for which the path
   to a peer is shortest.  Hosts do this automatically in many cases
   given that the standard address selection algorithm [3] prefers
   addresses with common prefixes.  Hosts also recognize provider
   changes and can therefore assist transport protocols in coping
   with the implied path change.

- API changes -- Six/One does not change the behavior of IPv6 from the
   application perspective, hence does not require API changes.

[3]  http://tools.ietf.org/html/rfc3484

Hope this was useful.

- Christian




--
to unsubscribe send a message to [e-mail] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg