[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