Return-Path: 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 C4E4912D679 for ; Wed, 11 May 2016 21:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorg676131.onmicrosoft.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 euF9k24QzXkN for ; Wed, 11 May 2016 21:49:04 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0110.outbound.protection.outlook.com [104.47.124.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C92212D0DD for ; Wed, 11 May 2016 21:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORG676131.onmicrosoft.com; s=selector1-nivettisystems-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6sqqEb71bYqDF/0cEUde6D2f+/ZG9XNLDBQwqJst2xA=; b=Ythu352CU+yhD5wdolOnCPTYJZ4OK8/GbVCj4T/J5hh/G9w5D+VNmTJw7ww1aF2u/5Aq/eNgQCgJjiW3gdthVlkJJQGO1VoJKtrwL3IMvRX2tmWGDNZeZ81RYVjNQG7w9NcPZ8czJPcJ20g0B/9aHPY2E0kFSBxHzS2v18iU0oY= Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com (10.165.249.158) by KL1PR04MB1606.apcprd04.prod.outlook.com (10.167.61.28) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 04:49:00 +0000 Received: from KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) by KL1PR0401MB1544.apcprd04.prod.outlook.com ([10.165.249.158]) with mapi id 15.01.0492.016; Thu, 12 May 2016 04:48:59 +0000 From: Ramakrishna DTV To: Manav Bhatia Thread-Topic: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt Thread-Index: AQHRq5iDI45ZmPCOekqfeZl/Lp+NDp+0k8d6gAAWyICAABC5kQ== Date: Thu, 12 May 2016 04:48:59 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nivettisystems.com; x-originating-ip: [25.169.49.132] x-ms-office365-filtering-correlation-id: ac24acd0-1281-4e3e-8310-08d37a20bbe7 x-microsoft-exchange-diagnostics: 1; KL1PR04MB1606; 5:SQ+/HHb3vK6AMJSbs0/VeZl0ThncOyY3sqioRlex2NekZHI44XfCs4WxKNLIIFazGVlz9QAQM6Y6Fw3NDcSoiH0GuJMfplgmAN4nzqNOTcT4rkjhno3Nipx5hoCV2LCkdefqPrKnOC7ETXc08ucYww==; 24:SsVOBlT1jco/k0TaqmL8IjauX7Fj3N2wXBsaadNIJsvsDBcGY97qDNOiyT8DslM50stsqTb/bKxdjxh+fzTBR3QPbDJnQOjrEBqkSGqE+wM=; 7:egpO0QE8fQHnnBcyvnXmIOVfV6VT8D7gFK9e1/OWShqfDhq52Yt3JI4ChbpLO5xE7MMULx0cmt9KJouCMZ8gTV7RL7sTjkRVAWfzfDPOmatwretLkEr/pTuw5Lclm1xXhQ2W99qFFsjznWm+PzGSSMECsGHwAnVGWt38kmQe1YxA+d1MyMgH2eoOHJZqMAda x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KL1PR04MB1606; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046); SRVR:KL1PR04MB1606; BCL:0; PCL:0; RULEID:; SRVR:KL1PR04MB1606; x-forefront-prvs: 0940A19703 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51884002)(24454002)(377424004)(377454003)(3660700001)(122556002)(10400500002)(77096005)(14971765001)(92566002)(87936001)(19580395003)(19580405001)(3900700001)(5002640100001)(66066001)(33656002)(86362001)(19625215002)(5004730100002)(74316001)(16236675004)(76176999)(50986999)(54356999)(10710500007)(19617315012)(3280700002)(4326007)(5008740100001)(1220700001)(16601075003)(2420400007)(9686002)(6116002)(586003)(102836003)(5003600100002)(3846002)(110136002)(106116001)(2950100001)(2900100001)(189998001)(19627405001)(76576001)(7110500001)(345774005)(15650500001)(15975445007)(2906002)(8936002)(230783001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:KL1PR04MB1606; H:KL1PR0401MB1544.apcprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_" MIME-Version: 1.0 X-OriginatorOrg: nivettisystems.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 04:48:59.7394 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b780cc-c0fe-4e87-8da2-4702ecb31b90 X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR04MB1606 Archived-At: Cc: "ospf@ietf.org" , Manjul Khandelwal 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 04:49:08 -0000 --_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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=3D{Persistent OSPF Attacks.}, author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Boneh, D= an}, booktitle=3D{NDSS}, year=3D{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=3D{OSPF vulnerability to persistent poisoning attacks: a systematic= analysis}, author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Waizel,= Ariel and Elovici, Yuval}, booktitle=3D{Proceedings of the 30th Annual Computer Security Application= s Conference}, pages=3D{336--345}, year=3D{2014}, organization=3D{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 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-s= equence-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-vulnerabi= lity-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 appe= ared ... Clipped from the blog: "This attack exploits a potential omission (or a bug if you will) in the st= andard where it does not mandate that the receiving router verifies that th= e 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 bein= g 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 bec= ause the OSPF spec clearly says in Sec 13.4 that =93A self-originated LSA i= s detected when either 1) The LSA=92s Advertising Router is equal to the ro= uter=92s own Router ID or 2) the LSA is a network LSA .. =93. This means that OSPF=92s natural fight back mechanism is NOT triggered by t= he victim router as long as the field =91Advertising Router=92 of a LSA is = NOT equal to the victim=92s Router ID. This is true even if the =91Link Sta= te ID=92 of that LSA is equal to the victim=92s Router ID. Going further it= means no LSA refresh is triggered even if the malacious LSA claims to desc= ribe the links of the victim router!" I describe further in the blog that not all router implementations are susc= eptible to the attack. Its dependent on how the LSA is picked up from the L= SDB. Cheers, Manav On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV > 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 "Implemen= tation advice". We can probably move it to a different section (e.g., "Introduction") to ma= ke it clear. If you think even more additional details about the attack are useful to th= e working group, please let us know. We will add. Thank you. Regards, Ramakrishna DTV. ________________________________________ From: Acee Lindem (acee) > 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-s= equence-number-00.txt Hi Manjul, Would it be possible to succinctly describe these =93certain security attacks=94 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" on behalf of manjul@ni= vettisystems.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 > >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 --_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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=3D{Persistent OSPF Attacks.},
  author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and Bon= eh, Dan},
  booktitle=3D{NDSS},
  year=3D{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=3D{OSPF vulnerability to persistent poisoning attacks: a syste= matic analysis},
  author=3D{Nakibly, Gabi and Sosnovich, Adi and Menahem, Eitan and Wa= izel, Ariel and Elovici, Yuval},
  booktitle=3D{Proceedings of the 30th Annual Computer Security Applic= ations Conference},
  pages=3D{336--345},
  year=3D{2014},
  organization=3D{ACM}
}

As you rightly mentioned, this attack does not depend upon sequence number<= br> predictability. But our draft is *not* targeting *this* attack.

Thanks and regards,
Ramakrishna DTV.



From: Manav Bhatia <man= avbhatia@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 "nat= ural fight-back mechanism" in OSPF. 

Its got *nothing* to do with the sequence numbers being predictable, e= tc. I have explained in depth how the Gaby attack works here:

https://rout= ingfreak.wordpress.com/2013/09/09/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 appe= ared ...


Clipped from the blog:

"This attack exploits a potential omission (or a bug if you will) in t= he standard where it does not mandate that the receiving router verifies th= at the Link State ID and the Advertising Router fields in the Router LSA ar= e 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 bein= g 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 i= s because the OSPF spec clearly says in Sec 13.4 that =93A self-originated = LSA is detected when either 1) The LSA=92s Advertising Router is equal to the router=92s own Router ID or 2) the LSA = is a network LSA .. =93.

This means that OSPF=92s natural fight back mechanism is NOT triggered by t= he victim router as long as the field =91Advertising Router=92 of a LSA is = NOT equal to the victim=92s Router ID. This is true even if the =91Link Sta= te ID=92 of that LSA is equal to the victim=92s 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 compro= mised router
   inside a routing domain.  In this attack, the compromised= router
   alters the LSA of an uncompromised router (victim).  Norm= ally, such
   an attempt does not have persistence because the victim genera= tes 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, ch= ecksum}
   are predictable.  It alters the existing LSA of victim to= suit its
   needs but sets the sequence number to +1 of the existing L= SA and
   alters the LSA so that checksum matches with checksum that wou= ld be
   generated by the victim when it generates the new LSA.  W= hen this
   disguised LSA reaches the victim, it does not fight back becau= se 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 e= ntire
   content of an LSA.  We think this attack is powerful.&quo= t;

These details are currently present in Section 4, which is titled "Imp= lementation advice".
We can probably move it to a different section (e.g., "Introduction&qu= ot;) to make it clear.

If you think even more additional details about the attack are useful to th= e working group,
please let us know. We will add.

Thank you.

Regards,
Ramakrishna DTV.


________________________________________
From: Acee Lindem (acee) <acee@cisco.c= om>
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-s= equence-number-00.txt

Hi Manjul,

Would it be possible to succinctly describe these =93certain security
attacks=94 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 b= ehalf 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 specifi= ed in RFC
>   2328 and RFC 5340 is completely predictable.  This ma= kes it prone to
>   certain security attacks which exploit the predictable nat= ure 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.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>
>We solicit feedback/comments on the draft and request for adoption by t= he
>OSPF working group.
>
>Regards,
>Manjul Khandelwal
>DTV Ramakrishna Rao
>________________________________________
>From: internet-drafts@ietf.= org <internet-drafts@iet= f.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<= br> >IETF repository.
>
>Name:           draft-manjuldtv-ospf-sequ= ence-number
>Revision:       00
>Title:          OSPF LSA sequence number gener= ation
>Document date:  2016-05-09
>Group:          Individual Submission
>Pages:          10
>URL:
>https://www.ietf.org/i= nternet-drafts/draft-manjuldtv-ospf-sequence-number-
>00.txt
>Status:
>https://datatracker.ietf.o= rg/doc/draft-manjuldtv-ospf-sequence-number/
>Htmlized:
>https://tools.ietf.org/html/d= raft-manjuldtv-ospf-sequence-number-00
>
>
>Abstract:
>   The mechanism for LS sequence number generation as specifi= ed in RFC
>   2328 and RFC 5340 is completely predictable.  This ma= kes it prone to
>   certain security attacks which exploit the predictable nat= ure 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

--_000_KL1PR0401MB1544349FCF40E95494CC1D4EA3730KL1PR0401MB1544_--