Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Mark Smith <markzzzsmith@gmail.com> Sun, 26 July 2015 03:26 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7DB1B2A2A for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 20:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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=1, SPF_PASS=-0.001] autolearn=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 TkMB8OdDH1qk for <v6ops@ietfa.amsl.com>; Sat, 25 Jul 2015 20:26:00 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 7968F1B2A29 for <v6ops@ietf.org>; Sat, 25 Jul 2015 20:26:00 -0700 (PDT)
Received: by iecri3 with SMTP id ri3so43388963iec.2 for <v6ops@ietf.org>; Sat, 25 Jul 2015 20:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=v4xyx4+dDGAJzTz0A2V3iHw5jOQIMSe5foo830uvH0I=; b=t5Wkj4KZeewv1S9BWSGn978/6bu1WXA5tBFewT/aEDkKP6rXB4M1vWAqGGYf5oGxnf SW5GfMsqqeTTcpajsiQeltoEiFZ89o2sAT/DiW3Qy9Oi8dqXwDzC1+1dAAm78DILYpM4 hkaxzuHf43lXHOVbMLO+gQQp+gQ1m8ZtULuPqCBaP0R5Vcl7I2aIMDDJzOF0BNNrXC7/ xkJW4nbtVCcCVqiR8FiureypNGHxjwrReA3jC0rXkjFYFdJm+YTbcY+YNsGbRUgqkYTw PHGQC8SjnBcwmva+hymdGpGY7WIgtlHRgE4AQ87RUidYxSwqO3lHcbHV0UnLYesTEn5l 6umA==
X-Received: by 10.50.30.65 with SMTP id q1mr7721783igh.28.1437881159995; Sat, 25 Jul 2015 20:25:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.169.143 with HTTP; Sat, 25 Jul 2015 20:25:30 -0700 (PDT)
In-Reply-To: <D1D96418.5E52E%wesley.george@twcable.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <D1D96418.5E52E%wesley.george@twcable.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 26 Jul 2015 13:25:30 +1000
Message-ID: <CAO42Z2x5umGi0ra977KpOWwYJ=A0JHDoW8C1g_+vO-zyjpggKg@mail.gmail.com>
To: "George, Wes" <wesley.george@twcable.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/LQELdiRvOjo8KyY7Y5cere2D_A0>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-colitti-v6ops-host-addr-availability@tools.ietf.org" <draft-colitti-v6ops-host-addr-availability@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Jul 2015 03:26:01 -0000

On 26 July 2015 at 11:21, George, Wes <wesley.george@twcable.com>; wrote:
<snip>
>
> 9.1 is combative, dismissive, and incomplete. The problem is not that
> operators have made the argument that DHCPv6 is the only way to...
> What they've said is that they require a way to track which IPv6 addresses
> are assigned to which hosts for policy and legal reasons, and that is
> driving a set of deployment decisions. That's not up for debate or
> negotiation, and is part of the reason why other discussions of this issue
> have been so...vigorous. IETF needs to get out of the habit of telling
> operators that their problem isn't a problem, and focus on discussing the
> possible solutions, identifying what consensus says is the best way to
> solve the problem.

So what I'd like to know more about then is the particular problem
being trying to be solved, or more specifically the business problem
or problems being solved.

"Having a record of IP addresses assigned to devices" isn't a problem
statement, it is a statement of what a mechanism such as DHCP is
theoretically achieves. That record needs to be used for something, so
what are those uses?

I assume it is to satisfy a security need. But what are the specific
security needs? Is there anything formal that requires it, e.g., PCI
DSS?

My view is that one of the security needs is to be able to have an
audit log of devices attached to the network at particular times, so
that if there is a security attack of some form, theoretically it is
possible to identify who and/or who's device was used for the attack.

Both DHCPv4 and DHCPv6 won't actually achieve that goal, because
neither of them record static address assignments on hosts, and DHCPv6
doesn't record link-local addresses assigned or in use either. A
competent attacker will certainly know the risks of using DHCP to
acquire an address on a network they wish to minimise their footprint
on. They'll configure valid static addresses or use link-local
addresses if their target is on-link.

The IETF can come up with a proper solution statement once a proper
problem statement exists. Does a proper problem statement exist
somewhere?


Regards,
Mark.