Subject: Re: [homenet] [v6ops] default LAN routing protocol for IPv6 CE router

From: Shane Amante <[email-masked]>
Date: Tue, 2 Aug 2011 19:20:37 -0600

On Aug 2, 2011, at 5:08 PM, Brzozowski, John wrote:
> On 8/2/11 8:28 AM, "Keith Moore" <[email-masked]> wrote:
>> On Aug 2, 2011, at 4:22 AM, Philip Homburg wrote:
>> 
>>> How do you construct a router such that the router always knows what it
>>> has to do, or at least is in some sense fail-safe?
>> 
>> 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.

So, I agree with this point, but are we constraining our thinking too early?  For example, if the assumption is there is a singular CPE-router/FW that has been allocated a /56 from a provider, then:
- why couldn't the FW provide 'stateful firewall' service for the first 'covering' /60 of IPv6 prefixes (/64's) allocated within the house;
- but, the CPE-router/FW would /NOT/ provide stateful or stateless firewall for the remaining 7/8's of address space allocated within the house.

Of course, just change the 'mask' lengths to represent whatever the WG thinks are 'sensible' defaults.

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

-shane

>> 
>> A different idea is that the firewall always work in a very minimal mode
>> by default (e.g. it passes no traffic, or maybe only outgoing port 80
>> traffic, but its configuration interface is enabled for the internal
>> ports) so that the user must configure it in order to get it to do
>> anything useful.  That way, the first thing a user learns about his
>> router/firewall is how to configure it.  Then you want to focus on making
>> the configuration interface easy to understand.  (You also have to figure
>> out how to keep the user from hooking up the internal port to the
>> external connection.)
> [jjmb] I said something similar to this is in an earlier email.  To the
> start there should perhaps be a basic configuration that protects the user
> and allows the service to be usable.
>> 
>> But these are user interface issues, not protocol issues.   Perhaps
>> they're better addressed in homenet than here.
> [jjmb] I could image some protocol work that could ease the pain here, UI
> for sure could facilitate ease of use.
>> 
>> Keith
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 2 Aug 2011 21:42:40 -0400

Please see below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
> 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.

-shane

SC>  Agree. I would like to see more openness in the design of 'future home network' where in the future we might need to do more auto-configuration; the networks and devices might be such that they would be more lightweight and suitable for address auto-configuration than today's DCHP only home-network - though DHCP(v6) support would be absolutely needed for backward compatibility. But constraining homenet into DHCP-only network will limit the applicability of new type of networks, topologies, devices and services etc.

-Samita

>> 
>> A different idea is that the firewall always work in a very minimal 
>> mode by default (e.g. it passes no traffic, or maybe only outgoing 
>> port 80 traffic, but its configuration interface is enabled for the 
>> internal
>> router/firewall is how to configure it.  Then you want to focus on 
>> making the configuration interface easy to understand.  (You also 
>> have to figure out how to keep the user from hooking up the internal 
>> port to the external connection.)
> [jjmb] I said something similar to this is in an earlier email.  To 
> the start there should perhaps be a basic configuration that protects 
> the user and allows the service to be usable.
>> 
> [jjmb] I could image some protocol work that could ease the pain here, 
> UI for sure could facilitate ease of use.
>> 
>> Keith
>> 

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 3 Aug 2011 01:45:12 +0000

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.

John
On 8/2/11 9:20 PM, "Shane Amante" <[email-masked]> wrote:

>So, I agree with this point, but are we constraining our thinking too
>early?  For example, if the assumption is there is a singular
>CPE-router/FW that has been allocated a /56 from a provider, then:
>- why couldn't the FW provide 'stateful firewall' service for the first
>'covering' /60 of IPv6 prefixes (/64's) allocated within the house;
>- but, the CPE-router/FW would /NOT/ provide stateful or stateless
>firewall for the remaining 7/8's of address space allocated within the
>house.
>
>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 ...
>
>-shane
>
>
>
>
>
>>> 
>>>mode
>>>making

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 3 Aug 2011 01:47:11 +0000

The use of DHCPv6 is a constraint?  It is just another option, which is
also dynamic, in my opinion.

On 8/2/11 9:42 PM, "Samita Chakrabarti" <[email-masked]>
wrote:

>SC>  Agree. I would like to see more openness in the design of 'future
>home network' where in the future we might need to do more
>auto-configuration; the networks and devices might be such that they
>would be more lightweight and suitable for address auto-configuration
>than today's DCHP only home-network - though DHCP(v6) support would be
>absolutely needed for backward compatibility. But constraining homenet
>into DHCP-only network will limit the applicability of new type of
>networks, topologies, devices and services etc.
>
>-Samita
>
>
>
>
>
>
>
>
>>>

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 2 Aug 2011 23:08:55 +0000

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 3 Aug 2011 15:16:17 -0400

> The use of DHCPv6 is a constraint?  It is just another option, which is also dynamic, in my opinion.

DHCP PD will work too in multi-router case but there might be limitation in case of multi-homing.
Another option to explore is stateless address auto-configuration using Neighbor Discovery during the startup process.

-Samita

On 8/2/11 9:42 PM, "Samita Chakrabarti" <[email-masked]>
wrote:

>'dynamically' request from the CPE-router/FW via, say, DHCPv6 or if 
>there are better options ...
>
>-shane
>
>
>> [jjmb] I could image some protocol work that could ease the pain 
>> here, UI for sure could facilitate ease of use.
>>> 
>>> Keith
>>>

---

From: Wouter Cloetens <[email-masked]>
Date: Wed, 03 Aug 2011 23:02:42 +0200

On 03/08/11 03:45, Brzozowski, John wrote:
> On 8/2/11 9:20 PM, "Shane Amante"<[email-masked]>  wrote:
>>> On 8/2/11 8:28 AM, "Keith Moore"<[email-masked]>  wrote:
>>> [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.

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

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

---

From: james woodyatt <[email-masked]>
Date: Wed, 03 Aug 2011 15:04:45 -0700

On Aug 3, 2011, at 14:02 , Wouter Cloetens wrote:
> 
> My take on firewalls is that devices, or more precisely software installed on devices, must request for services to be opened.

My take on home gateway firewalls, not surprisingly, is documented in RFC 6092, which is referenced specifically in the HOMENET working group charter.

The short summary of my position on this question is that unmanaged firewalls, as the ones in many home gateways necessarily will be, MUST NOT be deployed routinely in a way that makes it impractical to implement more managed end-to-end network security protocols.  I really feel quite strongly about that, and if necessary I will put on the asbestos suit and reprise my role in the IETF flame wars that led to the drafting of the rather nuanced language we finally achieved in RFC 6092.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 4 Aug 2011 05:17:36 +0000

I generally agree with your comments below including the reference to UPnP.