Internet DRAFT - draft-struik-6lo-on-ipv6-addressing
draft-struik-6lo-on-ipv6-addressing
6tisch R. Struik
Internet-Draft Struik Security Consultancy
Intended status: Informational October 27, 2014
Expires: April 30, 2015
Observations about IPv6 Addressing
draft-struik-6lo-on-ipv6-addressing-00
Abstract
This document contains some observations on IPv6 addressing.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
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 April 30, 2015.
Copyright Notice
Copyright (c) 2014 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
Struik Expires April 30, 2015 [Page 1]
Internet-Draft 6lo-addressing October 2014
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. Opaque identifiers . . . . . . . . . . . . . . . . . . . . . 2
2. Security Considerations . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3
5. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Opaque identifiers
RFC7217 [RFC7217] describes a mechanism for generating opaque
interface identifiers and argues that these identifiers improve
security and privacy of IPv6 addresses, when compared to using
modified EUI-64 address formats. The main case presented in that
document is that using opaque interface identifiers, rather than
fixed hardware device identifiers, thwarts attempts at correlating of
host activities over time, tracking across multiple networks, and
pinpointing devices that may exhibit known vulnerabilities.
There are also some down sides to adopting this opaque identifier
format:
1. Use of opaque identifiers does not preclude traceability on layer
2. While this is an obvious remark, the reverse also seems to
hold: if Layer 2 MAC addresses would be randomized (see, e.g.,
discussion on MAC address randomization at IETF-90), then
derivation of IPv6 addresses using those randomized MAC adddreses
(rather than the EUI-64 hardware address) would certainly serve
the same purpose as the technique in RFC 7217. Moreover, IPv6
opaque addresses may trickle down to Layer 2, by deriving the
randomized MAC address from the interface identifier (assumed to
be at least 64-bit long). This would allow constrained nodes to
derive compression benefits that would not be available if one
would cut the ties between Layer 2 and Layer 3 address formats.
As such, this would benefit "constrained cluster" specifications,
such as RFC6282, RFC4944, and RFC 6755.
2. The algorithm in RFC 7217 for generating opaque interface
identifiers RID depends on an intra-device secret key
(secret_key), and some public parameters (Prefix, Net_Iface,
Network_ID) and takes the form RID:=F(key, public parameters).
It is noted that F() MUST be difficult to reverse, MUST not be
computable without knowledge of the secret key, and should not
Struik Expires April 30, 2015 [Page 2]
Internet-Draft 6lo-addressing October 2014
leak the secret key given a number of samples F(key,public
parms), where parms are under the control of an adversary. The
output should be at least 64 bits (and, in practice, mostly is).
While the specification suggests that the secret key should,
indeed, be kept secret, the specification seems to allow
administrator access and depends on trustworthy bootstrapping.
Since it cannot be verified outside the device whether the
quantity RID and the opaque interface identifier were indeed
generated as specified with a secret key unknown to any outside
device, this leaves this technique open to "Big Brother"-esque
manipulation. Indeed, it is not hard to see (inspired by
[Surveillance]) that one could field devices, where device-
internal private information could be leaked via the opaque
interface identifier, no matter the good intentions: the
supposedly opaque interface identifier simply serves as a so-
called subliminal channel. This subliminal channel cannot be
detected without close examination of the entire device
implementation.
2. Security Considerations
This note illustrates that privacy is a system issue and illustrates
examples where the opaque interface identifier could be turned into a
subliminal channel for releasing secret information to a Big Brother
agent, without means for detecting this.
3. IANA Considerations
There is no IANA action required for this document.
4. Acknowledgments
Kudos to Edward Snowden for introducing fascinating technical
problems to the paranoid.
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
Struik Expires April 30, 2015 [Page 3]
Internet-Draft 6lo-addressing October 2014
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012.
[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-01 (work in progress),
October 2014.
[I-D.ietf-6man-why64]
Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", draft-ietf-6man-why64-07 (work in
progress), October 2014.
[I-D.sarikaya-6lo-cga-nd]
Sarikaya, B. and F. Xia, "Lightweight and Secure Neighbor
Discovery for Low-power and Lossy Networks", draft-
sarikaya-6lo-cga-nd-01 (work in progress), October 2014.
[Surveillance]
Mihir Bellare, Kenneth G. Paterson, Phillip Rogaway,
"Security of Symmetric Encryption Against Mass-
Surveillance", CRYPTO 2014, IACR, August 2014.
Author's Address
Rene Struik
Struik Security Consultancy
Email: rstruik.ext@gmail.com
Struik Expires April 30, 2015 [Page 4]
