Whilst I don't disagree significantly with Fred's list (which seems to
match the functionality of the installed IPv4 base), I think the
challenge for Homenet is going to be to make this requirements list work
in a multi-vendor environment out of the shrink wrap (Homenet
architecture by definition assumes more than one CPE device). To me,
ensuring interoperability is the main added value of the Homenet WG.
I therefore humbly submit that language based on "MAY" is generally not
going to cut it for Homenet.
Here are my suggested modifications of Fred's list, for further improvement.
1) s/a CPE Router MAY include a firewall function/a Customer Edge Router
(CER) SHOULD implement a mechanism to facilitate egress and ingress
access control of traffic crossing the external border of the Homenet.
This MAY be implemented either as a firewall or as simple IPv6 Access
Control List (ACL)./
ACL being debatable, but it's functionality that exists today in IPv4
and which works. Who am I to say that isn't "good enough" for some
folks' security needs? As an end-user, I'm all for functional
equivalence with IPv4.
2) For me it's debatable whether the Homenet WG needs to further define
how this egress or ingress control functionality actually processes
traffic. That's something IMHO where vendors can differentiate their
products, and which can evolve over time.
Perhaps:
/The firewall MAY be functionally defined by
draft-ietf-v6ops-cpe-simple-security or
draft-vyncke-advanced-ipv6-security-03. Other functional definitions of
the ingress and egress access control mechanism may be introduced to
Homenet later. As a general principle, equivalent security controls
SHOULD be applied to both IPv4 and IPv6 traffic when running in dual
stack mode at the external boundary./
3) s/IF such a function is implemented, it MUST be possible to disable
it, reducing the CPE to a simple router./
It MUST be possible to disable the ingress and egress access control
function to reduce the CER to a simple router, and the mechanism to
achieve this SHOULD ...../
In this case, "be manual" or do you want the device to "auto-detect that
the device is acting as a CER"?
I think this is pretty essential for ensuring that Homenet works as a
system when users plug and play kit from various vendors.
Perhaps the detail is best left for another day.
4) s/IF it is a "deny all" firewall, it SHOULD have a means of providing
access rules for services inside the home/
IF it is a "deny all" ingress mechanism, it SHOULD have a means of
providing access rules for services located inside the home, and the
mechanism to achieve this SHOULD be ...../
"PCP"?
If PCP isn't considered by the WG to be "good enough" for the task of
acting as the Homenet control protocol for the ingress and egress
security function, then I submit that the challenge is either going to
be to make PCP "good enough", or come up with an alternative. I am
neutral on what the control protocol should be. But there's no doubt in
my mind that we really should define an open and standard control
protocol to configure the ingress and egress access control mechanism
(to ensure interoperability, to preserve e2e, and to ensure the sanity
of developers and end users).
regards,
RayH
Fred Baker wrote:
On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote:
My cursory research says you are not going to be able to present a convincing
amount of data to support the fact that a stateful
inspection firewall should be applied in a contemporary home environment.
I don't recall anyone saying that a "stateful inspection" firewall was specifically called for. I
think we argued that there is a market expectation that a firewall is at least available, and that however
the firewall is implemented, it should prevent simple attacks from "outside" the network (I will
argue "network layer attacks" as opposed to combing through bits in layers above). As we get into
the specifics of kinds of firewalls, I think we're treading even more heavily on people's religion.
As to "kinds of firewalls", I have a posted draft (which I think I mentioned),
which might be discussed in opsawg and might be discussed in the Security Area meeting. I
haven't heard a decision on that. I would suggest we defer to that discussion. However,
as far as *this* draft goes, I think that it is fair to say that
- a CPE Router MAY include a firewall function.
- IF such a function is implemented, it MUST be possible to disable
it, reducing the CPE to a simple router.
(my rule on the use of "MUST": I use the term when failing to
do so breaks something, and I try to say what breaks. In this
case, a CPE Router that has a firewall that can't be turned off
cannot be used as an interior router in the home network)
- IF it is a "deny all" firewall, it SHOULD have a means of providing
access rules for services inside the home, such as allowing SMTP
to an SMTP server or ISP access to a set-top box. PCP or other
protocols like it MAY be used to achieve that.
- IF it is a role-based firewall, it SHOULD have a means of
configuring and using roles.
- IF it is a stateful inspection, reputation-based, or anomaly
detection firewall, it SHOULD have a way to maintain the indicated
tables such as periodic download of signed files from a trusted
site.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
