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

From: Pekka Savola <[email-masked]>
Date: Wed, 1 Aug 2007 08:04:59 +0300 (EEST)

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jul 2007 22:33:41 -0700

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:[email-masked]] 
> 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
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Aug 2007 00:03:36 -0700

> From: Dan Wing [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2007 10:34 PM
> To: 'Pekka Savola'
> Cc: 'IPv6 Operations'; 'Behave WG'

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

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. They may also
keep their address "hidden", so as to not receive traffic.

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. 

-- Christian Huitema

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Aug 2007 16:26:18 -0700

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

> 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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Aug 2007 10:01:38 +0300 (EEST)

On Mon, 6 Aug 2007, [email-masked] wrote:
> Some low-speed radio links might need to be protected.
...
> Whether it is a good or bad business model, it is a matter of
> fact that some operators charge their users per-bit or
> per-packet, and it seems like IPv6 will not bring a change
> here.

I think this is what the argument boils down to.  I.e., which 
mechanisms are applicable on low-speed radio links vs everywhere else.

I'd argue that because low-speed radio links already need to implement 
lots and lots of other protocol unpleasantry (I'd call it 'junk'), the 
scenario is not very interesting from a generic host perspective.

Maybe the best would be to recognize the (at least) two different 
scenarios and consider applicable solutions separately.