Subject: RE: [BEHAVE] RE: Firewall control

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 17 Nov 2007 11:19:23 +1000

> > 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.
 > 
 > What you describe as a "stateful" firewall actually behaves rather
 > like a NAT, and as you imply is missing a more granular policy
 > component.

=> I agree with this analysis but I don't think there is an issue with
missing policies. By decoupling the policy entity from the firewall you let
that decision be made in the PDP and simply gets "told" to the FW. There are
many architectures, especially in cellular networks, where this model makes
a lot of sense, especially when you consider that all the knowledge needed
to authorise the pinhhole is known at the PDP. 
I think the trickiest part with something like this is building the right
APIs for applications to make such requests. I guess that's what you are
saying above and I agree with that. But of course this is not the only
scenario where such API is needed, QoS signaling is another example where
this is needed. 

Hesham

 > Melinda

---

From: james woodyatt <[email-masked]>
Date: Tue, 20 Nov 2007 14:18:05 -0800

On Nov 16, 2007, at 07:34, Melinda Shore wrote:
> On 11/16/07 10:27 AM, "Rémi Denis-Courmont" <remi.denis- 
> [email-masked]> 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.
>

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 <[email-masked]>
member of technical staff, communications engineering