Re: [OSPF] Dropping malformed LSAs

"A. Przygienda" <> Thu, 12 September 2013 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1715821E80BF for <>; Thu, 12 Sep 2013 15:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.27
X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_26=0.6, RDNS_DYNAMIC=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XzxpJxyMQhee for <>; Thu, 12 Sep 2013 15:51:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D1A8321E80EB for <>; Thu, 12 Sep 2013 15:51:06 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (8.14.4/8.14.4) with ESMTP id r8CMp46t006726 for <>; Fri, 13 Sep 2013 00:51:04 +0200
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 2MBIU-Dlsq3q for <>; Fri, 13 Sep 2013 00:51:03 +0200 (CEST)
Received: from ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id r8CMowKo006722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <>; Fri, 13 Sep 2013 00:51:00 +0200
Message-ID: <>
Date: Fri, 13 Sep 2013 00:50:56 +0200
From: "A. Przygienda" <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------090200070203080502030708"
Subject: Re: [OSPF] Dropping malformed LSAs
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 22:51:33 -0000

On 09/12/2013 11:46 PM, Glen Kent wrote:
> No, this is not the premise. Yes, somebody could do this if he has
> access to the keys. In this case the attack was done in the absence of
> any authentication being used.

this will be unfortunately the tenor of this discussion until a threat
model is being talked about first in terms of what is that
is being feared [protected value] and how the attack is mounted
[attacker sophistication and resources]. Only then what is
being done & whether a solution makes sense will be agreed upon.

And on a lighter note and to keep things in perspective: In my
experience over years, the worst threats to routing protocols were

01. coding bugs/naive implementation
02. coding bugs/naive implementation
31. coding bugs/naive implementation
32. misunderstanding of the spec
33. misunderstanding of the spec
66. misunderstanding of the spec
67. misconfiguration: (wonder what happens if I just inject this default
route into this statement I don't understand ??? ;-)
68. misconfiguration: well, I need another patch and this one looks like
it can be borrowed.
69. misconfiguration: well, let's test our spanning tree, more patches
in a rack are better, right ;-)
70. deteriorating links (how about 50-60 flaps/min ?)
71. memory chip failures
???. malicious, intended link-state packet attacks [there were cases
people breaking via telnets & stuff & (cough, cough ...) MIB
writes of cause)] but I fail to remember anyone injecting LSA, replaying
adjancencies or any such stuff since you simply
have to be on a link that carries OSPF adj normally (unless you fwd'
OSPF protocol in your network in a promiscuous fashion or naively
peer on any GRE tunnel in sight)  and those are hard to find on the
outside. Albeit an interesting paper by Boneh shows
a somewhat interesting remote adjacency attack. That shows however how
sophisticated the attacker must be and
he'll be debugging his code for long time until he has any success with
such a threat.

On the other hand, CC'suming the LSPs/LSA (well, more in ISIS unless you
don't age in OSPF)
when you have a router sitting in there for years was a [very good thing
to do] (TM) and I saw my share of flipped bits.
A memory chip never thought itself a threat possibly but it was a
realistic one.

so keep the blackhat-threats along the 1-71 (byzantine robustness)
before worrying about people stealing keys (80% of
security breaches are from the inside) and then about injection into
OSPF carrying links (unless it's on the edge but then
I would start to worry about 1-69. again when a no-name edge vendor
configured by an optimistic admin tries to talk
OSPF to you).

my semi-rusty 2c ;-)

--- tony