Re: [OSPF] Dropping malformed LSAs

"A. Przygienda" <prz@mail.zeta2.ch> Thu, 12 September 2013 11:46 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 5154811E8222 for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 04:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9ydDjgiHsVuB for <ospf@ietfa.amsl.com>; Thu, 12 Sep 2013 04:46:43 -0700 (PDT)
Received: from www.zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id D882A11E8218 for <ospf@ietf.org>; Thu, 12 Sep 2013 04:46:42 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by www.zeta2.ch (8.14.4/8.14.4) with ESMTP id r8CBkfsd032269 for <ospf@ietf.org>; Thu, 12 Sep 2013 13:46:41 +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 CIrhIeCNoZWd for <ospf@ietf.org>; Thu, 12 Sep 2013 13:46:39 +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 r8CBkY9L032263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ospf@ietf.org>; Thu, 12 Sep 2013 13:46:35 +0200
Message-ID: <5231A998.1070005@zeta2.ch>
Date: Thu, 12 Sep 2013 13:46:32 +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>
In-Reply-To: <5231A28C.5030102@cisco.com>
Content-Type: multipart/mixed; boundary="------------080604060505050709070702"
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 11:46:48 -0000

On 09/12/2013 01:16 PM, 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

Anton,

'securing an adjacency' is ok a step but it will not give you what
people seem to look for here.
Once you have that you start to talk about the threat models where
an adjacency can be compromised or an LSA be injected by some nefarious
means.
So first thing first: What's the threat model here ? blackhats getting
to phy links ? blackhats being able to fake
adjacencies ? blackhats being in possesions of PKAs to fake their way
into forming secure adjacencies with
other people ? blackhats compromising router configurations ? blackhats
spoofing end-system
addresses to make routers advertise their /32 reachability ?

All vastly different things  & attacks.

So, without a threat model first of all those security discussion tend
to change the target while the
hunt is ongoing.  As it already does, it started from simple attack
I-claim-to-be-someone-else attack easily mounted & defeated and  talks
here now about harder things (reachability
attacks, those actually need end-system adjacencies secured as well,
hard stuff & not in Internet
routing architecture much @ all normally).

The thing that holds for the kind of threats this discussion started on
quite well
is a chain-of-trust security where you basically have to assure not only
that an LSP/LSU has been
originated by the person claiming to be the originator but as well that
all the flooding has happened along trust-of-chain
(to prevent .e.g. replay attacks by someone injecting into a link
[without an adjacency, not unlikely on ether e.g.]).

Techniques for that are known and not that expensive computationally but
it is a non-negligible amounts of work involved in
such an undertaking. That better be on workgroup charter, requirements
docs then ;-)

If links to paper, previous art on that are desired, pls ping me, I'll
provide

--- tony