Subject: On firewall traversal vs. bypass

From: Aki Niemi <[email-masked]>
Date: Tue, 31 Jul 2007 11:09:34 +0300

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.

Cheers,
Aki

[1] http://tools.ietf.org/id/draft-ietf-mmusic-ice

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Melinda Shore <[email-masked]>
Date: Tue, 31 Jul 2007 08:11:14 -0400

> traversing NAT, they are in fact bypassing firewall policies, which they

I think it's more complicated than that.
1) there were complaints about the difficulties caused
   specifically by firewalls (apart from NATs)
2) Eric said that the IETF is producing firewall traversal
   protocols like ICE
3) I pointed out that ICE is a NAT traversal protocol, not
   a firewall traversal protocol, and that a key functional
   difference is that NATs don't really do policy (beyond
   address policy) while firewalls are specifically policy
   devices.

Where I think we differ is in what we think firewalls ought
to do.  While the default policy of a residential firewall
probably should be something along the lines of "keep
unsolicited traffic out," enterprise policies tend to be and
should be a lot richer.

STUN and ICE effectively work by side-effect, creating NAT
table mappings simply by passing data across the NAT.  In the
firewall case you really must allow the firewall the possibility
to say "no," and you should give the firewall the data it
needs to make an informed decision.  That data might include
application identification, user credentials - whatever
information is used as the basis for a policy decision.  It's
also nice if you're able to tell the application that its
request has been denied so that it can fail and/or recover
gracefully.  

I also think the assumption that any media flows across a
firewall ought to be allowed is questionable, but that's a
somewhat different matter.

Melinda

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Jul 2007 11:47:26 -0700

> -----Original Message-----
> From: Aki Niemi [mailto:[email-masked]] 
> Sent: Tuesday, July 31, 2007 1:10 AM
> To: [email-masked]
> 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.
>
> 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).
>
> 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.
>

Here is one way to do the first,
http://tools.ietf.org/id/draft-wing-session-auth-00.txt
(currently expired).

-d