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.