Re: 6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]

神明達哉 <jinmei@wide.ad.jp> Wed, 20 February 2019 19:44 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1D3130E6A for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 11:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Zm7iVcz5kIt7 for <ipv6@ietfa.amsl.com>; Wed, 20 Feb 2019 11:44:23 -0800 (PST)
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 A18DD130E7E for <ipv6@ietf.org>; Wed, 20 Feb 2019 11:44:22 -0800 (PST)
Received: by mail-wr1-f42.google.com with SMTP id t18so27490092wrx.2 for <ipv6@ietf.org>; Wed, 20 Feb 2019 11:44:22 -0800 (PST)
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=V/k1awgOcL3YffwijzhJg9ZTkZ8VDvnwtLFXoDmiA+A=; b=J2DzbS8ipE5ptaUPjsK6Lyt4mMHrdQmwMB20c5CcPC0FUIYBdEMvkrZYULMaP9YdNo rQGecDck/IrI4sYMOwhu07kosgSSro2ELZFjQySxsoFfUtMUWwL9Xx+JWcMd/cFHv7/Q A3NQ7hEfaDQyUCa0k3PykrcI/I9Bct78uVx4sc4mY5BluyexPHWYQn9Ga1fhCK2vkeV+ a7EARNX6TeIB6Y3GoNUeDxj0RUW07HoaNnpEap5Os5rT3XtRvgX+OheyTvhV2UvcFYaT AtOIgb6HnXlTw1dv2cz/OnNGu9yplMGBMDioGZD+IAECAVYztXHe3FAndfRdtTv1t6cE Fmiw==
X-Gm-Message-State: AHQUAuaWTFgOTzttvPyEuFGJ6Hoy+z3NjOSlFoUejo4OMM60gBq3oB+x egL4VvjhaZGAkXu2WyA78oYwk5cgmK0fDQHGcY0=
X-Google-Smtp-Source: AHgI3IawAqYe2Xee3MBOUBP96EVNcLVhObmsEhHWpA4uS91K3w6GBbfEo+MS+fcD0L7mV4WAFA1dyJDFGa9ZS/3Qoj0=
X-Received: by 2002:adf:f103:: with SMTP id r3mr27998483wro.50.1550691860657; Wed, 20 Feb 2019 11:44:20 -0800 (PST)
MIME-Version: 1.0
References: <60fabe4b-fd76-4b35-08d3-09adce43dd71@si6networks.com> <CAHL_VyCN8kU7qnLOphfGR25-xGBe_p6WeGTkKVXwU5uy5aJ8Dg@mail.gmail.com> <65DB4854-97D2-4C31-A691-2CD93812EF93@consulintel.es> <CAHL_VyCMpCcGkEQu+RV1GRf2QLB-HD0+AOOBV0YhfQ5sbydVzQ@mail.gmail.com> <8CE7A0CD-97D9-46A0-814D-CAF8788F9964@consulintel.es> <e3e0bf2273e04f15b792665d0f66dfe5@boeing.com> <4c5fab33-2bff-e5b5-fc1d-8f60a01a146d@go6.si> <b4525832-9151-20bf-7136-31d87ba6c88d@huitema.net> <463f15cf-2754-e2e8-609d-dc0f33448c6c@go6.si> <ff649810-7242-7bc2-d36f-3f998f7bdd71@asgard.org> <9CDF41CA-83B4-4FC4-B995-EF79727C5458@steffann.nl> <CAO42Z2wA+vLmU7+sU6xLK7TO6pWfNQA5shs9zp=PqANCihLmBQ@mail.gmail.com> <BAB3061A-1808-4C0E-AA1B-2D7DD5BA63FC@employees.org> <bbd8b761-403a-5b3f-3f04-dc3bfdea116e@foobar.org> <6F3036C6-50A1-43C6-B554-31293B69E59D@employees.org> <433607c1-dbc6-a42e-cb17-dc209e33bdaa@si6networks.com> <12EA4FAE-BE3D-4CFE-9837-DF052F79A998@employees.org> <3f38c28b-76c5-6f07-c271-777f1374737a@gmail.com> <bb630d79-d134-5109-ebc1-3b6a2f1463b3@si6networks.com>
In-Reply-To: <bb630d79-d134-5109-ebc1-3b6a2f1463b3@si6networks.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Wed, 20 Feb 2019 11:44:09 -0800
Message-ID: <CAJE_bqfeAzS6ac5AVgQ6v8gNCUncmqshewLmkyoV1rYMGFwaxQ@mail.gmail.com>
Subject: Re: 6renum alive again? [A common problem with SLAAC in "renumbering" scenarios]
To: Fernando Gont <fgont@si6networks.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000082c8b5058258951e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fUcubn_nj5KRjC6JHqMQRomTyWE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 19:44:25 -0000

At Wed, 20 Feb 2019 02:03:52 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> 10.1.  Address Configuration
>
>    o  RA Prefix Lifetime Limitation
>
>       Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime
>       is greater than 2 hours or greater than RemainingLifetime, set the
>       valid lifetime of the corresponding address to the advertised
>       Valid Lifetime."  So when renumbering, if the previous
>       RemainingLifetime is longer than two hours, it is impossible to
>       reduce a prefix's lifetime to less than two hours.  This
>       limitation is to prevent denial-of-service attacks.
>
> This seems a flaw in RFC4862 to me. Me, I think ND security boils down
> to: modulo some basic sanity checks, you trust the RAs, or you don't.
> There's not much of a point in sanitizing the Prefix Lifetimes and then
> honoring Router Lifetimes of 0, or even blindly trusting RAs that would
> make you configuring addresses from invalid prefixes, RAs that might
> override your preferred router with one with higher preference, etc.

I don't remember precisely how we decided to introduce this
restriction in RFC2462 (it first appeared in 2462, not 4862), but I'm
at least pretty sure everyone understood that "ND security boils down:
you trust the RAs, or you don't".  It should be just that it's not
necessarily always all-or-nothing (with which we would never have to
worry about neighbor cache exhaustion or bother to introduce RA guard,
for example) but about providing a safety net when its benefit is
deemed to outweigh the cost.  In the case of the "two hour rule", I
guess (again, I don't remember the precise discussion at that time)
the consensus was that the resulting address stability against
operational errors or minor mischief is worth adding the additional
complexity to the protocol; no one naively assumed that's a strong
security measure against determined attacks.

As usual in such a case, different people can have a different sense
of balance, so it's not surprising if someone disagrees with this
consensus.  So I don't think it's necessarily a "flaw" in the spec
simply because you have a different view on this particular tradeoff.
On the other hand, it's possible that we now might reach a different
conclusion if we had this discussion today: people may revise their
opinions, actual experiments and/or technology evolution may suggest
revising the original tradeoff considerations, etc.  If you think
that's the case, you can always start revising the spec with a "The
two hour rule in SLAAC is considered harmful" draft.

--
JINMEI, Tatuya