Re: [OSPF] Dropping malformed LSAs

"A. Przygienda" <prz@mail.zeta2.ch> Thu, 12 September 2013 22:51 UTC

Return-Path: <prz@mail.zeta2.ch>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1715821E80BF for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 15:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.27
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzxpJxyMQhee for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 15:51:16 -0700 (PDT)
Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id D1A8321E80EB for <ospf@ietf.org>; Thu, 12 Sep 2013 15:51:06 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CMp46t006726 for <ospf@ietf.org>; Fri, 13 Sep 2013 00:51:04 +0200
X-Virus-Scanned: amavisd-new at zeta2.ch
Received: from www.zeta2.ch ([127.0.0.1]) by localhost (www.zeta2.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2MBIU-Dlsq3q for <ospf@ietf.org>; Fri, 13 Sep 2013 00:51:03 +0200 (CEST)
Received: from prz-workstation.zeta2.ch (prz-workstation.zeta2.ch [192.168.1.51]) (authenticated bits=0) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CMowKo006722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ospf@ietf.org>; Fri, 13 Sep 2013 00:51:00 +0200
Message-ID: <52324550.5000105@zeta2.ch>
Date: Fri, 13 Sep 2013 00:50:56 +0200
From: "A. Przygienda" <prz@mail.zeta2.ch>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: ospf@ietf.org
References: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com> <DC74E46E9699A84EB0E1183B90FD160928F2C192@xmb-aln-x11.cisco.com> <1376248961.41754.YahooMailNeo@web165004.mail.bf1.yahoo.com> <20211F91F544D247976D84C5D778A4C32E4B3B43@SG70YWXCHMBA05.zap.alcatel-lucent.com> <5231A28C.5030102@cisco.com> <20211F91F544D247976D84C5D778A4C32E4B4924@SG70YWXCHMBA05.zap.alcatel-lucent.com> <9F1F84B6-9A14-4C6E-84C3-2D2A26754C7E@lindem.com> <1B502206DFA0C544B7A6046915200863174B866E@eusaamb105.ericsson.se> <CAPLq3UOXkSOcRq3=CgRvLxUQQjB3XD+K6_RWLLh5e++4S8nEvg@mail.gmail.com>
In-Reply-To: <CAPLq3UOXkSOcRq3=CgRvLxUQQjB3XD+K6_RWLLh5e++4S8nEvg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------090200070203080502030708"
Subject: Re: [OSPF] Dropping malformed LSAs
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=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