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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 11 May 2016 15:19:29 +0000

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"
<[email-masked] on behalf of [email-masked]> 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: [email-masked] <[email-masked]>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: Ramakrishna DTV <[email-masked]>
Date: Thu, 12 May 2016 02:29:26 +0000

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) <[email-masked]>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; [email-masked]
Cc: Ramakrishna DTV
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt

Hi Manjul,

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 12 May 2016 02:55:34 +0000

Hi Ramakrishna, 

I believe there is a flaw in the description of the “Disguised LSA” attack. If the sequence number of the LSA is set to +1 by the attacker, the originator (aka, the victim) will determine that the received LSA is newer and will originate a newer LSA (“fight-back”) as described below. See section 13.1 and 13.4 in RFC 2328. 

Thanks,
Acee 

> On May 11, 2016, at 10:29 PM, Ramakrishna DTV <[email-masked]> wrote:
> 
> Hi Acee,
>

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 12 May 2016 09:16:33 +0530

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/

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 <
[email-masked]> wrote:

> Subject: Re: [OSPF] Fw: New Version Notification for

---

From: Ramakrishna DTV <[email-masked]>
Date: Thu, 12 May 2016 04:48:59 +0000

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 <[email-masked]>
Sent: Thursday, May 12, 2016 9:16 AM
To: Ramakrishna DTV
Cc: Acee Lindem (acee); Manjul Khandelwal; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Acee,

Thank you.

Regards,
Ramakrishna DTV.

________________________________________
From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; [email-masked]<mailto:[email-masked]>
Cc: Ramakrishna DTV
Subject: Re: [OSPF] Fw: New Version Notification for draft-manjuldtv-ospf-sequence-number-00.txt

Hi Manjul,

Thanks,
Acee

On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

>From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
>The IETF Secretariat
>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
OSPF mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ospf

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 12 May 2016 10:41:25 +0530

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 <
[email-masked]> wrote:

> ------------------------------
> *From:* Manav Bhatia <[email-masked]>
> *Sent:* Thursday, May 12, 2016 9:16 AM
> *To:* Ramakrishna DTV
> *Cc:* Acee Lindem (acee); Manjul Khandelwal; [email-masked]
> *Subject:* Re: [OSPF] Fw: New Version Notification for
> Its got *nothing* to do with the sequence numbers being predictable, etc.
> I have explained in depth how the Gaby attack works here:
>
>
> 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/>
> 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 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
> 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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 May 2016 07:03:18 -0400

Hi Manav, 
> On May 12, 2016, at 1:11 AM, Manav Bhatia <[email-masked]> wrote:
> 
> Hi DTV,
> 
> 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:
> 
> 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 <[email-masked]> wrote:
> 
> Hi Manav,
> 
> On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV <[email-masked]> wrote:
> Hi Acee,
>

---

From: Ramakrishna DTV <[email-masked]>
Date: Thu, 12 May 2016 11:09:46 +0000

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 <[email-masked]>
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,

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 May 2016 17:28:14 +0000

<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"
<[email-masked] on behalf of [email-masked]>
wrote:

>> 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:
>>
>> 
>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
>><[email-masked]> wrote:
>>
>> Hi Manav,
>>
>> Its got *nothing* to do with the sequence numbers being predictable,
>>etc. I have explained in depth how the Gaby attack works here:
>>
>> 
>>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.
>>
>>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 .. “.
>>
>>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!"
>>
>>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
>><[email-masked]> wrote:
>> Hi Acee,
>>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 17 May 2016 19:12:14 -0700

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) <[email-masked]> wrote:
>