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

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

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?

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:[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
> >
> 
>