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

Mark Smith <markzzzsmith@gmail.com> Mon, 04 February 2019 06:58 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA2B130DE4; Sun, 3 Feb 2019 22:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iiPQqwu16kw0; Sun, 3 Feb 2019 22:58:02 -0800 (PST)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 292DA126CC7; Sun, 3 Feb 2019 22:58:02 -0800 (PST)
Received: by mail-ot1-x335.google.com with SMTP id 81so11359868otj.2; Sun, 03 Feb 2019 22:58:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MzDyh1S9t2tpeo8WWZtGjITCYsFLc4Q91qh+JmNkxFE=; b=RC8HY176WI+bc61uRQ14y77HXRFea1+UqEAMRfatg0kuBIPlaKG2RxBwVxqLsUswie pPkNXdogmOYkRagNxEvbO/Z8YlHBXcn4faO1jo1gJZqiQcIgUh4xdXdr45nH9F1dYHQr BbRu2Pd0DIiTSLLvtitDwajkuvvjAnp38YCC0B99NsSXoq9pHgsTJQ91zr4u9e9mxO0t jXkhlRYOLTFvcQMa3pCJmOgmeUS2C2rp9Pm//WB961pc9ebaion21EPj0R8cKN9FOfz3 +xx9QXmgPLIgKk4vCq+vNYdqK8OSuYr5POKhzF5clfnaXwrX0MtJ6TIpodQFDMBjONa1 ljwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MzDyh1S9t2tpeo8WWZtGjITCYsFLc4Q91qh+JmNkxFE=; b=oxp0117xyKTn8V8L+DDzBkrQh/Wjfs/zxMr7KCON7fHQ5tEtxCVENcXzSXoQ6N9+O7 vK8hRnUaXUdqZGEk2PFmm3WX/GGs3WV3Q7em93TrklRBIKvZ/3LvJNLdl9z6RrwOYnIJ cSRJQju+5i1o1Q5LIagBx4+sfrQLlKx0R2bhcQHOBNnjvy4J5nxe072PM0EveHhmX0AK +0Ep4WBIaGJD/dx+5tgjAuWUCXGRWM3L/kg37unTFE/59E+WT2D5VHnB4gYAVSwKBfk5 ripN35DNagmSWoC+WeA6KDsOaLTR+o1s5d+z0FJOkBfvFN6Zo97Wj0TkfpXWPgp5wMwR 315Q==
X-Gm-Message-State: AHQUAuaPXe9JLyO+M6C2Fkj7Q4HcROarBc9sS6xXcB6Kb3J8LvUkBcqd lVUIYnGlXtn62fedanvPohmvncQFLvfPojnbo28BmQ==
X-Google-Smtp-Source: ALg8bN7MmLPD0cKRbfRvAIy7KrN1pC4qLs8JEcNhp/GEN96QizdMznin/QSbdKG7xkJmIBta4wMnYtR0DpsvfV/CZtA=
X-Received: by 2002:aca:2807:: with SMTP id 7mr26100155oix.7.1549263481205; Sun, 03 Feb 2019 22:58:01 -0800 (PST)
MIME-Version: 1.0
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> <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net>
In-Reply-To: <6e077b15-073a-3c55-1a77-6f49f8b3b648@huitema.net>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 04 Feb 2019 17:57:49 +1100
Message-ID: <CAO42Z2y=BtZgRTX5Ljxg8xmMr=P1Djm9CPGpWNVhxo_Oy7Fj2A@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Fernando Gont <fgont@si6networks.com>, Ole Troan <otroan@employees.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000075f88305810c0333"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VLyhvA25IoKYNp8cWZCSX3AOAKc>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2019 06:58:04 -0000

On Mon., 4 Feb. 2019, 16:44 Christian Huitema <huitema@huitema.net wrote:

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

Possibly a prefix deprecating RA could be sent in parallel to the ICMP
message, rather than waiting for the host to solicit one. It could be
unicast, or probably more usefully multicast, rate limited.

The deprecated prefix length of the old prefix would need to be assumed,
probably quite accurately to be the common prefix length of the newer
prefixes on the interface, and likely /64.

A unicast deprecating RA with a /128 PIO that matches the source address is
an interesting idea, although probably wouldn't work, because I assume
there is prefix length checking upon lifetime updating when receiving PIOs.


Regards,
Mark.


> -- Christian Huitema
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>