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

Gabi Nakibly <> Sun, 11 August 2013 19:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D310211E80DF for <>; Sun, 11 Aug 2013 12:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nvu4e1FpvlDS for <>; Sun, 11 Aug 2013 12:29:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A80111E80E0 for <>; Sun, 11 Aug 2013 12:22:42 -0700 (PDT)
Received: from [] by with NNFMP; 11 Aug 2013 19:22:41 -0000
Received: from [] by with NNFMP; 11 Aug 2013 19:22:41 -0000
Received: from [] by with NNFMP; 11 Aug 2013 19:22:41 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 55227 invoked by uid 60001); 11 Aug 2013 19:22:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1376248961; bh=8x7wuk+vSj74YQTyIeU4byCPPmU/zHxibCY4itLgiGM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mmCrGdq13bTryvb4doWqZd7BPu1M4fhVHlxmSE/3RUHoZjvyz7I8MmEOkGOB7jVjWvNyP6PvbcE5tvka5EqNMFl1uZnyoF/s5FTTyYfU3kuahbc40zcTevo2rf0gxJJ+ih23InPq8cz8hvnK/T9FFKrqcu710oZGMqq2efhbgdQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cOkwEBc6gfQ0qIMXlsxhS34L2dJlrqUPq2jJ37BKdN8AG4ue0xjISeISxyPIc3eZDRmmLbAmTXlm5a4u9B9mjuH8C3xPONhzBea/8JRTb/JQYgpa7xJdr+TZwVldUuJoVsVImpLLZCto6UBhELuh+m3QVBtf72A9S7CQkBtof7o=;
X-YMail-OSG: 7Omvv2gVM1n.LF4VwaqA2mrldbzem8o3GPkH9EbvbgRWUFe DJTl5fy2IElkIPgZT47XnRel3xWSpkhe1p6dktOJThJqipJ.C5ngPLduhu_T q8u0EAPRchkJ8xvFPJfjPtCSH9U9O0pUsV53Tql.ujrFg6p6zXP1QnumT7FB W2oUcbABr3JcWcB0uhuDMF72wRaXRmswMlFvIWO3Kv5I8.qEWoey5ogh0ai2 xh0kMi80wnjt3zz_ZOBPgAWBkyOcH8OcX2EdxCxQg1gdn055eg_GXg0PKzMi xPkQNvFeL_lVedLMpJcZ1ypH8lP1rYpbYsdOFCv9Z_jDWcIAm.ve8vYxiQO8 ntBzgbFr73Dohl0n.s7Hp847NjXc9q3rVaTC6nB9q5R_IHgnarosmRT9C5zM YWzrku7lBdnmTq5om1.s0AAZvAgeVK1O8LH4oy4D4h9UEOkQ1j9ZCF0anFvL q9pc1d.MFjEo.0SmSrgbNExWp4pJYRp4h3nGpa5_Jwd4juEEy1I7jXuGenWr whIgq_JU9crBzkrZpv0uuF5vnTWbBNOKgoA0isnSGQcqzkn5U09aABsu263t hMVdVPXQsjh_mexBxZeFlu8x2DluPpCUD9yoQpipRnUz3OqG0GPi0lU2Ul8_ bHoL3HvdGLaCf6cjnXWITSpGynpVtZtfCCSGEq1w301I_aSqw2_hqh7fh2tZ q5.A54SjYaayv8H6DLJlANSsYHA0_MRbZNq2K3DMPXhfVsnGsVK2TME6YVTj RvaXhs2wkTzgUUKlhZ2e7kVYul4Ttk3vpxdh75NTJw.d0O7.0
Received: from [] by via HTTP; Sun, 11 Aug 2013 12:22:41 PDT
X-Rocket-MIMEInfo: 002.001, SGkgWWksCkluZGVlZCwgbWl0aWdhdGluZyB0aGUgYXR0YWNrIGNhbm5vdCBiZSBlYXNpZXIsIGlmIHlvdSBsb29rIGZvciB0aGUgcmlnaHQgbWFsZm9ybWVkIHBhY2tldC4gWW91IG9ubHkgbmVlZCB0byBjaGVjayB0aGF0IHRoZSBMaW5rIFN0YXRlIElEIGVxdWFscyB0aGUgQWR2ZXJ0aXNpbmcgUm91dGVyLiBUaGlzIG1lYXN1cmUgaXMgbm93IGVtcGxveWVkIGJ5IENpc2NvLCBKdW5pcGVyIGFuZCBhIGZldyBvdGhlciB2ZW5kb3JzLiBOb25ldGhlbGVzcywgSSBhbSBzdXJlIHRoYXQgdGhlcmUgYXJlIG1vcmUBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Sun, 11 Aug 2013 12:22:41 -0700 (PDT)
From: Gabi Nakibly <>
To: "Yi Yang \(yiya\)" <>, Acee Lindem <>, David Lamparter <>, Glen Kent <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Gabi Nakibly <>
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Aug 2013 19:30:02 -0000

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.


----- Original Message -----
> From: Yi Yang (yiya) <>
> To: Gabi Nakibly <>om>; Acee Lindem <>om>; David Lamparter <>et>; Glen Kent <>
> Cc: "" <>
> 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 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" <> 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
>> in Section
>> 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
>> ntOSPF.pdf in Section 4.2.
>> I would appreciate your continued feedback on the new attack.
>> Thanks,
>> Gabi
>>> ________________________________
>>>  From: Acee Lindem <>
>>> To: David Lamparter <>et>; Glen Kent
>>> <>
>>> Cc: "" <>
>>> 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" 
> <> wrote:
>>>> On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote:
>>>>>  Does anybody have details on what this OSPF vulnerability is?
>>>> 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
>>> _______________________________________________
>>> OSPF mailing list
>> _______________________________________________
>> OSPF mailing list