Re: Shared Locator Address Pool (SLAP) protocol proposal

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

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" <brc@zurich.ibm.com>
To: "Spencer Dawkins" <spencer@mcsr-labs.org>
Cc: <multi6@ops.ietf.org>
Sent: Thursday, November 20, 2003 7:00 AM
Subject: Re: Shared Locator Address Pool (SLAP) protocol proposal


> 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
>
> Spencer Dawkins wrote:
> >
> > 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
>