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

Owen DeLong <owen@delong.com> Fri, 01 November 2019 16:17 UTC

Return-Path: <owen@delong.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 E34AC120954 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 09:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 (1024-bit key) header.d=delong.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 x14hgcy44fw4 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 09:17:49 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 7021D1208FA for <v6ops@ietf.org>; Fri, 1 Nov 2019 09:17:49 -0700 (PDT)
Received: from dhcp-220-72.meetings.nanog.org (dhcp-220-72.meetings.nanog.org [199.187.220.72]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id xA1FR3Vn010266 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 1 Nov 2019 08:27:08 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com xA1FR3Vn010266
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572622029; bh=75Qq72Z5x1NxQtKCwDmiFxUG1N8myUYj0FtMakDilps=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=x5imAAGxBpZ425agjal/JnVUIkXATk8cBxdsKDqAKCHJ7uyKCvHH9/1CWbtcw7L/h ePj2onC1XUQUqpMaigHis8eVmK7EIHelThYTX8Swx7Mycql/1wLBN/g55TqoAes3NM pdk8oiFKEDqEZBqUBj4M1HptN2a0UFwr0+ZIxQD0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <95cbe3d9-191e-c6e1-cb42-305686ef1e42@si6networks.com>
Date: Fri, 1 Nov 2019 08:27:02 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <51E4F723-C5DF-4FB1-A72D-6A66B9CBF0F6@delong.com>
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <7C913CC2-938F-449C-9750-85C36EC05E38@delong.com> <48c864c7-589d-23cf-417e-6f4ec012a76a@si6networks.com> <7C142F1F-04C6-48A2-A65A-7CADD3691ECF@delong.com> <8dbfb1b6-5efa-019f-313b-e8045ee277ee@si6networks.com> <A97CB183-B7D0-42F3-A6C5-0224049936F1@delong.com> <95cbe3d9-191e-c6e1-cb42-305686ef1e42@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 01 Nov 2019 08:27:09 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/81oVy2VCZsnBXtVdoQIcDypLcDs>
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 16:17:51 -0000


> On Oct 31, 2019, at 7:04 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> Hello, Owen,
> 
> On 31/10/19 16:27, Owen DeLong wrote:
> [....]
>>>> 
>>>> I’m not sure what I could do to elaborate. The addition of a specific
>>>> call-out that
>>>> even if the current behavior of ≤2 hours = 2 hours is to be preserved,
>>>> there should
>>>> be a special case for “0 seconds” which causes the prefix to be immediately
>>>> deprecated with extreme prejudice.
>>>> 
>>>> Hosts should be required to treat an RA containing a prefix with a 0 second
>>>> valid lifetime as an invalid prefix and immediately deprecate it from
>>>> the interface
>>>> if it is in use.
>>> 
>>> OK, so you do agree with the proposed change? (in
>>> draft-gont-6man-slaac-renum, not in *this* document)
>> 
>> From the context of my thinking at the time of writing the original reply,
>> “this document” referred to draft-gont-6man-slaac-renum. Apolgies
>> for my lack of clarity as you have apparently interpreted it differently.
> 
> Ok. BUt, double-checking: DO you agree with the proposed behaviour?

I agree that a host receiving an RA with a PIO containing a 0s preferred lifetime should
immediately deprecate the prefix from the interface and send an appropriate exception to
any open sockets bound to that prefix.

While this can be a significant DoS vector, any environment where that is a concern already has a number of other significant DoS vectors from malicious RAs anyway.

> 
> 
> 
> 
> [....]
>>>>> 
>>>>> Even with the default RA frequency, if you were to unprefer a prefix
>>>>> upon, say, second RA that doesn't advertise it, and say, remove the
>>>>> prefix after many other RAs are received, that would be a *big*
>>>>> improvement to what we have now.
>>>> 
>>>> I don’t like this idea because I can think of some scenarios where you
>>>> may receive multiple RAs from router A not containing the prefix in the
>>>> same time frame that router B has not sent an additional RA containing
>>>> the prefix, but it will do so in its next RA.
>>> 
>>> Maybe it wasn't clear in the I-D, but the basic idea is:
>>> If you receive multiple RAs from router A that do not advertise the
>>> prefix, then you disassociate such prefix with router A. If nobody else
>>> is advertising the prefix, you'd deprecate it. If other routers are
>>> advertising it, this would not change the status quo of the prefix wrt
>>> such other routers.
>> 
>> That’s definitely not how I interpreted the I-D and I would strongly encourage
>> you to review and update the I-D for clarity in this area. I’m actually still not
>> 100% convinced that this is correct behavior. It also places additional burdens
>> on hosts to track all routers associated with a given prefix rather than merely
>> tracking candidate default gateways, RIO data, and one set of prefix timers
>> utilizing the most recently received timer refreshes.
> 
> Thanks for the feedback! I will definitely clarify the text. FWIW, in
> the context of RFC8028, you already need to keep prefixes associated
> with routers….

I’ll have to reread.

Owen


> 
> 
>> 
>>>> There is no requirement for all routers on the same link to provide the
>>>> same set of PIOs, nor are they required to use the same advertisement
>>>> timers.
>>> 
>>> Agreed. Please see above.
>> 
>> With the above clarification, I think it can be done and is less likely to break
>> things. However, it does place a significant additional tracking burden on the
>> host which I’m not entirely convinced is a desirable situation. Especially in the
>> case of a resource-constrained host which is using SLAAC to avoid the overhead
>> of DHCP.
> 
> In the context of RFC8028, you don't have much of an option -- otherwise
> you run the risk of being egress filtered.
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
>