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

Ted Lemon <mellon@fugue.com> Sun, 27 October 2019 12:02 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 83A66120128 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 05:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 0aQPMGAk4SU0 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 05:02:43 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 3D39F120127 for <v6ops@ietf.org>; Sun, 27 Oct 2019 05:02:43 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id z22so10452334qtq.11 for <v6ops@ietf.org>; Sun, 27 Oct 2019 05:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:date:message-id:subject :in-reply-to:references:to; bh=xsfbM29se1bIrATOvUFzH5SYbJmvD4Lxdznb8ypCsIg=; b=eEC/aouINY97f2+SW5SyOrbcYpjpNCEByOGL9YUEIAiwFx6/nr8ZvDx3wgojpHXNZt RXLwimtK7NW5XmmtJm54i7SJ8v0NzxLcTRbtoqw5SfMuGgKBNIC8DgXgMxTEFW8GoMf9 Zdk5Ft/p2PGeoYIfEWf7tzUvxpX2S1OFoyzLizkbBiJXXLMSlHLNR9SKRF3jeZibqK6I d9ba16oTwUWNhlio4Q/CI2W+bX1UgIMXmTGVmERPcl5BeS8Fn+SRJY8G6o+2nzBk8Yym 50fvDJAMCewVQBVl9YRKAC/+qCBf5XuceQKCoB5V2L3s0czYRfJ8YRQRneQ6FBJ86mqS qVSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :message-id:subject:in-reply-to:references:to; bh=xsfbM29se1bIrATOvUFzH5SYbJmvD4Lxdznb8ypCsIg=; b=ki3Z+KAwxeiqLRA9IBEuIiolWYXUK7KnXgVWxWJbivvdTgRetDybCH+WlXLZbFSvle 8gJ9U4XTLZvTCXBlPlfBLNZ4bwsTxZsLXOZq0WFxsgvcoWuoTwkx3xyMKze4h5ASv5V4 Il9yCqtkSyN+YrLKIftOiaIopOB71PknJrmhXpi6tjMzABLRXhydP5BFDrskTuHibFw/ eLYN9VEl7lxd8mt/9ig1G/tAc4r1rGQ9R7pXO9lQ12s35mWbF8iwf5qei0FRd7Af1S3T 9mgcYax+5RUndeCTVJ2WRkQ7NfJgOKZo4IukiXsvmca+Bq3v9SC17BR2Wnn7Ch/1e7M3 EvKQ==
X-Gm-Message-State: APjAAAWuzXWYeGGGu/9aaFmRG24iRJf2LRfQTar6a3hcSg5C/wVhJBPg pCMZ+ZmbqZGrxIJ0try8cNSerz5oIUpDJA==
X-Google-Smtp-Source: APXvYqzeJF4pfeJQZQ2eoxjzIJgV1MHLPRV/Md+c0eAMtWK4enjjVQrK5FAGhYdlvsZdFZkWBT5ySQ==
X-Received: by 2002:ac8:7006:: with SMTP id x6mr12491217qtm.152.1572177762008; Sun, 27 Oct 2019 05:02:42 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:2097:1591:d7c2:2263? ([2601:18b:300:36ee:2097:1591:d7c2:2263]) by smtp.gmail.com with ESMTPSA id o201sm1207149qka.17.2019.10.27.05.02.41 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 27 Oct 2019 05:02:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 27 Oct 2019 08:02:40 -0400
Message-Id: <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com>
In-Reply-To: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com>
To: v6ops list <v6ops@ietf.org>
X-Mailer: iPad Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/E1HTRqsR1WTSAOhTytGvrurVguc>
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 12:02:46 -0000

Indeed, this would also not actually solve the problem.   At present, the ISPs are doing something that is out of spec and causes problems.   If we “fix” this by accommodating what they do, does that help, or does it just encourage them to continue doing it?

What should be happening on the host with a prefix that’s deprecated is that TCP connections should be timing out.   This doesn’t take very long.   And if there is a new prefix being advertised on the link, that address should have a valid lifetime newer than the old prefix, meaning that the next TCP connection should come from that new prefix, not the old one.

I think Fernando’s plan to shorten some timers makes sense, but shortening the minimum really doesn’t—it just opens up an opportunity for an easy DoS, since I can now just send out death packets to the local network and break everything all at once.

If you Really Really want to be able to have the routers send out RAs that deprecate the default route, and, as Mark is saying here, to upgrade millions or perhaps billions of hosts, why not ask for something that’s a real improvement?

First of all, fix CPEs so that they definitely support clean deprecation of prefixes using PD.  Second, fix RA so that it’s non-repudiable by a device that doesn’t have the secret key.

SEND does this, sort of.  Nobody uses SEND because it tries to solve a too-big problem and does it using obsolete technology.   But the basic idea is good: include a public key in every RA that can be used to validate that the RA was signed with the corresponding private key. 

When another RA arrives, see if it was signed with the same key.   If so, it came from the same router, and can be trusted to update whatever information that router sent, including flash-deprecating a prefix.   If not, ignore it.

This avoids the problem of validating which RAs are good RAs: you just do what you’re doing now with RAs.  But if an RA goes out that supersedes a previous RA, you don’t let it supersede it unless it’s provably from the same source.  I’m currently doing something similar with DNSSD Service Registration Protocol, using ECDSA, and the implementation has a small enough footprint to run on IoT devices.  Something like this would make SEND/CGA a bit more useful, I think.

Note that this would not be required for hosts, and hence would not create unwanted privacy properties for host addresses.   Also, when used e.g. in a hotspot setting where it might be desirable to vary addresses, that’s okay, because a new key can be generated regularly as long as the prefix on the local link doesn’t need to be deprecated.