RE: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.

["Smith, Donald" <Donald.Smith@qwest.com>]

-----Original Message-----
From: owner-opsec@psg.com
To: Ross Callon
Cc: gmj@pobox.com; opsec@ops.ietf.org; bwijnen@lucent.com
Sent: 2/22/2004 12:16 AM
Subject: Re: Reply to comments on opsec draft from Bert Wijnen/OPS directorate. Part 1.


Ross Callon <rcallon@juniper.net> writes:
> Similarly, the security threat implicit in having hackers break into 
> network management will depend upon other details of how the 
> network is set up. For example, there are some networks where 
> there are a moderate number of very large routers, and where *all*
> incoming interfaces (from customers) have packet filters set which
> prevent the customers from sending packets to the routers (ie, 
> they can't set the IP destination address to be the address of an 
> internal router within the network). In this case hackers can't break 
> into a router

Wanna bet?

djs It helps to limits your exposure. Overflows that only require the router to PROCESS the 
djs packet such as the recent H323 vulnerabilites are sill a possible vector of attack.

> because they can't send a packet to the router at all
> (they can send packets via the router, but only if the destination is
> not the router). In this case the urgency of encrypting network 
> management might be lower than in other cases. 

Most big iron these days lets me ssh in. That is nice and
secure. Most of them will do other kinds of secure management as
well. Given that, why should we encourage Potemkin security?

djs Blocking access to services on the router prevents other attacks such as syn floods against djs a service on the router.
djs Ratelimiting the service or the initial packet for a service on the route also helps 
djs mitigate the possiblity of a resource exaustion attack on any service on the router.


-- 
Perry E. Metzger		perry@piermont.com