Subject: Re: [RPSEC] Comments on draft-jones-ospf-vuln-00.txt

From: Emanuele Jones <[email-masked]>
Date: Fri, 12 Mar 2004 18:10:41 -0500

Acee,

thank you for your comments regarding the OSPF vulnerabilities draft.
Please find my further comments in line.

Acee Lindem wrote:

 > Comments
 >
 > 1. General - Define what you mean by an OSPF routing session
 > or replace it with a generally accepted term.
 > It is not a term from RFC 2328 and appears to be used
 > in more than one context. In some cases it refers to an
 > OSPF routing domain, other cases an OSPF router, and
 > other cases an OSPF adjacency.
 >
Agreed

 > 2. Page 8, top paragraph. An RFC 2328 compliant router will
 > not consider reflooding the same as originating the LSA
 > itself. So, the statement that the router will not fight
 > back at all is incorrect. Anyway, as we discussed, I
 > believe this sequence is wrong and the check for a
 > self-originated LSA must be done before reflooding the
 > LSA. I know my implemenation does this.
 >
Agreed.
I will rephrase this paragraph to state that a 2328 compliant router
will fight back only every MinLSInterval.

 > 3. Page 8, 3.1.3.2 - You might want to elaborate. Once the
 > network is partitioned the attacker's bogus LSAs will be
 > ignored unless the attacker is able to maintain the
 > real router's adjacencies.
 >
Agreed.
What we really meant to say with this paragraph was that the network is
still entirely connected, but the attacker is sitting on a critical node
that *would* partition the network if removed. In this position the
attacker could inject a forged LSA *only* to one part of the network,
pretending this LSA is coming from an existing router from the other
part. Thus, the legitimate owner of the LSA will never be aware of the
forged information on his behalf and never initiate a fightback.

 > 4. Page 8, 3.1.5 - "stub or NSSA areas" rather than "stub areas".
 >
Agreed

 > 5. Page 10, You should state that any attacks in sections
 > subsequent sections require the no authentication or must
 > be carried out by an inside attacker.
 >
Agreed

 > 6. Page 10, last paragraph - Actually this is harder than it
 > looks since you also have assure you list all the routers
 > on the network in your bogus hello. However, once you've
 > done that effectively you can keep the network LSA from
 > being originated permanently.  
 >
Partially Agreed.
At least the DR and BDR must be present in the neighbor's list of any
malicious Hello in order to initiate any DR-change attack.
If the current DR and BDR are the only routers listed in the neighbors'
list then:
1) the current DR and BDR will acknowledge the malicious Hello and drop
their DR and BDR role immediately
2) the remaining routers on the network (i.e. all the ones that were not
listed in the malicious Hello) will not acknowledge any DR/BDR change
and thus they would still consider the previous DR and BDR to be in charge.
This will create inconsistencies and disrupt data traffic.
 
 > 7. Page 11, Paragraph beginning "Finally...". I don't understand
 > what this is getting at, the source would ignore it's replayed
 > hello anyway. So if you replayed an old one that wasn't
 > protected by auth sequence numbers you could still wreck
 > havoc by forcing routers to 1-Way state.
 >
Not understanding.
Just a bit of context here, with this paragraph I am arguing that one of
the attacks previously described in [7] is not doable, and hence this
is why it will not be listed in the draft. Based on the first part of
your comment, you seem to be in agreement with my statement. Given we
both agree that this attack does not work (and I have decided to list it
in here only for the sake of completeness), I am not sure I understand
how you could force a router to go back to the 1-Way state with a
non-authenticated Hello.

 > 8. Page, Section 3.2.4 - All attacks to LSAs require the orginating
 > router to be in state exchange or higher with a router in the
 > domain.
 >
Agreed

 > 9. Page 12, 3.2.4.2 - Replace "refreshment" with "refresh".
 >
Agreed

 > 10. Page 12, 3.2.4.2, Second paragraph. - I'm not sure it makes
 > sense to publish this since most deployed implementations
 > do not have the bug.
 >
I would to keep this section (maybe shortened) just as a reminder of
an historical OSPF's implementation problem. Just to sort of keep track 
of it.

 > 11. Page 16, Number of Neighbors on multicast networks - Hello messages
 > are not retained. Rather, a neighbor data structure is created.
 > However, the latter probably requires as much or more resources as
 > the former.
 >
Agreed
 
 > 12. Page 16 and page 17 - I'm not sure whether the specific Zebra
 > bugs are relevant. At some point a fragmented packet that is
 > arbitrarily large may be rejected by an implementation. Many
 > times that number is less than 65535 since in practice fragmented
 > IP packets that large are not sent.
 >
Agreed.

Regards,

Emanuele

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: "Acee Lindem" <[email-masked]>
Date: Sat, 13 Mar 2004 13:58:21 -0500

Hi Emanuele,
See inline. 
----- Original Message ----- 
From: "Emanuele Jones" <[email-masked]>
To: <[email-masked]>; "rpsec" <[email-masked]>
Sent: Friday, March 12, 2004 6:10 PM
Subject: Re: [RPSEC] Comments on draft-jones-ospf-vuln-00.txt

> This will create inconsistencies and disrupt data traffic.

Agreed. The case of messing up only the DR and BDR may be worse because
the DR re-election could take longer. 

> how you could force a router to go back to the 1-Way state with a

I can't remember what I was thinking here. The only way an attacker
could make this work would be to have saved a hello with a higher auth
sequence number (indicating the router's auth sequence number has
been reset). 

> an historical OSPF's implementation problem. Just to sort of keep track 

Fair enough since you indicate that it is a bug.