Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

Christian Huitema <huitema@huitema.net> Fri, 14 December 2018 19:28 UTC

Return-Path: <huitema@huitema.net>
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 EC3CF1312AD for <secdir@ietfa.amsl.com>; Fri, 14 Dec 2018 11:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZIGBdob3nfJR for <secdir@ietfa.amsl.com>; Fri, 14 Dec 2018 11:28:45 -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 A085D1312B7 for <secdir@ietf.org>; Fri, 14 Dec 2018 11:28:42 -0800 (PST)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx63.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gXt8Z-0009BL-8q for secdir@ietf.org; Fri, 14 Dec 2018 20:28:40 +0100
Received: from [10.5.2.12] (helo=xmail02.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 1gXt7n-00043I-HT for secdir@ietf.org; Fri, 14 Dec 2018 14:28:37 -0500
Received: (qmail 22276 invoked from network); 14 Dec 2018 19:01:09 -0000
Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org>; 14 Dec 2018 19:01:09 -0000
To: mohamed.boucadair@orange.com, JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "secdir@ietf.org" <secdir@ietf.org>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org>
References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <c4a5cb73-3957-d81e-2318-168465aa96ba@huitema.net>
Date: Fri, 14 Dec 2018 11:01:06 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
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.11)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vwon9KZlglxxIbQMkBX98l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQSEIsaL6W5kBtA1+kI91C8+oyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R1Tp2qINNumDttMaLRLWWvV6Xe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsey6n3SPEHq5iliCZ8XofdvQPwUimsNGvJJilSn4u6QSZKX4S37qQQBw Aej9qldla+ss95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53mHv93Xd4vvLeOO86n1rCqjAMgFPp7+h3kLe NmBV53UGW9b8VrusR2lXu2H6mhL90RXoHi/zqZrZl2NgJNWo0lVRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/FR5hOBQdDDoj2Q1DGd4Y477G3ch6MdB0XuALpEgtIRS8rMgFGxC0xSok+fi i+Mknt40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/AgE3NUFyDlPv2yEYoz3k9cYjFTU>
Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11
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: Fri, 14 Dec 2018 19:28:47 -0000

Pointing to the RFC8415 security section would definitely help. What is
specific about your draft is that attackers can leverage the DHCPv6
issue and mislead nodes into choosing transition schemes in the wrong
order. This is an additional exploitation mechanism on top of  the
existing issues mentioned in the DHCPv6 RFC.

I would also mention that these security issues are hard to mitigate and
that secure environments might require other configuration methods.

This also begs the larger question about why we have so many transition
mechanisms in the first place, and why the local nodes even need to be
aware about them. It seems that this could be radically simplified, by
having the router either advertise IPv4 connectivity using traditional
IPv4 means, or advertise a NAT64 prefix if it expects local nodes to
perform their own mapping.

On 12/13/2018 11:44 PM, mohamed.boucadair@orange.com wrote:
> Christian,
>
> As mentioned by Jordi, RFC8026 already describes the attack vector you mentioned. 
>
> Wouldn't pointing to https://tools.ietf.org/html/rfc8415#section-22 be sufficient here? 
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : ietf [mailto:ietf-bounces@ietf.org] De la part de Christian Huitema
>> Envoyé : vendredi 14 décembre 2018 08:26
>> À : JORDI PALET MARTINEZ; secdir@ietf.org
>> Cc : v6ops@ietf.org; ietf@ietf.org; draft-ietf-v6ops-transition-
>> ipv4aas.all@ietf.org
>> Objet : Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-
>> ipv4aas-11
>>
>>
>> On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote:
>>> Hi Christian,
>>>
>>> Thanks a lot for your review.
>>>
>>> Please see below in-line.
>>>
>>> I'm working in a new version according to the comments got from the ops
>> review as well, so will be able to integrate yours very quickly.
>>> Regards,
>>> Jordi
>>>
>>>
>>>
>>> -----Mensaje original-----
>>> De: v6ops <v6ops-bounces@ietf.org>; en nombre de Christian Huitema
>> <huitema@huitema.net>;
>>> Fecha: jueves, 13 de diciembre de 2018, 21:50
>>> Para: <secdir@ietf.org>;
>>> CC: <v6ops@ietf.org>;, <ietf@ietf.org>;, <draft-ietf-v6ops-transition-
>> ipv4aas.all@ietf.org>;
>>> Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-
>> ipv4aas-11
>>>     Reviewer: Christian Huitema
>>>     Review result: Has Issues
>>>
>>>     I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the
>>>     security directorate's ongoing effort to review all IETF documents
>>>     being processed by the IESG.  These comments were written primarily for
>>>     the benefit of the security area directors.  Document editors and WG
>> chairs
>>>     should treat these comments just like any other last call comments.
>>>
>>>     The summary of the review is "ready with issue".
>>>
>>>     The document describes solution for providing "IPv4 as a service", i.e.
>>>     provision of IPv4 as a service over an IPv6 only network.
>>>     It calls this support "transition as a service".
>>>
>>>     For various reasons, IETF working groups have standardized not just one
>> but
>>>     five different mechanisms for providing this transition: 464XLAT
>> [RFC6877],
>>>     Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596],
>>>     MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python
>> could have
>>>     produced a nice sketch about that.) The purpose of the draft is to
>>>     state how home routers (a.k.a. customer premise equipment, CPE) should
>>>     inform local devices about which of the mechanisms are available, which
>>>     should be preferred, and what parameters should be used when deploying
>>>     the chosen services. This is done using the DHCPv6 "S46" option
>>>     specified in RFC 8026.
>>>
>>>     The draft also makes specific recommendation regarding the use of the
>> UPnP and
>>>     PCP services, by requiring specific error codes when a requested port
>> mapping
>>>     is not available through the specified transition technology.
>>>
>>>     The security section briefly points to the "Basic Requirements for IPv6
>>>     Customer Edge Routers" specified in RFC 7084, and to the security
>>>     section of each of the RFC describing the security technologies, and
>> implicitly
>>>     argues that there are no other security issues. I think that is
>> insufficient.
>>>     The draft introduces a reliance on the DHCPv6 "S46" option for
>> assessing the
>>>     relative priority of different transition technologies. An attacker
>> could spoof
>>>     the DHCPv6 response, and direct client traffic to a different
>> technology than
>>>     selected by the service provider. This could be used, for example, to
>> capture
>>>     IPv4 traffic in an IPv6 network and send it to a route chosen by the
>> attacker.
>>>     The attack might also be used in a dual stack network that does not
>> support
>>>     any transition technology. I don't understand how this attack is
>> mitigated.
>>> Not sure if you will suggest here that we should say something about the
>> security considerations already mention in RFC8026. In general all those are
>> generic DHCPv6 security considerations I think.
>>
>> Basically, the devices should be programmed to ignore DHCPv6 if they
>> have another more secure way of getting their configuration data. Plus,
>> apply general defense against DHCPv6 hacks in the network, etc. I
>> understand that your draft is meant to inform the building of CPEs, but
>> its effect is generalization of an unsafe mechanism.
>>
>>
>>>     Nits:
>>>
>>>     The introduction uses the acronym WAN without spelling out "Wide Area
>> Network".
>>>     Also, WAN is used as substitute for local Internet Service Provider
>> network. We could
>>>     debate whether such networks are always "wide area", by opposition to
>> say
>>>     "metropolitan" or "regional". This is the same convention used in RFC
>> 7084 that
>>>     this document updates. It is arguably defined by reference, but
>> spelling it out
>>>     would be nice.
>>>
>>> Will do.
>>>
>>>
>>>     The comparison with RFC7084 section includes a mangled sentence:
>>>
>>>        This document doesn't include support for 6rd ([RFC5969]), because
>> as
>>>        in an IPv6-in-IPv4 tunneling.
>>>
>>> Typo, sorry the correct sentence was:
>>>        This document doesn't include support for 6rd ([RFC5969]), because
>> is
>>>        an IPv6-in-IPv4 tunneling.
>>        This document doesn't include support for 6rd ([RFC5969]), because it
>> is
>>        an IPv6-in-IPv4 tunneling.
>>
>>>     Please rephrase. Please also rephrase the next sentence, for similar
>> reasons:
>>>        Regarding DS-LITE [RFC6333], this document includes slightly
>>>        different requirements, because the PCP ([RFC6887]) support and the
>>>        prioritization of the transition mechanisms, including dual-stack.
>>>
>>> I think it is much clear this way:
>>>
>>>        Regarding DS-LITE [RFC6333], this document includes slightly
>>>        different requirements, related to the support of PCP ([RFC6887]),
>>>        IGD-PCP IWF [RFC6970] and the prioritization of the transition
>>>        mechanisms, including dual-stack.
>> OK.
>>
>>
>>>
>>>     _______________________________________________
>>>     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.
>>>
>>>