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

Versions: 00

Network Working Group                                          D. Thaler
Internet-Draft                                                 Microsoft
Intended status: Standards Track                       February 16, 2015
Expires: August 20, 2015


     Enabling Security/Privacy Addressing On 6LoWPAN Technologies
                   draft-thaler-6lo-privacy-addrs-00

Abstract

   It is commonly assumed today that 6LowPAN header compression is
   incompatible (or at least inefficient) with the notion of using
   addresses with sufficient entropy to mitigate various security and
   privacy threats.  This draft explores ways one might dispel that
   notion, and discusses how security/privacy addressing might be used
   on 6LoWPAN technologies without additional overhead in data packets.

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 August 20, 2015.

Copyright Notice

   Copyright (c) 2015 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
   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




Thaler                   Expires August 20, 2015                [Page 1]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Compression Details . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Use of IEEE-Identifier-Based Addresses  . . . . . . . . .   4
     3.2.  Use of 16-Bit Short Addresses . . . . . . . . . . . . . .   5
     3.3.  Use of Non-IEEE-Identifier-Based Addresses  . . . . . . .   6
       3.3.1.  Source Address Compression  . . . . . . . . . . . . .   6
       3.3.2.  Destination Address Compression . . . . . . . . . . .   6
       3.3.3.  Context Identifier  . . . . . . . . . . . . . . . . .   6
       3.3.4.  Context State . . . . . . . . . . . . . . . . . . . .   7
       3.3.5.  Context Distribution  . . . . . . . . . . . . . . . .   7
       3.3.6.  Negotiation . . . . . . . . . . . . . . . . . . . . .   8
       3.3.7.  Discussion of Tradeoffs . . . . . . . . . . . . . . .   8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Amount of Entropy Needed . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   RFC 6973 [RFC6973] discusses privacy considerations for Internet
   protocols, and Section 5.2 in particular covers a number of privacy-
   specific threats.  In the context of IPv6 addresses, Section 3 of
   [I-D.ietf-6man-ipv6-address-generation-privacy] provides further
   elaboration on the applicability of the privacy threats.  When
   interface identifiers (IIDs) are generated without sufficient
   entropy, devices and users become vulnerable to the various threats
   discussed there, including correlation of activities over time,
   location tracking, address scanning, and device-specific
   vulnerability exploitation.

   Interfaces identifiers formed from IEEE identifiers can have
   insufficient entropy unless the IEEE identifier itself has sufficient
   entropy, and enough bits of entropy are carried over into the IPv6
   address to sufficiently mitigate the threats.  Typically "enough"
   bits of entropy means at least 46 bits (see Appendix for why);
   ideally all 64 bits of the IID should be used, although historically
   some bits have been excluded for reasons discussed in [RFC7421].




Thaler                   Expires August 20, 2015                [Page 2]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   Furthermore, IEEE-identifier-based IIDs are also insufficient to
   prevent location tracking unless the IEEE identifier itself is
   different at each network location.  This observation suggests that
   the privacy threats can be mitigated in either of two ways: either
   use an IPv6 address generation mechanism that is not IEEE-identifier-
   based, or else make sure the IEEE identifier contains at least 46
   bits of entropy and is changed if a device moves to a different
   network.  For this reason, [I-D.ietf-6man-default-iids] recommends
   using the address generation scheme in [RFC7217] by default, rather
   than IEEE-identifier-based addresses.

   Furthermore, to mitigate the threat of correlation of activities over
   time, [RFC4941] specifies the notion of a "temporary" address to be
   used for sessions that should not be linkable to a more permanent
   identifier (such as a DNS name, user name, or stable hardware
   address).  Such temporary addresses are appropriate for connections
   (typically locally-initiated outbound sessions) that an attacker
   cannot link to a stable identifier such as a user name or DNS name.
   Indeed, the default address selection rules [RFC6724] now prefer
   temporary addresses by default for outgoing connections.  When
   temporary addresses are used, a new temporary address is periodically
   (default is 1 day in [RFC4941]) generated, which limits the threat of
   correlation of activies over time to that period.  The address itself
   though may still be usable for existing long-lived connections (but
   not new connections) for some longer period (default is 1 week); this
   allows for not breaking application sessions, especially those that
   might be initiated shortly before a new temporary address is
   generated.  This fact means that multiple temporary addresses can
   exist at the same time, one for new connections, and one or more
   (often up to 6, per the default periods) old ones for long-lived
   connections.  This is in addition to any "stable" addresses that
   might be used for connections that are linkable to more permanent
   identifiers such as DNS names or user names.  Whereas most threats
   could be mitigated if the IEEE identifier contains sufficient entropy
   and is different per-network, mitigating the threat of correlation of
   activities over time typically cannot be done using an IEEE-
   identifier-based-IID, since mitigating such a threat typically
   involves the ability to use multiple IPv6 addresses simultaneously
   whereas typically only one IEEE identifier can be used at a time.

   Finally, allowing efficient use of addresses that are not IEEE-
   identifier-based also has additional security benefits not specific
   to privacy.  For example, addresses such as Cryptographically
   Generated Addresses (CGAs) [RFC3972] and Hash-Based Addresses (HBAs)
   [RFC5535] can be used in security protocols such as Secure Neighbor
   Discovery (SeND) [RFC6496], IPsec, etc.  Such techniques rely on
   having around 59 or more bits of entropy in the address to provide
   sufficient cryptographic protection.



Thaler                   Expires August 20, 2015                [Page 3]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   RFC 6775 [RFC6775] already allows for the use of non-IEEE-identifier-
   based addresses, such as those provided by DHCPv6 [RFC3315].  There
   has been some concern, however, that such approaches necessarily
   interfere with efficient header compression for IPv6 (e.g., over IEEE
   802.15.4-based networks [RFC6282]), as it is important to keep data
   packets small on 6LoWPAN networks.

   Another potential concern is that of efficiency, such as avoiding DAD
   all together when IPv6 addresses are IEEE-identifier-based.
   Appendix A of [RFC4429] provides an analysis of address collision
   probability based on the number of bits of entropy.  A simple web
   search on "duplicate MAC addresses" will show that collisions do
   happen with MAC addresses, and thus based on the analysis in
   [RFC4429], using sufficient bits of entropy in non-IEEE-identifier-
   based addresses can provide greater protection against collision than
   using MAC addresses.

   The remainder of this document explores how one might use addresses
   with sufficient entropy on 6LoWPAN networks while avoiding extra
   overhead.

2.  Terminology

   This document uses the terminology defined in Section 3 of [RFC6973],
   including terms such as "(un)linkability" and "anonymity set".

   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 [RFC2119].

3.  Compression Details

   The LOWPAN_IPHC encoding format specified in Section 3.1 of RFC 6282
   [RFC6282] defines a method for deriving IIDs from the link-layer
   source and/or destination addresses in the encapsulation header.
   Unicast IPv6 addresses may be compressed to 64, 16, or 0 bits in the
   encoded IPv6 header.

3.1.  Use of IEEE-Identifier-Based Addresses

   As noted earlier, some threats could be mitigated using per-network
   "randomized" IEEE identifiers with 46 or more bits of entropy.  A
   number of such proposals can be found at
   <https://mentor.ieee.org/privecsg/documents>, and Section 10.8 of
   [BTCorev4.1] specifies one for Bluetooth.  Using IPv6 addresses
   derived from such IEEE identifiers would be roughly equivalent to
   those specified in [RFC7217].




Thaler                   Expires August 20, 2015                [Page 4]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   Such addresses would be encoded as usual using the LOWPAN_IPHC
   encoding format.  For example, if the source and destination
   addresses are both on-link and derived from the IEEE identifier in
   the encapsulating header:

   o  SAC (Source Address Compression) is set to 0 to indicate stateless
      compression.

   o  SAM (Source Address Mode) is set to 11 to indicate the address is
      fully elided and can be computed from the encapsulating header.

   o  DAC (Destination Address Compression) is set to 0 to indicate
      stateless compression.

   o  DAM (Destination Address Mode) is set to 11 to indicate the
      address is fully elided and can be computed from the encapsulating
      header.

3.2.  Use of 16-Bit Short Addresses

   An IPv6 address formed (per Section 6 of [RFC4944]) from an 16-bit
   identifier such as an IEEE 802.15.4 16-bit short address does not
   provide sufficient entropy to fully mitigate address scanning, as the
   size of the address scan search space depends on the entropy in the
   IID, and only 15 bits are available for unicast addresses.  An
   adversary could also use statisical methods to determine the size of
   the L2 address space and thereby make some inference regarding the
   underlying technology being IEEE 802.15.4 on a given link.  As such,
   this address generation mechanism SHOULD NOT be used on networks
   where privacy threats may be an issue, such as any networks that have
   Internet connectivity.

   It might be possible to construct IPv6 addresses from 16-bit short
   addresses using an alternate mechanism that mitigates address scans,
   if all nodes on a given L2 network have a shared secret (such as the
   key needed to get on the layer-2 network) and generate the IID by
   using a one-way 64-bit hash of the shared secret together with the
   short address.  The use of such a hash would result in the IIDs being
   spread out among the full range of IID address space.

   "Temporary" addresses could possibly be generated in the same way by
   also including in the hash the Version Number from the Authoritative
   Border Router Option (ABDO) if any.  This would allow changing
   temporary addresses whenever the Version Number is changed (even if
   the set of prefix or context information is unchanged).  Such a
   scheme would likely require using the Context Identifier (CID) to
   distinguish between non-temporary addresses, "current" temporary




Thaler                   Expires August 20, 2015                [Page 5]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   addresses, and "past" temporary addresses based on a previous Version
   Number.

   Specifying further details of such a scheme is left for future
   versions of this draft, if there is interest.

3.3.  Use of Non-IEEE-Identifier-Based Addresses

   Unicast addresses that are not IEEE-identifier based could be
   compressed to 0 bits as follows, using stateful context-based
   compression where the entire IPv6 address including the IID (as
   opposed to only the IPv6 prefix) are covered by context information.
   It is also worth pointing out that this same scheme would also allow
   compressing DHCPv6-assigned addresses even in networks where privacy
   is not a primary concern, thus potentially providing efficiency
   benefits in addition to privacy and security ones.  Furthermore,
   unlike stateless compression, stateful context-based compression
   could also allow compressing addresses of nodes outside the local
   network (i.e., where the IEEE identifier in the encapsulating header
   is that of a router rather than the peer, and the peer's address does
   not have a prefix in the local network) and hence can provide greater
   savings in such cases.

3.3.1.  Source Address Compression

   SAC (Source Address Compression) MUST be set to 1 to indicate
   stateful context-based compression.

   SAM (Source Address Mode) MUST be set to 11 to indicate that the
   address is fully elided.

3.3.2.  Destination Address Compression

   DAC (Destination Address Compression) MUST be set to 1 to indicate
   stateful context-based compression.

   DAM (Destination Address Mode) MUST be set to 11 to indicate that the
   address is fully elided.

3.3.3.  Context Identifier

   When non-IEEE-identifier-based addresses are used as described in
   this document, each address MUST be associated with a separate
   context.  That is, the "prefix" associated with a context MUST be the
   full 128 bits of the IPv6 address.

   LOWPAN_IPHC supports up to 16 source address contexts and 16
   destination address contexts, allowing for simultaneous use of up to



Thaler                   Expires August 20, 2015                [Page 6]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   16 source addresses and 16 destination addresses that are not IEEE-
   identifier-based.  Context 0 is the default context if the CID
   (Context Identifier Extension) octet is absent, and other values
   require the CID to be present.  As such, the address most commonly
   used (typically either the stable non-temporary address, or the
   currently preferred temporary address) could be assigned to context 0
   so that the presence of the CID octet is minimized.

3.3.4.  Context State

   As specified in [RFC6775], context state is distributed by routers
   and is shared across a LoWPAN.  This means that the use of CIDs
   described above would only support compression of 16 source and
   destination addresses across the entire LoWPAN.  However, Section 8
   of [RFC6775] explicitly allows for such context dissemination to be
   substituted by alternatives defined in other specifications.  We now
   describe such a substitute that would allow header compression with
   up to 16 source addresses and 16 destination addresses *per node*.

   First, a context entry is defined to be indexed by a { link-layer
   address, CID } tuple, rather than just a CID.  Second, each node is
   responsible for generating and disseminating the CIDs for its own
   IPv6 addresses.

   Thus, each Neighbor Cache Entry (NCE) in a router conceptually
   contains the CID of the neighbor's address, used when compressing
   packets sent to it.

3.3.5.  Context Distribution

   To disseminate CID information from a host to a router, the Address
   Registration Option (ARO) defined in Section 4.1 of [RFC6775] can be
   extended to include the CID by using 5 of the 24 Reserved bits (one
   for a flag to denote a CID is present, and 4 for the CID).  For
   distribution in a multihop network, the Duplicate Address Request
   (DAR) and Duplicate Address Confirmation (DAC) messages can be
   similarly extended to include the CID in currently Reserved bits.

   To disseminate CID information from a router to a host, Section 4.2
   of [RFC6775] defines the 6LoWPAN Context Option (6CO) for use in
   Router Discovery.  If a router sees that a host is sending packets
   without compressing a source or destination address, the router could
   send it an updated 6CO with a CID for that address as the context
   prefix, to allow compression of subsequent packets.  Since each non-
   IEEE-identifier-based address requires its own context, the Context
   Length field MUST be set to 128 in the 6CO containing such context
   information.  Note that the CID in a 6CO for another address within
   the 6LoWPAN is still generated by the router (since it is specific to



Thaler                   Expires August 20, 2015                [Page 7]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   the router's link-layer address as used by the host to which the 6CO
   is sent); it is not the same value as the CID generated by the
   destination node itself, which CID is used by its router when
   forwarding a packet to it.  Thus a router is responsible for updating
   CIDs in packets it forwards, just as it updates the link-layer source
   and destination addresses in the encapsulating header.

   Specifying further details of such a scheme is left for future
   versions of this draft, if there is interest.

3.3.6.  Negotiation

   To negotiate using the substitute mechanisms above, rather than the
   default mechanisms specified in [RFC6775], the 6LoWPAN Capability
   Indication Option (6CIO) could be used as allowed for in Section 3.4
   of [RFC7400] by assigning one of the "6LoWPAN capability Bits" for
   this purpose.

3.3.7.  Discussion of Tradeoffs

   This proposal decentralizes a portion of context generation and
   distribution to include simple nodes.  In many 6LoWPAN scenarios, as
   much as possible is offloaded to router nodes precisely because end
   nodes are so limited.  Until context info is learned for a given
   destination address, a node is not able to compress it.  Compression
   would kick in after the context info is known.  After context info is
   learned, the 4-bit CID must be stored for the destination address.
   As such, using this scheme requires a slight amount of overhead in
   the initial packet(s) but no additional overhead afterwards, and it
   requires no additional memory overhead initially, but a slight amount
   of additional memory overhead after context is learned.

   In the rare case that a simple node needs to simultaneously
   communicate with more than 16 other non-IEEE-identifier-based
   destination addresses, at most 16 of them will be able to be
   compressed, and the others will have additional packet overhead.

4.  IANA Considerations

   The approach described in Section 3.3 would require IANA to allocate
   a bit in the "6LoWPAN capability Bits" subregistry for this purpose.

5.  Security Considerations

   This entire document is about security considerations and possible
   mitigations.





Thaler                   Expires August 20, 2015                [Page 8]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


6.  Acknowledgements

   Thanks to Fernando Gont, Christian Huitema, and Gabriel Montenegro
   for discussion on the ideas described in this draft.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC6282]  Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              September 2011.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, November 2014.

7.2.  Informative References

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4429]  Moore, N., "Optimistic Duplicate Address Detection (DAD)
              for IPv6", RFC 4429, April 2006.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC5535]  Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June
              2009.




Thaler                   Expires August 20, 2015                [Page 9]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   [RFC6496]  Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
              Martinez, "Secure Proxy ND Support for SEcure Neighbor
              Discovery (SEND)", RFC 6496, February 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973, July
              2013.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, February 2014.

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217, April 2014.

   [RFC7288]  Thaler, D., "Reflections on Host Firewalls", RFC 7288,
              June 2014.

   [RFC7421]  Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
              A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
              in IPv6 Addressing", RFC 7421, January 2015.

   [I-D.ietf-6man-ipv6-address-generation-privacy]
              Cooper, A., Gont, F., and D. Thaler, "Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              draft-ietf-6man-ipv6-address-generation-privacy-03 (work
              in progress), January 2015.

   [I-D.ietf-6man-default-iids]
              Gont, F., Cooper, A., Thaler, D., and W. Will,
              "Recommendation on Stable IPv6 Interface Identifiers",
              draft-ietf-6man-default-iids-02 (work in progress),
              January 2015.

   [BTCorev4.1]
              Bluetooth Special Interest Group, "Bluetooth Core
              Specification Version 4.1", December 2013,
              <https://www.bluetooth.org/DocMan/handlers/
              DownloadDoc.ashx?doc_id=282159>.







Thaler                   Expires August 20, 2015               [Page 10]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


Appendix A.  Amount of Entropy Needed

   In terms of privacy threats discussed in
   [I-D.ietf-6man-ipv6-address-generation-privacy], the one with the
   need for the most entropy is address scans.  To mitigate address
   scans, one needs enough entropy to make the probability of a
   successful address probe be negligible.  Typically this is measured
   in the length of time it would take to have a 50% probability of
   getting at least one hit.  Address scans often rely on sending a
   packet such as a TCP SYN or ICMP Echo Request, and determining
   whether the reply is an ICMP unreachable errors (if no host exists)
   or TCP response or ICMP Echo Reply (if a host exists), or neither in
   which case nothing is known for certain.

   Many privacy-sensitive devices support a "stealth mode" as discussed
   in Section 5 of [RFC7288] whereby they will not send a TCP RST or
   ICMP Echo Reply.  In such cases, and when the device does not listen
   on a well-known TCP port known to the scanner, the effectiveness of
   an address scan is limited by the ability to get ICMP unreachable
   errors, since the attacker can only infer the presence of a host
   based on the absense of an ICMP unreachable error.

   Generation of ICMP unreachable errors is typically rate limited to 2
   per second (the default in routers such as Cisco routers running IOS
   12.0 or later).  Such a rate results in taking about a year to
   completely scan 26 bits of space.  For a network with at most 2^16
   devices on the same subnet, and the average lifetime of a device
   being 16 (2^4) years or less, this results in a need for at least 46
   bits of entropy (16+26+4) so that a address scan would need to be
   sustained for longer than the lifetime of devices to have a 50%
   chance of getting a hit.

   The actual math is as follows.  Let 2^N be the number of devices on
   the subnet.  Let 2^M be the size of the space to scan (i.e., M bits
   of entropy).  Let S be the number of scan attempts.  The formula is:
   P(at least one success) = 1 - (1 - 2^N/2^M)^S = 1/2.  Assuming 2^M >>
   S, this simplifies to: S * 2^N/2^M = 1/2, giving S = 2^(M-N) / 2, or
   M = N + log_2(2S).

   Although 46 bits of entropy may be enough to provide privacy in such
   cases, 59 or more bits of entropy are needed if addresses are used to
   provide security against attacks such as spoofing, as CGAs [RFC3972]
   and HBAs [RFC5535] do, since attacks are not limited by ICMP rate
   limiting but by the processing power of the attacker.  See those RFCs
   for more discussion.

   If, on the other hand, the devices being scanned for do not implement
   a "stealth mode", but respond with TCP RST or ICMP Echo Reply



Thaler                   Expires August 20, 2015               [Page 11]


Internet-Draft          6LoWPAN Privacy Addresses          February 2015


   packets, then the address scan is not limited by the ICMP unreachable
   rate limit in routers, since the attacker can determine the presence
   of a host without them.  In such cases, more bits of entropy would be
   needed to provide the same level of protection.

Author's Address

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: dthaler@microsoft.com





































Thaler                   Expires August 20, 2015               [Page 12]


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