On 03/08/11 03:45, Brzozowski, John wrote:
On 8/2/11 9:20 PM, "Shane Amante"<[email protected]> wrote:
On Aug 2, 2011, at 5:08 PM, Brzozowski, John wrote:
On 8/2/11 8:28 AM, "Keith Moore"<[email protected]> wrote:
On Aug 2, 2011, at 4:22 AM, Philip Homburg wrote:
The idea that a firewall should automatically know what "it has to do"
strikes me as utterly bizarre. I realize that there's a desire to
minimize the configuration burden for unsophisticated users (and agree
with that), but the idea that the firewall knows better than the user
what his security policy should be seems ridiculous.
[jjmb] I agree Keith that having a firewall automatically know
what to do is a tall order. I also think the is more than a
desire to ease configuration burden, this is a must since most
users on the Internet have very basic technical skills.
[...]
My take on firewalls is that devices, or more precisely software
installed on devices, must request for services to be opened. UPnP IGDv2
is capable of doing this today for IPv6, just as UPnP IGDv1 does it for
IPv4.
I see no other way to make firewalling scalable (working for every
service at every hop), sturdy (not fall over due to misconfiguration),
and working without user interaction.
And, we'd need to decide if this is something a device in the home can
'dynamically' request from the CPE-router/FW via, say, DHCPv6 or if there
are better options ...
Another interesting scenario where part of a delegated is interested
or required to be firewalled while others not. I do not think we are
limited ourselves. I think advanced users will still have the ability
to do as they please and we are making sure not so advanced are not
unknowingly exposed.
As I mentioned earlier, I think there may be an opportunity for some
protocol development in this space.
I'm not a big fan of the UPnP protocol, but it already fills some of
this space. Others could be considered, e.g. PCP.
My take on this, and every single technical element in the scope of
homenet's problem space, is that the challenge is symmetry: to make
every protocol and delegation work upstream and downstream from every
router.
I would bet that every CPE router will contain a firewall. All available
IPv4 CPE routers today do, and my customers all require the same for IPv6.
UPnP IGDv2 (or another protocol) can be extended to allow opening all
ports in all protocols for a prefix that is delegated to a downstream
router, (or announced by a downstream router or whatever).
So, thinking about our "tall order" here...
Scenario 1: the downstream router implements its own firewall. The
upstream router's firewall allows all traffic from and to that router to
pass through, assuming the downstream router will handle it.
Scenario 2: the downstream router does not implement its own firewall,
or is not aware that the upstream router already implements a firewall,
and relays firewall service requests to the upstream router.
Scenario 3: the downstream router implements its own firewall. The
upstream router's firewall, by policy, denies all traffic from and to
that router, or, in the more likely SPI case, denies all new connections
to that router's prefix. The downstream router must not only serve
requests by hosts on its own downstream interface, but relay those
requests to the upstream router.
Scenario 3a: same as 3, but the downstream router starts by requesting
to allow all traffic to and from its prefix to release the upstream
router of the burden of firewalling, like in scenario 1.
... and more scenarios imaginable.
Upstream and downstream capability detection is one challenge, so the
right behaviour for the right scenario can be picked.
All of this must be subject to override by policies set by the user or
the provider. That's another challenge; the user must be able to
determine at what level which policy makes his application fail.
It all has to be secure. You don't want a malware agent to be able to
pose as a downstream CPE router and punching a /64-size (or bigger) hole
in the firewall.
bfn, Wouter
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
