[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BEHAVE] RE: Firewall control
On Nov 16, 2007, at 07:34, Melinda Shore wrote:
On 11/16/07 10:27 AM, "Rémi Denis-Courmont" <remi.denis-
courmont@nokia.com> wrote:
Uh? UPnP is about mapping external ports to internal ones, and
getting the
external address of the middlebox. Now, if that's not NAT centric...
The last time I looked at it it also included firewall pinholing.
There are hints that UPnP IGD 2.0 may support firewall pinholing in
IPv6 whenever it's eventually published. I have seen no public
documents yet, but I would be very surprised if this feature is
inserted into the specification by any method beyond the
straightforward method of extended the XML schemas to allow IPv6
addresses and, possibly, to note that no NAT is necessary.
A firewall that has an "advanced" policy such as what you'll find
in a typical
corporate network most certainly does not want to be controlled
anyway.
Back when we were trying to figure out what to call this work there
was a strong "suggestion" from Scott Bradner to call it "middlebox
communication" because we didn't want to imply that the endpoint or
its proxy was actually going to be controlling anything. The problem
here isn't to allow applications to open pinholes on firewalls, but
rather for applications to request these network resources, give the
network/firewall sufficient information to say "yes" or "no," and
give the network a mechanism to communicate its decision back to the
endpoint.
I'd like to point out that my ALD proposal is very deliberately
presented with an inverted perspective on this. The problem I tried
to address is to give the stateful firewall a chance to discover
application endpoint addresses that policy requires it to exempt from
the general prohibition on blocking incoming packets not conforming
to any existing state created by tracking the flow of outbound packets.
ALD is absolutely *NOT* a mechanism for applications to "control"
firewalls, or even to "request" firewalls to open pinholes for them.
It is a mechanism for firewalls to discover application listeners, so
that incoming flows for those applications can be delivered to them
properly, even when applications don't know in advance where those
flows will originate. Notice that ALD notifications go from nodes to
firewalls, and acknowledgements are sent by firewalls solely for the
purpose of telling nodes to stop sending notification retries. No
information is provided by firewalls to applications beyond that.
This is quite intentional.
I think firewalls should be as transparent as possible, except when
policy requires them to intervene.
In my humble opinion, ALD's primary virtue is that it correctly
places the burden on the firewall not to destroy network transparency
unnecessarily. To that end, it aims to define a way for IPv6 node
implementations to provide firewalls with enough information to
behave transparently in the face of passive listening applications.
It does not try to inform applications of the state of firewalls in
the network.
We all still think applications shouldn't have to care, right?
I also think it's worth noting that any proposal for nodes/
applications to communicate with firewalls to solve these sorts of
problems will inevitably involve disclosing the addresses of
application passive listener endpoints when their users may not be
expecting it. I don't know how to prevent that from happening and
still comply with the recommendations described in RFC 4864 and
expanded in draft-ietf-v6ops-cpe-simple-security, but I don't think
many participants here think this is a sensible security
consideration. Furthermore, I suspect many network operators will be
very interested in mining the information stream produced by
protocols of this class.
This is another virtue of ALD. It gives operators the potential for
some snooping goodness they can't get with current IPv6
implementations, and it does so *without* larding their firewalls
down with a lot of extra work trying to inform applications of things
they shouldn't need to know.
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering