Re: [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks)
Fernando Gont <fgont@si6networks.com> Thu, 19 July 2012 12:54 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 5A5F521F8738; Thu, 19 Jul 2012 05:54:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.458
X-Spam-Level:
X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_13=0.6]
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 w4h5xiWJVG-M; Thu, 19 Jul 2012 05:54:49 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 728E521F8736; Thu, 19 Jul 2012 05:54:49 -0700 (PDT)
Received: from bl10-131-211.dsl.telepac.pt ([85.243.131.211] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <fgont@si6networks.com>) id 1SrqGX-0001LD-A3; Thu, 19 Jul 2012 14:55:37 +0200
Message-ID: <5007643C.9050003@si6networks.com>
Date: Thu, 19 Jul 2012 02:34:52 +0100
From: Fernando Gont <fgont@si6networks.com>
Organization: SI6 Networks
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
References: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com>
In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com>
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, Merike Kaeo <merike@doubleshotsecurity.com>
Subject: Re: [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks)
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: Thu, 19 Jul 2012 12:54:50 -0000
Hi, Eric (et al), I think this document is filling an existing gap. Thanks for writing it! I've begun to read your I-D. I'll be sending some feedback in batches, since it will likely result in more timely feedback. Abstract: I wouldn't go as far as saying that "RFC 4942 describes the security issues in the protocol". Introduction: The I-D says "Network Address and Port Translation [RFC3022] has lead to the common feeling that NATPT equals security and with IPv6 NATPT is no more needed." A side effect of NATPT is that the *device* ends up operating as a stateful firewall that only allows return traffic. I'd personally find it challenging (?) to find a term for which one could claim "X equals security" (since there are many aspects of security, which can hardly be addressed by a single "device"). However, I'd note that there are security properties in firewalls (which a NATPT ends up acting as, as a side effect). Regarding "IPv6 NATPT", I seem to recall that it already ships with Linux? Nits: Section 2.1.1: "Once an address allocation has been assigned" This doesn't seem to parse well. Section 2.1.1: You should probably clarify that, when talking about "manually configured addresses", you're talking about devices (e.g. routers) that typically have their addresses manually-configured, and *not* encouraging manually-configured addresses in general devices. Section 2.1.2: I don't recall the details of the discussion regarding ULAs, but would guess that some have probably argued that they may make troubleshooting painful? Section 2.1.3: This section should probably reference draft-ietf-v6ops-v6nd-problems, since using /112 also works as a workaround for buggy implementations that fail to properly manage the Neighbor Cache. Some slideware I've used recently (e.g. , ) might be of help, too. Section 2.1.4: This section should reference RFC4941 rather than RFC3041. You may want to reference draft-gont-opsec-ipv6-host-scanning. Nit: s/know/known/ This section says "Privacy addressing attempts to mitigate this threat". However, privacy addresses are typically (*) configured *in addition* to IEEE-derived IIDS -- hence they do not mitigate the host scanning problem. draft-ietf-6man-stable-privacy-addresses does, since they are meant to replace the IEEE-derived IIDs. (*) with the notable exception of OpenBSD, which removes IEEE-derived IIDs when privacy addresses are enabled. This section says "While privacy addresses are truly generated randomly to protect against user tracking, but assuming that nodes use the EUI-64 format for global addressing, a list of expected pre-authorized host addresses can be generated." I don't follow... for outgoing connections, hosts would employ privacy addresses, so... Section 2.2: Nits: s/relied/relies/ s/not he/on the/ Section 2.2.1: You should probably note the many reasons for which SEND is challenging to deploy (PKI, not widely implemented, etc.) Additionally, as noted in draft-ietf-6man-nd-extension-headers, if you end up relying on fragmentation (which you shouldn't!), it could be possible for an attacker to circumvent SEND. Section 2.2.2: You may want to look at/reference: draft-gont-opsec-dhcpv6-shield. Section 2.2.3: Nit: s/DOS/DoS/ Section 2.2.4: The I-D says "However, several evasion techniques that circumvent the protection provided by RA Guard have surfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation." Note that for existing implementations, you do not even need to use fragmentation: these RA-Guard implementations simply expect the ICMPv6 to follow the fixed IPv6 header -- hence simply including any IPv6 extension header is enough to circumvent them. [I-D.gont-6man-nd-extension-headers] should now be [I-D.ietf-6man-nd-extension-headers] ;-) Ok, 2:33 AM... more on this later.... ;-) Cheers, Fernando On 07/18/2012 03:34 PM, Eric Vyncke (evyncke) wrote: > We have posted a new version of our draft draft-vyncke-opsec-v6 at: > > http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 > > > > As usual comments are welcome, at Paris, comments were ‘yes this is > required’. BTW, the intent is not to write 100’s of pages but rather > document existing I-D and good practices. > > > > Best regards > > > > -merike, kk and éric > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] New updated version of draft-vyncke-opsec… Eric Vyncke (evyncke)
- Re: [v6ops] New updated version of draft-vyncke-o… Fernando Gont