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

[Christian Vogt <christian.vogt@nomadiclab.com>]

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 rrg-request@psg.com 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