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

Roberta Maglione <> Thu, 05 December 2013 14:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E7CE1ADF30 for <>; Thu, 5 Dec 2013 06:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nqe3PaK61rZc for <>; Thu, 5 Dec 2013 06:56:58 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::230]) by (Postfix) with ESMTP id 955A41AC863 for <>; Thu, 5 Dec 2013 06:56:57 -0800 (PST)
Received: by with SMTP id n7so10174231lam.7 for <>; Thu, 05 Dec 2013 06:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=90s/zwl0h5OVMuIEmUBDyT+/efIcCt9ArLTiE7TMHx8=; b=Ed50OqkvslTY7cY/8adsd5Y9TB9mNJ1WiA9RucQlLUzVFpyiwneVFx9OiVHgyn0i/a dOr3dAuZD/Nukb1bAtRWJTA32ts0WmhlxsPl1pBfkAF0yiKlqSifIcMGhFU6+Djx7bje +Nb4luJ3ysH2nXrYINwkf1csCpr8QhIvXFaSxNOsLQ3TpA7oT/3RCPChhr3zgF7CD1ia 3Y3nWOt+/AMd+GxPi43gW/UG0+yZE+DLs+WqzPM0xeWK+31Yj+iURDDY15dsTAPAJEKk 37OpqdIIukgekIS5vNQHWJhaf9UGC0dO7pR5rleqgm9jzWCfzUI+oPlWDgH2dNWUJGj+ M2AA==
MIME-Version: 1.0
X-Received: by with SMTP id sd5mr7511696lab.26.1386255413513; Thu, 05 Dec 2013 06:56:53 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 06:56:53 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 5 Dec 2013 09:56:53 -0500
Message-ID: <>
From: Roberta Maglione <>
To: Tom Taylor <>,
Content-Type: multipart/alternative; boundary=001a113458547d918104eccabde1
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: Thu, 05 Dec 2013 14:57:01 -0000


I understand the privacy concerns related to MAC address you mentioned.
However in some DSL Broadband environments the source MAC address (taken
from the DHCPv4 discover message sent by the DHCP client) has been used as
one of the identifiers to trigger the authorization (through AAA/RADIUS
Server) for a new subscriber session. For more details please see
requirements  R-43 and R-44 from BBF TR-146.

In my opinion using the source MAC  address for conditional access purposes
seems in-line with this approach, so I would prefer to keep a link with the
MAC address (or the device id) in the ANCP message, mitigating the privacy
issues either by using an optional hashing/mapping function as you
suggested or by adding some clarifications notes as proposed by Francois.



On Tue, Dec 3, 2013 at 2:31 PM, Tom Taylor <>wrote;wrote:

> 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
>> generation-privacy-00,
>> 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
> _______________________________________________
> ANCP mailing list