Internet DRAFT - draft-thaler-6lo-privacy-addrs
draft-thaler-6lo-privacy-addrs
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]
