On (2013-08-03 18:38 -0500), Jimmy Hess wrote:
That's not news to me, but fully expected. Do the vendors /really/ have a code fix to what would seem to be an inherent problem; if you failed to properly secure your OSPF implementation (via MD5 authentication)?
It is news to me. It's design flaw in the protocol itself which has gone unnoticed for two decades and I would have naively fully expected that this flaw does not exist in standard. As I've understood issue lies in the fact that 'link state id' and 'advertising router' should always be the same (so it's redundant information in the LSA, single field should suffice?). But standard does not enforce this at all. Victim will omit doing corrective reflood for received bogus LSA if 'advertising router' is something else than 'router-id', even while 'link state id' == 'router-id' I suppose vendors implement fix where either a) corrective reflood occur if 'link state id' == 'router-id' or b) LSA is rejected unless 'link state id' == 'advertising router' How serious or new this is, may be debatable, as only thing it seems remove, is the need for attacker to inject 0.2pps worth of packets which will suppress the corrective reflooding. -- ++ytti