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