Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt

Acee Lindem <acee.lindem@gmail.com> Thu, 12 May 2016 11:03 UTC

Return-Path: <acee.lindem@gmail.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 CB28512D8E7 for <ospf@ietfa.amsl.com>; Thu, 12 May 2016 04:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXmMYFLrAPZw for <ospf@ietfa.amsl.com>; Thu, 12 May 2016 04:03:22 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F294A12D8D4 for <ospf@ietf.org>; Thu, 12 May 2016 04:03:21 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id o66so77942824ywc.3 for <ospf@ietf.org>; Thu, 12 May 2016 04:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tDEL2DjwfEhjA7HqISEgQ5flg1S+JOMFM1CC/RBUYZ4=; b=rcsmgfmDWvx7laZ1iJWAkuNqhWlQdEV7JDeSq9sZOXjcwInzeIT1Lt1/7tKnslVnXC fPC+NZLoettqlR60pJND7Ue+uyE2hRfXHAv8bu6oZhRLV8IOtxl8h5flegpzw5EvsPWW nabd2qtFrISAEcCpuJ7y4hlK7ehLvClOJnECTgRh54NSzkCQWdaCNNjJRnMWl7zTpqn6 BNyLw8N8N2kSDebmKwp3MU6VCF4EV4RgUZ4LAdYexlR2yVL6Y38Uttn2hB86AP8Qs7tU NzNJHfsx6UzQ8sTVhS8sXBg4RPP29D958RAdqbewss6fVTF3m3xwBL8uWEve+yuDcUwm VL0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tDEL2DjwfEhjA7HqISEgQ5flg1S+JOMFM1CC/RBUYZ4=; b=lJwZRU1IA2o51YInxn1zTXxFW2oq0QXMX1U8HZhpcprs3ECetBH7XNZi2WE1WXtX6D 7johH9FIjIM9NB7ENlth7S038+LhldQc5fWIRtBaNH+r1scQuSiazdDwv0gSOhQC7VX7 cv9wUi3kS84tVaQMfERPKrT4TAdnUFSCPlXr9m7tLV1tUOLbo2Gt20yH2qg5lnAOU1HN 4JxNGB8xBPv/egmvJAZm3RNQ4U82fUf0tzZBZ5JjxLC7pRNyv1oNufxe7SiOXc/btO5b sTwpfLsT3/mGHdO8jieYOpZjnmlJIdu2MWFyW5vubdFylIgBWVPlF87rdQ2hODSKW1Ki EBcA==
X-Gm-Message-State: AOPr4FV3qFBkwdNkuG9MCRWx961bPwt8IQqvCKZqyZt3frk2M953+HDW10yWqzeILByCfg==
X-Received: by 10.13.237.130 with SMTP id w124mr4125367ywe.248.1463051000896; Thu, 12 May 2016 04:03:20 -0700 (PDT)
Received: from [10.0.1.18] (cpe-65-190-56-15.nc.res.rr.com. [65.190.56.15]) by smtp.gmail.com with ESMTPSA id o75sm6923276ywd.7.2016.05.12.04.03.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 04:03:20 -0700 (PDT)
From: Acee Lindem <acee.lindem@gmail.com>
X-Google-Original-From: Acee Lindem <acee@lindem.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CAG1kdogZhHgGxbL5caBkAVypncnA3yTtb5+ZebV1m2Yzj0r+jA@mail.gmail.com>
Date: Thu, 12 May 2016 07:03:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com>
References: <D358C4E4.607A9%acee@cisco.com> <KL1PR0401MB1544944FE1E375A8FB7A31C0A3730@KL1PR0401MB1544.apcprd04.prod.outlook.com> <CAG1kdoiyj_s_gzHibrmomPJAZo28bCLDxqPRnbeS6-ooJzb_MQ@mail.gmail.com> <KL1PR0401MB1544349FCF40E95494CC1D4EA3730@KL1PR0401MB1544.apcprd04.prod.outlook.com> <CAG1kdogZhHgGxbL5caBkAVypncnA3yTtb5+ZebV1m2Yzj0r+jA@mail.gmail.com>
To: Manav Bhatia <manavbhatia@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/g6P6L-LeXIMHzVCC2YPPfMM6lu8>
Cc: OSPF List <ospf@ietf.org>, Ramakrishna DTV <ramakrishnadtv@nivettisystems.com>, Manjul Khandelwal <manjul@nivettisystems.com>
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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 May 2016 11:03:25 -0000

Hi Manav, 
> On May 12, 2016, at 1:11 AM, Manav Bhatia <manavbhatia@gmail.com> wrote:
> 
> Hi DTV,
> 
> Aha. Thanks for the catch ! 
> 
> In that case, i dont understand why the "victim" will NOT generate a new LSA with LS sequence number one past the received LS sequence number. I see that the new attack tries to do something by updating the sequence number and the checksum -- did not spend too much time on trying to understand what exactly its doing there. However, OSPF also has provisions to get around that, and i wrote about this many years ago here:
> 
> https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determining-the-newer-lsa/
> 
> So i have the same question as Acee -- why will the natural fight-back mechanism not work here?

It will and that was my point. I can think of only one possible attack where the same sequence number is used but the attacker can only change the contents of the LSA for OSPF routers for which it is in the flooding path from the originator. 

Thanks,
Acee

> 
> Cheers, Manav
> 
> On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV <ramakrishnadtv@nivettisystems.com> wrote:
> 
> Hi Manav,
> 
> Thank you for your comments.
> 
> Gabi has published multiple attacks against OSPF.
> 
> The attack we are targeting is published in
> 
> @inproceedings{nakibly2012persistent,
>   title={Persistent OSPF Attacks.},
>   author={Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh, Dan},
>   booktitle={NDSS},
>   year={2012}
> }
> 
> This attack indeed depends on predictability of sequence numbers.
> On a side note, we even verified that fact with Gabi Nakibly himself
> over a private mail.
> 
> The attack you are discussing in your article is a different attack.
> It was described by Gabi in great detail in a different paper:
> 
> @inproceedings{nakibly2014ospf,
>   title={OSPF vulnerability to persistent poisoning attacks: a systematic analysis},
>   author={Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waizel, Ariel and Elovici, Yuval},
>   booktitle={Proceedings of the 30th Annual Computer Security Applications Conference},
>   pages={336--345},
>   year={2014},
>   organization={ACM}
> }
> 
> As you rightly mentioned, this attack does not depend upon sequence number
> predictability. But our draft is *not* targeting *this* attack.
> 
> Thanks and regards,
> Ramakrishna DTV.
> 
> 
> 
> From: Manav Bhatia <manavbhatia@gmail.com>
> Sent: Thursday, May 12, 2016 9:16 AM
> To: Ramakrishna DTV
> Cc: Acee Lindem (acee); Manjul Khandelwal; ospf@ietf.org
> Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt
>  
> Hi DTV,
> 
> I dont agree to your assessment of how the attack evades the "natural fight-back mechanism" in OSPF. 
> 
> Its got *nothing* to do with the sequence numbers being predictable, etc. I have explained in depth how the Gaby attack works here:
> 
> https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerability-exposed-by-black-hat/
> How bad is the OSPF vulnerability exposed by Black Hat ...
> routingfreak.wordpress.com
> I was asked a few weeks ago by our field engineers to provide a fix for the OSPF vulnerability exposed by Black Hat last month. Prima facie there appeared ...
> 
> 
> Clipped from the blog:
> 
> "This attack exploits a potential omission (or a bug if you will) in the standard where it does not mandate that the receiving router verifies that the Link State ID and the Advertising Router fields in the Router LSA are the exact same value.
> 
> This attack sends malacious Router LSAs with two different values in the LS header. The Link State ID carries the Router ID of the router that is being attacked (the victim) and the Advertising Router is set to some different (any) value.
> 
> When the victim receives the malacious Router LSA, it does not refresh this LSA as it doesnt recognize this as its own self generated LSA. This is because the OSPF spec clearly says in Sec 13.4 that “A self-originated LSA is detected when either 1) The LSA’s Advertising Router is equal to the router’s own Router ID or 2) the LSA is a network LSA .. “.
> 
> This means that OSPF’s natural fight back mechanism is NOT triggered by the victim router as long as the field ‘Advertising Router’ of a LSA is NOT equal to the victim’s Router ID. This is true even if the ‘Link State ID’ of that LSA is equal to the victim’s Router ID. Going further it means no LSA refresh is triggered even if the malacious LSA claims to describe the links of the victim router!" 
> 
> I describe further in the blog that not all router implementations are susceptible to the attack. Its dependent on how the LSA is picked up from the LSDB. 
> 
> Cheers, Manav
> 
> On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV <ramakrishnadtv@nivettisystems.com> wrote:
> Hi Acee,
> 
> We currently provided the following description of this attack in the draft:
> 
>  "The paper refers to the attack as "Disguised LSA" and is of
>    persistent nature.  This attack is launched from a compromised router
>    inside a routing domain.  In this attack, the compromised router
>    alters the LSA of an uncompromised router (victim).  Normally, such
>    an attempt does not have persistence because the victim generates a
>    new LSA when it sees such self-originated LSAs (referred to as
>    "fight-back" mechanism in the paper).  But the paper makes disguised
>    LSA persistent because all the fields { LS sequence number, checksum}
>    are predictable.  It alters the existing LSA of victim to suit its
>    needs but sets the sequence number to +1 of the existing LSA and
>    alters the LSA so that checksum matches with checksum that would be
>    generated by the victim when it generates the new LSA.  When this
>    disguised LSA reaches the victim, it does not fight back because it
>    compares only the fields { LS sequence number, checksum, age} to
>    check for duplicates and not the actual content of LSA.
> 
>    This attack enables an insider attacker to fully control the entire
>    content of an LSA.  We think this attack is powerful."
> 
> These details are currently present in Section 4, which is titled "Implementation advice".
> We can probably move it to a different section (e.g., "Introduction") to make it clear.
> 
> If you think even more additional details about the attack are useful to the working group,
> please let us know. We will add.
> 
> Thank you.
> 
> Regards,
> Ramakrishna DTV.
> 
> 
> ________________________________________
> From: Acee Lindem (acee) <acee@cisco.com>
> Sent: Wednesday, May 11, 2016 8:49 PM
> To: Manjul Khandelwal; ospf@ietf.org
> Cc: Ramakrishna DTV
> Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt
> 
> Hi Manjul,
> 
> Would it be possible to succinctly describe these “certain security
> attacks” in the draft rather than expecting everyone to read the
> referenced paper?
> 
> Thanks,
> Acee
> 
> On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
> <ospf-bounces@ietf.org on behalf of manjul@nivettisystems.com> wrote:
> 
> >Hi,
> >
> >We have recently submitted a draft which deals with OSPF LS sequence
> >number
> >generation mechanism.
> >
> >Abstract of the draft:
> >   The mechanism for LS sequence number generation as specified in RFC
> >   2328 and RFC 5340 is completely predictable.  This makes it prone to
> >   certain security attacks which exploit the predictable nature of LS
> >   sequence numbers.  This draft updates the RFC 2328 to make LS
> >   sequence number generation an implementation choice rather than a
> >   fixed increment by 1 for successive LSAs.
> >
> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/
> >
> >We solicit feedback/comments on the draft and request for adoption by the
> >OSPF working group.
> >
> >Regards,
> >Manjul Khandelwal
> >DTV Ramakrishna Rao
> >________________________________________
> >From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> >Sent: Monday, May 9, 2016 7:22 PM
> >To: Manjul Khandelwal; Ramakrishna DTV
> >Subject: New Version Notification for
> >draft-manjuldtv-ospf-sequence-number-00.txt
> >
> >A new version of I-D, draft-manjuldtv-ospf-sequence-number-00.txt
> >has been successfully submitted by Manjul Khandelwal and posted to the
> >IETF repository.
> >
> >Name:           draft-manjuldtv-ospf-sequence-number
> >Revision:       00
> >Title:          OSPF LSA sequence number generation
> >Document date:  2016-05-09
> >Group:          Individual Submission
> >Pages:          10
> >URL:
> >https://www.ietf.org/internet-drafts/draft-manjuldtv-ospf-sequence-number-
> >00.txt
> >Status:
> >https://datatracker.ietf.org/doc/draft-manjuldtv-ospf-sequence-number/
> >Htmlized:
> >https://tools.ietf.org/html/draft-manjuldtv-ospf-sequence-number-00
> >
> >
> >Abstract:
> >   The mechanism for LS sequence number generation as specified in RFC
> >   2328 and RFC 5340 is completely predictable.  This makes it prone to
> >   certain security attacks which exploit the predictable nature of LS
> >   sequence numbers.  This draft updates the RFC 2328 to make LS
> >   sequence number generation an implementation choice rather than a
> >   fixed increment by 1 for successive LSAs.
> >
> >
> >
> >
> >Please note that it may take a couple of minutes from the time of
> >submission
> >until the htmlized version and diff are available at tools.ietf.org.
> >
> >The IETF Secretariat
> >
> >_______________________________________________
> >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