Manav -
On Sep 12, 2013, at 10:40 AM, Bhatia, Manav (Manav) wrote: > Anton, > > I understand that once the attacker can insert LSAs in the flooding domain > then there are several things that can be done. However, in most cases the > attacks can be easily identified and a corrective action can be easily taken. > In this particular case, the attack is a little more insidious and its not > straight forward catching the erring LSA. > > Since its something that's missing in rfc 2328 we will keep having newer > implementations that will carry this bug. A short one page RFC that updates > 2328 imo would do no harm. Do you see any issue in publishing such an RFC? There is NO bug in RFC 2328. The RFC clearly states that a Router-LSA will be advertised with the same Router-ID for both the LSID and the Advertising router. I don't think it is 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. 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-vulnerability-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
