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

"Yi Yang (yiya)" <yiya@cisco.com> Fri, 09 August 2013 01:37 UTC

Return-Path: <yiya@cisco.com>
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 E1D1D11E817D for <ospf@ietfa.amsl.com>; Thu, 8 Aug 2013 18:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 c-o1MVUy7bXC for <ospf@ietfa.amsl.com>; Thu, 8 Aug 2013 18:37:17 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC0111E80F8 for <ospf@ietf.org>; Thu, 8 Aug 2013 18:37:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5064; q=dns/txt; s=iport; t=1376012237; x=1377221837; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UFwFR0GoixfPl9f+ivZkmif6i+jU397tnQww5Yt9m+4=; b=TQPjcxmw4uiPBWXj/J7MvwCuQriyiGox45las9d78ELaOrjeJxHKW8fB GiCDoEA1GvyAZ2LiH5jnM+kBwEPi/iB4QaqD736NuUtSr+e2/2W5x/4X7 UF4FI2o4U4XNOaFnvTyLiqHaoNUloxL99C9JWDhxSXwI8NF9lBNFZtrZ7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFAFFHBFKtJXHB/2dsb2JhbABbgwY1UKwmkiiBGRZ0giQBAQEEAQEBNzICCxIBCA4DBAEBAQoUMQYLEwoIAgQBDQUIh3YDDwyvdA2IXo0rgj8xB4MadAOVeASCG3SKfoUngV+BOYIq
X-IronPort-AV: E=Sophos;i="4.89,843,1367971200"; d="scan'208";a="245281192"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 Aug 2013 01:37:16 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r791bGe7008210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 01:37:16 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.144]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 8 Aug 2013 20:37:15 -0500
From: "Yi Yang (yiya)" <yiya@cisco.com>
To: Gabi Nakibly <gnakibly@yahoo.com>, Acee Lindem <acee.lindem@ericsson.com>, David Lamparter <equinox@diac24.net>, Glen Kent <glen.kent@gmail.com>
Thread-Topic: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
Thread-Index: AQHOlKD6hb+nS+9dYkaGPDIp2FKfDw==
Date: Fri, 9 Aug 2013 01:37:15 +0000
Message-ID: <DC74E46E9699A84EB0E1183B90FD160928F2C192@xmb-aln-x11.cisco.com>
In-Reply-To: <1375736635.93585.YahooMailNeo@web165005.mail.bf1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.116.75.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <909950D36C72734AA44F5C9DFB29B670@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)
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: Fri, 09 Aug 2013 01:37:22 -0000

I would think such an attack can be categorized as "overclaiming", as
defined at http://tools.ietf.org/html/rfc4593#section-4.5.1.1. 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" <gnakibly@yahoo.com> 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
>http://tools.ietf.org/id/draft-ietf-rpsec-ospf-vuln-02.txt in Section
>4.1.3.1. 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
>https://www.cs.technion.ac.il/people/gnakibly/online-publications/Persiste
>ntOSPF.pdf in Section 4.2.
>
>I would appreciate your continued feedback on the new attack.
>
>Thanks,
>Gabi
>
>>________________________________
>> From: Acee Lindem <acee.lindem@ericsson.com>
>>To: David Lamparter <equinox@diac24.net>et>; Glen Kent
>><glen.kent@gmail.com>
>>Cc: "ospf@ietf.org" <ospf@ietf.org>
>>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" <equinox@diac24.net> wrote:
>>
>>>On Fri, Aug 02, 2013 at 10:11:01PM +0530, Glen Kent wrote:
>>>> Does anybody have details on what this OSPF vulnerability is?
>>>> 
>>>> https://www.blackhat.com/us-13/briefings.html#Nakibly
>>>
>>>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@ietf.org
>>>https://www.ietf.org/mailman/listinfo/ospf
>>
>>_______________________________________________
>>OSPF mailing list
>>OSPF@ietf.org
>>https://www.ietf.org/mailman/listinfo/ospf
>>
>>
>>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www.ietf.org/mailman/listinfo/ospf