[OPSEC] Fwd: Re: [v6ops] WGLC for draft-ietf-opsec-v6

Fernando Gont <fgont@si6networks.com> Tue, 18 April 2017 11:54 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3454129B84 for <opsec@ietfa.amsl.com>; Tue, 18 Apr 2017 04:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VfeLhO-Q9rLE for <opsec@ietfa.amsl.com>; Tue, 18 Apr 2017 04:54:48 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC67126DC2 for <opsec@ietf.org>; Tue, 18 Apr 2017 04:54:48 -0700 (PDT)
Received: from [100.78.23.17] (unknown [94.117.66.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5EDC98094B; Tue, 18 Apr 2017 13:54:43 +0200 (CEST)
References: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com>
To: "'opsec@ietf.org'" <opsec@ietf.org>
From: Fernando Gont <fgont@si6networks.com>
X-Forwarded-Message-Id: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com>
Message-ID: <225b3c0e-2e79-373a-0017-7dc410367d21@si6networks.com>
Date: Tue, 18 Apr 2017 12:41:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <1491877d-b445-af79-1f44-2e5507054a92@si6networks.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/ewv6A1DpS0NSQHgjf-3kKeNQPpU>
Subject: [OPSEC] Fwd: Re: [v6ops] WGLC for draft-ietf-opsec-v6
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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 Apr 2017 11:54:50 -0000

fwd'ing, since there was a typo in the original email...


-------- Forwarded Message --------
Subject: Re: [v6ops] [OPSEC] WGLC for draft-ietf-opsec-v6
Date: Tue, 18 Apr 2017 12:10:37 +0100
From: Fernando Gont <fgont@si6networks.com>
To: otroan@employees.org, opsec@ietf.ortg
CC: Gunter Van De Velde <guntervandeveldecc@icloud.com>, v6ops@ietf.org
Operations <v6ops@ietf.org>, 6man@ietf.org

On 04/18/2017 09:18 AM, otroan@employees.org wrote:
> A few initial comments. Draft is not quite ready.
> 
> Section 2.1.3:
>   6164 does not _recommend_ /127 it _permits_ /127 on p2p links.

Agreed on this.


>   The ping pong attack is mitigated in RFC4443.

I must be missing something.. what does RFC4443 have to do with this? A
ping pong attack does not require the attack packets to be ICMPv6 echo
requests...


>   I am not convinced there is justification that this document should recommend /127 for "security reasons".

Besides ping-pong, there's NCE. While I do agree that the real solution
to the above two issues is *not* to use a /127, this document being an
operational one, I can see why the authors may want to recommend /127.



> Section 2.2:
>   I am not sure that extension headers are one of the most critical differentiators between IPv4 and IPv6. IPv4 had variable length options...

The packet structure does make a big difference. For instance, it's
trivial to find (in IPv4-based packets) the upper layer protocol type
and protocol header, while in IPv6 it actually isn't.



> Section 2.3.2:
>   Consider Secure DHCPv6?

Question: is that doable? (i.e., widely supported)




> Section 3.1:
>   In general update references. e.g. ipv6-eh-filtering is outdated.
>   I question referencing opsec-ipv6-eh-filtering. It has wrong and outdated advice. E.g. on section of HBH header.
>   The advice in ipv6-eh-filtering is essentially to ossify the network.

Have you read the I-D? Because the I-D boils down to: "pass all EHs
unless they are known to be very harmdful".

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




.