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

Mitchell Erblich <> Thu, 12 September 2013 23:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2CC21E81F8 for <>; Thu, 12 Sep 2013 16:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k0E6he1c6VdK for <>; Thu, 12 Sep 2013 16:33:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B59E821E81EA for <>; Thu, 12 Sep 2013 16:33:49 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=UfMGdGtklWJagKp7LznazupF0IkIkL9Y5tLfAstZNjNNL6eob72tbad/dZEjy5fO; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from <>) id 1VKGOP-0006mw-B4; Thu, 12 Sep 2013 19:33:45 -0400
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=windows-1252
From: Mitchell Erblich <>
In-Reply-To: <>
Date: Thu, 12 Sep 2013 16:33:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Anton Smirnov <>
X-Mailer: Apple Mail (2.1283)
X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7953123ca55f525450d11efdaa4a613e82350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Cc: "" <>
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Sep 2013 23:33:54 -0000


	I agree partially with the below qualifications:

		A valid set of LSAs that constitute a flooding attack, where the flooding attack is based on a reverse route summarization, should be able to be identified and mitigated,

		An excess of valid and invalid LSAs could be run against an acceptable quantity of LSAs, and any quantity above X from a single non-trusted source, could cause the equiv of a tail or a RED drop of some percentage of LSAs per period of time, 
		Some form of authentication challenge against LSAs (like a ICMP echo request) or first recv'ing packets from the path, could be used to validate the LSA before using the actual LSA (if the LSA is suspect) could be done…

		Thus, as in most de facto implementations, a layering of secure/authentication methods tend to be more effective then just at a single layer.

		So, why wouldn't a best practices type document given a set of well known attacks with SHOULDs be minimally productive?

		Mitchell Erblich

On Sep 12, 2013, at 4:16 AM, Anton Smirnov wrote:

>   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