Subject: [Isis-wg] *SNP replay

From: Jeff Parker <[email-masked]>
Date: Thu, 25 Apr 2002 10:11:11 -0400

Just to be clear I have removed the draft name
from the subject line.  

> > I'm not suggesting we delay the document.
> 
>
> So a robust IS-IS implementation probably won't be very badly
> affected by packet replay.  For non-robust implementations,
> any number of things could be a problem -- but that is an
> implementation quality issue IMHO.

True.  I hope that improving implementation quality 
is something worth discussing on this list.  

What is interesting about replaying *SNP packets is
that it is one of the few ways in ISIS to introduce
a multiplier.  The worst of the DOS attack depend 
upon other machines doing the work, and an out of
date *SNP will cause other machines to retransmit
LSPs.  I agree that there are rate limits on how
fast you resend an LSP, but with a large configuration,
SNPs with stale info could force constant updates.  

(The only other packet I can think of with leverage
is changing the priority on a hello to force a
DIS election.  If I send a duplicate of a hello 
from a low-status IS with high priority, can't I 
force all of the machines on a network to swing
back and forth between two DISs?)

- jeff parker
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 26 Apr 2002 00:32:14 -0700

>is something worth discussing on this list.  
yes, to some extent,
but it shouldn't be or become this list main activity, we are about 
interoperating
implementations, we are not in business of protecting people from 
themselves or
helping people build businesses ;-)

>SNPs with stale info could force constant updates.  
yes, also corrupted SNPs can lead to interesting effects, e.g. just sending
large SNPs full of rubish can lead to many routers running around trying to
find out what's going on ;-)  Few package but large damage, I think that's
the metric you are alluring to ;-)

>back and forth between two DISs?)
I don't remember of the top of my head whether ISIS spec prescribes that
but many good implementations tend to artificially bump their DIS priority
significantly when elected
to prevent other routers with same or just slightly higher priority
to bump them of the DIS. This stops a problem if e.g. a router with 
highest ID
on a LAN with everyone being same priority  is flacky. This has a good 
chance
to prevent this kind of attack as well. Loosing DIS is
unplesant for everyone, that's why e.g. OSPF went the whole nine-yards
to get the BDR working.

    thanks

    -- tony