A method for Generating Stable Privacy-Enhanced Addresses with IPv6 | BOT24

A method for Generating Stable Privacy-Enhanced Addresses with IPv6


   This document specifies a method for generating IPv6 Interface
   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
   (SLAAC), such that addresses configured using this method are stable
   within each subnet, but the Interface Identifier changes when hosts
   move from one network to another.  The aforementioned method is meant
   to be an alternative to generating Interface Identifiers based on
   IEEE identifiers, such that the benefits of stable addresses can be
   achieved without sacrificing the privacy of users.

1.  Introduction

   [RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC)
   for IPv6 [RFC2460], 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) that typically
   embeds a hardware address (e.g., using IEEE identifiers) [RFC4291].

   Generally, stable addresses are thought to simplify network
   management, since they simplify Access Control Lists (ACLs) and
   logging.  However, since IEEE identifiers are typically globally
   unique, the resulting IPv6 addresses can be leveraged to track and
   correlate the activity of a node over time and across multiple
   subnets and networks, thus negatively affecting the privacy of users.

   The "Privacy Extensions for Stateless Address Autoconfiguration in
   IPv6" [RFC4941] were introduced to complicate the task of
   eavesdroppers and other information collectors to correlate the
   activities of a node, and basically result in temporary (and random)
   Interface Identifiers that are typically more difficult to leverage
   than those based on IEEE identifiers.  When privacy extensions are
   enabled, "privacy addresses" are employed for "outgoing
   communications", while the traditional IPv6 addresses based on IEEE
   identifiers are still used for "server" functions (i.e., receiving
   incoming connections).

      As noted in [RFC4941], "anytime a fixed identifier is used in
      multiple contexts, it becomes possible to correlate seemingly
      unrelated activity using this identifier".  Therefore, since
      "privacy addresses" [RFC4941] do not eliminate the use of fixed
      identifiers for server-like functions, they only *partially*
      mitigate the correlation of host activities (see Appendix A for
      some example attacks that are still possible with privacy
      addresses).  Therefore, it is vital that the privacy
      characteristics of "stable" addresses are improved such that the
      ability of an attacker correlating host activities across networks
      is reduced.

      Another important aspect not mitigated by "Privacy Addresses"
      [RFC4941] is that of host scanning.  Since IPv6 addresses that
      embed IEEE identifiers have specific patterns, an attacker could
      leverage such patterns to greatly reduce the search space for
      "live" hosts.  Since "privacy addresses" do not eliminate the use
      of IPv6 addresses that embed IEEE identifiers, host scanning
      attacks are still feasible even if "privacy extensions" are
      employed [Gont-DEEPSEC2011] [CPNI-IPv6].  This is yet another
      motivation to improve the privacy characteristics of "stable"
      addresses (currently embedding IEEE identifiers).

   Privacy/temporary addresses can be challenging in a number of areas.
   For example, from a network-management point of view, they tend to
   increase the complexity of event logging, trouble-shooting, and
   enforcing access controls and quality of service, etc.  As a result,
   some organizations disable the use of privacy addresses even at the
   expense of reduced privacy [Broersma].  Also, they result in
   increased complexity, which might not be possible or desirable in
   some implementations (e.g., some embedded devices).

   In scenarios in which "Privacy Extensions" are deliberately not used
   (possibly for any of the aforementioned reasons), all a host is left
   with is the addresses that have been generated using e.g.  IEEE
   identifiers, and this is yet another case in which it is also vital
   that the privacy characteristics of these stable addresses are

   We note that in most (if not all) of those scenarios in which
   "Privacy Extensions" are disabled, there is usually no actual desire
   to negatively affect user privacy, but rather a desire to simplify
   operation of the network (simplify the use of ACLs, logging, etc.).

   This document specifies a method to generate interface identifiers
   that are stable/constant within each subnet, but that change as hosts
   move from one network to another, thus keeping the "stability"
   properties of the interface identifiers specified in [RFC4291], while
   still mitigating host-scanning attacks and preventing correlation of
   the activities of a node as it moves from one network to another.

   This document does not update or modify IPv6 StateLess Address Auto-
   Configuration (SLAAC) [RFC4862] itself, but rather only specifies an
   alternative algorithm to generate Interface IDs.  Therefore, the
   usual address lifetime properties (as specified in the corresponding
   Prefix Information Options) apply when IPv6 addresses are generated
   as a result of employing the algorithm specified in this document
   with SLAAC [RFC4862].  Additionally, from the point of view of
   renumbering, we note that these addresses behave like the traditional
   IPv6 addresses (that embed a hardware address) resulting from SLAAC

   For nodes that currently disable "Privacy extensions" [RFC4941] for
   some of the reasons stated above, this mechanism provides stable
   privacy-enhanced addresses which may already address most of the
   privacy concerns related to addresses that embed IEEE identifiers
   [RFC4291].  On the other hand, in scenarios in which "Privacy
   Extensions" are employed, implementation of the mechanism described
   in this document would mitigate host-scanning attacks and also
   mitigate correlation of host activities.

read more.............http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02

Share on Google Plus

About Bradley Susser

    Blogger Comment
    Facebook Comment


Post a Comment