Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12

Tom Taylor <> Tue, 03 December 2013 19:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE1B61AC404 for <>; Tue, 3 Dec 2013 11:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CzlmjE_ibZfj for <>; Tue, 3 Dec 2013 11:31:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22c]) by (Postfix) with ESMTP id 1E6A21AE1A0 for <>; Tue, 3 Dec 2013 11:31:22 -0800 (PST)
Received: by with SMTP id qd12so24734659ieb.31 for <>; Tue, 03 Dec 2013 11:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QsS8WphMfrnxPLaLfOQze9Y5+KhK8WNxMBw/8tuamRw=; b=HftpEaPaYoFrdDaO9yph5Gup3bs0vyUUEprvxtZVCxihcoKEKjaV7BWcgnSKgZ3O8x 37bJsl6svgG5DpxJfnw46MrwpIH8LiR2ZPsHjfpTpV4W5/9VFt2hOLDJie29C71cLglA mUA3UMe4pk/GiX6eGOMAu5n7sOWWcVxWRLbRqcpsEc78bd1A/f7bK9Y52yKgAhhHFhzv Jbj63caovdRBHLNszoqgzdTZwbTAVCC9dSjhdwfNimC9WPWi8f3QmOJqkUZTcqBKzrBQ T0EPCh/kuuzZ4yMmhQ+yqFXNCyUSEEKhvJEcPYe/Ao6BsGR92whWPXMiktEBnrM6qouT L0zQ==
X-Received: by with SMTP id p9mr47456652icf.4.1386099079366; Tue, 03 Dec 2013 11:31:19 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id p14sm4620637igr.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 11:31:18 -0800 (PST)
Message-ID: <>
Date: Tue, 03 Dec 2013 14:31:15 -0500
From: Tom Taylor <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Ted Lemon <>, "Francois Le Faucheur (flefauch)" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [ANCP] Privacy issue in draft-ietf-ancp-mc-extensions-12
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Access Node Control Protocol working group mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2013 19:31:24 -0000

On 02/12/2013 10:15 AM, Ted Lemon wrote:
> I think that I've failed to adequately communicate the concern I have
> about this.   It might help for folks to review
> particularly section 3.1 (but you should probably read up to that so
> that you get the context).
> I am assuming here that the device whose MAC address is being
> identified is some end-user device, not the home gateway.   On an
> IPv4 network, or an IPv6 network for devices that use stable privacy
> addresses
> (,
> there is no ability to correlate activities based on the MAC address
> of the host.   So using the MAC address as an identifier for access
> control goes against the current trend in the IETF of avoiding using
> global, fixed identifiers like the MAC address in this way.
> If there is a need for an identifier to be used for access control,
> it should be an identifier specific to the context, which will not be
> used in other contexts.   So it shouldn't be the MAC address.
[PTT] Point about MAC address privacy accepted. Thinking over the IP 
address alternative, I can see practical problems -- since the device is 
in the home network, the provider has no control over the stability of 
the address (if IPv6), and can't determine the device from the address 
(if IPv4 with the usual NAT at the home gateway). My proposed technical 
solution would be to require the AN to create a context-specific device 
identifier by hashing the MAC address with something stable at the AN, 
with the result predictable so that the subscriber AAA profile can be 
set up as required.

The use cases I could see for this are not essential but possible:
-- provider-enforced parental controls on selected devices
-- provider-enforced device-specific limitations (e.g., mobile vs. fixed)

Have to admit the second case at least seems very weak.

Tom Taylor