Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 07 January 2019 10:38 UTC

Return-Path: <prvs=19105d24b1=jordi.palet@consulintel.es>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41F12D4F1; Mon, 7 Jan 2019 02:38:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 fmaDl5Uh37VH; Mon, 7 Jan 2019 02:38:40 -0800 (PST)
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 63BA8129AA0; Mon, 7 Jan 2019 02:38:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546857515; x=1547462315; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=qdf+atTfShMJ7kXOJy+MpCTDAZ2kI1uh++fEGfcc9mw=; b=GG0Y2SAufIeSD cPYFGchc5iZu4gtuCMQnnddy1zJqFEVn+840yp2k5uFxqvBF/z+pCIL4+HsGNiJN 7WZKDCu80fdMItBO1jcntXGIfQUiTMah9s4GEVFRGjgoLIe5c4Ns8WisUq0pc3Ot 5ns/xsJGMWNu5YZ1w2ZmWdnaw1xBMk=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 07 Jan 2019 11:38:35 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006100209.msg; Mon, 07 Jan 2019 11:38:33 +0100
X-MDRemoteIP: 2001:470:1f09:495:b467:f4bf:e908:d5fd
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Mon, 07 Jan 2019 11:38:33 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=19105d24b1=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Mon, 07 Jan 2019 11:38:33 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Christian Huitema <huitema@huitema.net>, <secdir@ietf.org>
CC: <v6ops@ietf.org>, <ietf@ietf.org>
Message-ID: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es>
Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <CD5A6FC1-77A1-42F8-83F6-86581F11E838@consulintel.es>
In-Reply-To: <CD5A6FC1-77A1-42F8-83F6-86581F11E838@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/l8KGQN2QSH0E9Pp1g4LJrwAAJs0>
Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 10:38:42 -0000

Hi Christian,

I've drafted this at the moment. Let me know if you think now this is better and if you think anything else is needed.

8.  Security Considerations

   The IPv6 Transition CE Router must comply with the Security
   Considerations as stated in [RFC7084], as well as those stated by
   each transition mechanism implemented by the IPv6 Transition CE
   Router.

   As described in [RFC8026] and [RFC8415] Security Consideration
   sections, there are generic DHCP security issues, which in the case
   of this document means that malicious nodes may alter the priority of
   the transition mechanisms.

   Considering that, networks using DHCPv6, depending on their specific
   topologies, should consider using authentication mechanisms such as
   those based on IEEE-802.1X or access control mechanisms such as DHCP
   snooping, DHCP guard, or TR-069, among other possible choices.

   As stated in the introduction, this document addresses deployment of
   IPv4aaS in residential, SOHO and SME networks.  Deployment in more
   challenging environments would require additional security analysis.


Regards,
Jordi
 
 

-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org>; en nombre de JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>;
Fecha: lunes, 7 de enero de 2019, 11:17
Para: Christian Huitema <huitema@huitema.net>;, <secdir@ietf.org>;
CC: <v6ops@ietf.org>;, <ietf@ietf.org>;
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    Hi Christian,
    
    Thanks for your review.
    
    There is a typo there, wrong copy and paste. It should be RFC8415 and RFC8026, as we discussed after your review.
    
    My point, as discussed in the previous email exchange, is that this is a generic issue of DHCP. DHCP is used by both residential and non-residential service provisioning, and I don't see how we can solve that problem unless we implement some new DHCP "extension" that apply end-to-end encryption between, in this case, the CEs and the servers.
    
    I can have a security section with basically replicates the text available in RFC8415 Security Section, including considerations of using IEEE-802.1X, DHCP snooping/guard/access control mechanisms, use of TR-069 access control mechanisms, etc.
    
    I'm also happy to add your suggested paragraph regarding additional security analysis in more challenging environments.
    
    Or maybe the correction of the RFC8415 references is sufficient in your opinion or you will prefer some additional text to summarize the RFC8415 security considerations/mitigations?
    
    I'm going to wait a couple of days, in case there are further inputs, before uploading a new version correcting the mistake and also take in considerations the suggestions from the Gen-ART review a couple of days ago.
    
    Regards,
    Jordi
     
     
    
    -----Mensaje original-----
    De: v6ops <v6ops-bounces@ietf.org>; en nombre de Christian Huitema <huitema@huitema.net>;
    Fecha: lunes, 7 de enero de 2019, 7:28
    Para: <secdir@ietf.org>;
    CC: <v6ops@ietf.org>;, <ietf@ietf.org>;, <draft-ietf-v6ops-transition-ipv4aas..all@ietf.org>;
    Asunto: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
    
        Reviewer: Christian Huitema
        Review result: Ready
        
        I already reviewed the version 11 of this draft. From a security point of view,
        the main change between the two versions is the addition of a paragraph
        acknowledging the potential risks of relying on DHCP for configuration. To
        quote: "As described in [RFC8026] and [RFC8026] Security Consideration
        sections, there are generic DHCP security issues, which in the case of this
        document means that malicious nodes may alter the priority of the transition
        mechanisms."
        
        Well, on the one hand, this does directly address the point I raised in the
        previous review. On the other hand, it is a bit sad to have a dry
        acknowledgement like that, without any hint at mitigations. If I was writing an
        April's fool RFC, I would qualify that as one of those security sections that
        seem written primarily for appeasing the security reviewer. But then, do we
        want to give some advice to implementers? For example, do we want to tell them
        that it is OK to deploy compliant devices in a basic home network? Probably. In
        the branch office of a financial institution? Most probably not. Do we have a
        way to convey that in simple terms? I would add something like:
        
        "As stated in the introduction, this document addresses deployment of IPv4 as a
        service in a residential or small-office network. Deployment in more
        challenging environments would require additional security analysis."
        
        
        _______________________________________________
        v6ops mailing list
        v6ops@ietf.org
        https://www.ietf.org/mailman/listinfo/v6ops
        
    
    
    
    **********************************************
    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.
    
    
    
    



**********************************************
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.