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

[Anton Smirnov <[e-mail]>]

    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
>