Manav, The premise of the attack is still somebody know the AUTH keys of the router. If private keys of the router can be possibly subverted/leaked/stolen, then we all agree lot of things in lot of protocols can break (not only in OSPF or this is not specific to OSPF issue).
One can definitely try to introduce protocol mechanisms to thwart some of these attacks to a certain extent, but the point is the problem is not still addressable this way. The question is how far it's real (I know KARP WG is contending with this) and what are the other mechanism one can adopt to solve the issue at the root instead of introducing more complicated protocol machinery. I also feel this should be analyzed more from KARP protocol threat documents... -- Uma C. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Acee Lindem Sent: Thursday, September 12, 2013 7:59 AM To: Bhatia, Manav (Manav) Cc: [email protected] Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack) 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-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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
