Re: [OSPF] Dropping malformed LSAs (was: OSPF - Owning the Routing Table Attack)

[Mitchell Erblich <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf