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

Fernando Gont <fgont@si6networks.com> Fri, 01 November 2019 03:07 UTC

Return-Path: <fgont@si6networks.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 565D3120860 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 20:07:33 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 TnB8FLmwcrao for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 20:07:31 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83A612006D for <v6ops@ietf.org>; Thu, 31 Oct 2019 20:07:30 -0700 (PDT)
Received: from [192.168.1.36] (unknown [177.27.208.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2C2608671F; Fri, 1 Nov 2019 04:07:27 +0100 (CET)
To: Ted Lemon <mellon@fugue.com>
Cc: v6ops list <v6ops@ietf.org>
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>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com>
Date: Thu, 31 Oct 2019 23:27:19 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jERaAkCJ9O_NRj27-gqaK2rmpi8>
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 03:07:36 -0000

On 31/10/19 16:34, Ted Lemon wrote:
> On Oct 31, 2019, at 3:21 PM, Fernando Gont <fgont@si6networks.com
> <mailto: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.

For the home network case, the situation right now is that there are
deployments that break, and ISPs meaning to deploy IPv6 that can't do
stable prefixes. Certainly, that's a very bad strategy on our side.

That said, and as noted, the home network case is just *one* scenario
where this problem may be faced. And a subset of the mitigations for
this scenarios are useful for the general case.



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

Nope. The default user timeout is 5 minutes as per RFC793. (The first
para of the second page of RFC5482 provides a summary wrt the
specification of the user timeout).




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

For many reasons: one of them: two different routers might be using
different values for these timers, in an un-coordinated manner. And
there's not reason for which the smaller or larger lifetimes should
imply an address is preferred.

OTOH, you might thing about preferring "the last advertised prefix". BUt
that would mean that src address would flap, which is bad for
trouble-shooting.


> 
>>> 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”?

Sorry, for that: First Hop Security, Cisco's speak for RA-Guard, ND
inspeaction, and so on...




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

Is there any of the proposed fixes that we shouldn't be doing, already,
anyway?


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

The point is: in a network where you do not employ RA-Guard, you are
already trusting the router. Actually, it's worse: you trust all local
systems.


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

Exactly: that's the point: you already trust the local network. What's
the rationale for trusting one of the RAs, but not the others?


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492