Hi Acee, > There is NO bug in RFC 2328. The RFC clearly states that a
While I did use the "b" word, I did not mean a "bug" -- have always referred to it as an ommission. > Router-LSA will be advertised with the same Router-ID for > both the LSID and the Advertising router. I don't think it is This is at the sending side. What about the RX side? I guess that's where the omission was. > productive to write "short" RFCs for every attack and believe > the CERT Alert is a better and swifter mechanism for > disseminating information on attacks. > Note that my implementation was not susceptible to this > attack as the vulnerability was identified in a packet > mutation suite many years back. > > I spoke to Gabi offline about authoring an informational RFC > that discusses classes of OSPF attacks and possible > mechanisms to thwart them. I am fine with that as well. I just want the different kids of attacks to get documented somewhere. Cheers, Manav > > Thanks, > Acee > > > > > I have written a short post on what the issue in 2328 is > and how it can be exploited to launch an attack. > > > http://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulne > > rability-exposed-by-black-hat/ > > > > Cheers, Manav > > > >> -----Original Message----- > >> From: Anton Smirnov [mailto:[email protected]] > >> Sent: Thursday, September 12, 2013 4:46 PM > >> To: Bhatia, Manav (Manav) > >> Cc: Gabi Nakibly; Acee Lindem; [email protected] > >> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - > Owning the > >> Routing Table Attack) > >> > >> If attacker has joined flooding domain and can inject > an LSA into > >> LSDB then it can screw up routing in the domain. > >> Methods such as pretending being an ABR/ASBR and advertise > >> destinations with good metric are almost impossible to combat once > >> authentication barrier is penetrated. > >> This particular vulnerability allows attacker to bring network > >> down in style but if this vulnerability is not present in the > >> particular network then attacker will simply resort to > other numerous > >> possibilities to affect routing via LSA injection. If attacker can > >> inject LSA into LSDB then your network is at his mercy. > Give or take > >> one particular method is a detail. > >> So IMO we don't need a draft on this particular > vulnerability. It > >> might be of some limited interest to document all known methods to > >> exploit LSA injection which would include this > vulnerability but what > >> value would this RFC bring? Such methods are regularly > published in > >> academic literature since 90-th. > >> > >> IMO we need good (reliable, secure, manageable etc) methods of > >> authenticating adjacencies. KARP group is working on that. > We *might* > >> benefit from a work on mechanism to prevent any router to > originate > >> reachable LSA on behalf of any other router (kind of LSA signing). > >> But work on what will go wrong when intended security barriers are > >> broken IMO is not needed. > >> > >> Anton > >> > >> > >> > >> On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote: > >>> Hi Gabi, > >>> > >>> [clipped] > >>> > >>>> Nonetheless, I am sure that there are more OSPF vendors > out there > >>>> that are still vulnerable to the attack and do not check > for this. > >>>> Moreover, since this check is not part of the standard, in most > >>>> likelihood future OSPF implementations will also be vulnerable. > >>>> > >>> [clipped] > >>> > >>>> I am willing to write a draft describing this mitigation > >> measure. I > >>>> would appreciate the list's thoughts on this. > >>> I think it's a good idea to write a draft that describes > >> the attack and what implementations MUST do to avoid it. > >>> > >>> Cheers, Manav > >>> > >> > >> > > _______________________________________________ > > OSPF mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
