RE: [BEHAVE] RE: Firewall control

["Hesham Soliman" <Hesham@elevatemobile.com>]

 > > 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
 >