> -----Original Message----- > From: Aki Niemi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 1:10 AM > To: [email protected] > Subject: On firewall traversal vs. bypass >
> Continuing on something heard at the technical plenary last week. > There were people complaining that while protocols like STUN/TURN > and ICE are traversing NAT, they are in fact bypassing firewall > policies, which they should not be doing. > > I think it should be noted that ICE [1] does *not* circumvent the > typical firewall policies. The default policy of a stateful firewall > tends to be "keep unsolicited traffic out". > > Now, the problem is that applications like VoIP or video chats > generally follow this policy in theory -- after all, a VoIP call, if > accepted, is solicited traffic -- but they do not follow it in > practice. Specifically, the media sessions can't punch the necessary > holes into stateful firewalls, and just generally are poor at > managing the transport flows they use (for instance, checking > whether a certain flow actually works before attempting to use it). > > ICE remedies this, by modifying the on-the-wire behavior of these > application protocols so that they match not only the intent but > also the letter of the stateful firewall policy. Whether this > happens as a side-effect of an ICE-like procedure, or via explicit > firewall control is a matter of taste, but we also have to keep in > mind that the deployment models for these differ considerably. While > the first only requires changes to endpoints, the latter requires > ubiquitous deployment to middleboxes to become a *full* solution to > the problem. > > Needless to say, I opt for the first, and consider the latter an > optimization. Here is one way to do the first, http://tools.ietf.org/id/draft-wing-session-auth-00.txt (currently expired). -d > Cheers, > Aki > > [1] http://tools.ietf.org/id/draft-ietf-mmusic-ice > > _______________________________________________ > Ietf mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ietf
