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

Christian Huitema <huitema@huitema.net> Mon, 07 January 2019 18:02 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8528130FEE for <ietf@ietfa.amsl.com>; Mon, 7 Jan 2019 10:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 UBrGfgzaoPS9 for <ietf@ietfa.amsl.com>; Mon, 7 Jan 2019 10:02:40 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F16130E92 for <ietf@ietf.org>; Mon, 7 Jan 2019 10:02:40 -0800 (PST)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1ggZEN-0005wd-Vy for ietf@ietf.org; Mon, 07 Jan 2019 19:02:38 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1ggZEG-0004WT-Kl for ietf@ietf.org; Mon, 07 Jan 2019 13:02:28 -0500
Received: (qmail 6632 invoked from network); 7 Jan 2019 18:02:21 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <secdir@ietf.org>; 7 Jan 2019 18:02:21 -0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16C101)
In-Reply-To: <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es>
Date: Mon, 07 Jan 2019 10:02:19 -0800
Cc: secdir@ietf.org, v6ops@ietf.org, ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B0031737-005E-4AF9-9C0C-4A2A5774F73C@huitema.net>
References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <CD5A6FC1-77A1-42F8-83F6-86581F11E838@consulintel.es> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
Subject: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
X-Originating-IP: 168.144.250.230
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.23)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5jHkVeuB2ZXQ1iguQK3r7Pt602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO4tDwdNAVmgs/7KSsJM2vK1s1ujulqUFmMITHM77eiViY9OCdPiKzYj4JNdfylHeJs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB1VzUjpi3KNxdQZ39cmOPHk5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxhwZ+JqwRq4dm7gx9VmMD3oQl+86MkQJ6nrl0gGH3bP6cMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjMauXIUif1JzGdiG0o4ggCmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJE2d52fY0d/1mkgffWkdO 4QEiRQv+PVjjwa+Z5RFCOMSvBkSqQUHV5hMinZNqXMuOqpzxuZ/FKz4x4mg8I92kbnLAa6pIepTM vjSF5dSnMOpk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsfj3cQFz5QBYZW/yDwrWuVZYSpQQtCkh8qZ SV0LCxteTbG3U0/bYoSUcINHnPK1R1KIx0wUHYysBh+bMiBA2/khu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uK//KzSfzfwEldM3jWkCPmDu9UshveVgoiypAicYsWUtd9a2LHJVD1n7GG0fP 4s+aIo4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_zuGhDT8sEgv1HXFtzMUzTQrr_8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2019 18:02:46 -0000

Yes, that would work fine. If it could help convince these routers to implement DHCP guard or RA guard, that would be a great result.

I am not so sure about 802.1x. The routers could of course support a setting like that of the IETF network, and that would have some advantage over WPA residential, but it would not address an important threat: local device compromised by some virus and engaging in DHCP spoofing. DHCP guard or RA guard would still be needed.

-- Christian Huitema 

> On Jan 7, 2019, at 2:38 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> 
> 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.
> 
> 
>