Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Ted Lemon <mellon@fugue.com> Sun, 27 October 2019 13:54 UTC

Return-Path: <mellon@fugue.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 F0C1C120122 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 06:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 HWPziWo9ldmX for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 06:54:42 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 D075E120098 for <v6ops@ietf.org>; Sun, 27 Oct 2019 06:54:41 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id q70so6098908qke.12 for <v6ops@ietf.org>; Sun, 27 Oct 2019 06:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2Iio03ETgIJOe7kfx6oVvrXs/VJyQLD1jn5DvORlzkg=; b=DlXBzoGZIbgNOni6t2XZANMP3qTI5DN6GcaYsU2EmSw73rxfJmvEtXIeq2uIkhjxUI y/TOqF64fR7v3OGmg0Uo8CRja7HF3L2eh72HMOmcG+bl6jQdElGva8z13A8K8o3HSVTZ aslb4hWQzck+cl1uzPJiirojOe+Llzl0i0Ilp6DPiyFZ84eru+V89OdBNPO+CTiD03Gf EVQe524+y+rinROZLmN+767HLzJ3qMn8o9DvnBjQtSHZl6aR2d66B4HfVO/+89+LpuSt cu5QPzF//ckWgS93NLvxs5/L9x8vvmii1e46u+epRnnWfFP/hBDkMKrVnsE2dhhT1Ycf nKyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2Iio03ETgIJOe7kfx6oVvrXs/VJyQLD1jn5DvORlzkg=; b=DQnpvgwRmSvSFuCZE57IaODw6xQcrINLQ2B9FLBDlqUuGdZ6d/578um+uZkyBUqNvo DESUsmCHHIejZdMgCePoifA38wGi0KkvqlhXLT/pKqHDZfrb6SZftdiCzigBU0GG/4PO rO2/5Umqv108h5TVVWlUyrmm24zgxFSIzy8lsNZelKvoOAdai+up7X3osYXgUciiim43 wk6nRQ2HuKrOttEHYlwzNGZlsHdfOZfvC7t6CopQYSw5YKtNb1bpp6yxeCzj6nrv2sPb ENAv6Bx4s/4URcaFoxVVjFqYz+P4HhQdwa+vzuIVd+vQCvs3v+AIt8dqJbsqvnulzeHJ kiNg==
X-Gm-Message-State: APjAAAWyBP0cPg+mLgE0UNvLVLC6T0lWHNNMGn+VMcfBzoTp8E4iU3kC l/jna54DDg/voW6RzpBnH6dopA==
X-Google-Smtp-Source: APXvYqyNRyko6hTR9rbN2GQtECACgmt5FJ/xQTDVW2uLXK655lry2/IrrMZwz9tRsEu9/xPvP02Otg==
X-Received: by 2002:a05:620a:74b:: with SMTP id i11mr11432816qki.417.1572184480677; Sun, 27 Oct 2019 06:54:40 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:dc26:8796:798d:38c8? ([2601:18b:300:36ee:dc26:8796:798d:38c8]) by smtp.gmail.com with ESMTPSA id 44sm5491981qtt.13.2019.10.27.06.54.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Oct 2019 06:54:40 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <DC2F31E2-8CA4-483A-B1A1-6730A904BA32@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B4FF6A1-4731-4D19-921C-D1E41909455D"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.4\))
Date: Sun, 27 Oct 2019 09:54:36 -0400
In-Reply-To: <m1iOinq-0000J3C@stereo.hq.phicoh.net>
Cc: v6ops@ietf.org
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <e67f597d-93a7-3882-3a12-69519178893d@foobar.org> <m1iOinq-0000J3C@stereo.hq.phicoh.net>
X-Mailer: Apple Mail (2.3601.0.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cyCpn9Wwg-nNsbb_WRVVoXrXAto>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
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: Sun, 27 Oct 2019 13:54:44 -0000

On Oct 27, 2019, at 9:41 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
> The little bit missing is that the CPE should write prefixes advertised using
> SLAAC to persistent storage which allows the CPE to invalidate stale prefixes
> after a reboot.

Actually I do not believe this is correct behavior.   Let us assume prefix delegation.   If we have prefix delegation, then when the CPE comes back from a power cycle, it should reconfirm the prefix it had previously; the assumption is that that prefix is still valid.  This can be handled in infrastructure—the ISP edge router should know whether the prefix is still valid, because if it is it should be advertising a route for it.   If it is not still valid, then the CPE router should attempt to renew it, which would go to the DHCP server (possibly both messages would).  If the lease on the address is still valid, the ISP should renew the lease and not issue a new one.   It is a misconfiguration for some other thing to happen in this case.   This would then re-establish the route in the ISP edge router.

If the ISP wants to deprecate the old prefix, the thing to do is not to fail to renew it, but rather to renew it with a preferred lifetime of zero and offer another prefix with a preferred lifetime that is not zero.   The CPE router should in this case advertise both prefixes, with the applicable lifetimes.  Using my limited SEND proposal, the advertisement with a preferred lifetime of zero would be immediately seen by all hosts that implement limited SEND, and they would start using the new preferred prefix.  Hosts that don’t implement limited SEND would still behave correctly, but might take longer to stop using the old prefix.  This should be okay because the old valid lifetime is still valid.

That’s the way things should go when everything is working correctly.   If however the ISP’s DHCP server loses its cookies and can’t renew the old prefix, then we’d see the new behavior where hosts that implement limited SEND could immediately see that the old prefix was no longer usable, and would stop using it in preference to the new prefix.   Hosts that don’t implement limited SEND would behave as they behave today.

And in the DoS attack case, because the attacker doesn’t have the limited SEND key that was used to advertise the prefix that it is attacking, only hosts that don’t implement limited SEND would even see the attack.  These hosts would reject any RA proposing a lifetime shorter than two hours.   So the DoS attack would be useless both for hosts that implement limited SEND and hosts that don’t.