Subject: Reg: DDOS prevention in OSPF

From: "Nanda Kishore S." <[email-masked]>
Date: Wed, 22 Feb 2006 15:10:21 +0530

Hi,

            In quite some places we mention that Authentication is 

a must to provide DDOS protection for OSPF. 

            But as simple password is not so useful we will be using

MD5 authentication and even if is enabled, wont' the socket buffers

become full and drop genuine adjacencies when DDOS attack happens. 

            I was wondering if any implementations are there where 

authentication is done before queuing the packet at socket/packet 

buffer layer. 

            My idea is implementing MD5 authentication at socket

level at greater speeds (DDOS attack's speed) is not feasible or won't

give such performance so, why not have a cascaded authentication 

mechanism like (Simple password + MD5) so, that before queuing of

packets we can do simple password at greater efficiency and MD5 for

better security later. 

            (Assuming that it won't be that easy to get the simple
password

as knowing just the IP addresses of OSPF routers). 

Any comments?

-Nanda Kishore

---------------------------

Nanda Kishore,

Sr. Software Engineer,

Citrix - ANG, Bangalore.

Tel: 51341000 Ext: 416

Cell: 9880720721

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Feb 2006 05:15:22 -0800

Dumb question: why no use IPsec, which (unless I am mistaken)  
accomplishes the same thing?

Historically, the reason we built MD5 authentication into OSPF was  
because IPsec couldn't produce a result to save its soul. This  
authentication mechanism is basically borrowed more or less directly  
from the IPsec AH drafts of the time. IPsec produced a result...

On Feb 22, 2006, at 1:40 AM, Nanda Kishore S. wrote:
> My idea is implementing MD5 authentication at socket level at  
> greater speeds (DDOS attack’s speed) is not feasible or won’t give  
> such performance so, why not have a cascaded authentication

---

From: vijay gill <[email-masked]>
Date: Wed, 22 Feb 2006 09:11:56 -0500

> a must to provide DDOS protection for OSPF.

Unless you can do distributed authentication checks at the point of 
ingress of traffic (i.e. at the line card, right after the framer, at 
wirespeed), authentication is almost a win for DDOS, because what 
happens is you get a bunch of packets with auth on them, you send them 
to the CPU, CPU sits there, decoding and discarding and well, box keels 
over and dies. This is the same result we saw when the MD5 auth was 
turned on for BGP. Most router vendors actually had worse performance 
when subject to DDOS attacks with MD5 than without, because now instead 
of just discarding junk, they had to decode and then discard.

> MD5 authentication and even if is enabled, wont’ the socket buffers
> 

This is correct.

> level at greater speeds (DDOS attack’s speed) is not feasible or won’t
> 
>             (Assuming that it won’t be that easy to get the simple password
> 

This is the right way. See also GTSM where for some protocols, we used 
TTL as a fast key to disambiguate junk from non-junk.

http://www.ietf.org/rfc/rfc3682.txt

/vijay

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 22 Feb 2006 07:33:21 -0800

Hi,

> This is the right way. See also GTSM where for some protocols, we
> used TTL as a fast key to disambiguate junk from non-junk.
GTSM is certainly a good way to clear the chaff to prevent a DDOS due to
flooding of junk packets which use authentication mechanisms, however it may
not be of much use for packets received over virtual links.

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 22 Feb 2006 07:41:46 -0800

Vijay,

Besides for GTSM to work, all current implementations should have their TTL/
Hop Limit programmable for all IP packets containing the OSPF
payload.Bydefault the IP TTL valie of 64 is used.

Thanks,
Vishwas

---

From: vijay gill <[email-masked]>
Date: Wed, 22 Feb 2006 14:12:37 -0500

Vishwas Manral wrote:
> flooding of junk packets which use authentication mechanisms, however it 
> may not be of much use for packets received over virtual links.
>  

Of course, gtsm is not a catch-all. I just used it as an illustration of 
something that used something fast and easy to parse quickly, (eg. was 
in a fixed offset) so you didn't have to go through and decode the 
entire packet for validity, considering there may not be enough 
cycles/silicon to do that on the line card.

In fact, I am considering the merits of having a fixed offset after the 
ip packet for a 32 bit field that holds a cookie that is agreed upon 
when an adjacency is formed, just for the purposes of quick disambiguation.

/vijay

> Thanks,
> Vishwas
>  
> On 2/22/06, *vijay gill* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Nanda Kishore S. wrote:
>      > Hi,
>      >
>      >
>      >
>      >             (Assuming that it won't be that easy to get the
>     simple password
>      >

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 22 Feb 2006 11:27:19 -0800

Hi Vijay,

The cookie mechanism is of more use in cases where either the replay of a
previous session is not required or no security mechanism is used. It is
more like an anti-spoofing cookie to prevent against off path attacks. Note:
It does not prevent on-path attacks at all.

The cookie idea is good and is heavily used in IKE case for DDoS prevention
when too many resources are being used. So if a new adjacency is to be
formed and we feel we may be heavily loaded (and may be under DDoS attack)
caused by sending a lot of initial request packets, we could ask the other
end to send in their hellos cookies, or reflect the cookie we have sent to
it, we only accept packets with the cookies.

It is of course another level of removing the "junk from the non-junk" in
the MD5 case and prevent off-path attacks, but not on-path attacls.

Thanks,
Vishwas

On 2/22/06, vijay gill <[email-masked]> wrote:
> used

---

From: Erblichs <[email-masked]>
Date: Wed, 22 Feb 2006 13:09:07 -0800

Group,

	Shouldn't their be a way to implement a simple
	lightweight mechanism that can mechanism that
	can match src IP address with router-id?

	The DOS attacker(s) must know router id's that
	we accept control pkts from.

	This removes the new hellos from router's as exception 
	cases.

	Thus, we only need to do a minimal pre-check iff
	we are failing a percentage of OSPF auths. If
	the auth failures are occuring at a single intf
	if it feasible that one could also implement some
	 QoS type process that sets the processing of those 
	pkts at a lower priority best effort basis.

	The logic of doing a minimal pre-check is with the
	assumption that the burst of packets per sec (pps)
	is short enough in duration that the buffer will
	not overflow/tail drop. If an attack or a LSA flooding
	storm is present, a simple RED on a combined input
	queue that drops the identifyied OSPF pkt type (if
	identified) other than hello SHOULD not cause an adj
	to be dropped.

	However, with OSPF we should have excess capacity
	with recving Update pkts / flooding to handle flooding
	bursts and even if we drop some recv'd updates, they
	should be resent anyways. If the AREA is somewhat
	stable, 99+% of these LSAs are just age refreshes
	and will not effect routing if not immedaitely handled.
	The other 0.9% are new LSAs that would result in
	newer routes that no application will use in the near
	future. The last 0.1% of LSAs are the important ones.

	So, unless the router is totally stuck in processing
	bad LSAs the router SHOULD still operate normally in
	a normally stable area.

	And I would think a more effective DOS attack would
	be a wirespeed of pings to the router from a number of
	attackers. These pkts would force some type of tail
	or RED at the input buffer of the router AND would
	be a system wide attack. This would force recption
	and many echo replies.

	Mitchell Erblich
	-----------------

vijay gill wrote:
> > MD5 authentication and even if is enabled, wont the socket buffers
> >
> > level at greater speeds (DDOS attacks speed) is not feasible or wont
> >
> >             (Assuming that it wont be that easy to get the simple password
> >

---

From: Dave Katz <[email-masked]>
Date: Wed, 22 Feb 2006 14:04:23 -0800

> 	we accept control pkts from.

If the attacker has access to the LSDB, this is a trivial thing to  
figure out.

If the network is properly secured (tossing all OSPF packets at the  
edge), the most likely attack of this type is going to be from inside  
(topologically) in which case the LSDB is going to potentially be  
accessible.

Realistically I think OSPF authentication needs to be viewed as a  
last-resort mechanism to try to protect the infrastructure as best as  
can be done if all other defenses have been penetrated.  OSPF MD5  
authentication is unlikely to get the kind of hardware assist  
necessary to do this well, since it's one-off and kind of gross.  As  
Fred mentioned, running inside IPsec makes a lot more sense (since  
hardware assist is generally available.)  This also makes  
eavesdropping much more difficult for no extra charge.

--Dave

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 22 Feb 2006 14:12:20 -0800

Dave,

Good points there about IPsec being a better solution than a patch solutions
we are talking about. With automatic key generation mechanisms we can get
over most of the problems encountered. However other issues like verifying
identity (eg. PKI) and related topics come into picture.

Besides I would like to add, there are quite a few security coprocessors out
there, to which we feed the data, give the key and the algorithm name and we
get the message digest.

Thanks,
Vishwas

---

From: Erblichs <[email-masked]>
Date: Wed, 22 Feb 2006 14:54:03 -0800

> (topologically) in which case the LSDB is going to potentially be

	Yes, but I assume that 99% of the attacks will not be
	physically within the AREA. Not being in the area, SHOULD
	prevent LSA flooding or hellos reaching the attacker(s).

	If it were within the area, the attack would be more 
	successful because the AREA/AS was no longer consisting 
	of TRUSTED entities. But it should be easier to isolate 
	the attackers and then the routing domain is in control
	of the admins.
	
	then Again the more generic intf isolation/QoS change in the
	case that auth failures indicated a possible attack COULD also be
	used.

	Lastly, if it were within the area, a more sucessful attack
	is one which is subtle by flooding invalid/bad LSAs that
	result in poor routing.

	Mitchell Erblich
------------------------