Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt
"Smith, Donald" <Donald.Smith@CenturyLink.com> Tue, 18 February 2014 23:42 UTC
Return-Path: <Donald.Smith@CenturyLink.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5681A02BB for <opsec@ietfa.amsl.com>; Tue, 18 Feb 2014 15:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE3QogWaiAiV for <opsec@ietfa.amsl.com>; Tue, 18 Feb 2014 15:42:55 -0800 (PST)
Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF901A0106 for <opsec@ietf.org>; Tue, 18 Feb 2014 15:42:55 -0800 (PST)
Received: from lxomavmpc030.qintra.com (emailout.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s1INgl8D000942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 16:42:47 -0700 (MST)
Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 417EC1E006F; Tue, 18 Feb 2014 17:42:42 -0600 (CST)
Received: from sudnp796.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 122AE1E0049; Tue, 18 Feb 2014 17:42:42 -0600 (CST)
Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1INdUrY026352; Tue, 18 Feb 2014 16:39:30 -0700 (MST)
Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s1INdUHB026338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:39:30 -0700 (MST)
Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 16:39:30 -0700
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: Marco Ermini <Marco.Ermini@ResMed.com>, "opsec@ietf.org" <opsec@ietf.org>
Thread-Topic: I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt
Thread-Index: Ac8suawmwS2WEn1STli9AEMChgEPqAAQEsj4
Date: Tue, 18 Feb 2014 23:39:29 +0000
Message-ID: <68EFACB32CF4464298EA2779B058889D123C146D@PDDCWMBXEX503.ctl.intranet>
References: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org>
In-Reply-To: <38465846B6383D4A8688C0A13971900C469B76AA@GE2EML2K1003.corp.resmed.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.119.128.7]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/keyVzhkch6kCp1WrA4WuV0e_zTI
Cc: "fgont@si6networks.com" <fgont@si6networks.com>
Subject: Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 23:42:59 -0000
Just a nit initially. "This document specifies a set of requirements for IPv6 firewalls, marked as "mandatory", "recommended", or "optional"." That isn't the language we use. In fact in terminology Mr Gont uses the right language. " 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]." This is hard very hard I don't know of a single v4 firewall that can do full proxies for all tcp applications. REQ GEN-3: MUST support full-proxy for the TCP [RFC0793] connections (the handshake is validated on the firewall before reaching the target system). I think what you want is proxies for common layer 7 protocols (like http, ftp etc...) So maybe something like this: REQ GEN-3: Should support full-proxy for common TCP [RFC0793] layer seven protocols. However if what you really want is TCP three ways proxied that is a little different. Would a tcp cookie implementation meet this requirement? Or do you want the three way done with the firewall then thrown away and you add the src to a whitelist for the next attempt or replay one side or do you want the fw to proxy the syn in, syn/ack out and ack back in? If so what is the benefit if it keeps all the state in two places now (host and firewall)? Time outs are generally used mostly for UDP not TCP. I don't object to having a timeout ability on tcp connections too but their primary use is UDP today in v4. REQ GEN-4: MUST be able to enforce timeouts on TCP connections based on specific protocols (e.g. enforce DNS timeout to a specific number of seconds, or FIN-WAIT, etc.). In general, it MUST have different kind of timeout values and thresholds to be used to prevent idle established connections to saturate resources on both the device and the service that is defended. So maybe "timeouts on UDP, TCP and other IP protocols" ... This is sometimes referred to as policy routing. REQ GEN-6: MUST be able to redirect specific traffic to a proxy server e.g. for HTTP/S protocols. But by saying "redirect" in theory a FW could meet that requirement by just rewriting the MAC and replaying the packet. Not really routing a layer 2 redirect. Which did you mean or did you mean both? REQ SPC-1 and 4 are the same. It says here that we want to match icmpv6 errors to tcp and udp you should include "and other ipv6 protocols" and won't this bring on new icmp blind tcp reset issues? REQ SPC-6: MUST be able to statefully match ICMPv6 errors to TCP [RFC0793], UDP [RFC0768], and ICMPv6 [RFC4443] communication instances. Split tunneling is almost always a concern on the client side not on firewalls. REQ VPN-5: MUST be able to disable or enable split-tunnelling feature on VPN as required. I have never seen that applied to a firewall but can't say it couldn't be:) In general you allow in a vpn remote access client and DON'T want them also connected directly to the internet as that punches a whole in your firewall (potentially anyways). This: REQ VPN-6: MUST be able to work indifferently on IPv4 and IPv6, and also offer both protocol in dual-stack in the same VPN connection. Should be this: REQ VPN-6: MUST be able to transit IPv4 and IPv6 packets providing full parity for services, and also offer both protocols in dual-stack in the same VPN connection. I am thinking tunnel instead of connection but do not feel strongly about it. The use of indifferently isn't technically wrong but isn't the common use of that word. This is really ip stack specific attacks (not really os specific). I have run non-native ip stacks on some OSes in the past (win3.1...) REQ DoS-1: MUST be able to protect against OS-specific attacks: nuke, ping- of-death (NOTE: this list should be expanded, and references added). And all of those pretty much died out. Having said that in there isn't bad. Here are a few more of those ip stack attacks. ICMP Fragments based attacks (this would include POD) and you include fragement based attacks in the next requirement. Smurf Attack Xmas Tree Attack LAND Attack Teardrop Attack This one probably needs some expansion. REQ DoS-4: MUST be able to protect against TCP resource exhaustion attacks: zero-window attacks, SYN-floods, etc. (see e.g. [CPNI-TCP]) So for syn flooding do we want proxied tcp cookies, or simple tcp ratelimiting and do you expect grey, white and blacklisting to be done based on some form of authentication (completes the hand shake or gets the cookie right ...)? Or can any or all methods be treated the same? Wrong RFC :) REQ DoS-8: MUST be able to participate to a blackhole/sync hole routing infrastructure as per [RFC5635]. You probably want this one https://tools.ietf.org/rfc/rfc3882.txt as it talks about sinkholing (and it is sink hole not sync hole :) The other one is about doing urpf with BHF and being able to do src based BHF. Also we may need to define what "participate" means. I generally don't expect firewalls (FW) to talk bgp and BHF is generally done with BGP. I will stop here for now to allow you to think about it and the next section is going to take more thought. (coffee != sleep) & (!coffee == sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of Marco Ermini [Marco.Ermini@ResMed.com] Sent: Tuesday, February 18, 2014 7:57 AM To: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewall-reqs-00.txt Hi everyone, a new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is about defining requirements for IPv6-capable Firewalls. You are welcome to have a look and contribute. Title : Using Only Link-Local Addressing Inside an IPv6 Network Authors : F. Gont M. Ermini W. Liu Filename : draft-gont-opsec-ipv6-firewall-reqs-00.txt Pages : 12 Date : 2014-02-14 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". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-firewall-reqs/ Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Kind regards, Marco Ermini - PhD CISSP CISA CEH ITIL MCP Senior IT Security & Compliance Analyst | Compliance Europe ResMed Germany Inc. Geschäftsführer: Frank Rebbert, Eric Paffrath, Michael Taube Sitz der Gesellschaft: München Registergericht: München, HRB 156206 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attachment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between ResMed and the intended recipient. This communication is confidential and may contain legally privileged information. By the use of email over the Internet or other communication systems, ResMed is not waiving either confidentiality of, or legal privilege in, the content of the email and of any attachments. If the recipient of this message is not the intended addressee, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
- [OPSEC] I-D Action: draft-gont-opsec-ipv6-firewal… Marco Ermini
- Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-fir… Smith, Donald
- Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-fir… Marco Ermini
- Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-fir… Smith, Donald
- Re: [OPSEC] I-D Action: draft-gont-opsec-ipv6-fir… Fernando Gont