Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets
Fernando Gont <fgont@si6networks.com> Wed, 15 August 2012 01:14 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772C321F870A; Tue, 14 Aug 2012 18:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE9LWfZYm1us; Tue, 14 Aug 2012 18:14:19 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF921F8702; Tue, 14 Aug 2012 18:14:19 -0700 (PDT)
Received: from [186.134.26.60] (helo=[192.168.123.104]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <fgont@si6networks.com>) id 1T1SBa-0008Ud-FF; Wed, 15 Aug 2012 03:14:15 +0200
Message-ID: <502AEB54.8050904@si6networks.com>
Date: Tue, 14 Aug 2012 21:20:36 -0300
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com>
In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com>
X-Enigmail-Version: 1.5a1pre
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: "opsec@ietf.org" <opsec@ietf.org>, "v6ops v6ops WG (v6ops@ietf.org)" <v6ops@ietf.org>
Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Aug 2012 01:14:20 -0000
Hi, Eric, Thanks so much for your feedback! -- Please find my comments in-line... On 08/14/2012 05:42 AM, Eric Vyncke (evyncke) wrote: [...] > Let’s start with generic: > > - It should not be a BCP but rather informational Just curious: what's the rationale for your preference? > - I also wonder whether it is worth an IETF RFC because it is well > known topics in the security area (as you probably know) I disagree with both points, for a number of reasons: * An IETF RFC means IETF consensus on a topic. That doesn't necessarily mean that the information is new, but rather than that's how the IETF thinks about the problem. * There has been quite some talk about the implications of transition technologies, and recommendations to "block them"... but concrete advice on how to filter each of these technologies is not always readily available. Try Google. * I generally disagree about "well known topics in the security area" (unless you clearly define what you mean by "known" and what you mean by "security area"). Most of the time I've seen any topic deemed as "well-known" in the security community, it really wasn't. And when it comes to IPv6 security in particular. there has been so much crap around it that I'd probably deem "well known IPv6 security topic" as an oxymoron. :-) > - Missing point: awareness of IPV6 by CISO is the key problem, I don't necessarily disagree, but that kind of aspect seems to be out of the scope of this particular document. > should also add that IPv6 is not dangerous per se, and enabling IPv6 in > intranet is a good way to bypass all automatic tunnels The focus of this document is how IPv6 affects your "IPv4-only" network. If you explicitly enable IPv6, then this document does not apply to your network. -- Not to mention that lots of devices are not IPv6-capable, which means that it shouldn't come up as a surprise if an admin cannot enforce enforce on v6 the same policies he enforces on v4. > - Intro / title should specify ‘end-user network’ (to avoid > confusion for ISP) Do we really need/want to make a difference, here? -- The generic issues being discussed in this document apply to any network that has "dormant IPv6 connectivity". > - IP flow (netflow), firewall log, DNS request log could also be > monitored to detect tunnels establishments Could you please elaborate a bit? > - Using NAPT (and not NAT as previously commented) usually blocks > ‘magically’ IP protocol 41 and most tunnels Agreed. I will add a note about this. > - If the security policy is to force all traffic through > application proxies (done by all major organizations) then tunnels are > not a threat Should I add any comments about this? If so, where? > Let’s continue with the details: > > - 1.0 please avoid all discussion about NAPT being > ‘minimal/simple’ security, the days of scanning are over and have been > replaced by malware download/email propagated ... yet we still use firewalls. Clearly, a NAT-PT blocks some attack vectors, and reduces host exposure. And technologies such as Teredo essentially eliminate any sort of protection that could be achieved by such NAT-PT. And they do block some attacks -- not "all" or "most", but they do block some. > - 2.0 congruent security policy indeed with the exception of RFC > 4890 (ICMPv6) I'd argue that the policy is still the same -- it's just that there are additional message types in v6 /which are not present in v4). It's quite unfortunate to hear in v6 circles things like "in v6, you cannot filter all ICMP as you do in v4" -- because even in v4 you couldn't do this without braking PMTUD. > - 2.1 filtering the IPv6 ethertype is TOO dangerous (= could break > too many things) to be recommended in an IETF document Filtering EtherType 0x86DD does what it is meant to do: block native IPv6 traffic. Note that we are not recommending that people do it, and even less to have products ship with that filter "on by default" -- we just note that if you want to prevent block native IPv6 traffic, that's one possible way to do so. > - 3.1 should refer to the RFC Done! > - 3.3 AFAIK there is no by default implementation of 6RD in > generic OS and it requires either manual configuration or DHCPv4 option > => remove this section I'd probably argue that we should argue the comment on DHCPv4 possibly enabling 6rd, rather than removing the whole section -- for instance, an attacker could exploit such vector. That aside, removing the entire section would likely trigger feedback of the form "hey guys, you forgot to describe 6rd!". > - 3.5 leave ISATAP (automatic config through DNS) but specify that > blocking 41 also blocks it The current text already notes that. > - 3.6 as noted, Teredo default port can be changed. The good > recommendation anyway for enterprises is to block outbound UDP traffic > (except some pin holes for DNS of course), even my employer network > blocks them since 1997 ;-). This is going beyond the type of advice this document is meant to provide. We want to provide advice on how to block Teredo... rather than recommend to filter all UDP. > Also, Microsoft implementation disables > Teredo when personal firewall is disabled or when the host is in an > Active Directory network That still leaves Windows systems with a firewall and no Active Directory network with Teredo "on by default". > - Other tunnels TSP (but also Sixxs, ...) all require explicit > installation and configuration by end-users. They are no more a thread > than any other covert channel (being IP over DNS or over ICMP or ...), I > would remove this section TSP could allow incoming connections to the local network, which is something quite different from an internal node being able to "send stuff out on top of DNS or ICMP". Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] 3 Volunteers wanted - Draft: draft-gont-o… Gunter Van de Velde (gvandeve)
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Gunter Van de Velde (gvandeve)
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Smith, Donald
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Lee Howard
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Eric Vyncke (evyncke)
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Fernando Gont
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Smith, Donald
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Fernando Gont
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Smith, Donald
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Fernando Gont
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Eric Vyncke (evyncke)
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Smith, Donald
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Fernando Gont
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Warren Kumari
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Mark Andrews
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Carlos M. martinez
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Lee Howard
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Philipp Kern
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Jeroen Massar
- Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: … Warren Kumari