Re: [OPSEC] Operational Security Considerations for IPv6 Networks (draft-ietf-opsec-v6)
JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Sun, 21 July 2019 15:49 UTC
Return-Path: <prvs=1105e7c234=jordi.palet@consulintel.es>
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 40527120020 for <opsec@ietfa.amsl.com>; Sun, 21 Jul 2019 08:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 dtqQ2ofHJ3UP for <opsec@ietfa.amsl.com>; Sun, 21 Jul 2019 08:49:29 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2F1120019 for <opsec@ietf.org>; Sun, 21 Jul 2019 08:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1563724166; x=1564328966; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=AdcT60Ne M6SOWVkvLiwJig59ToJ2Q5O1vY9e8xUmSB8=; b=XHKdezHHAaAhdBTqgmt/mRnW DAK4EUXuiVFkJi/JACxsgpp0Etecdq57CdN7Ozbe7hpVOuuVkkPKy9z+RSX0jNvo 5dWkTwNfl0fIzxCaZO5lbWhD4gKytLMQTw5FRYtH4Jjx2cV3TOGvBhCo8K8Ktxmh Xl51fhbzfyjZBBKMzKY=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Sun, 21 Jul 2019 17:49:26 +0200
X-Spam-Processed: mail.consulintel.es, Sun, 21 Jul 2019 17:49:26 +0200
Received: from [31.133.129.166] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006332021.msg for <opsec@ietf.org>; Sun, 21 Jul 2019 17:49:25 +0200
X-MDRemoteIP: 2001:67c:370:128:9065:52c2:6349:39f8
X-MDHelo: [31.133.129.166]
X-MDArrival-Date: Sun, 21 Jul 2019 17:49:25 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1105e7c234=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: opsec@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.c.190715
Date: Sun, 21 Jul 2019 11:49:21 -0400
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Enno Rey <erey@ernw.de>, "opsec@ietf.org" <opsec@ietf.org>
Message-ID: <F16F913C-1407-4EFA-904D-838D3610323E@consulintel.es>
Thread-Topic: [OPSEC] Operational Security Considerations for IPv6 Networks (draft-ietf-opsec-v6)
References: <851C8B13-6636-4336-82CB-2F2FC92C3FAE@cisco.com>
In-Reply-To: <851C8B13-6636-4336-82CB-2F2FC92C3FAE@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/oOc6ESxJKch6SZZmj09vuBqj-Go>
Subject: Re: [OPSEC] Operational Security Considerations for IPv6 Networks (draft-ietf-opsec-v6)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 21 Jul 2019 15:49:32 -0000
Hi Eric, Thanks for considering my previous inputs. However, I think it is still important to remark the different implications of MAP-T vs MAP-E and also consider lw4o6. Same for the implications of not having a DNS proxy in some transition mechanism, as stated in RFC8585. Also, in section 5. Residential Users Security Considerations Replace If the Residential Gateway has IPv6 connectivity, [RFC7084] defines the requirements of an IPv6 CPE and does not take position on the debate of default IPv6 security policy as defined in [RFC6092]: with If the Residential Gateway has IPv6 connectivity, [RFC7084] and [RFC8585] define the requirements of an IPv6 CPE and does not take position on the debate of default IPv6 security policy as defined in [RFC6092]: I think in this section, it makes sense a reference to Section 5. UPnP Support of draft-ietf-v6ops-transition-ipv4aas, which also includes a reference to PCP support. Does it make sense to mention a specific operator or should this paragraph be anonymized? There is also an alternate solution which has been deployed notably by Swisscom: open to all outbound and inbound connections at the exception of an handful of TCP and UDP ports known as vulnerable. In any case "an handful" -> "a handful"? Some nits: 2.1.1 more feasable -> more feasible ? 2.7.2 some bullets finish with ";" others with "." 3.2 Missing ending "." for paragraph at the end of "provided in Section 2.8" Regards, Jordi @jordipalet El 17/7/19 4:25, "OPSEC en nombre de Eric Vyncke (evyncke)" <opsec-bounces@ietf.org en nombre de evyncke@cisco.com> escribió: Jen, Ron, As co-author of the document, the latest -17 revision dated 2019-07-05 addresses (at least from the authors point of view): - the comments received during the WG meeting at IETF-104 - the OPSDIR review by Tim Chown dated 2018-07-02 - the WGLC ended in 2017-09-29 The state of the document in the datatracker is still "Revised I-D Needed - Issue raised by WGLC" since 2017-09-29 though. As I was co-chair at that point of time, I should have reset the state to a more suitable one... Would you mind resetting the state to a more suitable one? Note: I have requested a slot to present this work at V6OPS https://datatracker.ietf.org/meeting/105/materials/agenda-105-v6ops-03 With all the reviews and the updates, may I kindly suggest, if the WG chairs and members agree, to request publication? Happy to talk to you in Montreal of course. Thank you for considering this request, -éric On 06/07/2019, 18:43, "OPSEC on behalf of Enno Rey" <opsec-bounces@ietf.org on behalf of erey@ernw.de> wrote: Dear WG Chairs, All, we've considered & mostly incorporated the input from the mailing list (thanks for the latest reviews and comments!) and from the IETF104 session, and we'd hence like to ask for WGLC of the document. thanks Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Florian Grunow, Michael Schaefer ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- Re: [OPSEC] Operational Security Considerations f… Eric Vyncke (evyncke)
- Re: [OPSEC] Operational Security Considerations f… Ron Bonica
- Re: [OPSEC] Operational Security Considerations f… JORDI PALET MARTINEZ