Subject: Shared Locator Address Pool (SLAP) protocol proposal

From: Dave Crocker <[email-masked]>
Date: Sat, 15 Nov 2003 08:45:55 -0800

Folks,

A fundamental advantage that transport-based locator-pool schemes
(SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6,
MAST, MIP) is that they can multiplex the control exchange in with
data traffic, potentially saving on number of packets. Wedge-layer
approaches are forced to have an explicit, separate exchange. MAST
makes this asynchronous from the data exchange that uses the locator
pool; this avoid startup delay. However the basic cost of the exchange
remains. If a host must do this exchange with every other host it
talks to, the aggregate overhead is high.

Deferring use of the mechanism, as Pekka S. described, is one way to
reduce such traffic.

Wouldn't it be nice if it were possible to have the "enhanced"
transport services share their lower-cost largesse with the
wedge-layer schemes?

So, here's the thought:

1. An endpoint runs Locator Pools (LP) as a resource shared among different
consumer services at the endpoint -- eg, a wedge layer service and an enhanced
transport service -- potentially with multiple maintainers. (Yes, the latter
raises a concern about synchronization, but let's ignore that minor detail,
for now.) LPs might vary in their granularity.  Bigger grains makes it
more likely that the pool will be shared.  A pool that is the finest
grain (Connection) can't be shared, of course.

2. A common Shared Locator Address Pool (SLAP) protocol is used by the
different maintenance services, over different communication channels
(eg, multiplexed on the transport channel, versus over an independent
control channel). The maintenance services also might use different
"configurations", such as peer-to-peer exchange, versus third-party
agent mediation.

3. Enhanced transport services access the pool directly. Legacy
transport services access the pool via the much-vaunted IP wedge layer
service. If an enhanced transport is one of the participants, then
there really is no need for a wedge-layer service to conduct an
exchange. This saves packets.

The obvious direction this idea leads is towards an effort to produce
a common protocol.  Clearly it should include the locator
"characterization" attribute-signalling capability that Erik suggested.

Anyone from the various camps interested in discussing such an effort?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 15 Nov 2003 14:13:09 -0600

Dave,

If this proposal can be made to work, that would be lovely. The part
that scares me is having a number of different entities maintaining
this pool (if we had TCP, SCTP, RTP/RTCP, and DCCP on one node, that's
not a small amount of software) - just figuring out why something was
added or deleted seems daunting.

But I'll let others chime in here, one way or the other.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2003 13:48:06 +0100

Spencer, I think the point here is that there will be state
to maintain, and each user of that state will need to access a
common STorage Information bloCK, i.e. the SLAP STICK.

The kind of shim that NOID suggests could also be a user
and maintainer of the slapstick.

I'd encourage people to think about this as a potential
architectural component, in the spirit of the final part of
the discussion last week.

  Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 17 Nov 2003 07:09:01 -0600

Hi, Brian,

> the discussion last week.

This all works for me. The thing in the back of my mind was that we
didn't head in a parallel direction with ECM (Endpoint Congestion
Management) - we developed the base specs, and then everthing kind of
stopped. But we've clearly considered providing a common capability
for all transports in a situation that was architecturually similar,
and the ECM pictures had congestion management in a shim underneath
multiple transports (the same point in the stack, if I get the SLAP
vision).

I don't think there was any technical obstacle to ECM, just a lot of
stack developers who already had working TCPs and didn't want to dork
with them. ECM happened before DCCP and pretty early for SCTP, so
there weren't a lot of non-TCP transports that were trying to get
congestion control right. But I digress.

The rules for using the SLAP STICK, and especially for modifying it,
need to be pretty clear. We know how to write clear rules, we just
need to make sure we do it this time!

Thanks,

Spencer

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Nov 2003 07:08:26 -0800

Spencer,

SD> stopped. But we've clearly considered providing a common capability
SD> for all transports in a situation that was architecturually similar,
SD> and the ECM pictures had congestion management in a shim underneath
SD> multiple transports (the same point in the stack, if I get the SLAP
SD> vision).

I think it is the same point in the stack, yes. In fact, the discussions
that led to my suggestion using "connection id" as the fine-grained
identifier for a pool also prompted me to realize that the new, IP
Endpoint (IP-EP) module also needs to provide common congestion control,
as I commented in my parallel proposal to SLAP.

SD> The rules for using the SLAP STICK, and especially for modifying it,
SD> need to be pretty clear. We know how to write clear rules, we just
SD> need to make sure we do it this time!

Yup!

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2003 17:06:12 +0100

Dave, please look carefully at the way the NOID proposal uses
the Flow Label as (part of) the connection ID. I had my doubts when
it was first proposed in the design team, but it has its advantages.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Nov 2003 13:34:21 -0800

Brian,

BEC> Dave, please look carefully at the way the NOID proposal uses
BEC> the Flow Label as (part of) the connection ID. I had my doubts when
BEC> it was first proposed in the design team, but it has its advantages.

 If I have suggested anything that contradicts NOID, concerning SLAP,
 then I don't know what it is.  Please clarify.

 (For the total topic of multiaddressing, I want to find mechanisms that
 do not put special or extra information into the packet header, at
 least so it will work with IPv4, but I don't think that the SLAP
 proposal affects this issue, one way or the other.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 17 Nov 2003 17:32:36 -0800

Folks,

Further thought:

SD>> stopped. But we've clearly considered providing a common capability
SD>> for all transports in a situation that was architecturually similar,
SD>> and the ECM pictures had congestion management in a shim underneath
SD>> multiple transports (the same point in the stack, if I get the SLAP
SD>> vision).

DC> I think it is the same point in the stack, yes. In fact, the discussions
DC> that led to my suggestion using "connection id" as the fine-grained
DC> identifier for a pool also prompted me to realize that the new, IP
DC> Endpoint (IP-EP) module also needs to provide common congestion control,
DC> as I commented in my parallel proposal to SLAP.

With a multiaddressing pool mechanism, the transport may not see the
locator information, instead seeing only an identifier.

However, differential congestion control is needed at the locator level.

So I think the long-term effect of creating pools needs to be to bring
congestion control into the core of the pool mechanism.

Think of this as taking the bottom end of transport and the top end
(sort of) of IP and making them overlap.

Mumble.

d/

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Nov 2003 03:18:23 +0900

Dave;

> approaches are forced to have an explicit, separate exchange.

And, that is a possible new security threat of DoS amplifying.

> consumer services at the endpoint

The Internet today already have DNS cache, which even enabls
sharing beyond an endpoint.

> "characterization" attribute-signalling capability that Erik suggested.

Some characterristic of a locator is already stored in an endpoint
as routing table entry or cache.

Some (such as PMTU) is better treated by the transport layer.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2003 09:17:08 +0100

Dave,

>  then I don't know what it is.  Please clarify.

NOID includes the flow label in the n-tuple that identifies a flow (for
lack of a better word). This isn't different from what you suggest at
10,000 meter level, but it affects some details, including the granularity
at which multihoming occurs - in fact the granularity becomes identically
the scope of a {srce, dest, flow label} 3tuple, rather than the scope of a 
{srce, dest, port, port, protocol} 5tuple. And it has the advantage of using
fields that are outside all IPSEC headers.

As far as I can tell, NOID is fully compatible with the flow label spec
(draft-ietf-ipv6-flow-label-08.txt).

>  proposal affects this issue, one way or the other.)

This is the IPv6 multihoming WG...

   Brian

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 19 Nov 2003 12:56:53 +0100

> the discussion last week.

Personally, I like the SLAP STICK idea very much.  To me,
it is pretty clear that the interface between multi-addressed
layer 3.5 and transport has some serious issues, as discussed
e.g. by Spencer.  Perhaps SLAP, maybe combined with ECM,
could do something to them.

However, I am also worried about potential DoS and other
security issues.  To me, it looks like a bad idea of allowing
all of the upper layer protocols to add or remove addresses
from SLAP.  Updating (soft) address state is probably fine,
but both adding and deleting addresses is potentially dangerous.

Hence, maybe we should consider a new protocol to maintain
the SLAP state, and instead of having upper layer address
update mechanism (eg. SCTP addip), route the upper layer
APIs to the new protocol.

--Pekka Nikander

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Nov 2003 08:30:35 -0800

Pekka,

PN> However, I am also worried about potential DoS and other
PN> security issues.  To me, it looks like a bad idea of allowing
PN> all of the upper layer protocols to add or remove addresses
PN> from SLAP.  Updating (soft) address state is probably fine,
PN> but both adding and deleting addresses is potentially dangerous.

Please elaborate on your concerns.

My assumption is that the apps each has at least the requisite, basic
"authentication of exchange continuity" that routing-based IP validation
provides.

So all I can guess is that the danger you fear is the general one of
having too many participants (applications and transport add/delete
mechanisms) and that any one of them can do a lot of damage.  That's why
I think it would be great to try to standardize a single control
protocol, but permit it to be used over a variety of mechanisms (layer
3.5, transport, and even apps.)

d/

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 19 Nov 2003 18:50:36 +0100

Dave,

> Please elaborate on your concerns.

It's mostly gut feeling right now.  I have to do some analysis
before I can say much more, and I don't have that time right now.
Maybe reading Erik's threat draft would give some insight?

> "authentication of exchange continuity" that routing-based IP validation

Well, while that may suffice as a baseline, it may still have
some issues.  Like what if some applications have better security
properties than others?  In that case you could use an application
with weaker security to confuse the SLAP state in order to launch
an attack against a more secure application.

> mechanisms) and that any one of them can do a lot of damage. 

More or less yes.  But there are probably details, and they
need to be worked out.

> That's why

I agree that it would be great to standardize a single control
protocol.  However, I am not so sure whether it would be great
to permit it to be carried over a variety of mechanisms.

One particular problem with security is that it is not composable,
in general.  That is, if you have a perfectly secure mechanism A,
and another perfectly secure mechanism B, putting them together
into A + B (where + is some sort of a composition operator) may
result in a system that is not secure any more.  (I am not saying
that it is not composable in this particular case.  I am merely
saying that we don't know before we've done some analysis.)

--Pekka Nikander

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 19 Nov 2003 21:08:07 -0600

Hi, Pekka and Dave,

I didn't mean to bring up a subject quite this dark. My concern was
about errors in one transport or one application hosing the multi6
capability for everyone, and about how difficult it might be to debug
this (visualize kernel debugging in many implementations). Pekka's gut
feeling about one transport or one application being manipulated into
hosing the multi6 capability for everyone is the next step, when one
thinks about it (thanks for thinking about it).

Put another way, I was talking about software engineering, not about
protocol design. Pekka brought the concept back into protocol design
territory.

If we're saying that, in the absence of secure discovery mechanisms,
anybody can respond to ARP requests and steal traffic, that's true,
but maybe a little easier for the average snifferholic to debug than
what Pekka and I are noodling about - a blown pointer would be
sufficient to cause the effect I'm talking about.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2003 14:00:08 +0100

Our guideline here is that the multi6 solution must not introduce any new
security vulnerabilities that we don't have today. And Pekka is certainly
correct - anytime you add shared state, you need to protect it against bad
people. But we can't assume that any key material is available to multihoming
participants, unless we also define how they acquire it, since multihoming 
participants likely have no pre-existing relationship.

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Nov 2003 07:44:29 -0600

Maybe I'm the only one that's still catching up, but I think this
makes three categories of worries,

- protecting different users of multi6 on a single node from each
other's implementation bugs (not our problem, but anything we do to
keep from making it worse helps),

- protecting different users of multi6 on a single node from each
other's exploitation vulnerabilities (not quite the same as previous,
but close, because we're talking about "implementation bug
amplifiers"),

- protecting all the users of multi6 on a single node from attackers
on other nodes (clearly our problem).

Is this close?

- so there's probably a category of worry about protecting groups of
multi6 participants from attack, too...

Spencer

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 20, 2003 7:00 AM
Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal

> > > > My assumption is that the apps each has at least the
requisite,
> > basic
> > > > So all I can guess is that the danger you fear is the general
one
> > of
> > > > protocol, but permit it to be used over a variety of
mechanisms
> > (layer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 20 Nov 2003 07:30:35 -0800

Spencer,

SD> - protecting different users of multi6 on a single node from each
...
SD> - protecting different users of multi6 on a single node from each
...
SD> - protecting all the users of multi6 on a single node from attackers

The fact that SLAP involves multiple instances of the control protocol
does not necessarily mean that the instances are under the control of
different users.

Of course, a user can take over the kernel of a machine, but there is
nothing we can do about that problem.

So, the normal scenario is that the control protocol instantiations are
running in the operating system.  Different users might be the cause of
having multiple instantiations, just like they might be the cause of
multiple TCP connections. But that does not mean the users have special
priviledges over each other.

Note that the pool of TCP connections is "shared" state, of exactly the
type that we have with SLAP.  Do we view that shared, TCP pool as a
security risk?

d/