[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                    SI6 Networks / UTN-FRH
Intended status: Best Current Practice                            W. Liu
Expires: November 28, 2016                           Huawei Technologies
                                                            May 27, 2016


                   IPv6 Address Usage Recommendations
            draft-gont-6man-address-usage-recommendations-00

Abstract

   IPv6 hosts typically configure and use a number of addresses of
   different scope and stability properties.  Recent work has analyzed
   the security and privacy implications of IPv6 addressing, and
   improved the security and privacy properties of some of the
   aforementioned address types.  However, advice is still missing
   guidance regarding which address properties are desirable in
   different scenarios, and how such addresses should be used when they
   are configured.  This document complements the aforementioned work by
   providing advice regarding which address types to configure and how
   to employ them in a number of popular scenarios.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 28, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Gont & Liu              Expires November 28, 2016               [Page 1]


Internet-Draft        IPv6 Address Recommendations              May 2016


   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Address Scope Considerations  . . . . . . . . . . . . . . . .   3
   4.  Address Stability Considerations  . . . . . . . . . . . . . .   3
   5.  Usage Type Considerations . . . . . . . . . . . . . . . . . .   5
   6.  Advice on IPv6 Address Configuration  . . . . . . . . . . . .   6
   7.  Advice on IPv6 Address Usage  . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   A typical IPv6 host may have multiple IPv6 addresses available, which
   may differ in multiple aspects, such as address scope and address
   persistence (e.g. stable addresses vs. temporary addresses).

   Given previous work in this area [RFC7721], we expect (and assume in
   the rest of this document) that implementations have replaced any
   schemes that produce predictable addresses with alternative schemes
   that avoid such patterns (e.g., RFC7217 in replacement of the
   traditional SLAAC addresses that embed link-layer addresses).

   There are three parameters that affect the security and privacy
   properties of an address:

   o  Scope

   o  Stability

   o  Usage type (client-like "outgoing connections" vs. server-like
      "incoming connections")






Gont & Liu              Expires November 28, 2016               [Page 2]


Internet-Draft        IPv6 Address Recommendations              May 2016


   Section 3, Section 4, and Section 5 discuss the security and privacy
   implications (and associated tradeoffs) of the scope, stability and
   usage type properties of IPv6 addresses, respectively.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Address Scope Considerations

   The IPv6 address scope can, in some scenarios, limit the attack
   exposure of a node as a result of the implicit isolation that may be
   implied by a non-global address scope.  For example, a node that only
   employs link-local addresses may, in principle, only be reached
   exposed to attack to other nodes in the local link.  Hosts employing
   only Unique Local Addresses (ULAs) may be more isolated from attack
   than those employing Global Unicast Addresses (GUAs), assuming that
   proper packet filtering is enforced on the network edge.

   The potential protection provided by a non-global addresses should
   not be regarded as a complete security strategy, but rather as a form
   of "prophylactic" security (see
   [I-D.gont-opsawg-firewalls-analysis]).

   We note that the use of non-global addresses is usually limited to a
   reduced type of applications/protocol that e.g. are only meant to
   operate on a reduced scope, and hence their applicability may be
   limited.

   A discussion of ULA usage considerations can be found in
   [I-D.ietf-v6ops-ula-usage-considerations].

4.  Address Stability Considerations

   The stability of an address has two associated security/privacy
   implications:

   o  Ability of an attacker to correlate network activity

   o  Exposure to attack

   For obvious reasons, an address that is employed for multiple
   communication instances allows the aforementioned network activities
   to be correlated.  The longer an address is employed (i.e., the more
   stable), the longer such correlation will be possible.  In the worst-
   case scenario, a stable address that is employed for multiple



Gont & Liu              Expires November 28, 2016               [Page 3]


Internet-Draft        IPv6 Address Recommendations              May 2016


   communication instances over time will allow all such activities to
   be correlated.  On the other hand, if a host were to generate (and
   eventually "throw away") one new address for each communication
   instance (e.g., TCP connection), network activity correlation would
   be mitigated.

   Typically, when it comes to attack exposure, the longer an address is
   employed the longer an attacker is exposed to attacks (e.g. an
   attacker has more time to find the address in the first place
   [RFC7707]).  While such exposure is traditionally associated with the
   stability of the address, the usage type of the address (see
   Section 5) may also have an impact on attack exposure.

   A popular approach to mitigate network activity correlation is that
   known as "temporary addresses".  Temporary addresses are typically
   configured and employed along with stable addresses, with the
   temporary addresses being employed for outgoing communications.  We
   note that the extent to which temporary addresses provide improved
   mitigation of network activity correlation and/or reduced attack
   exposure may be questionable in a number of scenarios.  For example,
   a temporary address that is reachable for, say, a few hours has a
   questionable "reduced exposure" (particularly when automated attack
   tools do not typically require such a long period of time to complete
   their task).  Similarly, if network activity can be correlated for
   the life of such address (e.g., in the order of several hours), there
   are scenarios in which such period of time would be long enough for
   an attacker to correlate all the network activity he is meaning to
   correlate.

      NOTE: Ongoing work [I-D.gont-6man-non-stable-iids] aims at
      updating [RFC4941] such that temporary addresses can be employed
      without the need to configure stable addresses.

   In order to better mitigate network activity correlation and/or
   possibly reduce host exposure, an implementation might want to either
   reduce the preferred lifetime of a temporary address, or even better,
   generate one new temporary address for each new transport protocol
   instance.  The associated lifetime/stability of an address typically
   may have a negative impact on the network.  For example, if a node
   were to employ "throw away" connections, or employ temporary
   addresses [RFC4941] with a short preferred lifetime, and the node
   were to use lots of outgoing connections, nodes might need to
   maintain too many entries in their Neighbor Cache, and a number of
   devices (possibly enforcing security policies) might also need to
   keep such additional state.

   Enforcing a maximum lifetime on IPv6 addresses may cause long-lived
   TCP connections to fail.  For example, an address becoming "Invalid"



Gont & Liu              Expires November 28, 2016               [Page 4]


Internet-Draft        IPv6 Address Recommendations              May 2016


   (after transiting through the "Preferred" and "Deprecated" status)
   would cause the TCP connections employing them to break.  This, in
   turn, would cause e.g. long-lived SSH sessions to break/fail.

   In some scenarios, attack exposure may be reduced by limiting the
   usage of temporary addresses to outbound connections, and prevent
   such addresses from being used for inbound connections (please see
   Section 5).

5.  Usage Type Considerations

   A node that employs one of its addresses to communicate with an
   external server (i.e., to perform an "outgoing connection") may cause
   such address to become exposed to attack.  For example, once the
   external server receives an incoming connection, the corresponding
   server may scan the client's address for network services.  A real-
   world instance of this attack scenario has been documented in [Hein].

   However, employing an IPv6 address for an outgoing session/connection
   need not increase the exposure of local services to the parties to
   which the client connects.  For example, nodes could employ temporary
   addresses only for outgoing connections, but not for incoming
   connections.  Thus, external nodes that learn about client's
   addresses could not really leverage such addresses for actively
   contacting the clients.

   There are multiple ways in which this could possibly be achieved,
   with different implications.  Namely:

      Run a host-based firewall

      Bind services to specific (explicit) addresses

      Bind services only to stable addresses

   A client could simply run a host-based firewall that only allows
   incoming connections on the stable addresses.  This is clearly more
   of an operational way of achieving the desired functionality, and may
   require good firewall/host integration (e.g., the firewall should be
   able to tell stable vs. temporary addresses), may require the client
   to run additional firewall software for this specific purpose, etc.

   Services could be bound to specific (explicit) addresses.  However,
   there are a number of short-comings associated with this approach.
   Firstly, an application would need to be able to learn all of its
   addresses and associated stability properties, something that tends
   to be non-trivial, non-portable, and that makes the application
   unnecessarily protocol-dependent.  Secondly, the Sockets API does not



Gont & Liu              Expires November 28, 2016               [Page 5]


Internet-Draft        IPv6 Address Recommendations              May 2016


   really allow a socket to be bound to a subset of the node's
   addresses.  That is, sockets can be bound to a single address or to
   all available addresses (wildcard), but not to a subset of all the
   available addresses.

   Binding services only to stable addresses provides a clean separation
   between addresses employed for client-like outgoing connections and
   server-like incoming connections.  However, we currently lack an
   appropriate API for nodes to be able to specify that a socket should
   only be bound t stable addresses.  This could be considered for
   future work.

6.  Advice on IPv6 Address Configuration

   [TBD]

7.  Advice on IPv6 Address Usage

   [TBD]

8.  IANA Considerations

   There are no IANA registries within this document.  The RFC-Editor
   can remove this section before publication of this document as an
   RFC.

9.  Security Considerations

   This document discusses address usage considerations, and also
   describes possible future standards-track work to allow for greater
   flexibility in IPv6 address usage.

10.  Acknowledgements

   [TBD]

11.  References

11.1.  Normative References

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.



Gont & Liu              Expires November 28, 2016               [Page 6]


Internet-Draft        IPv6 Address Recommendations              May 2016


   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <http://www.rfc-editor.org/info/rfc4941>.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <http://www.rfc-editor.org/info/rfc7217>.

11.2.  Informative References

   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
              <http://www.rfc-editor.org/info/rfc7707>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.

   [I-D.ietf-v6ops-ula-usage-considerations]
              Liu, B. and S. Jiang, "Considerations For Using Unique
              Local Addresses", draft-ietf-v6ops-ula-usage-
              considerations-00 (work in progress), February 2016.

   [I-D.gont-6man-non-stable-iids]
              Gont, F. and S. LIU, "Recommendation on Non-Stable IPv6
              Interface Identifiers", draft-gont-6man-non-stable-iids-00
              (work in progress), May 2016.

   [I-D.gont-opsawg-firewalls-analysis]
              Gont, F. and F. Baker, "On Firewalls in Network Security",
              draft-gont-opsawg-firewalls-analysis-02 (work in
              progress), February 2016.

   [Hein]     Hein, B., "The Rising Sophistication of Network Scanning",
               January 2016, <http://netpatterns.blogspot.be/2016/01/
              the-rising-sophistication-of-network.html>.

Authors' Addresses









Gont & Liu              Expires November 28, 2016               [Page 7]


Internet-Draft        IPv6 Address Recommendations              May 2016


   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com


   Will(Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com

































Gont & Liu              Expires November 28, 2016               [Page 8]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/