Subject: TASL

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Aug 2004 19:34:51 +0200

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Aug 2004 16:04:32 -0700 (PDT)

> used locator ULID1. This seems to cover a lot of the multihoming

This assumes that the responder has a certificate?
What is the binding between that certificate and the identity of the
responder? Based on the FQDN matching, or based on having IP address(es)
in the certificate?
Assuming we worry about pre-meditated attacks (aka time-shifting attacks)
we do need a reasonably strong binding between the cert and the responder.

> repeated independently in the reverse direction.

Does this mean that a separate tls session is established in the reverse 
direction?
Would the initiator of the communication need a TLS certificate?

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Aug 2004 05:08:48 +0200

> responder? Based on the FQDN matching, or based on having IP address(es)

Personally I'd rather avoid any DNS dependence so maybe it has to be
address based... but I'm too tired to think very clearly tonight...

> we do need a reasonably strong binding between the cert and the responder.

Yes
> Does this mean that a separate tls session is established in the reverse 

In the general case I think so, but it might be possible to optimize
it out in many cases.

> Would the initiator of the communication need a TLS certificate?

That seems likely to be necessary.

The idea is half baked of course - I just wanted it on the table in
case it has any merit.

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Sat, 7 Aug 2004 16:57:32 -0700

Brian,

BEC> In TASL, a pair of MUltihoming SHims (MUSHes) communicate independently of
BEC> the IP flow that is to benefit from multihoming, using TLS, in order to

 I apologize for seeming to be reading-impaired, but I am not seeing
 what significant differences there are between TASL and MAST.

 Please elighten me.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Aug 2004 11:45:20 +0200

>  what significant differences there are between TASL and MAST.

Cuter acronym? :-)

Seriously, there is obviously a very close relationship (the actual
protocol exchanges would be like those in MAST and NOID, so I didn't
spell them out). But when I re-read MAST I don't see it clearly stated that
a separate, reliable, and secure transport connection is used to carry the
exchanges - that is suggested as an option at the end of the MAST security
considerations, but it is basic to TASL. And I don't see any need to use
XMPP as you suggest in MAST. So I'd argue it's a simpler approach, but
clearly closely related.

     Brian

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Aug 2004 10:09:49 -0700

Brian,

BEC> Seriously, there is obviously a very close relationship (the actual
BEC> protocol exchanges would be like those in MAST and NOID, so I didn't
BEC> spell them out). But when I re-read MAST I don't see it clearly stated that
BEC> a separate, reliable, and secure transport connection is used to carry the

separate:  yes.

reliable: the spec calls for retransmission with exponential backoff.

secure: the current spec calls for a random string, to protect against
obvious within-session spoofing.

doing more than this requires carefully deciding among tradeoffs for
cost and benefit. TLS is an easy, reasonable choice, but the overhead of
a tcp connection gets a little scary when the scaling effects of having
every host-pair do this is considered.

BEC> exchanges - that is suggested as an option at the end of the MAST security
BEC> considerations, but it is basic to TASL. And I don't see any need to use
BEC> XMPP as you suggest in MAST. So I'd argue it's a simpler approach, but
BEC> clearly closely related.

The question is whether there is need for a dynamic rendezvous service.
It is offered as an adjunct, not core, capability in MAST, in order to
support situations with mobile servers.

d/