Re: Shared Locator Address Pool (SLAP) protocol proposal

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

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