Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))

Fernando Gont <fgont@si6networks.com> Fri, 17 November 2017 07:46 UTC

Return-Path: <fgont@si6networks.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 53AA8128C81; Thu, 16 Nov 2017 23:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UekRFtkjyWXH; Thu, 16 Nov 2017 23:46:37 -0800 (PST)
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 CD95212741D; Thu, 16 Nov 2017 23:46:36 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909] (unknown [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909]) (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 4C27480C3F; Fri, 17 Nov 2017 08:46:32 +0100 (CET)
Subject: Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Suresh Krishnan <suresh.krishnan@gmail.com>, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Cc: Ted Lemon <mellon@fugue.com>, Mark Smith <markzzzsmith@gmail.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
References: <be9724f5-2ff5-d90c-2749-ecae2c628b78@si6networks.com> <ea772bfd-4004-7f94-8469-b50e3aff0f29@si6networks.com> <F2330138-6842-4C38-B5A0-FB40BFACD038@employees.org> <e40697ca-8017-c9d2-c25d-89087046c9cf@gmail.com> <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <CAKD1Yr26NK2osApYZBm8Yd=0X7xcetrxojp6=JHOEAu9BB0q8A@mail.gmail.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <E67105A3-396B-403C-B741-E9E01CFB5CE7@employees.org> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <AM5PR0701MB2836C00EA1AAC73E7E63F583E02B0@AM5PR0701MB2836.eurprd07.prod.outlook.com> <CAO42Z2xacRco7ne7biQ93so0k-x4xSnM2jzoB13-sdVRLshQDQ@mail.gmail.com> <CAKD1Yr0Zz6Jxg_ZuEbBkMhBdEaZKOrtx-eUns7KWi9v-5PDBzg@mail.gmail.com> <CAO42Z2xqwRH94dw=XJf5mt3STdDcTYmB_i1NbXP46shdJQeaPA@mail.gmail.com> <E7F9E3EF-B5AA-4698-8BBC-772228129277@fugue.com> <AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280@AM5PR0701MB2836.eurprd07.prod.outlook.com> <F762F88F-ABCE-4B91-BA75-66D464420AEE@gmail.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <bff593fe-db26-46e8-c7dd-18203f9780f2@si6networks.com>
Date: Fri, 17 Nov 2017 15:44:57 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <F762F88F-ABCE-4B91-BA75-66D464420AEE@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zk2CjIbNH7hXAA9aqzdpsUQS_I4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 17 Nov 2017 07:46:39 -0000

Hello, Suresh,


On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> Hi all,
>   I would like to summarize the issues that have been brought up, along
> with my views (I apologize for the long mail but I think it is warranted
> in this case)

Thanks for the summary!


> b) Mechanism does not work
> 
> Given that the mechanism has been implemented and deployed by the
> authors, I have a hard time taking this claim at face value. Providing
> an unique prefix per host has been standard practice in 3GPP mobile
> networks for the past *15 years*. based on recommendations from the IETF
> back at that time. When a mobile attaches, there is state created on the
> first hop router that does exactly what this draft wants to do. The only
> issue I see is a lack of mechanism to clean up stale prefixes if the
> hosts go away, but depending on the deployment this may or may not be an
> issue.

I don't think anyone has argued that the mechanism "does not work".

The issue raised has had to do with two things:

1) Reduced resiliency of SLAAC as a result of the required (previously
inexistent) state

2) The security implications associated with 1)

This means that SLAAC can break in new ways, and also that attackers can
attack SLAAC in new ways.


FWIW, the motivation for raising this discussion was the reduced
resiliency and reduced security of the corresponding deployment of
SLAAC. Essentially, it was either "bad timing" (on my side, as it
happened), or "worse timing" ( on my side, too -- i.e. not raise the
issue at all, and then just see the aforementioned issues happen). The
fact that the document is bcp made the above considerations even more of
a concern, since we are telling all IPv6 deployments that this document
is the way to go.

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