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 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]> > Sent: Wednesday, May 11, 2016 8:49 PM > To: Manjul Khandelwal; [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] on behalf of [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] <[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. >> >> The IETF Secretariat >> >> _______________________________________________ >> OSPF mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
