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

[Manav Bhatia <[e-mail]>]

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?

Cheers, Manav

On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV <
[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, May 12, 2016 9:16 AM
> *To:* Ramakrishna DTV
> *Cc:* Acee Lindem (acee); Manjul Khandelwal; [e-mail]
> *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 ...
> <https://routingfreak.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
> 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 <
> [e-mail]> 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) <[e-mail]>
>> Sent: Wednesday, May 11, 2016 8:49 PM
>> To: Manjul Khandelwal; [e-mail]
>> 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"
>> <[e-mail] on behalf of [e-mail]> 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: [e-mail] <[e-mail]>
>> >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
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ospf
>>
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
>>
>
>