IETF Logo Mail Archive

Re: [v6ops] ipv6only-flag-02 security

Ole Troan <otroan@employees.org> Wed, 19 September 2018 19:02 UTC

Return-Path: <otroan@employees.org>
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 BA87E131072; Wed, 19 Sep 2018 12:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 j_HnSgzYDHqM; Wed, 19 Sep 2018 12:02:20 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237801310DF; Wed, 19 Sep 2018 12:02:18 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id 2F85FFECBC77; Wed, 19 Sep 2018 19:02:17 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 18D87635A3E; Wed, 19 Sep 2018 21:02:15 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <5A0F0BE1-DDDD-494C-9626-68751730ABF6@apple.com>
Date: Wed, 19 Sep 2018 21:02:14 +0200
Cc: David Farmer <farmer@umn.edu>, Philip Homburg <pch-ipv6-ietf-5@u-1.phicoh.com>, V6 Ops List <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <112EDEC9-D5C1-41F9-AD5B-F8F6F5CBC72D@employees.org>
References: <2D09D61DDFA73D4C884805CC7865E6114DEA863A@GAALPA1MSGUSRBF.ITServices.sbc.com> <270E7E7C-D2C7-4725-939C-7B48C4558D72@jisc.ac.uk> <CAO42Z2zqivtrvcGgvS5KEJy6pquRp-m79ooBvR7ob4PBpnUP4g@mail.gmail.com> <fa723433-11da-f785-4e07-70cd5b661f05@foobar.org> <cd8c2e56-2cb7-644b-10c9-9bc7aa74b935@gmail.com> <6f23d206-5052-aadf-fb3a-9c39acd41ce7@foobar.org> <065d4d34-23a0-b8c9-83e0-e8ccf78d31c5@gmail.com> <d893d148-c087-81e4-9e83-806fdc136c9b@foobar.org> <CAO42Z2zs9AWf8D8rtYiyyKTbKRsajgS9UVferu=itUPfHcFp9A@mail.gmail.com> <m1g2O32-0000GmC@stereo.hq.phicoh.net> <d012fea0-aa37-d41c-5f30-eaf18449ae21@gmail.com> <m1g2a1R-0000GmC@stereo.hq.phicoh.net> <15B65172-138E-434B-B51A-C2CC3AF536AF@employees.org> <m1g2bCA-0000GqC@stereo.hq.phicoh.net> <CAN-Dau0iRaBwsd1_gSm7kNJyfJErAtn+7KxExs-URFu_Epa2JQ@mail.gmail.com> <98C88286-F47E-4B02-A303-F4317A5A6482@employees.org> <5A0F0BE1-DDDD-494C-9626-68751730ABF6@apple.com>
To: David Schinazi <dschinazi@apple.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DB-CeydWUBHEleNGy4P7Y4MSdjA>
Subject: Re: [v6ops] ipv6only-flag-02 security
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: Wed, 19 Sep 2018 19:02:28 -0000

David,

>>> I'd like to suggest we not completely drop the IPv6-only flag work, at least yet. I like us to talk with the DNSSD WG and probably DHC WG too, maybe they will think it is the way to solve these issues or maybe they have better solutions. 
>> 
>> What’s the worst that can happen if we standardize this bit?
>> 
>> Given that it appears mostly harmless, I don’t see a big risk in standardizing it.
> 
> This is not harmless. It costs us a bit from a limited pool, and will cause issues when trying to deploy the next version of IP after 6.

We have RFC5175 so this is hardly a scarce resource.
The next version after IPv6? I certainly hope that’s going to be something a little more creative than existing within this version space…

> This problem can be solved at other layers. If the authors want to bring a draft to DNSSD recommending that hosts do not send mDNS over IPv4 link-local when there is routable IPv6 present, that would be a welcome discussion.

It’s not quite obvious how mDNS can be repaired. Or if it’s worth the effort, over something as simple as a single flag.
Disabling IPv4 link-local has more promise. (Although it would have been nice to able to disable mDNS for IPv6 too.)

Cheers,
Ole

v2.23.0 | Report a Bug | By Email