[fi-rg] FI-RG current document #1

[Melinda Shore]

On 5/29/06 7:40 AM, "Ralph Niederberger" <r.niederberger at fz-juelich.de>
wrote:
> Until now I did not get any additional contributions.

I have to apologize for coming in late, not attending any
meetings, not participating in the mailing list until
recently, yet having opinions anyway.

By way of introduction and context, I work on firewall
traversal issues at Cisco and chair the IETF midcom working
group.  I formerly chaired the ETSI Project TIPHON
security working group, and some of what we did there was
spun off to the IETF and eventually became midcom.

This is a very impressive document overall and I hope that
it eventually could be reformatted and submitted to other
fora, including the IETF, but I do have some questions about
some of the text.

One of those questions is about the use of the word "transparent"
to describe NAT.  I think that in the simplest case (a user
behind a NAT initiating a single simple message) it could be
considered to be transparent, but one of the unfortunate design
problems in IP is that identity is overloaded on addresses and
so even in the simpler cases transparency can become a problem
when relying on addresses for identity information (which is
unfortunately common).  For example, a firewall outside of a
NAT isn't going to be able to do much discrimination, or rather
the discrimination is not going to be very granular.

We don't like to consider NAT a security mechanism because it
isn't really applying policy in a meaningful sense of the word.
However, it unquestionably introduces difficult traversal problems
and because deployment tends to be architecturally similar to
firewall deployment it's useful to consider both NAT and firewall
traversal together.

In the discussion of ALGs, ALGs are actually commonly used for
both firewall and NAT traversal, although in the former case
they're used to open pinholes and in the latter case they're
used to do payload address rewrites.  We have two major problems
with them: 1) they compromise application security by forcing
traffic to be sent in the clear and in the case of NAT payload
rewrites by breaking message authentication, and 2) they
force firewall vendors to support a bunch of application
protocol stacks on their firewalls, which is expensive and
increases exposure to implementation errors.

Another firewall/NAT traversal technology that's seeing fairly
wide deployment in IP telephony is the Session Border Controller.
It's basically just a proxy, but it performs an access mediation
role by making relaying decisions based on policy it receives from
a call control server.  In that sense it's sort of a hybrid
between a relay and a decomposed application layer firewall.

I think section 5 is extremely important, and I hope that this
can be brought to the IETF security area.  There's been some
recent interest in starting up a new work item/working group
around "distributed security" but it is as yet fairly poorly
scoped and foundering a bit, and the work being done here might be
useful to them in refocusing.

Melinda