Re: Shared Locator Address Pool (SLAP) protocol proposal

["Spencer Dawkins" <spencer@mcsr-labs.org>]

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

----- Original Message ----- 
From: "Pekka Nikander" <pekka.nikander@nomadiclab.com>
To: "Dave Crocker" <dcrocker@brandenburg.com>
Cc: <multi6@ops.ietf.org>
Sent: Wednesday, November 19, 2003 11:50 AM
Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal


> Dave,
>
> > 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.
>
> 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?
>
> > My assumption is that the apps each has at least the requisite,
basic
> > "authentication of exchange continuity" that routing-based IP
validation
> > provides.
>
> 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.
>
> > 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.
>
> More or less yes.  But there are probably details, and they
> need to be worked out.
>
> > 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.)
>
> 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
>
>
>