Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

["Bhatia, Manav (Manav)" <[e-mail]>]

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:[e-mail]]
> >> Sent: Thursday, September 12, 2013 4:46 PM
> >> To: Bhatia, Manav (Manav)
> >> Cc: Gabi Nakibly; Acee Lindem; [e-mail]
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ospf
> 
>