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

Mark Smith <markzzzsmith@gmail.com> Fri, 01 November 2019 00:20 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 81249120105 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 17:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.496
X-Spam-Level:
X-Spam-Status: No, score=-0.496 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=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=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 Xc30Mz7SZc1l for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 17:20:39 -0700 (PDT)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 E203F1200EF for <v6ops@ietf.org>; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
Received: by mail-oi1-x236.google.com with SMTP id v186so6831222oie.5 for <v6ops@ietf.org>; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
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=TPjVaNG6mqGXCUY83DF1Xk3jt1L0XQqGUT6Vzi7WqK0=; b=thOSRrFcA1JHVDXps7CEwW9ylctLH3ZP41ft+Tnd1SLi1lTE49s1XzmHR0kF27IIIF DJhfbAbRi9jH3lVvH5IB9g5YmtT1rSZHNXQi70F5pXcJ2XTtKlGiy81bWqmO68cOT2EB xNqKk83itRTk3uAn4VJvmLPDwp1mjQ3eFharKMTqBkMT+XonywXOqK214u5LJ0Ct2+/9 GvZ1g5jwigLCKi1AzFulDcn1GfAq02PSDXSxgmSb3Sz8QKdKf3p8MoZmrjUDfmg3i0St mWfMVwCh7lhn/hGr1fiMFcqvVFS8nJQfY4Dp6T1mbAIa0nnjVAiKNzb0gpudc6KBac8e ZipA==
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=TPjVaNG6mqGXCUY83DF1Xk3jt1L0XQqGUT6Vzi7WqK0=; b=P6OTOEKH9nay/MUMc9Xn9XLFBNN2FsrTuDYNjsGuh445/ejnT8EQ0DvFsXDeL3k3p+ JM+yQgtEoVoYQA7Hm3d9tdIqQlnZ27+UvsYNHGMbrZGncCjoBCe7xdtHc9r1YPfIn3UT kLcTmsMXc7B/5NI1UbQxAZ5Exma2CS8EhDKyEOkF57iaUUFCVVjwjcl8CyA6L8A83S+C hBtijZaXZjodD+WnnLvv084jyj2+sDqyhG/qYKmf1ZoOut6d6nJ7vLZxlr5aoOi64isi 6fk7mD9IW+JYdcnBrewFC8vYjwzqatoaqqiKuDRagxcvkCdCewL4YpSZsobOaDdGk34/ /nDw==
X-Gm-Message-State: APjAAAU3Fm/j7lqBmj5bFM01lBq3oiPt0K8I3HR92WkP3HY56cK9DxGd sKngFvxKA7Z2CpcNU+1HcMcxcxfOUql+13xCYg4=
X-Google-Smtp-Source: APXvYqy5aS7RYcc415J2c6dE43rF76+xxf5Qyh5+M86Q/vrN0KCLBGiTTUa6q/S5p1CCK5OdDq7Vl02xUXdwkJsvWLo=
X-Received: by 2002:aca:f553:: with SMTP id t80mr457506oih.60.1572567638166; Thu, 31 Oct 2019 17:20:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com>
In-Reply-To: <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 1 Nov 2019 11:20:27 +1100
Message-ID: <CAO42Z2w5kDSMXCUTM3nQNO_Jhm0ShTo9OW_njLsno7Dhk7LLdw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Fernando Gont <fgont@si6networks.com>, v6ops list <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007550a305963def58"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/VdMpe6tK3MIJL6T7lqFmG1YqzDg>
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: Fri, 01 Nov 2019 00:20:40 -0000

On Fri, 1 Nov 2019, 06:34 Ted Lemon, <mellon@fugue.com> wrote:

> On Oct 31, 2019, at 3:21 PM, Fernando Gont <fgont@si6networks.com> wrote:
>
> On 27/10/19 09:02, Ted Lemon wrote:
>
> 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?
>
>
> Did happy eyeballs encourage broken IPv6 connectivity, or did it
> actually help IPv6 deployment?
>
>
> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the
> situation.   I am saying that we should be strategic about 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.
>
>
> ~9 minutes, IIRC.
>
>
> Should be 90 seconds.
>

You've got no more than 10 seconds unless you want end users to actively
try to do something to recover, which can include calling their ISP's
helpdesk.

A short presentation on some user experience factors for network engineers.

"A bit of UX for NEs"
https://www.slideshare.net/markzzzsmith/ausnog-2019-lightning-talk-a-bit-of-ux-for-nes



>
> 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.
>
>
> That's not correct. Neither the Valid Lifetime nor the Preferred
> Lifetime affect address selection.
>
>
> Okay, there’s something to fix.  Why would these not affect source address
> selection?
>
> 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.
>
>
> The reality with ND attacks are (modulo sanity checks on the packets):
> you enforce FHS, or you don't.
>
>
> What is “FHS”?
>
> 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?
>
>
> Every piece helps.
>
>
> Right, but if the effort involved in two different options differs by
> epsilon, you should always choose the option that produces the better
> outcome, shouldn’t you?
>
> 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.
>
>
> What's the practical difference between that, an a network that supports
> RA-Guard?
>
>
> On a network that supports RA guard, there probably is no difference, but
> RA guard on some networks, as we’ve discussed in the past, will actually
> make the network not work.   RA guard requires an active administrator.
> So the CPE case we’re talking about isn’t relevant.
>
>
> 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.
>
>
> In the non-SEND trust model, you do trust the local router. Why did you
> trust the local router to configure your network, but not for
> deprecating the prefix?
>
>
> In the non-SEND trust model, you trust the local network.   You *hope* that
> the RA you get “from the router” is actually from the router.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>