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

[Gabi Nakibly <[e-mail]>]

Hi Yi,
Indeed, mitigating the attack cannot be easier, if you look for the right malformed packet. You only need to check that the Link State ID equals the Advertising Router. This measure is now employed by Cisco, Juniper and a few other vendors. 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.

As RFC 4593 points out, byzantine attacks are possible form of attack against routing protocols and measures should be employed  to "minimize the impact of attacks of this sort". IMHO, since byzantine attacks do occur in practice and the mitigation for this specific attack is easy to deploy, the WG might want to do an effort to advice on the mitigation measures for this attack.

I am willing to write a draft describing this mitigation measure. I would appreciate the list's thoughts on this.

Gabi

----- Original Message -----
> From: Yi Yang (yiya) <[e-mail]>
> To: Gabi Nakibly <[e-mail]>; Acee Lindem <[e-mail]>; David Lamparter <[e-mail]>; Glen Kent <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: Friday, August 9, 2013 4:37 AM
> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
> 
> I would think such an attack can be categorized as "overclaiming", as
> defined at http://tools.ietf.org/html/rfc4593#section-4.5.1.1. In this
> case, an attacker claims a resource (link state ID) which does not belong
> to it. 
> 
> While it might be challenging to defense overclaiming in some cases, it's
> not that hard to recognize the attack in this case. As pointed out by
> David and Acee, such LSAs should be considered as malformatted as they
> have unmatched Advertising Router and Link State ID and can be dropped. A
> more challenging example of overclaiming is the attacker simply advertises
> a bunch of prefixes that are not really attached on itself.
> 
> Yi 
>   
> 
> On 8/5/13 5:03 PM, "Gabi Nakibly" <[e-mail]> wrote:
> 
>> Hi all,
>> My name is Gabi. I am the researcher who presented the new attack at
>> Black Hat last week. I have noticed the discussion on the list and I
>> would be happy to try to clarify how the attack is different from known
>> ones. 
>> Indeed the attack assumes that the attacker is an insider, meaning that
>> the attacker has already gained control of one of the router within the
>> AS. I agree 100% that once an attacker is an insider he can already do
>> all sorts of attacks that can harm the network and indeed a few past
>> works have already reported on this. Nonetheless,  the crux of the new
>> attack, as Acee has already pointed out, is that an attacker is now able
>> to falsify an LSA on behalf of another router while evading the
>> fight-back mechanism. This new capability allows an attacker to
>> *persistently* and *stealthily* subvert the LSA DB of other routers that
>> install the false LSA and thereby altering their routing tables. This
>> gives rise to a new class of attacks that in my opinion have not existed
>> before and, in many times, are more desirable for an attacker (due to
>> their stealth and persistence).
>> To my best knowledge, no other general technique to stealthily evade
>> fight back is known. The only general attack technique to evade fight
>> back is periodic injection (flooding false LSAs at a rate higher thanone
>> every MinLSInterval)  presented in
>> http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt in Section
>> 4.1.3.1. However,  using such technique the attack is hardly stealthy.
>> 
>> BTW, I have also presented in the past another general technique to evade
>> fight back called 'Disguised LSA'. It is described in
>> https://www.cs.technion.ac.il/people/gnakibly/online-publications/Persiste
>> ntOSPF.pdf in Section 4.2.
>> 
>> I would appreciate your continued feedback on the new attack.
>> 
>> Thanks,
>> Gabi
>> 
>>> ________________________________
>>>  From: Acee Lindem <[e-mail]>
>>> To: David Lamparter <[e-mail]>; Glen Kent
>>> <[e-mail]>
>>> Cc: "[e-mail]" <[e-mail]>
>>> Sent: Monday, August 5, 2013 5:28 AM
>>> Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the
>>> Routing Table Attack)
>>> 
>>> 
>>> 
>>> 
>>> On 8/4/13 6:06 AM, "David Lamparter" 
> <[e-mail]> wrote:
>>> 
>>>> On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote:
>>>>>  Does anybody have details on what this OSPF vulnerability is?
>>>>> 
>>>>>  https://www.blackhat.com/us-13/briefings.html#Nakibly
>>>> 
>>>> As people may have noticed by now (the embargo on providing details 
> has
>>>> expired as the talk was presented), this issue consists of Router 
> LSAs
>>>> where the Router ID is different from the Link State ID.  As such, 
> this
>>>> attack is implementable from any router in an OSPF area against any
>>>> other router in the OSPF.
>>>> 
>>>> (Quite honestly, IMHO this is seriously far fetched.  If your 
> control
>>>> plane got compromised this far you have other problems.)
>>> 
>>> I agree that once the OSPF control plane is open, you are susceptible to
>>> many attacks. However, this attack is a bit more insidious than most
>>> since
>>> the actual OSPF router corresponding to the link state ID will most
>>> likely
>>> not recognize the LSA as self-originated and re-originate a more recent
>>> version when the malformed one is received. Hence, the malicious LSA 
> will
>>> remain in the routing domain and, depending upon the OSPF 
> implementation,
>>> could result in traffic being redirected.
>>> 
>>>> 
>>>> While Quagga is unaffected by this, we've implemented a 
> warning.  We're
>>>> also considering dropping the LSA outright, but I'm somewhat 
> split on
>>>> that (tilted towards dropping).  I'd be interested if the WG has
>>>> comments on that?
>>> 
>>> I can't speak for the WG but my implementation will skip the LSA in 
> the
>>> Link-State Update packet.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> 
>>>> 
>>>> 
>>>> -David
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ospf
>>> 
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>>> 
>>> 
>>> 
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>