From: Acee Lindem <acee.lindem@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CAG1kdogZhHgGxbL5caBkAVypncnA3yTtb5+ZebV1m2Yzj0r+jA@mail.gmail.com>
Date: Thu, 12 May 2016 07:03:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <89E7259B-72EE-4B60-BFC1-BA55BE761B9C@lindem.com>
References: <D358C4E4.607A9%acee@cisco.com>
 <KL1PR0401MB1544944FE1E375A8FB7A31C0A3730@KL1PR0401MB1544.apcprd04.prod.outlook.com>
 <CAG1kdoiyj_s_gzHibrmomPJAZo28bCLDxqPRnbeS6-ooJzb_MQ@mail.gmail.com>
 <KL1PR0401MB1544349FCF40E95494CC1D4EA3730@KL1PR0401MB1544.apcprd04.prod.outlook.com>
 <CAG1kdogZhHgGxbL5caBkAVypncnA3yTtb5+ZebV1m2Yzj0r+jA@mail.gmail.com>
To: Manav Bhatia <manavbhatia@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/g6P6L-LeXIMHzVCC2YPPfMM6lu8>
Cc: OSPF List <ospf@ietf.org>,
 Ramakrishna DTV <ramakrishnadtv@nivettisystems.com>,
 Manjul Khandelwal <manjul@nivettisystems.com>
Subject: Re: [OSPF] Fw: New Version Notification for
 draft-manjuldtv-ospf-sequence-number-00.txt
Precedence: list

Hi Manav,=20
> On May 12, 2016, at 1:11 AM, Manav Bhatia <manavbhatia@gmail.com> =
wrote:
>=20
> Hi DTV,
>=20
> Aha. Thanks for the catch !=20
>=20
> 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:
>=20
> =
https://routingfreak.wordpress.com/2010/07/02/using-checksum-in-determinin=
g-the-newer-lsa/
>=20
> 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.=20

Thanks,
Acee

>=20
> Cheers, Manav
>=20
> On Thu, May 12, 2016 at 10:18 AM, Ramakrishna DTV =
<ramakrishnadtv@nivettisystems.com> wrote:
>=20
> Hi Manav,
>=20
> Thank you for your comments.
>=20
> Gabi has published multiple attacks against OSPF.
>=20
> The attack we are targeting is published in
>=20
> @inproceedings{nakibly2012persistent,
>   title=3D{Persistent OSPF Attacks.},
>   author=3D{Nakibly, Gabi and Kirshon, Alex and Gonikman, Dima and =
Boneh, Dan},
>   booktitle=3D{NDSS},
>   year=3D{2012}
> }
>=20
> 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.
>=20
> The attack you are discussing in your article is a different attack.
> It was described by Gabi in great detail in a different paper:
>=20
> @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 =
Applications Conference},
>   pages=3D{336--345},
>   year=3D{2014},
>   organization=3D{ACM}
> }
>=20
> As you rightly mentioned, this attack does not depend upon sequence =
number
> predictability. But our draft is *not* targeting *this* attack.
>=20
> Thanks and regards,
> Ramakrishna DTV.
>=20
>=20
>=20
> From: Manav Bhatia <manavbhatia@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
> =20
> Hi DTV,
>=20
> I dont agree to your assessment of how the attack evades the "natural =
fight-back mechanism" in OSPF.=20
>=20
> Its got *nothing* to do with the sequence numbers being predictable, =
etc. I have explained in depth how the Gaby attack works here:
>=20
> =
https://routingfreak.wordpress.com/2013/09/09/how-bad-is-the-ospf-vulnerab=
ility-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 ...
>=20
>=20
> Clipped from the blog:
>=20
> "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.
>=20
> 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.
>=20
> 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 =E2=80=9CA =
self-originated LSA is detected when either 1) The LSA=E2=80=99s =
Advertising Router is equal to the router=E2=80=99s own Router ID or 2) =
the LSA is a network LSA .. =E2=80=9C.
>=20
> This means that OSPF=E2=80=99s natural fight back mechanism is NOT =
triggered by the victim router as long as the field =E2=80=98Advertising =
Router=E2=80=99 of a LSA is NOT equal to the victim=E2=80=99s Router ID. =
This is true even if the =E2=80=98Link State ID=E2=80=99 of that LSA is =
equal to the victim=E2=80=99s 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!"=20
>=20
> 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.=20
>=20
> Cheers, Manav
>=20
> On Thu, May 12, 2016 at 7:59 AM, Ramakrishna DTV =
<ramakrishnadtv@nivettisystems.com> wrote:
> Hi Acee,
>=20
> We currently provided the following description of this attack in the =
draft:
>=20
>  "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.
>=20
>    This attack enables an insider attacker to fully control the entire
>    content of an LSA.  We think this attack is powerful."
>=20
> 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.
>=20
> If you think even more additional details about the attack are useful =
to the working group,
> please let us know. We will add.
>=20
> Thank you.
>=20
> Regards,
> Ramakrishna DTV.
>=20
>=20
> ________________________________________
> From: Acee Lindem (acee) <acee@cisco.com>
> 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-sequence-number-00.txt
>=20
> Hi Manjul,
>=20
> Would it be possible to succinctly describe these =E2=80=9Ccertain =
security
> attacks=E2=80=9D in the draft rather than expecting everyone to read =
the
> referenced paper?
>=20
> Thanks,
> Acee
>=20
> On 5/11/16, 10:19 AM, "OSPF on behalf of Manjul Khandelwal"
> <ospf-bounces@ietf.org on behalf of manjul@nivettisystems.com> wrote:
>=20
> >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 <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
>=20
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>=20
>=20
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf