Re: DRAFT of the architecture presentation for the WG session this week

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Geoff,

Mostly as FYI but maybe useful for your presentation,
below is a copy of a message that started a brief
private discussion with Erik, Dave and some others in last
October.  It really considers only wedge approaches,
but goes into some more detail than your current slides.
Some of the information may already be stale, given
that it is five months since this discussion.

--Pekka Nikander

I think that I am starting to see components.  There are a
couple of things that seem to be more or less ubiquitous
over the various solutions:

  1. A wedge layer between IP and the transport layers,
     translating IDs to locators and back.
  2. A modified resolver library that returns IDs instead
     of locators.

Then we seem to have a number of possible solutions that
allow the recipient to map incoming packets on the right
ID pairs:

  3a. A new extension header that provides an
      ephemeral 32-bit ID that acts as a pointer to a
      specific ID pair.
  3b. An ESP extension header that provides a 32-bit
      SPI that acts as a pointer to a specific ID pair.
  3c. A single bit stolen from the IP header that indicates
      that the incoming locator pair must be mapped to an
      ID pair.
  3d. Conceptually steal a bit in the IP header, but implement
      it with clever encoding.
  3e. An implicit assumption that if two hosts communicate,
      they always communicate either with or without the
      new semantics.  Hence, each incoming locator pair
      can be matched against known and cached locator pairs,
      and if a match is found, the locator pair can be mapped
      to an ID pair.

3a and 3b allow multiple IDs behind a single address.
3c, 3d and 3e do not.  3e does not allow locator rewriting
by routers.

So far I think that the solution space is pretty clear.
Next we seem to reach muddier waters.

We seem to need a method to prevent redirection attacks
(both connection hijacking and flooding).

  4a. Rely on some variant of return routability
  4b. Rely on forward and reverse DNS.

The next thing is the context creation protocol.  This seems
to require a 4-way handshake, consisting of a trigger,
request, response, and confirm.

What is noteworthy is that both TCP and SCTP can be
piggybacked over this context creation, since neither TCP SYN
nor SCTP INIT requires state to be created at the responder.

There are multiple dimensions on how the context creation
protocols differ.

Time:

  5a. The context is created immediately.
  5b. Context creation may be delayed.

Security strength of identifiers:

  6a. The context is not associated with any strong
      identifier.
  6b. The context is authenticated with a strong identifier.

Actual mechanism:

  7a. A simple tag is shared during context creation,
      and this tag is later used as a weak means of
      authentication.
  7b. A simple secret is shared during context creation,
      and this secret is later used to authenticate
      changes to the context.
  7c. A D-H protocol is run immediately, and the thereby
      created shared secret is used.
  7d. A D-H protocol may be run later.
  7e. A pair of hash chain anchors are exchanged during
      context creation, and the previous hashes from
      the hash chain are later used to authenticate
      changes to the context.