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

Philip Homburg <pch-v6ops-9@u-1.phicoh.com> Sun, 27 October 2019 20:02 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.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 651C4120052 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 13:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 0jK0klwLAYR8 for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 13:02:37 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC97120046 for <v6ops@ietf.org>; Sun, 27 Oct 2019 13:02:36 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1iOokE-0000KvC; Sun, 27 Oct 2019 21:02:34 +0100
Message-Id: <m1iOokE-0000KvC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <m1iOk6q-0000IyC@stereo.hq.phicoh.net> <855496CB-BF7E-41E6-B273-41C4AA771E41@fugue.com>
In-reply-to: Your message of "Sun, 27 Oct 2019 13:14:59 -0400 ." <855496CB-BF7E-41E6-B273-41C4AA771E41@fugue.com>
Date: Sun, 27 Oct 2019 21:02:24 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-zzZGn1ChtciKGx8ddZGpVRKDYk>
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 20:02:39 -0000

>    I think you missed my point.  You can't do flash renumbering by
>    advertising a prefix with a valid lifetime of zero, because that
>    will be ignored by hosts.   If it were not ignored by hosts, it
>    would be a very effective DoS vector.    And so if you want to
>    be able to flash deprecate a route, you need some way to validate
>    that the deprecation is coming from the same source as the route.
>    Hence my suggested "limited SEND".

Today, you can deprecate a prefix by sending an RA with the preferred lifetime
set to zero. That is enough to get IPv6 at the same level as IPv4.

Without RA-guard or SEND there are already quite a lot of opportunities to
perform both a denial of service attack and a man in the middle attack
on a local LAN.

I'm not sure if the protection against advertising a zero valid lifetime
is actually worth it. Any network that worries about local malicious 
hosts probably already uses RA-guard (or possibly SEND). 

In any case, it doesn't matter to the CPE whether the host will accept
zero valid time or not. The CPE can just send them and then a separate
document can either instruct hosts to accept all RAs with zero valid time
or require some for of SEND.

The key thing is that without any protocol modifications we can get IPv6
at the same level as IPv4. 

If we make more extensive modifications to the host, then there is no 
reason to rely on RA timers and the host could handle unmodified CPEs.