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

[Roberta Maglione <[e-mail]>]

Hello,

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.

Thanks

Roberta




On Tue, Dec 3, 2013 at 2:31 PM, Tom Taylor <[e-mail]>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
>> http://tools.ietf.org/html/draft-ietf-6man-ipv6-address-
>> 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
>> (http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-15),
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ancp
>