[ipv6hackers] Requirements for IPv6 firewalls (new IETF-ID)
carsten.schmoll at fokus.fraunhofer.de
Wed Feb 19 18:04:52 CET 2014
Dear Fernando, authors of this I-D,
thanks for pushing this (IMO) worthwhile topic forward.
The more we see IPv6 availability for the end user at home, the more important is it that the CPE router/gateway/firewalls, aka "plastic routers", will provide an (at least) on-par-security for IPv6, compared to IPv4.
With such a document, CPE makers can have a valuable checklist in their hands - and go at least for the "conditionally-compliant" feature set.
My gut feeling is that such document should aim "a little higher" than providing parity with IPv4 firewall features. IMO this is especially true for the DoS section (chapter 7), since more attack vectors exist with IPv6 (or so it feels to me).
two small ideas:
* If deemed as useful, the document should clearly state the importance of (the NAT-less yet) stateful PF with IPv6, and maybe some details of it.
* If suitable for this I-D, some words could be added on privacy issues with IPv6 and how an IPv6-FW could help (or not) with that.
From: ipv6hackers-bounces at lists.si6networks.com [mailto:ipv6hackers-bounces at lists.si6networks.com] On Behalf Of Fernando Gont
Sent: Wednesday, February 19, 2014 6:28 AM
To: IPv6 Hackers Mailing List
Subject: [ipv6hackers] Requirements for IPv6 firewalls (new IETF-ID)
We have published a new I-D on "Requirements for IPv6 Firewalls"
The I-D is available at:
The goals of this first (and drafty) version of the document are as follows:
1) Agree on a rationale to write this spec.
For example, one possible rationale is "aim at providing parity of features with IPv4". Another one could be that "should should aim a little higher". For example, in the light of draft-farrell-perpass-attack we may aim at requiring some privacy features that might not be that common in IPv4 firewalls.
2) Expose different aspects of firewalls that we may want to standardize.
High-level feedback along the lines of "this other aspect is missing, and should be added" or "we probably should not address this or that other aspect" are very valuable.
3) Discussion of concrete requirements.
Here the feedback would be in the form of "This or that requirement is missing", "this or that requirement doesn't make sense and should be eliminated", etc. And for each of those that we keep in, arguments in favor of "mandatory", "recommended", or "optional" (i.e., what the level of each requirement should be).
It would be great if you could post any feedback on the opsec wg mailing-list (Instructions here: <>). BUt in any case feel free to discuss this document on this list (ipv6hackers) or send your feedback to all the co-authors at:
<draft-gont-opsec-ipv6-firewall-reqs at tools.ietf.org>.
P.S.: Regardless of what we end up doing with this I-D, etc., I think the brainstorming would be fruitful. :-)
More information about the Ipv6hackers