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

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

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).

-d

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi] 
> Sent: Tuesday, July 31, 2007 10:05 PM
> To: Dan Wing
> Cc: 'james woodyatt'; 'IPv6 Operations'; 'Behave WG'
> Subject: RE: [BEHAVE] Re: CPE equipments and stateful filters
> 
> On Tue, 31 Jul 2007, Dan Wing wrote:
> >> Neither of these two
> >> forms of traffic could reasonably be described as "unsolicited" in
> >> this case.
> >
> > We have different definitions of 'solicited traffic' and
> > 'unsolicited traffic'.  Other than opening a listener on UDP/500
> > for IKE (and telling the upstream firewall to please open a
> > permission for incoming traffic), the host didn't do anything to
> > solicit an incoming IKE packet.  I call that incoming traffic
> > 'unsolicited', because the host (and its firewall) are unaware
> > of when a client will send a packet to establish a connection.
> > An HTTP server or SMTP server fall into this category, for
> > example.
> >
> > This differs from the SIP model and the RTSP 2.0 model.  In
> > both SIP and RTSP 2.0, an offer/answer exchange allows the
> > server to learn the client desires a new session.  With that
> > knowledge, the server can communicate more specific information
> > to its firewall about the client's IP address; in this way, the
> > firewall doens't need to necessarily permit incoming IKE packets
> > from arbitrary remote addresses, unless those are first signaled
> > with SIP or RTSP.  This model is also used by HIP and EME, two
> > working groups in the IRTF (www.irtf.org).  This is what I would
> > consider 'solicited traffic'.
> 
> I'm not sure if this distinction matters that much from the security 
> perspective.  IMHO the main point is the attack vector and effect. 
> Even though SIP and RTSP 2.0 were offer/answer protocols, the main 
> point is that there needs to be a service listening (to the whole 
> world) on some ports, the same as with IKE.  You're just shifting the 
> attack vector from IKE to SIP/RTSP 2.0 which in and of itself doesn't 
> help anything; in fact it could make the situation worse, given that 
> (AFAIK) the SIP/RTSP 2.0 protocol suite is more complicated than IKE.
> 
> The critical question then is, how much (and how complex) code in the 
> listening service is required to make a decision whether to drop the 
> new session or allow it to be established.  In other words, if a 
> vulnerability is found in the listening service software, can it be 
> exploited by unauthenticated/unauthorized attackers and can 
> it be used 
> for compromise (e.g., remote code execution)?  (I exclude DoS 
> vulnerabilities from the interesting ones in this context.)
> 
> This also affects protocol design, i.e., the protocols should be 
> designed so that the amount and complexity of code needed to drop 
> uninteresting connection requests can be minimal.
> 
> There have been security vulnerabilities in both IKE and SIP protocol 
> suites, but I do not recall outright whether such have enabled 
> unauthenticated remote code execution exploits.  If such were to be 
> the case, or such vulnerabilities would have a high likelihood of 
> succeeding, I'd think that most security administrators would want to 
> filter out both IKE and SIP/RTSP 2.0.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings