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

[Acee Lindem <[e-mail]>]

Hi Manav, 

On Sep 12, 2013, at 11:05 AM, Bhatia, Manav (Manav) wrote:

> 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.

Note that if you use a simplistic reference implementation and do the LSDB lookups during your SPF, you will have no problems. It is only optimized implementations that have a problem. For example, my implementation would have had the problem had I not ignored the malformed LSA while the public domain ZebOS would not have a problem. I won't speak for any other vendor's implementation on this list.  Hence, there is no omission from RFC 2328 since it describes a simplistic SPF intra-area computation in section 16.1. 


> 
>> 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.

A think a single OSPF(v3) vulnerabilities document would be much more useful than short RFCs documenting very specific attacks. One was started in RPSEC but never finished due to the demise of the author's company and the RPSEC WG itself. 

Thanks,
Acee 




> 
> 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
>> 
>> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf