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

"George, Wes" <wesley.george@twcable.com> Mon, 27 July 2015 13:57 UTC

Return-Path: <wesley.george@twcable.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 9F1011B2DD4 for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2015 06:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.925
X-Spam-Level: **
X-Spam-Status: No, score=2.925 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uAEjOIYJb-xf for <v6ops@ietfa.amsl.com>; Mon, 27 Jul 2015 06:57:47 -0700 (PDT)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id C621E1B2DD2 for <v6ops@ietf.org>; Mon, 27 Jul 2015 06:57:46 -0700 (PDT)
X-SENDER-IP: 10.136.163.14
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.15,554,1432612800"; d="scan'208";a="290719316"
Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 27 Jul 2015 09:36:06 -0400
Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 27 Jul 2015 09:57:45 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 27 Jul 2015 09:57:43 -0400
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AdDIdDZdq0uthLAMSeG10ygJ/vZ6/g==
Message-ID: <D1DB99FA.5E7B0%wesley.george@twcable.com>
References: <201507061147.t66Bl1AE028312@irp-lnx1.cisco.com> <D1D96418.5E52E%wesley.george@twcable.com> <CAO42Z2x5umGi0ra977KpOWwYJ=A0JHDoW8C1g_+vO-zyjpggKg@mail.gmail.com>
In-Reply-To: <CAO42Z2x5umGi0ra977KpOWwYJ=A0JHDoW8C1g_+vO-zyjpggKg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.3.150624
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-WxIrq3rJiszi_-W6XKpFsTZJTo>
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: Mon, 27 Jul 2015 13:57:48 -0000

On 7/25/15, 11:25 PM, "Mark Smith" <markzzzsmith@gmail.com>; wrote:


>On 26 July 2015 at 11:21, George, Wes <wesley.george@twcable.com>; wrote:
>>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
>
>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?
WG] We disagree on whether IETF needs to know what a given implementation
intends to do with the data in order for the problem statement to be
complete.

>
>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?
WG] Well, I thought that the second part of the statement above was pretty
self-explanatory, but since you asked for more detail, here are a few
examples:

Enforcing/Responding to violations of AUP (spam, malware, attacks,
prohibited content, etc)
Complying with LEA requests (CALEA or equivalent, Lawful Intercept, etc),
DMCA or equivalent takedown requests
Sandboxing devices/users that do not have permission to use the network
due to nonpayment or one of the above violations
Enabling different tiers of service by device or by user, dealing with
entitlement to a given service

>The IETF can come up with a proper solution statement once a proper
>problem statement exists. Does a proper problem statement exist
>somewhere?
WG] the problem with the "proper" problem statement you're asking for is
that I don't think the IETF really wants to know the answer because of the
very complex issues it will raise. If the explanation gets much more
detailed than "I have multiple legal and policy enforcement mandates that
require me to have a way to map an IP address/device on the network to the
user that is sending/receiving on it" you start getting into a combination
of legal and policy areas that the IETF typically stays away from. Are we
willing to make tools available for government agencies and businesses to
do things that some of our participants are opposed to? How far are we
willing to go into implementation details that involve multiple
jurisdictions and regions with conflicting views about what is legal,
illegal, and compulsory? It gets difficult to optimize a solution around
that problem space, especially to do it objectively, unless you abstract
it to a fairly high level.
The discussion also tends to devolve quickly into blaming the messenger,
in which people get angry or dismissive to the operators saying that they
need certain functionality, because they are being required by their local
government or employer to do something some consider distasteful with it,
and the operators respond by getting angry at "IETF" for telling them that
the thing that they're legally required to do isn't important or necessary
or is otherwise "wrong". I'd rather stay away from that debate here, but
if you would like to kick the hornets' nest on NANOG again to satisfy your
own curiosity, be my guest.

The only thing I agree might be unclear in my generic problem statement
above is what level of accuracy or confidence in the mapping between IP,
user, and device is necessary, and at what time resolution. In this case,
I think we can point to the systems in place today (e.g. DHCPv4) and say
that it's largely best-effort, with time accuracy on the order of seconds
or minutes, and if something better than that is required, it probably
requires implementation of additional security in address assignment
(SEND, etc).

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.