Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)
Mark Smith <markzzzsmith@gmail.com> Fri, 09 June 2017 08:18 UTC
Return-Path: <markzzzsmith@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 B9C2C129526 for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 01:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RaebTdfrdC0n for <ipv6@ietfa.amsl.com>; Fri, 9 Jun 2017 01:18:32 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 E9204124D37 for <ipv6@ietf.org>; Fri, 9 Jun 2017 01:18:31 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id 191so25531144vko.2 for <ipv6@ietf.org>; Fri, 09 Jun 2017 01:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NHZl8j+1YSxqChItg9soey+97ydQRb9N63w2197M+UE=; b=lTUGxr5zPm7t8Kl8b+i6FGr04VSrYB6kaSaC7nqkuy9SF5MkX6L/IXkYIZKW/nRqrX qJ8gFVst1B1HIJX4TjCia0vlquPEEWGyu9y39TJaho+29on2QAfYCZ7mwZU89byMOszz ZyX5jx03J7W7Povmf+y7qwxqC11co9OWIlHTBK8nHbz4WsnBNiXaR6DcUyiXuOs/HteN 5x0tFKUAHCPp4x1C+Mjo0CgzJCk/5vQ4DYfjkqbfEuPGJS2b8bGcuGVNg/Lkykk5oWv9 V7y7tdQObAW6yP7JHfugDDFbv6soy7xbfMRbqKcqWtwPNaFgDMcOvp9ZpXv2HubgzHtF gs4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NHZl8j+1YSxqChItg9soey+97ydQRb9N63w2197M+UE=; b=erUm7/dmcC9K8leHv/NH2IGCmxJ4s29Be5OmUHMI0nWlr52uT8MOj6wEvFzJ0FfJsc LgofbRaF5PRfxcDCOA3ysNJzb0sCPwYFUErrdMn62n73A8IpoW2JuPo4yLDmytYuacAN oBFEIpDscTF+9N+BB8VFOprKNkKKlcuZg0wJCn3iixZ7IoabgEHZ6o4i1Tlan6e/GTc5 ahBSe3ToRirplLxeeeJfNne8fhbhkJH4EXr6Kdy76AQZDs0FTl3yquRnfpOeqCi8cBpZ IeJL+zB1zybQhNzPYt6n9C+N170uDOZEU+1kE9KcUo00N0UgbH4cY/puJXzZvkQqr1GM txSg==
X-Gm-Message-State: AODbwcBuwpajPS84NVPApRm6HwlHBU/CGHb9iMFpWofiXTrUNhQoiSL0 4dqoWKiNl9+rCYEAU6R798W4zRi0RQ==
X-Received: by 10.31.7.72 with SMTP id 69mr5395290vkh.119.1496996310995; Fri, 09 Jun 2017 01:18:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.92.67 with HTTP; Fri, 9 Jun 2017 01:18:00 -0700 (PDT)
In-Reply-To: <CALx6S36pQe3vJS8H2s3AJ8e5ZdLaKQh+_zeb_Vu+OkOVRYp2yA@mail.gmail.com>
References: <CAO42Z2ziUZnK+n2f9N_Xvb5TZBppApXgNSmDsRLxaT1_taLvFw@mail.gmail.com> <4a6969ba-4cd3-ba30-2f3b-9ec4cc3fcf60@si6networks.com> <CAKD1Yr2x_EevJ37NnOg59Xk5+r3YYHmHEQKg_YCCSycuPpBzwA@mail.gmail.com> <bb3abd49-5ddc-076c-64a4-fe5f7dcd47d1@si6networks.com> <CAO42Z2zgRQscdJqtwSsF+BQJEQ9v9DOCrbDHU+CmZk-xC206Kw@mail.gmail.com> <CALx6S36pQe3vJS8H2s3AJ8e5ZdLaKQh+_zeb_Vu+OkOVRYp2yA@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Fri, 09 Jun 2017 18:18:00 +1000
Message-ID: <CAO42Z2yMnqTwhSBzG9KX7Ln4x_ccoQHXodgU2DLFySx4DYTySA@mail.gmail.com>
Subject: Re: Giving up security & privacy when manually configuring addresses - rfc4291bis text (Re: draft-bourbaki-6man-classless-ipv6-00)
To: Tom Herbert <tom@herbertland.com>
Cc: Erik Kline <ek@google.com>, 6man WG <ipv6@ietf.org>, Job Snijders <job@instituut.net>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="001a1143d69058d9010551829d49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bPtG1F7M5ii_DWlRviHgWorAYrU>
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, 09 Jun 2017 08:18:35 -0000
Hi Tom, On 9 Jun. 2017 13:03, "Tom Herbert" <tom@herbertland.com> wrote: On Thu, Jun 8, 2017 at 7:46 PM, Mark Smith <markzzzsmith@gmail.com> wrote: > On 9 June 2017 at 03:17, Fernando Gont <fgont@si6networks.com> wrote: >> On 06/08/2017 02:41 PM, Lorenzo Colitti wrote: >>> On Wed, Jun 7, 2017 at 9:03 PM, Fernando Gont <fgont@si6networks.com >>> <mailto:fgont@si6networks.com>> wrote: >>> <snip> > This is about raising the security bar, and with manually configured > addresses with high entropy, or RFC7217 on routers and switches out of > the box, raising it by default. If the device can't be discovered, it > isn't possible to send a packet to it. > Mark, I don't quite understand this statement. Isn't is true that If I send a packet to any IID in the prefix for a device it will reach the device and be processed? Yes. You know the IID is valid at the point in time you send the packet, meaning the IID is in use by a device and the device can be targetted with an attack. This is mitigation against discovery of IIDs assigned to devices via probing, prior to launching the attack on the device. I'm pointing out that concerns about discovery of valid addresses on conventional hosts via probing can also be concerns for networking devices with IPv6 addresses as well, such as routers and switches, and that large entropy IIDs can provide them with an additional level of defence in depth that wasn't possible to have in IPv4. The control planes of networking devices are performing host functions too, so host security mitigations are applicable. Some seem to believe that network devices software/firmware is far more robust and they're universally configured far more securely such that limiting the exposure and discoverability of the devices' addresses provides no value. I think the links I provided earlier and the following links to network OS vulnerabilities shows that this isn't the case. https://www.cvedetails.com/vulnerability-list/vendor_id- 874/product_id-3989/Juniper-Junos.html https://www.cvedetails.com/vulnerability-list/vendor_id- 16/product_id-19/Cisco-IOS.html Regards, Mark. I may not get a response because that's not the IID randomly chosen as the address of the device, but it still seems like that could be used for DOS (like a tuple attack on a NIC queue) if the prefix is discovered or predictable. Tom > If you choose to specifically lower device security against discovery > by putting routers in DNS, or allowing routers to respond to > traceroutes, you consciously know you're lowering it for the specific > device and can be vigilant when taking other measures to raise it > again (ACLs etc.) > > Note that I'm not saying this is the only security measure you should > have. It is an additional defence in depth measure that IPv6 > addressing can provide to network infrastructure devices that IPv4 > addressing could not. > > Regards, > Mark. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Giving up security & privacy when manually config… Mark Smith
- Re: Giving up security & privacy when manually co… David Farmer
- Re: Giving up security & privacy when manually co… Fred Baker
- Re: Giving up security & privacy when manually co… Job Snijders
- Re: Giving up security & privacy when manually co… Christopher Morrow
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… sthaug
- Re: Giving up security & privacy when manually co… Erik Kline
- Re: Giving up security & privacy when manually co… sthaug
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Mark Andrews
- Re: Giving up security & privacy when manually co… Nick Hilliard
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Philip Homburg
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Simon Hobson
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… Lorenzo Colitti
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Alexandre Petrescu
- Re: Giving up security & privacy when manually co… Mark Smith
- Re: Giving up security & privacy when manually co… Simon Hobson
- Re: Giving up security & privacy when manually co… Tom Herbert
- Re: Giving up security & privacy when manually co… Fernando Gont
- Re: Giving up security & privacy when manually co… Fernando Gont