TASL

[Brian E Carpenter <brc@zurich.ibm.com>]

Co-chair hat is OFF

I know that the WG is not looking for yet more solutions proposals, but
the idea below (which seems very obvious) came to me when thinking about
the DNS dependency in NOID. I'm sending this message to get the idea
on the record, but I don't intend to write a complete draft... this
is simply something that the wedge layer design team may want to
consider. Oh, and if this idea has already been proposed in the past,
please say so.

Transport Assisted Shim Layer (TASL)

In TASL, a pair of MUltihoming SHims (MUSHes) communicate independently of
the IP flow that is to benefit from multihoming, using TLS, in order to
establish shared MUltihoming STate (MUST). The TASL exchange itself isn't
multihomed, to avoid a recursion issue.

[But if it was in fact established over SCTP instead of TCP, that
issue would go away.]

At the highest level it looks like this. ULID = Upper Level Identifier
(a.k.a. AID), but it's actually an IPv6 address that serves as the
initial locator for a host in a multihomed session.

                _________     ____      ____     _________
               |         |   |    |    |    |   |         |
               |  MUSH1  |   |    |    |    |   |  MUSH2  |
               |       <-|---|-----TLS------|---|->       |
               |         |   |    |    |    |   |         |
               |  _____  |   |    |    |    |   |  _____  |
 ULP           | |     | |   |    |    |    |   | |     | |    ULP
 send(ULID2)-->|-|MUST1|-|-->|-IP-|....|-IP-|-->|-|MUST2|-|--->receive
               | |_____| |   |    |    |    |   | |_____| |
               |_________|   |____|    |____|   |_________|


The ULP in host 1 sends a first packet to the ULID of host 2
(ULID2), sourced from its own ULID (ULID1).

The MUSH in host 1 intercepts this packet, creates empty MUST for
it, and sends the first packet on its way to locator ULID1.

MUSH1 asynchronously opens a TLS session to a well-known port
at host 2 on locator ULID2. It then uses NOID- or MAST-like
protocol elements on that session to exchange locator lists with
MUSH2. As long as the session stays open, updates can be conveyed.
The locator lists and any other state is saved in MUST1 and MUST2.
(Presumably, the contents of MUST1 and MUST2 will be equivalent.)

Presumably MUSH1 binds to an ephemeral port, and contacts MUSH2
on a  well-known port at ULID2. Potentially, the same inter-MUSH
TLS session is shared among all ULPs that use the same
ULID pair.

There is a risk here of (up to) doubling the number of ports in use,
and that can be a scaling disadvantage of this solution.

Since the protocol exchange is protected by TLS, we are certain
that no 3rd party has injected bogus locators or been able to
observe the locator exchange. Thus, whichever host initially
responded to locator ULID2 is the only one able to send and receive
news of alternative locators, and only to the host that initially
used locator ULID1. This seems to cover a lot of the multihoming
threats.

If host 2 doesn't have a MUSH, it will not respond to the
TLS session, so host 1 will never establish MUST, and MUSH1
will be transparent to the packet flow.

The ULP session will proceed with its original locators until
a multihoming event occurs, at which time source and/or destination
locators will change. The incoming packets at host 2 will at all times be
matched to the state in MUST2; likely the 3-tuple {srce, dest, flow_label}
will be used, and that will define the granularity of multihoming
between host 1 and host 2. If the source changes from ULID1, and/or
the destination changes from ULID2, as long as the new locators are
saved in MUST2, the packet will be accepted and the original
{ULID1, ULID2} will be restored just as in NOID.

Instead of the 3-tuple of {src, dst, flow_label}, a 2-tuple of
{src, dst} could be used. That would share the MUST among
all sessions using the same initial pair of ULIDs. (As long as
most traffic has no flow label, that will happen anyway.)

Of course an attacker can inject spoofed packets using any valid
locator pair at any time. But that's always been true. TASL means
that no third party can learn the locators in use.

If the TLS session (which isn't multihomed) goes down, further updates
to the MASTs become impossible --- so we should ensure that the initial
exchange involves an unguessable nonce, which will be kept secret by
TLS. Then a new TLS session can be created, between a new pair of
locators, and connected to the existing MASTs by use of the nonce.

The mechanism for choosing new locators, either when a multihoming
event occurs, or when the TLS session goes down, is not defined
here (but needs to be defined somewhere).

Note that this is all a one-way solution as far as the ULP is concerned.
If ULP packets come back from host 2 to host 1, the whole thing is
repeated independently in the reverse direction.

However, there is no reason that an implementation can't optimize by
noting that a TLS session and MUST state already exists in the reverse
direction, and short-circuiting the state exchange as far as possible -
it can probably be completely eliminated if the flow label is zero.

Brian Carpenter
with help from Roy Brabson