[ipv6hackers] Requirements for IPv6 firewalls (new IETF-ID)

Fri Feb 21 20:18:55 CET 2014

A few additional minor things came to mind:

Req DoS-2:  If this is a requirement, it should probably be explicit about
what attacks are included in the specification, unless you intend to say
"*all* ip6 resource exhaustion attacks," which is probably too onerous a
requirement.  In addition to fragment flooding, we might want to explicitly
require protection against neighbor cache exhaustion/brute force scanning
(e.g., if the firewall sees more than several hundred (configurable)
connection attempts (which pass other rules, hence are allowed) from a
single host to a single /64 that all fail (i.e., no response), it should
raise an alarm/log/or dynamically block the source of those packets. This
might be a SHOULD/MAY as it is a bit tricky.

Should we include a requirement for enforcing multicast scope boundaries in
packets, or is this implicit?

This is more a local-router or switch requirement, so may be out of scope,
but since many firewalls at small deployments are also the local router,
maybe something about RA-spoofing detection might be useful to include as a
"SHOULD" or "MAY."  I.e., if the firewall is acting as the default gateway,
other hosts sending RAs should be logged or blocked; AND/OR the firewall
should have a configuration option to specify the legitimate routers on the
attached segments, and RAs from any other hosts should be logged or
blocked.  Just a thought, but I understand this might be beyond the scope.

Cheers,
Jake Czyz
https://www.linkedin.com/in/jakeczyz

On Fri, Feb 21, 2014 at 1:07 PM, JJC <jjc4progress at gmail.com> wrote:

> Fernando,
>
> Thanks for your efforts on this (and all your nice IPv6 work).  Here are a
> few suggestions/comments/typos:
>
> Rule Additions:
> 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. :-)
>
> Cheers,
> Jake Czyz
> https://www.linkedin.com/in/jakeczyz
>
>
>
>
>
>
>
>
>
>
> On Wed, Feb 19, 2014 at 12:28 AM, Fernando Gont <fgont at si6networks.com>wrote:
>
>> Folks,
>>
>> We have published a new I-D on "Requirements for IPv6 Firewalls"
>>
>> The I-D is available at:
>> <http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00>
>>
>> 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. :-)
>>
>> Thanks!
>>
>> Best regards,
>> Fernando
>>
>>
>>
>>
>> -------- 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
>> draft-gont-opsec-ipv6-firewall-reqs-00.txt
>> 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
>> URL:
>>
>> http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-firewall-reqs-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/
>> Htmlized:
>> http://tools.ietf.org/html/draft-gont-opsec-ipv6-firewall-reqs-00
>>
>>
>> Abstract:
>>    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
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> Ipv6hackers mailing list
>> Ipv6hackers at lists.si6networks.com
>> http://lists.si6networks.com/listinfo/ipv6hackers
>>
>
>