Re: [Madinas] I-D Action: draft-ietf-madinas-mac-address-randomization-10.txt

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks a lot Bob for your comments. Please see inline below.

On Wed, Feb 21, 2024 at 6:28 PM Bob Hinden <[e-mail]> wrote:

> Carlos,
>
> Greatly improved, thanks very much!
>
> A few suggested edits and comments to Section 6 below.
>
> Bob
>
>
> 6.  MAC randomization in IETF Protocol Standards
>
>    [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
>    IPv6, which typically results in hosts configuring one or more
>    "stable" addresses composed of a network prefix advertised by a local
>    router, and an Interface Identifier (IID).  [RFC8064] formally
>    updated the original IPv6 IID selection mechanism to avoid generating
>    the IID from the MAC address of the interface (via EUI64), as this
>    potentially allowed for global tracking of a device at L3 from any
>    point on the Internet (note that the prefix part of the address
>    provides meaningful insights of the physical location of the device
>    in general, which together with the MAC address-based IID, made it
>    easier to perform global device tracking).
>
>
> The same can be said for IPv4 prefixes, they can be used to track the
> location.
>

[Carlos] True, we will try to adapt the text to mention that as well.


>
>    [RFC8981] identifies and describes the privacy issues associated with
>    embedding MAC stable addressing information into the IPv6 addresses
>    (as part of the IID).  It describes an extension to IPv6 Stateless
>    Address Autoconfiguration that causes hosts to generate temporary
>    addresses with randomized interface identifiers for each prefix
>    advertised with autoconfiguration enabled.  Changing addresses over
>    time limits the window of time during which eavesdroppers and other
>    information collectors may trivially perform address-based network-
>    activity correlation when the same address is employed for multiple
>    transactions by the same host.  Additionally, it reduces the window
>    of exposure of a host as being accessible via an address that becomes
>    revealed as a result of active communication.  These temporary
>    addresses are meant to be used for a short period of time (hours to
>    days) and would then be deprecated.  Deprecated addresses can
>    continue to be used for already established connections, but are not
>    used to initiate new connections.  New temporary addresses are
>    generated periodically to replace temporary addresses that expire.
>    In order to do so, a node produces a sequence of temporary global
>    scope addresses from a sequence of interface identifiers that appear
>    to be random in the sense that it is difficult for an outside
>    observer to predict a future address (or identifier) based on a
>    current one, and it is difficult to determine previous addresses (or
>    identifiers) knowing only the present one.  The main problem with the
>    temporary addresses is that they should not be used by applications
>    that listen for incoming connections (as these are supposed to be
>    waiting on permanent/well-known identifiers).  Besides, if a node
>
>
>
> Zuniga, et al.           Expires 23 August 2024                 [Page 8]
> 
> Internet-Draft     Randomized and Changing MAC Address     February 2024
>
>
>    changes network and comes back to a previously visited one, the
>    temporary addresses that the node would use will be different, and
>    this might be an issue in certain networks where addresses are used
>    for operational purposes (e.g., filtering or authentication).
>    [RFC7217], summarized next, partially addresses the problems
>    aforementioned.
>
>
> I am not sure I would say “The main problem with temporary addresses….”
>
> If you want to be reachable, then you need a stable address.    This isn’t
> a problem with temporary addresses.    Clients should use temporary
> addresses, servers should use stable addresses.  You can be reachable
> without some sort of stable identifier.
>

[Carlos] OK, we will slightly adapt the text to make it more precise along
the lines of your comment.


>    [RFC7217] describes a method to generate Interface Identifiers that
>    are stable for each network interface within each subnet, but that
>    change as a host moves from one network to another.  This method
>    enables keeping the "stability" properties of the Interface
>    Identifiers specified in [RFC4291], while still mitigating address-
>    scanning attacks and preventing correlation of the activities of a
>    host as it moves from one network to another.  The method defined to
>    generate the IPv6 IID is based on computing a hash function which
>    takes as input information that is stable and associated to the
>    interface (e.g., a local interface identifier), stable information
>    associated to the visited network (e.g., IEEE 802.11 SSID), the IPv6
>    prefix, and a secret key, plus some other additional information.
>    This basically ensures that a different IID is generated when any of
>    the input fields changes (such as the network or the prefix), but
>    that the IID is the same within each subnet.
>
>    Currently, [RFC8064] recommends nodes to implement [RFC7217] as the
>    default scheme for generating stable IPv6 addresses with SLAAC, to
>    mitigate the privacy threats posed by the use of MAC-derived IIDs.
>
>    In addition to the former documents, [RFC8947] proposes an extension
>    to DHCPv6 that allows a scalable approach to link-layer address
>    assignments where preassigned link-layer address assignments (such as
>    by a manufacturer) are not possible or unnecessary.  [RFC8948]
>    proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or
>    a DHCPv6 relay to indicate a preferred SLAP quadrant to the server,
>    so that the server may allocate MAC addresses in the quadrant
>    requested by the relay or client.
>
>    Not only MAC and IP addresses can be used for tracking purposes.
>    Some DHCP options carry unique identifiers.  These identifiers can
>    enable device tracking even if the device administrator takes care of
>    randomizing other potential identifications like link-layer addresses
>    or IPv6 addresses.  [RFC7844] introduces anonymity profiles, designed
>    for clients that wish to remain anonymous to the visited network.
>    The profiles provide guidelines on the composition of DHCP or DHCPv6
>    messages, designed to minimize disclosure of identifying information.
>    [RFC7844] also indicates that the link-layer address, IP address, and
>    DHCP identifier shall evolve in synchrony.
>
>
> Just a comment, this section is titled "MAC randomization in IETF Protocol
> Standards”.  I wonder if the paragraph above is going beyond that.   It’s
> not only DHCP that has things that can be used for tracking.   Many of the
> higher level protocols such as used in the world wide web have things that
> are commonly used for tracking.  For example, “cookies”.
>
> Think about if this section is about MAC randomization” or if it is about
> the larger issue of tracking.   If the latter, there is a lot more to
> discuss.
>
> [Carlos] Fully agree. The rationale of this part of the text is that it
relates to the MAC addresses, as DHCP servers may make use of the MAC
address of the client to provide the same IP address. There are other
parameters that can also be used, and all this, including the binding
IP-MAC address generates a potential security threat related to tracking.
But of course, the goal of this section is not to discuss tracking in
general.

Thanks!

Carlos


>
>
> On Feb 20, 2024, at 11:18 PM, CARLOS JESUS BERNARDOS CANO <[e-mail]>
> wrote:
>
> Hi Bob, all,
>
> We have just posted a new version addressing your comments.
>
> Thanks!
>
> Carlos
>
> On Sat, Jan 13, 2024 at 8:46 PM Bob Hinden <[e-mail]> wrote:
>
>> Thanks
>> Bob
>>
>>
>>
>> On Jan 12, 2024, at 12:33 PM, CARLOS JESUS BERNARDOS CANO <
>> [e-mail]> wrote:
>>
>> Hi Bob,
>>
>> Sorry, I think I overlooked your previous comment. I'll update the draft
>> next week.
>>
>> Thanks!
>>
>> Carlos
>>
>> On Fri, Jan 12, 2024 at 1:38 AM Bob Hinden <[e-mail]> wrote:
>>
>>> I believe I made similar comments a while back.   Repeating myself.
>>>
>>> 6. MAC randomization-related activities at the IETF
>>>
>>> This title is ambiguous (and Section 4 and 5 the same problem).   “at
>>> the IETF” sounds like at an IETF meeting and “activities” isn’t clear.
>>> Protocols are not “activities”   This should be something like:
>>>
>>>           MAC randomization in IETF Protocol Standards
>>>
>>> The text in this section starts with:
>>>
>>> Several IP address assignment mechanisms such as the IPv6 stateless
>>> autoconfiguration techniques (SLAAC) [RFC4862] generate the Interface
>>> Identifier (IID) of the address from its MAC address (via EUI64), which
>>> then becomes visible to all IPv6 communication peers. This potentially
>>> allows for global tracking of a device at L3 from any point on the
>>> Internet. Besides, the prefix part of the address provides meaningful
>>> insights of the physical location of the device in general, which together
>>> with the MAC address-based IID, makes it easier to perform global device
>>> tracking.
>>>
>>>
>>> This is wrong and out dated.   RFC 8064 "Recommendation on Stable IPv6
>>> Interface Identifiers” published in 2017 formally updated IPv6 IID
>>> selection to prefer RFC 7217 IIDs and recommends against embedding stable
>>> link-layer address in IPv6 IIDS.
>>>
>>> This section needs a serious rewrite.
>>>
>>> Today, I also noted in third paragraph of this section a reference to
>>> [RFC4191].  The text is:
>>>
>>> [RFC4191] identifies and describes the privacy issues associated with
>>> embedding MAC stable addressing information into the IPv6 addresses (as
>>> part of the IID) and describes some mechanisms to mitigate the associated
>>> problems.
>>>
>>>
>>> RFC4191 is "Default Router Preferences and More-Specific Routes”.  This
>>> has nothing to do with embedding MAC stable addresss.
>>>
>>> Bob
>>>
>>>
>>> On Jan 11, 2024, at 3:02 AM, [e-mail] wrote:
>>>
>>> Internet-Draft draft-ietf-madinas-mac-address-randomization-10.txt is now
>>> available. It is a work item of the MAC Address Device Identification for
>>> Network and Application Services (MADINAS) WG of the IETF.
>>>
>>>   Title:   Randomized and Changing MAC Address state of affairs
>>>   Authors: Juan Carlos Zuniga
>>>            Carlos J. Bernardos
>>>            Amelia Andersdotter
>>>   Name:    draft-ietf-madinas-mac-address-randomization-10.txt
>>>   Pages:   18
>>>   Dates:   2024-01-11
>>>
>>> Abstract:
>>>
>>>   Internet privacy has become a major concern over the past few years.
>>>   Users are becoming more aware that their online activity leaves a
>>>   vast digital footprint, that communications are not always properly
>>>   secured, and that their location and actions can be easily tracked.
>>>   One of the main factors for the location tracking issue is the wide
>>>   use of long-lasting identifiers, such as MAC addresses.
>>>
>>>   There have been several initiatives at the IETF and the IEEE 802
>>>   standards committees to overcome some of these privacy issues.  This
>>>   document provides an overview of these activities, with the intention
>>>   to inform the technical community about them, and help coordinate
>>>   between present and future standardization activities.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-madinas-mac-address-randomization/
>>>
>>> There is also an HTMLized version available at:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-10
>>>
>>> A diff from the previous version is available at:
>>>
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-madinas-mac-address-randomization-10
>>>
>>> Internet-Drafts are also available by rsync at:
>>> rsync.ietf.org::internet-drafts
>>>
>>>
>>> --
>>> Madinas mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/madinas
>>>
>>>
>>> --
>>> Madinas mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/madinas
>>>
>>
>>
>