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

[Jeff Tantsura <[e-mail]>]

I fully agree with Acee's assessment,  to my feeling the solution proposed would cause more harm than good

Regards,
Jeff

> On May 17, 2016, at 10:28 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> <Speaking as an OSPF WG member>
> 
> Hi Ramakrishna, 
> 
> So the attack is predicated on the following:
> 
>    1. The attacker is able to modify the right fields in the LSA to get
> the desired behavior and still generate the same Fletcher checksum. This
> is probably doable - have you done it?
>    2. The attacker’s LSA reaches the originator (aka, the victim) after
> it has responded to the attack and generated the LSA with the desired
> sequence number. 
>    3. The attackers’s LSA reaches other routers before the originator’s
> LSA (which is probably only assured for routers downstream from the
> attacker in the best case flooding graph rooted at the originator). If the
> originator’s LSA reaches these routers first, it is ignored.
> 
> I must admit I’m not a big fan of the proposed change given that once a
> router in the routing domain is compromised (including obtaining
> authentication keys), there are many harmful attacks that may be levied
> and this is just one of them. More importantly, you neglect the fact that
> you’ll hasten the disruption caused by the sequence number advancing to
> MaxSequenceNumber (which cannot be skipped).
> 
> In short, I think this is definitely a case where “the medicine is worse
> than the cure.” 
> 
> Thanks,
> Acee 
> 
> On 5/12/16, 7:09 AM, "OSPF on behalf of Ramakrishna DTV"
> <[e-mail] on behalf of [e-mail]>
> wrote:
> 
>> Hi Acee/Manav,
>> 
>> I guess we were a little too brief in our description of the attack in
>> the draft.
>> 
>> The paper "Nakibly, G. et al, Persistent OSPF attacks, NDSS , 2012"
>> discusses about multiple variants of the "Disguised LSA attack". I will
>> describe
>> one variant below.
>> 
>> Some facts:
>> 
>> Quoting from the paper:
>> 
>> "Section 13.1 of the OSPF spec states that two instances of an LSA are
>> considered identical if they have the same values in the following three
>> fields:
>> 
>>    Sequence Number, Checksum, and Age.
>> 
>> In fact, two LSAs are considered identical even if their Age fields
>> differ by up to 15 minutes (and the Sequence Number and Checksum
>> fields are the same). The key point is that the spec considers these
>> two LSAs to be the same even if the actual advertised links in the LSAs
>> differ."
>> 
>> Network setup:
>> 
>> There are a set of routers in a routing domain.
>> 
>> In this network 'C' is the compromised router. 'V' is the victim router.
>> 
>> Intention: C intends to change an LSA of V without V fighting back.
>> 
>> Here is a time-line of events:
>> 
>> t0: V generated an LSA with sequence number 's' and all routers have it
>> installed in their database including C.
>> 
>> t1: C changes the LSA of V to sequence number 's+1' and floods it. The
>> paper
>> refers this as "trigger LSA".
>> 
>> While this LSA is flooding the network, and it is on its way to V as
>> well...
>> 
>> t2: C changes the LSA of V to sequence number 's+2' and changes the LSA in
>> such a way that checksum will be same as what V would have calculated. V
>> then
>> floods this "disguised LSA".
>> 
>> (Note: The time-gap between t1 and t2 is governed by MinLSArrival of RFC
>> 2328.)
>> 
>> t3: V receives LSA with sequence number 's+1' and as part of 'fight-back'
>> mechanism reissues LSA with sequence number 's+2' and starts flooding.
>> 
>> (Note that t3 may even be between t1 and t2 in some cases. But the attack
>> still
>> works in either case.)
>> 
>> The important point now is that there are two LSAs in race for flooding in
>> the network -- one prepared by C and other prepared by V.
>> 
>> Both the LSAs have same values for the following values:
>> 
>>    Sequence Number ('s+2'), Checksum, and Age.
>> 
>> But note that their contents are different!
>> 
>> Any receiving router (including victim V) will consider these as
>> duplicates and
>> installs the first one it receives.
>> 
>> The point is that LSA with sequence number 's+2' will not trigger
>> fight-back.
>> Instead, it will be considered as a duplicate.
>> 
>> The entire attack is made possible because C knows that V will generate
>> LSA with
>> sequence number 's+2' when it is fighting back an LSA with sequence
>> number 's+1'.
>> 
>> Note that at the end of the attack, some routers have the LSA as prepared
>> by V.
>> This is the correct LSA. The remaining routers will have the LSA as
>> prepared by
>> C. It is obvious that LSDB of this second set is effectively corrupted. An
>> important point is that even those routers which got correct LSA, it is
>> still
>> troublesome because LSDB is not same across all the routers.
>> Unsynchronized LSDB
>> across routers cause routing issues.
>> 
>> Gabi and co-authors have also provided a nice presentation which describes
>> this attack in graphical form with little more detail (especially look at
>> slides 14 to 20):
>> 
>>    http://www.internetsociety.org/sites/default/files/P01_3.pdf
>> 
>> Thanks and regards,
>> Ramakrishna DTV.
>> 
>> 
>> ________________________________________
>> From: Acee Lindem <[e-mail]>
>> Sent: Thursday, May 12, 2016 4:33 PM
>> To: Manav Bhatia
>> Cc: Ramakrishna DTV; OSPF List; Manjul Khandelwal
>> Subject: Re: [OSPF] Fw: New Version Notification for
>> draft-manjuldtv-ospf-sequence-number-00.txt
>> 
>> Hi Manav,
>>> On May 12, 2016, at 1:11 AM, Manav Bhatia <[e-mail]> 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-determini
>>> ng-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
>>> <[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-vulnera
>>> bility-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
>>> <[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-numbe
>>>> r-
>>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> OSPF mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ospf
>> 
>> _______________________________________________
>> OSPF mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ospf
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf