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

From: "Acee Lindem" <[email-masked]>
Date: Fri, 27 Feb 2004 11:50:38 -0500

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.

  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. 

  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. 

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

  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. 

  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. 
      
  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. 

  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. 

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

 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. 

 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.  
 
 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. 

------
Acee

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