[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: survey of isp security practices

At 8:04 AM -0800 11/9/04, Merike Kaeo wrote: 
On Nov 9, 2004, at 6:25 AM, Howard C. Berkowitz wrote:

At 6:16 AM -0800 11/9/04, David Barak wrote: 
--- "Howard C. Berkowitz" <hcb@gettcomm.com> wrote:

 I need to think some more about exactly where it
 would go and what
 would be in it, but my initial reaction is that
 there needs to be a
 section on "routing".  I'd move blackholes/sinkholes
 out of
 filtering, as well as uRPF, and add the issues of
 routing protocol
 security, sanity checks on routing (correlation with
 routing
 registries, prefix limits, etc.), and
 information-gathering from such
 things as flaps and generic changes-from-baseline of
 routing protocol
 specifics.


I agree with Howard that "routing" should be a major
heading, but I think that it has two major categories:
source validation, and information validation.

Good points, but there perhaps should be a third -- altering the routing/forwarding tables as part of a security mechanism such as blackholes, sinkhole attractors, and the effect of blackholes on uRPF.

I am not yet convinced that routing should be a separate category but instead the security practices that are currently employed for authentication, filtering, logging, etc can use a sub-category for what is specific to routing. However....I'm still thinking about it.....

If security-related changes were made only on the local router that detected a potential exploit, I'd agree completely with you. My concern is that when manual or automated actions introduce new routes (blackholes, redirection of hosts or subnets to sinkholes), you are affecting the behavior of the entire routing domain.

Hypothetically, if a large number of such routes were introduced as a result of security mechanisms, it could produce a do-it-yourself DoS if some of the edge routers have limited RIB memory. There are other effects of blackhole injection in the like that oculd be misinterpreted if on too large a scale -- for example, if one had a monitoring tool that looked for changes in the number of prefixes announced by a particular router or set of routers, and a distributed exploit caused a significant number of blackholes to be created, this could look like a variation from normal behavior, and trigger a needless response.