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

From: Tom Taylor <[email-masked]>
Date: Sun, 01 Dec 2013 15:50:12 -0500

In his review of draft-ietf-ancp-mc-extensions-12, our AD pointed out 
that the optional presence of the Request-Source-IP or 
Request-Source-MAC TLV in the ANCP Multicast Admission Control message 
posed privacy issues. Looking through the ANCP requirements in RFC 5851 
and TR-101, I could find no requirement that these be reported.

I proposed that these TLVs be dropped from the message and from the 
document. I will assume that I have consent for this change if I do not 
hear arguments against it by the end of Wednesday, December 18.

Tom Taylor

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 2 Dec 2013 09:11:02 +0000

Hello Tom,

I think these TLVs bring some value:
The ANCP Multicast Admission Control message supports the "Conditional Access and Admission Control Use Case". When conditional access is to be performed on a per device basis (as opposed to per DSL line basis), the message needs to provide the NAS with a way to identify the device.

In general (and more or less by definition) the NAS has a lot of visibility on each DSL line (certainly for unicast), so I assume the privacy concern is not so much about communicating the info to the NAS but has more to do with the risk of a monitoring attack of the ANCP protocol. Right?

How about an alternative approach where we keep these TLVs in the document and keep them as optional, but add a note that says that:
	* including those TLVs in the message is only useful when the NAS is to perform per-device "Conditional Access and Admission Control"
	* including those TLVs in the message results in an increased privacy concern because it exposes on the wire the corresponding privacy information about which IP/MAC is accessing which multicast channel, which could be exploited by a monitoring attack on the ANCP protocol.
	* these TLVs SHOULD NOT be included when per-device "Conditional Access and Admission Control" by the NAS is not used

Makes sense?

Francois

On 1 Dec 2013, at 21:50, Tom Taylor <[email-masked]>
 wrote:

> In his review of draft-ietf-ancp-mc-extensions-12, our AD pointed out that the optional presence of the Request-Source-IP or Request-Source-MAC TLV in the ANCP Multicast Admission Control message posed privacy issues. Looking through the ANCP requirements in RFC 5851 and TR-101, I could find no requirement that these be reported.
> 
> I proposed that these TLVs be dropped from the message and from the document. I will assume that I have consent for this change if I do not hear arguments against it by the end of Wednesday, December 18.
> 
> Tom Taylor
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Mon, 02 Dec 2013 04:59:53 -0500

This justification makes sense. I can think of use cases where one would 
want per-device control.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Dec 2013 10:15:59 -0500

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.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 03 Dec 2013 14:31:15 -0500

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

---

From: Roberta Maglione <[email-masked]>
Date: Thu, 5 Dec 2013 09:56:53 -0500

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 <[email-masked]>wrote:

> 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.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Dec 2013 11:02:57 -0500

On Dec 5, 2013, at 9:56 AM, Roberta Maglione <[email-masked]> wrote:
> 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.

Roberta, I understand where you are coming from.   However, the way these things go is that you do something expedient at time T, which seems harmless.   Then at time T+N, you learn that there are negative consequences to doing that thing.   There is never any time T+M, where M>N, at which the cost of implementing a better solution is lower than it is at time T+N.   So either you fix the problem once you've discovered it, or you don't fix the problem.

So I'm asking you, now that we understand the problem, to fix it.   I would also encourage you to work within the BBF to get the next version of TR-146 to switch over to using the same identifier we are proposing to use here.   I think this is a better approach in the long run than doing nothing, although I fully understand that it is not without cost.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Dec 2013 11:39:40 -0500

I propose to say in the main section that implementations MUST provide a 
mapping capability, either table-based or algorithmic, to map between 
device MAC and device identifier. Rather than separate requesting 
address and requesting MAC TLVs, define a single requesting device 
identifier TLV. Then in the Security Considerations section I can say 
that operators SHOULD deploy that mapping capability in the interest of 
privacy and untrackability.

Tom

---

From: Roberta Maglione <[email-masked]>
Date: Thu, 5 Dec 2013 11:41:40 -0500

Hello Ted,
I got your point.
Thanks
Roberta

On Thu, Dec 5, 2013 at 11:02 AM, Ted Lemon <[email-masked]> wrote:

> > 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
> Roberta, I understand where you are coming from.   However, the way these
> things go is that you do something expedient at time T, which seems
> harmless.   Then at time T+N, you learn that there are negative
> consequences to doing that thing.   There is never any time T+M, where M>N,
> at which the cost of implementing a better solution is lower than it is at
> time T+N.   So either you fix the problem once you've discovered it, or you
> don't fix the problem.
>
> So I'm asking you, now that we understand the problem, to fix it.   I
> would also encourage you to work within the BBF to get the next version of
> TR-146 to switch over to using the same identifier we are proposing to use
> here.   I think this is a better approach in the long run than doing
> nothing, although I fully understand that it is not without cost.
>
>