[ipv6hackers] Requirements for IPv6 firewalls (new IETF-ID)
jjc4progress at gmail.com
Fri Feb 21 19:07:02 CET 2014
Thanks for your efforts on this (and all your nice IPv6 work). Here are a
1) Given the idea that, as you know, IPv6 fragments (as standardized) are
very dangerous security-wise and the (admittedly controversial) effort to
deprecate them entirely (
http://tools.ietf.org/html/draft-bonica-6man-frag-deprecate-02 ), it might
be useful to have a requirement such as:
MUST be able to filter (drop or log) all IPv6 fragments.
Maybe also: SHOULD be able to filter (drop or log) atomic IPv6 fragments,
and too-small IPv6 fragments.
2) Related to the above, it's unclear if REQ SPC-2 also implies ability to
filter other (non-Routing) extension headers. This ability seems
relatively useful, and a new requirement for it should probably be included.
3) To REQ CON-2, I would add:
8. currently logged in users
9. your last login timestamp and IP
10. last other user login name, timestamp, IP
11. Count of failed login attempts since last user login (for awareness of
brute force attempts).
4) It's not clear if REQ CON-2 lists the minimum items that "MUST" be
included in a dashboard, or merely that the dashboard must include "health
monitoring information," of which the items are just OPTIONAL examples.
5) This may be implied or common sense to firewall vendors, but making them
explicit in the RFC might be useful:
* MUST Maintain counters for each firewall rule, including how many packets
(and optionally, how many bytes) triggered each rule.
* SHOULD (or MUST?) for each rule store and display the timestamp of last
change and the userid of who changed it.
6) An ssh-key-only mode:
SHOULD support an SSH-key-only login mode (analogous to OpenSSH
"PasswordAuthentication No" setting. As this raises security considerably
on the device itself.
7) Ability to apply a separate rule set on the administrative interface of
the device itself. (Again, probably common, but good to codify).
Comment on Section 8:
A Layer-7 firewall, with its DPI and complexity, and the attendant higher
hardware requirements appear, to me, to be a separate class of hardware
than normal Layer 2-4 firewalls. Thus, does it make sense to include these
requirements (sec. 8) in this document and expect the majority of firewall
vendors to make their basic firewalls "fully-compliant" with this RFC? It
seems that it might be useful to either make these "SHOULDS" or have a
separate document for application layer firewalls.
Minor typos (in sed/vim style):
* Global: s/e.g. /e.g.,/g
* In Abstract and Introduction: s/, and the reduced/and the reduced/
* In Introduction: s/provide a ser /provide a series/
* In REQ GSOC-6: s/SHOULD possible to have/SHOULD be possible to include/
* In REQ CON-2: s/must/MUST/
Thanks again for your good work on this and other IPv6 security matters!
I'm an avid reader. I hope some of these are useful comments.
By the way, if it's a possibility, I would love to be a co-author on this
RFC, as it closely relates to my research. :-)
On Wed, Feb 19, 2014 at 12:28 AM, Fernando Gont <fgont at si6networks.com>wrote:
> 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
> 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. :-)
> Best regards,
> -------- Original Message --------
> From: internet-drafts at ietf.org
> To: Will Liu <liushucheng at huawei.com>, "Shucheng LIU (Will)"
> <liushucheng at huawei.com>, Fernando Gont <fgont at si6networks.com>,
> "Fernando Gont" <fgont at si6networks.com>, Marco Ermini
> <marco.ermini at resmed.com>, "Marco Ermini" <marco.ermini at resmed.com>
> Subject: New Version Notification for
> Date: Fri, 14 Feb 2014 16:00:33 -0800
> A new version of I-D, draft-gont-opsec-ipv6-firewall-reqs-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> Name: draft-gont-opsec-ipv6-firewall-reqs
> Revision: 00
> Title: Requirements for IPv6 Firewalls
> Document date: 2014-02-15
> Group: Individual Submission
> Pages: 12
> While there are a large number of documents discussing IP and IPv6
> packet filtering, requirements for IPv6 firewalls have never been
> specified in the RFC series. When it comes to IPv6, the more limited
> experience with the protocols, and reduced variety of products has
> made it rather difficult to specify what are reasonable features to
> be expected from an IPv6 firewall. This has typically been a problem
> for network operators, who typically have to produce a "Request for
> Proposal" (from scratch) that describes such features. This document
> specifies a set of requirements for IPv6 firewalls, marked as
> "mandatory", "recommended", or "optional".
> Please note that it may take a couple of minutes from the time of
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF Secretariat
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
More information about the Ipv6hackers