Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Christian Huitema <huitema@huitema.net> Mon, 04 February 2019 06:17 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FCC130E1C for <ipv6@ietfa.amsl.com>; Sun, 3 Feb 2019 22:17:38 -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 cirKckg1m1WB for <ipv6@ietfa.amsl.com>; Sun, 3 Feb 2019 22:17:37 -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 6E9EB1294FA for <ipv6@ietf.org>; Sun, 3 Feb 2019 22:17:37 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gqX3P-0005MO-Kq for ipv6@ietf.org; Mon, 04 Feb 2019 06:44:24 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gqX3L-0003uZ-1N for ipv6@ietf.org; Mon, 04 Feb 2019 00:44:19 -0500
Received: (qmail 3200 invoked from network); 4 Feb 2019 05:44:16 -0000
Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <jordi.palet=40consulintel.es@dmarc.ietf.org>; 4 Feb 2019 05:44:15 -0000
To: Fernando Gont <fgont@si6networks.com>, Ole Troan <otroan@employees.org>
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <m1gpCcz-0000FlC@stereo.hq.phicoh.net> <ddd28787-8905-bafd-3546-2ceef436c8b0@si6networks.com> <m1gptWx-0000G3C@stereo.hq.phicoh.net> <69609C58-7205-4519-B17A-4FBC8AE2EA16@employees.org> <ac773bb5-0da8-064b-d46b-3a218b8c9e7a@si6networks.com> <CFAEACC4-BA78-4DF9-AD8A-3EB0790B8000@employees.org> <a4f6742e-f18e-3384-d4cc-06bfab49101f@si6networks.com> <FEFA99C2-4F09-4D8F-8D51-C9D9D7090637@employees.org> <a484d5de-0dce-a41a-928e-785d8d80d05d@si6networks.com> <A40C5116-9474-4F2B-BD94-F57D155ECD4C@employees.org> <b05e3872-d63b-108c-6c00-21b951dad263@si6networks.com> <A9FBBED3-A858-4BB1-A02A-2A06CBEB7662@consulintel.es> <010b2c6d-9c79-9309-aad8-32530c9dab94@gmail.com> <A0201A4B-77BB-40F4-A35F-F1491732D537@consulintel.es> <749b121f-cac5-30e0-686c-9f7f29313d91@huitema.net> <2BAD7ADA-6940-45EA-B7DD-0D82B9E95A05@employees.org> <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com>
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: <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net>
Date: Sun, 03 Feb 2019 19:44:13 -1000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <2d919f5d-672f-9319-2757-cfff86a0ff50@si6networks.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-Originating-IP: 168.144.250.232
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: ham
X-Spampanel-Outgoing-Evidence: Combined (0.09)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vAfvG2/689f/hOQIwzqDzR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO0+c5LB5+AaOnyUGHzplYThs1ujulqUFmMITHM77eiVitBVVpDKhxV29ZbNNkYAIDM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBfeuTov1vPAP3qEy01CsKmx/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgwJpy2yi2NB5qsi4dVukIa9cV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseyUYJbyy1lVJ6nYOoLd75iYvy7NvAbxEgZSsI+HSLa0cUaoTlZxJsHc 9QbYB8h0t6tk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUjMTi5Xt/sRoctxyu5EZ7wRl sQ6lNTZIrBtlLeoEHaVN0z6bhalFEM/pjPCQA+BAlsmxjTcEgjAf7uHQSebz5itZYSpQQtCkh8qZ SV0LCxte56M+NaPoRylmDQOIwqBa53zrS1j/yp3hcdnHXU5ZJ8shu1/rdU1t/SWu+yxj6TsAzBpI RKEYj3P5LT70ZY4uKy6Ua8iVFQnyU0X+eDelmfS9UshveVgoiypAicYsWUtdqW+JovcC0XtHTtan zqbG/I4cvttr0tmBjeIn/Z/emtVQvYq5Gwe6V5p1dZXUJLl9UHdlPJIlgYKUOVb4Kg3Ivfi62j4u w/K+m8SGihSRsuS3byv3CjhKpQiDxiH2EAzS5xSvMev/h5X3p2+rThvFRg==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/HcUoNvcKEkWAxnrqI9tBgxXW55Y>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2019 06:17:39 -0000

On 2/3/2019 1:51 PM, Fernando Gont wrote:
> On 3/2/19 17:19, Ole Troan wrote:
>> Christian,
>>
>> The router cannot in its RPF check determine the reason for the wrong source address. If its spoofed or a previously valid address. Therefore code 5. 
> Before anybody proposes reactions to code 5, please remember that GTSM
> is *not* enforced on ICMP errors, nor dor they ned to use any specific
> source address. i.e., they are trivial to spoof, and make an obvious
> attack vector unless simply considered "soft errors".

Sure. But then, devices can the code 5 Dest Unreachable ICMP as a hint.
They could for example solicit an RA, and check what prefixes are
currently advertised. If they learn a new prefix, they might want to
configure an additional address.

-- Christian Huitema