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 protected]>
Sent: Thursday, May 12, 2016 9:16 AM
To: Ramakrishna DTV
Cc: Acee Lindem (acee); Manjul Khandelwal; [email protected]
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 protected]<mailto:[email protected]>>
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) <[email protected]<mailto:[email protected]>>
Sent: Wednesday, May 11, 2016 8:49 PM
To: Manjul Khandelwal; [email protected]<mailto:[email protected]>
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"
<[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>
><[email protected]<mailto:[email protected]>>
>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<http://tools.ietf.org>.
>
>The IETF Secretariat
>
>_______________________________________________
>OSPF mailing list
>[email protected]<mailto:[email protected]>
>https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
