RE: [BEHAVE] Re: CPE equipments and stateful filters

["Dan Wing" <dwing@cisco.com>]

> > From: Dan Wing [mailto:dwing@cisco.com]
> > Sent: Tuesday, July 31, 2007 10:34 PM
> > To: 'Pekka Savola'
> > Cc: 'IPv6 Operations'; 'Behave WG'
> > Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters
> > 
> > Your email and Christian's email are both concerned with end-host
> > protection.  I am concerned with protecting the access link from
> > unwanted traffic to save bandwidth and, for battery-powered devices,
> > to save their batteries.  If the device isn't listening on UDP/500
> > and would merely throw away or ICMP the incoming packet, there are
> > advantages with bandwidth-constrained access links and with wireless
> > devices, to discard the packet in the network (in a 
> firewall device).
> 
> If we followed your reasoning, cell phones should never be allowed to
> ring, because doing so might deplete the batteries. They would only be
> allowed to make outgoing calls...

They would originate and maintain a signaling connection to their
call processing box.  That is what they do today on v4.

> There are many other ways to resolve this issue for the small battery
> powered devices. For example, they may be programmed to only listen to
> local addresses, which would radically solve the issue.

That could work well.

> They may also keep their address "hidden", so as to not receive 
> traffic.

I'm sure what you are referring to here; something akin to RFC3041?

> There are also some better ways to answer to DOS attacks in a
> firewall than blocking traffic outright. If the concern really 
> is the batteries, then rate limiting comes to mind.  For example, 
> if a device receives a packet and does not respond, or send an ICMP, 
> block the port for some period. 

Rate-limiting down to 0 would work fine to protect the battery and
the access link.  Higher, and the device has to wake up and scarce
access link bandwidth is consumed.

-d