Anton,
I agree partially with the below qualifications:
A valid set of LSAs that constitute a flooding attack, where
the flooding attack is based on a reverse route summarization, should be able
to be identified and mitigated,
An excess of valid and invalid LSAs could be run against an
acceptable quantity of LSAs, and any quantity above X from a single non-trusted
source, could cause the equiv of a tail or a RED drop of some percentage of
LSAs per period of time,
Some form of authentication challenge against LSAs (like a ICMP
echo request) or first recv'ing packets from the path, could be used to
validate the LSA before using the actual LSA (if the LSA is suspect) could be
done…
Thus, as in most de facto implementations, a layering of
secure/authentication methods tend to be more effective then just at a single
layer.
So, why wouldn't a best practices type document given a set of
well known attacks with SHOULDs be minimally productive?
Mitchell Erblich
On Sep 12, 2013, at 4:16 AM, Anton Smirnov wrote:
> 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
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
