Re: [pim] BSR update

[Stig Venaas <stig.venaas at uninett.no>]

John Zwiebel wrote:
> On Apr 10, 2006, at 11:02 PM, Stig Venaas wrote:
[...]
> > >      o <optional> only accept DNF-bit BSMs for <TBD> seconds after 
> > > discovery of
> > >         a new PIM neighbor.
> >
> > Yes, I'm not sure about this one. Regarding unicast BSMs it now says 
> > that they are accepted until first BSM or a maximum of 150s (I 
> > believe). Which kind of makes sense. I'm not able to see any problems 
> > in removing this restriction though. For unicast BSMs I think it's 
> > there partly to improve security...
>
> If the DNF-bit didn't also mean 'trust me' I wouldn't care.  But as it is
> now, I think 30 seconds is more than long enough.

You always have to trust the PIM neighbour. An attacker could at any 
time send out BSMs claiming to be a BSR (or actually just some address 
for which RPF is okay) with a very high priority. With DNF-bit set you 
can only poison the neighbour, without it set, everyone can be poisoned. 
So I don't see any security issues in allowing this at any time, but I 
agree that 30s or something is enough, so maybe I shouldn't bother 
pointing this out...

> Of course, we aren't addressing the potential loss of such a triggered 
> BSM. :-(

Well, let's not try too hard to make it better than the current unicast 
BSMs.
> > >   Trying to heal a broken network appears to be a pathological case 
> > > where the
> > >     network isn't configured for redundancy anyway.  There's no 
> > > advantage
> > >     to it since other problems will overshadow this fix.
> >
> > Doing the forwarding helps in exactly these pathological cases. But in 
> > those cases there is a risk of getting stale data as well (if a router 
> > is out of contact with BSR for a short while).
>
> Yes, IFF one has not configured his network for redundancy.
> If I sound like a broken record, sorry.  I just want to be sure
> that forwarding a triggered BSM is not an option.  The cases it
> fixes are few while the potential for causing problems that we
> don't currently understand are many.
>
> > BTW, a router could also have stale data if there is some packet loss 
> > on path from E-BSR...
>
> Which I interpret to mean that you will not forward the triggered BSM.
> Great.

Yep. I was initially questioning the need for this, but I've convinced 
myself (with your help), that it's best not to forward it. And again, 
this is just as good (or bad) as the current unicast BSMs.

In my opinion this change simplifies the draft and implementations quite 
a bit. There are some minor interoperability issues with routers 
implementing the old spec (since they may send or expect unicast BSMs), 
but in worst case it means that one has to wait for the periodic BSM to 
be sent. Also note that if we are to improve security, we can't be fully 
backwards compatible anyway.

Is anyone objecting to getting rid of unicast BSMs? If not I'll go ahead 
and update the draft. As was said at the wg meeting, we would like to 
have a last call pretty soon.

So please, if there are any objections to this change, let me know 
before I start rewriting the draft. You don't have to wait until last 
call to tell me. It seems at least some of us want this change, but I 
don't know whether we have rough consensus or not.

Stig

> _______________________________________________
> pim mailing list
> pim at ietf.org
> https://www1.ietf.org/mailman/listinfo/pim


_______________________________________________
pim mailing list
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim