If attacker has joined flooding domain and can inject an LSA into
LSDB then it can screw up routing in the domain. Methods such as
pretending being an ABR/ASBR and advertise destinations with good metric
are almost impossible to combat once authentication barrier is penetrated.
This particular vulnerability allows attacker to bring network down
in style but if this vulnerability is not present in the particular
network then attacker will simply resort to other numerous possibilities
to affect routing via LSA injection. If attacker can inject LSA into
LSDB then your network is at his mercy. Give or take one particular
method is a detail.
So IMO we don't need a draft on this particular vulnerability. It
might be of some limited interest to document all known methods to
exploit LSA injection which would include this vulnerability but what
value would this RFC bring? Such methods are regularly published in
academic literature since 90-th.
IMO we need good (reliable, secure, manageable etc) methods of
authenticating adjacencies. KARP group is working on that. We *might*
benefit from a work on mechanism to prevent any router to originate
reachable LSA on behalf of any other router (kind of LSA signing). But
work on what will go wrong when intended security barriers are broken
IMO is not needed.
Anton
On 09/12/2013 05:42 AM, Bhatia, Manav (Manav) wrote:
Hi Gabi,
[clipped]
Nonetheless, I am sure that there are more OSPF vendors out
there that are still vulnerable to the attack and do not
check for this. Moreover, since this check is not part of the
standard, in most likelihood future OSPF implementations will
also be vulnerable.
[clipped]
I am willing to write a draft describing this mitigation
measure. I would appreciate the list's thoughts on this.
I think it's a good idea to write a draft that describes the attack and what
implementations MUST do to avoid it.
Cheers, Manav
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
