| Internet Engineering Task Force | D. O'Reilly |
| Internet-Draft | April 25, 2018 |
| Intended status: Informational | |
| Expires: October 27, 2018 |
Analysis of the Crime Attribution Characteristics of Various IPv6 Address Assignment Techniques
draft-daveor-ipv6-crime-attribution-00
The migration from IPv4 to IPv6 is intended to fix a large number of problems with IPv4 that have been identified through many years of global use, not least of which is the shortage of available IPv4 addresses. One of the challenges with IPv4 that has not, apparently, been adequately considered is the crime attribution characteristics of IPv6 technologies.
The challenge of crime attribution on the Internet is an important one and a careful balance needs to be struck between the needs of law enforcement, the rights of crime victims and the right to privacy of the vast majority of Internet users who have no involvement in any sort of criminality.
The purpose of this document is to consider the crime attribution characteristics of various IPv6 address assignment techniques.
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 https://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 October 27, 2018.
Copyright (c) 2018 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 (https://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
IPv6 addresses are assigned to organisations in blocks that are much larger than the size of the blocks in which IPv4 addresses are assigned, with common IPv6 prefix sizes being /48, /56 and /64 [RFC6177], [RIPE_699]. Current regulatory models typically oblige ISPs to keep records to facilitate identification of their subscribers, and in the case of IPv6 this will mean recording the prefix(es) have been assigned to each customer.
From the perspective of crime attribution, therefore, when a specific IP address is suspected to be associated with criminal activity, records will most likely available from an ISP to identify the organisation to which the prefix has been assigned. The question then arises how an organisation approached by law enforcement authorities, particularly a large organisation, would be able to ascertain which host/endpoint within their network was using a particular IP address at a particular time.
This is not a new problem, with many difficulties of crime attribution already present in the IPv4 Internet. Nevertheless, it is worthwhile to consider the crime attribution characteristics of IPv6 in anticipation of wider deployment of this technology in the coming years.
IPv6 provides several mechanisms through which hosts can be assigned an IP address. [RFC7721] provides a list of these. Briefly they can be summarised as:
When approached by a law enforcement agency to identify the host/endpoint that was using a particular IP address at a particular time, the organisation's ability to deliver this information will depend on how IPv6 addresses are being assigned to endpoints within their network. This document considers the crime attribution characteristics of the address assignment methodologies listed above.
The crime attribution characteristics of several related topics are also considered:
This document considers only one scenario, as follows; through some means of investigation, an IPv6 address is suspected to be associated with criminal activity. How the IPv6 address has been associated with criminal activity is beyond the scope of this document - the starting point of this document is that an IPv6 address has already been identified (e.g. from logs of a victim or through other investigative means). What are the challenges arising from the use of IPv6 in attributing the activity of the suspect address to a specific endpoint?
Other aspects of the investigative process, including those that might be sources of evidence, which are out of scope of this document, include:
The security considerations associated with each of the technologies discussed are also out of scope except inasmuch as they influence the crime attribution characteristics of the technology.
The IPv6 addressing model is defined in [RFC4291]. This section provides a brief summary of the salient points of the IPv6 addressing model, the full detail of which can be found in the RFC.
In the IPv6 addressing model, addresses are assigned to interfaces, not nodes. There are three types of addresses:
There are no broadcast addresses in IPv6, their function being superseded by multicast addresses.
There are a number of special ranges of IPv6 addresses:
Global unicast addresses consist of an n-bit global routing prefix, m bits of subnet ID and 128-n-m bits of an interface ID. All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field. Global unicast addresses starting with binary 000 have no constraint on size or structure of interface ID field. An example of use of global unicast addresses starting with binary 000 are the IPv6 addresses that are used to map IPv4 addresses to the IPv6 address space.
Nodes and routers are required to recognise certain addresses as meaning themselves, as follows:
Similar to the way that IPv4 addresses can be manually assigned to hosts, IPv6 addresses can also be manually assigned. This is most frequently used in cases such as address assignment to routers or other infrastructure components, such as servers. Because IPv6 addresses are significantly less human-readable than IPv4 addresses, several address patterns have been noted [RFC7707]:
While it is expected that this address assignment technique is more likely to be used with infrastructure components rather than user hosts/endpoints, there is no reason in principle why endpoints could not have manually assigned IPv6 addresses. In such cases, the IT function in the organisation ought to have some process by which IPv6 addresses are selected for hosts.
Even if there is no such process, network monitoring could be carried out to isolate which host has been configured with a particular address, presuming the IPv6 address is still active on the network. Care must be taken to address the risk that a rogue client has temporarily used the IPv6 address that has been legitimately assigned to a different host while that legitimate host is inactive on the network.
In any case, the exact same problems arise with IPv4 and such issues are within the scope of normal investigative methodology.
Challenges can arise where a rogue host bypasses the organisational address assignment technique (e.g. DHCP), manually selecting an IPv6 address from the available space. Countermeasures can be deployed to address this risk, such as whitelisting of link-layer addresses, association of the link-layer addresses with specific IP addresses or other layer two authentication mechanisms.
Once again, this is not a problem that is unique to IPv6 and is not considered further here.
DHCPv6[RFC3315] allows servers to provide configuration, including IPv6 addresses, to IPv6 nodes. Clients and servers exchange DHCP messages using UDP. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. DHCP servers receive messages from clients using a reserved link-scoped multicast address. DHCP clients transmit most messages to this reserved multicast address, so the client does not need to be configured with the address or addresses of DHCP servers.
To request assignment of one or more addresses, a client locates a DHCP server and then requests the assignment of addresses and other configuration information from the server. IPv6 addresses that are assigned to the client have associated preferred and valid lifetimes, which are specified by the server.
Two advantages of IPv6 are that support for multicast is required and nodes can create link-local addresses during initialization. The availability of these features means that a client can use its link-local address and a well-known multicast address to discover and communicate with DHCP servers or relay agents on its link.
When a DHCP server assigns address(es) to a client, these addresses are encapsulated and provided to the client in a structure known as an identity association. A client may request the assignment of temporary or non-temporary addresses and different types of identity association will be used for each case. DHCP handling of address assignment is, however, no different for temporary addresses. The DHCP says nothing about details of the rules for generating successive temporary addresses, how clients use temporary addresses, rules for generating successive temporary addresses, etc. Clients ask for temporary addresses and servers assign them.
When a server is assigning temporary addresses, the identity association will carry one "set" of temporary addresses - that is, at most one address from each prefix assigned to the link to which the client is attached. Each address can have a separate valid and preferred lifetime associated with it. Requesting new temporary addresses from the server is the equivalent of generating new temporary addresses as described in [RFC4941]. The server will generate new temporary addresses and return them to the client. The client should request new temporary addresses before the lifetimes on the previously assigned addresses expire. A client may send a request to the server to have the lifetimes of temporary addresses extended.
In a message sent by a client to a server, values in the preferred and valid lifetime fields indicate the client's preference for those parameters. The client may send zero in these fields if it has no preference for the preferred and valid lifetimes. In a message sent by a server to a client, the client must use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes.
Stateful assignment of addresses using DHCP is amenable to retention of appropriate records.
At the present time, where DHCPv4 is in widespread use, it is uncommon for address mappings to be retained by organisations for extended periods of time indicating which hosts had which IP addresses at a particular time, particularly for smaller deployments. There is no reason to believe that the situation will be any different with the widespread deployment of DHCPv6.
There is a risk that an invalid client, masquerading as a valid client, can interact with a DHCP server and obtain valid addresses. The motivation for this may be for theft of service, or to circumvent auditing for any number of nefarious purposes.
DHCP authentication provides for authentication of the identity of DHCP clients and servers, and for the integrity of messages delivered between DHCP clients and servers. DHCP authentication does not provide any privacy for the contents of DHCP messages. The Delayed Authentication protocol described in section 21.4 of the DHCPv6 specification uses a secret key that is shared between a client and a server. The use of a "DHCP realm" in the shared key allows identification of administrative domains so that a client can select the appropriate key or keys when roaming between administrative domains. However, the Delayed Authentication protocol does not define any mechanism for sharing of keys, so a client may require separate keys for each administrative domain it encounters. The use of shared keys may not scale well and does not provide for repudiation of compromised keys.
IPv6 Stateless Address Autoconfiguration (SLAAC) describes the process used by a host in deciding how to auto configure its interfaces in IPv6[RFC4862]. This includes generating a link-local address, generating global addresses via stateless address autoconfiguration and then using duplicate address detection to verify the uniqueness of the addresses on the link. SLAAC requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers.
Routers advertise prefixes that identify the subnet(s) associated with a link and hosts generate an interface identifier that uniquely identifies an interface on a subnet. An address is formed by combining these two. In the absence of a router, hosts generate only link-local addresses. Autoconfiguration is only possible on multicast-capable links.
The process begins by generating a link-local address for the interface. This is achieved by appending the interface identifier to the well-known link-local prefix. At this point, the address is considered "tentative" because it might be in use by another host on the network. The host verifies the uniqueness of the address by sending a Neighbour Solicitation message containing the tentative address. If the address is already in use, the node that is using that address will send back a Neighbour Advertisement message. If the address is not unique, auto configuration stops and manual configuration is required or an alternative interface identifier can be used, if one is configured.
Once it has been established that the link-local address is unique, it is assigned to the interface. Next, the host listens for a Router Advertisement message or, if the host does not want to wait, it can send a Router Solicitation message to the all-routers multicast group.
Router Advertisement messages contain zero or more prefix information options that contain information that can be used to generate global addresses. Hosts can use stateless address autoconfiguration and DHCPv6 simultaneously if they want. If the Router Advertisement indicates that the prefixes can be used for autoconfiguration (by setting the "autonomous address-configuration flag" in the Prefix Information option field) it will also include a subnet prefix and lifetime values, indicating how long addresses created from this prefix will remain preferred and valid. Hosts process all Router Advertisements that are received periodically, adding to and refreshing the information received in previous advertisements.
Crucial to the crime attribution properties of SLAAC is the selection of interface identifier. Various algorithms exist for the generation of interface identifiers, depending on whether the interface identifier is intended to be stable (long-lived) or temporary. The following two sub-sections describe stable and temporary interface identifier generation algorithms.
Originally, various standards specified that the interface identifier should be generated from the link-layer address of the interface. For example [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], [RFC2590], [RFC3164], [RFC3527], [RFC4338], [RFC4391], [RFC5072], [RFC5121]. This is used in cases where a stable IPv6 address is being generated.
[RFC8064] changes the recommended default interface identifier generation scheme when SLAAC is in use to generate stable IPv6 addresses. It recommends against embedding stable link-layer addresses in IPv6 interface identifiers, recommending instead the use of a semantically opaque value as defined in [RFC7217] over all other alternatives. [RFC8064] also highlights some reasons why a stable IPv6 address would be desirable. For example, network management, event logging, enforcement of access control, provision of quality of service or for server or router interfaces. Similarly, they allow long-lived TCP connections. However, the document does not make recommendations about WHEN stable addresses should be used and when temporary addresses should be used.
[RFC7271] describes a method where an IPv6 address can be configured in such a way that it is stable within each subnet but the interface identifier changes when the host moves from one network to another. In general terms, the approach is to pass the following values to a cryptographic hash function (such as SHA1 or SHA256):
The interface identifier is generated by taking as many bits, starting at the least significant, as required. The result is an opaque bit stream that can be used as the interface id.
[RFC4941] describes a system by which interface identifiers generated from an IEEE identifier (EUI-64) can be changed over time, even in cases where the interface contains an embedded IEEE identifier. These are referred to as temporary addresses.
The reason behind development of this technique is that the use of a globally unique, non-changing, interface identifier means that the activity of a specific interface can be tracked even if the network prefix changes. The use of a fixed identifier in multiple contexts allows correlation of seemingly unrelated activity using the identifier. Contrast this with IPv4 addresses, where if a person changes to a different network their entire IP address will change.
The goals of the temporary address generation procedure are that:
To prevent the generation of predictable values, the algorithm must contain an unpredictable component. The algorithm assumes that each interface maintains an associated randomised interface identifier. When temporary addresses are generated, the current value of the interface identifier is used. The algorithm also assumes that for a given temporary address, the implementation can determine the prefix from which it was generated.
Two approaches to generate random interface identifiers are presented in [RFC4941], depending on whether stable storage is present.
When stable storage is present, it is assumed that a 64-bit history value is available and can be used. This value is generated as described below. The first time the system boots, a random value is selected.
When stable storage is not present, no history value will be available. Therefore, the initial history value should be generated at random. Algorithms other than MD5 can be used to compute the temporary address if desired.
Other approaches such as cryptographically generated addresses (CGA) can be used to generate random interface identifiers based on the public key of the node [RFC3972]. The goal of CGAs is to prove ownership of an address and prevent spoofing and stealing of IPv6 addresses. The CGA process may not be suitable for privacy addresses because (a) it requires nodes to have a public key, meaning the node can be identified by the key and (b) it is computationally intensive, discouraging frequent regeneration.
Devices implementing this specification must provide a way for end users to explicitly enable or disable the use of temporary addresses. Also, sites might wish to disable it, so implementations should provide a way for trusted system administrators to enable or disable the use of temporary addresses. Implementations should also provide a way to enable and disable generation of temporary addresses for specific prefix subranges.
IPv6 addresses are assigned to organisations in blocks much larger than the size of the blocks in which IPv4 addresses are assigned. The question arises about how an organisation approached by law enforcement authorities, particularly a large organisation, will be able to ascertain which host/endpoint within their organisation was using a particular IP address at a particular time when addresses have been assigned using SLAAC.
From the crime attribution perspective, both the recommended stable and temporary address generation algorithms pseudo-randomly select addresses from the space of available addresses. When SLAAC is being used, the hosts auto-configure the IP addresses of their interfaces, meaning there is no organisational record of the IP addresses that have been selected by particular hosts at particular points in time.
From a crime attribution point of view, the use of a stable interface identifier (whether generated for a link-local address or otherwise) will provide some measure of assurance that it will be possible to identify a specific host/interface based on the IPv6 address. While it may not be possible for a network administrator to calculate the interface identifier (and therefore the IPv6 address) that will be used by a specific interface, due to the presence of a secret key, with some effort it should be possible for a network operator to determine which host/endpoint, or at least a relatively small subset of hosts/endpoints, is responsible for traffic arising from a particular IPv6 address.
Due to the relatively long-term use of a particular address by an interface, it is at least possible that an organisation might be able to use traffic flow analysis or other similar network monitoring techniques to identify the endpoint using the address. This assumes that the IPv6 address is still active and generating traffic. It will also, of course, only identify the endpoint using the address at the time of the traffic flow analysis and not at the time of the alleged criminal activity that is under investigation.
The problem of crime attribution is exacerbated in the case of temporary interface identifier generation due to the fact that the generated addresses are the endpoint's preferred IPv6 address, by default, for a period of one day [RFC4941].
It is difficult to see how the activity of IPv6 addresses generated using temporary interface identifiers could be attributed to any host/endpoint. The interface identifier generation algorithm has a cryptographic component, meaning that the addresses will appear to be pseudo-randomly selected from the range of available addresses.
Even presuming that the host/endpoint is still active and generating traffic there is no apparent way to associate the activity of the host/endpoint's current address with the address in use at the time of the alleged criminal activity.
This attribution problem is "by design", arising from the expected behaviour of SLAAC with temporary interface identifiers. It therefore seems that the crime attribution challenges that will arise from the use of this technology have not been given due consideration. The use of this technology will likely become a significant crime attribution challenge in future.
Transitional technologies relate to the period during which IPv4 and IPv6 must co-exist on the Internet. The problem can be broken down into the following categories:
Two broad categories of technologies exist to facilitate this transition. The first is mapping/translation ([RFC6052], [RFC7915], [RFC6219], [RFC7757], [RFC6791], [RFC6146], [RFC3142], [RFC2529], [RFC6877], [RFC7599]) and the second is tunnelling ([RFC4213], [RFC3056], [RFC5214], [RFC4380], [RFC5569], [RFC5969], [RFC7600], [RFC7040], [RFC7596], [RFC7597]). Some technologies incorporate aspects of both mapping/translation and tunnelling ([RFC6877], [RFC6333]).
Only the crime attribution characteristics of the address mapping involved in these technologies are considered here. Additionally, for the purposes of this document, technologies that relate to extending the lifetime of IPv4 (such as Carrier-Grade NAT) are out of scope. The crime attribution characteristics of these technologies are discussed elsewhere [RFC6302], [I-D.daveor-cgn-logging].
Stateless mapping technologies involve algorithmic mapping between an IPv4 address and an IPv6 address. Generally this is achieved through one of a number of techniques for embedding an IPv4 address within an IPv6 address. For example, through the use of a well-known prefix [RFC6052], using a subset of a global prefix [RFC6052], [RFC6219] or through a lookup table [RFC7757]. In special cases, mapping to a specific (or small range) of IPv4 addresses is also possible [RFC6791].
Stateful mapping technologies involve recording mappings between addresses at intermediate translation infrastructure. Often mapping from an IPv4 source to IPv6 destination is achieved via stateless algorithmic mapping, with IPv6 source to IPv4 destination mapping taking place using some sort of stateful mapping between IPv6 address and IPv4 address plus port number [RFC6146].
[RFC6052] cites a security concern arising from embedding of a fake IPv4 address in an IPv6 address as the source of a malicious packet. After translation the packet will appear as an IPv4 address from the specified (fake) source, and identification of the true source will be extremely difficult, relying on the translation records of the mapping infrastructure. Without mitigation this attack could allow malicious IPv6 nodes to spoof arbitrary IPv4 addresses. To mitigate this, reverse path checks are required to verify that the packets are coming from the expected topological direction.
IPv6 tunnelling over IPv4 is achieved by provision of a virtual link using IPv4 as the lower-layer transport. Tunnelling of this type is most frequently performed between two router endpoints in which one router encapsulates the IPv6 packet in IPv4, forwards it to the other router where it is decapsulated and forwarded as an IPv6 packet. Similar tunnelling of IPv4 over IPv6 to facilitate the later stages of IPv6 migration is also possible.
Particular care must be taken to make sure that tunnelling technologies do not enable bypassing of ingress filtering, which could lead to injection of IPv6 packets into the encapsulation tunnel and these packets being successfully decapsulated and forwarded.
In some cases, traffic is accepted and decapsulated from any source from which IPv4 traffic would normally be accepted. This leads to a risk of "traffic laundering" where traffic is channelled through third parties to make tracing the real origin of the attack more difficult [RFC3056], [RFC3964].
[RFC6275] describes Mobile IPv6, a protocol that allows nodes to remain reachable while moving around in the IPv6 Internet. As a fundamental service in an IPv6 stack, it is expected that Mobile IPv6 will be deployed in most nodes of the Internet. [RFC6275] provides an excellent description of the basic operation of Mobile IPv6, from which this section borrows heavily.
Each node is always identified by its "home address", regardless of its current point of attachment to the Internet. The "home address" is an IP address assigned to the mobile node within its home subnet prefix on its home link. While situated away from home, a mobile node is also associated with a "care-of address", which provides information about the mobile node's current location. A care-of address is an IP address associated with a mobile node that has the subnet prefix of a particular foreign link. The mobile node can acquire its care-of address through conventional IPv6 mechanisms, such as stateless or stateful auto-configuration.
IPv6 packets addressed to the mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address and then to send any packets destined for the mobile node directly to it at this care-of address.
The association between a mobile node's home address and care-of address is known as a "binding" for the mobile node. While away from home, a mobile node registers its primary care-of address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. The mobile node performs this binding registration by sending a "Binding Update" message to the home agent. The home agent replies to the mobile node by returning a "Binding Acknowledgement" message.
Any node communicating with a mobile node is referred to as a "correspondent node" of the mobile node. There are two possible modes for communications between the mobile node and a correspondent mode. The first mode, bidirectional tunnelling, does not require Mobile IPv6 support from the correspondent node. Packets from the correspondent node are routed to the home agent and then tunnelled to the mobile node. Packets to the correspondent node are tunnelled from the mobile node to the home agent ("reverse tunnelled") and then routed normally from the home network to the correspondent node. In this mode, the home agent uses proxy Neighbour Discovery to intercept any IPv6 packets addressed to the mobile node's home address (or home addresses) on the home link. Each intercepted packet is tunnelled to the mobile node's care-of address using IPv6 encapsulation.
The second mode is known as "route optimisation". Packets from the correspondent node can be routed directly to the care-of address of the mobile node. When sending a packet to any IPv6 destination, the correspondent node checks its cached bindings for an entry for the packet's destination address. If a cached binding for this destination address is found, the node uses a new type of IPv6 routing header to route the packet to the mobile node by way of the care-of address indicated in this binding. Routing packets directly to the mobile node's care-of address allows the shortest communication path to be used.
While a mobile node is away from home, it continues to use its home address, as well as also using one or more care-of addresses. When sending a packet while away from home, a mobile node may choose among these in selecting the address that it will use as the source of the packet as follows:
As mentioned above, care-of addresses can be generated using normal IPv6 mechanisms such as stateless or stateful autoconfiguration and will presumably be assigned in accordance with the configuration of the "care-of" network to which the node is connected.
Three issues related to crime attribution have been identified regarding the use of Mobile IPv6. These will be discussed in the following sections.
Consider a node whose home network is "A", with a home IPv6 address of "A1" is present on a network "B" using care-of address "B1".
To allow forwarding of traffic to A1 while it is on network B, the node will register the binding between its home address and its care-of address with the home agent on network "A". This registration could, in principle at least, be recorded and made available if needed for a criminal investigation. Therefore, the best attribution information is likely to be available in the records of the home network, presuming those records are retained.
It is possible that an administrator of the home network could determine the preferred "care-of" address of a particular IPv6 address from records generated from the normal operation of the Mobile IPv6 protocol.
However, this presumes that a law enforcement agency knows to request information about the activity of IP address A1. It is possible that the mobile node may choose to use the care-of address (B1 in this example) as the source IP address in IP packets while away from home. In these cases, it is not clear how a law enforcement agency would even know about the relationship between the node and network A at all. To make that link feasible requires that network "B" has retained records of devices to which care-of addresses have been assigned and this will be discussed in the next section.
The mobile node has been assigned an IP address on the network B and, in the first instance, all of the attribution issues discussed elsewhere in this document will be applicable to the care-of address of the mobile node.
It is not apparent from the protocol that there is any difference between assignment of an IPv6 address to a mobile node that is visiting the network as opposed to assignment of an IPv6 address to a node for which it is the home network. If there is any difference, it would appear that the differences are organisational, meaning that addresses for mobile nodes are assigned from a different portion of the organisation's address space or are more comprehensively monitored, for example. There is, however, no particular reason (from the point of view of the Mobile IPv6 protocol) why temporary SLAAC addresses or other addresses for which no attribution records are retained, could not be assigned as care-of addresses to mobile nodes.
The protocol allows a mobile node to select its care-of address as the source address in IP packets and if this communication is criminal in nature, the records of which node was using the care-of address at a particular point in time would become important.
There is no aspect of the protocol that requires the "care-of" network to retain any particular records of use by mobile nodes of care-of addresses, or to retain any record of the binding between care-of addresses and home addresses. The hope, therefore, is that organisations that assign care-of addresses keep records of assignments on their network.
In summary, it may be very challenging for law enforcement authorities to identify the home network of a particular node based only on the care-of address and records available at the "care-of" network.
Correspondent routing/route optimisation allows a correspondent node to cache an association between the home and care-of addresses of the mobile node, and forward traffic directly to the mobile node rather than tunnel that traffic via the home agent. For the purpose of this discussion, consider the mobile node as engaging in criminal activity with the correspondent node being the victim or source of evidence of the activity.
In this case, because the route optimisation is only temporarily cached, it is highly likely that after a period of time the correspondent node will not retain any record of the relationship between the care-of and home addresses of the mobile node. The only remaining record will be of the activity of the care-of address, meaning total reliance of the records of the "care-of" network to associate the care-of address with the home address of the mobile node.
IPv6 allows multiple unicast addresses to be assigned to interfaces. These addresses might have different reachability scopes (link-local, site-local or global). They might also be preferred or deprecated. There might also be public addresses and temporary addresses. Both the source and destination endpoints may have multiple IP addresses by which they can communicate with each other.
[RFC6724] describes two related algorithms, one for source address selection and one for destination address selection that can be used by hosts when selecting IP addresses from the range of possibilities. The document specifies default behaviour and does not override choices made by applications or upper-layer protocols, nor does it preclude the development of more advanced mechanisms for address selection. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses, depending on the available source addresses.
The algorithm uses several criteria in making decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non-deprecated source addresses, avoid the use of transitional addresses when native addresses are available and all else being equal prefer address pairs having the longest possible common prefix. For source address selection, temporary addresses are preferred over public addresses. In mobile situations, home addresses are preferred over care-of addresses.
The default address selection document also mandates implementations to provide a mechanism that allows an application to configure its preference for temporary addresses over public addresses. It also allows for an implementation to prefer temporary addresses by default, so that the connections initiated by the node can use temporary addresses without requiring application-specific enablement.
The preference for temporary source addresses is explicitly incorporated into the default IPv6 address selection algorithms outlined in [RFC6724].
This recommendation further exacerbates the challenges highlighted in Section 2.3.2 relating to the use of temporary addresses and increases the importance of addressing these issues.
[RFC7084] specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies.
This document specifies, amongst other things, how an IPv6 CE router automatically provisions its WAN interface, acquires address space for provisioning of its LAN interfaces, and fetches other configuration information from the service provider network. Automatic provisioning of more complex topology than a single router with multiple LAN interfaces is out of scope for the document.
It was noted that requirement L-8 is:
[RFC6092] describes an additional set of recommended security capabilities for devices at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.
Requirement L-8, cited above indicates that the IPv6 CE router might be assigning addresses to endpoints. No corresponding recommendation that the router should record which addresses have been assigned to endpoints is contained in the document. No recommendation related to recording address assignments is contained in [RFC6092] either.
For reasons of improved host isolation and enhanced subscriber management on shared network segments, there are published approaches for assigning IPv6 prefixes to individual hosts [RFC8273], [RFC3314], [RFC7934]. Advantages are then achieved by making sure that devices cannot send packets to each other except through the first-hop router.
It is understood from the referenced sources that this model is proposed for use principally in mobile networks. The crime attribution characteristics of assignment of an IPv6 prefix per host will depend on the use to which the host puts the prefix. For example, in the scenario where a mobile device is acting as a "hotspot" for other tethered devices it will no longer be possible to attribute all activity related to any addresses with the prefix to a specific endpoint. This scenario is specifically discussed in [RFC3314] and [RFC7934] as an advantage of assigning IPv6 prefixes per host.
This situation is analogous to the situation with attributing criminal activity to a host that is attached to a wireless LAN access point. Without appropriate security controls there is a risk that an attacker could use an unauthorised connection to the wireless LAN access point to commit criminal acts. Similarly in cases where an IPv6 prefix has been assigned to a mobile device that can act as a wireless "hotspot", unauthorised tethered devices may be able to perform criminal acts in an untraceable way. This problem is, of course, not specific to IPv6 because the same problem could arise with an unauthorised tethering to a mobile device using IPv4.
It has been highlighted elsewhere that the assignment of a prefix per host could make the prefix an identifying characteristic of the host, with the associated privacy implications [I-D.herbert-ipv6-prefix-address-privacy]. The reference cited proposes a high-level model involving the randomisation of addresses to address this (referred to as identifier addresses), followed by an address translation to a globally stable addresses (referred to as locator addresses). The document proposes that the crime attribution concerns of the proposed approach could be addressed by maintaining records of the mappings between identifier and locator addresses, meaning that from a crime attribution point of view the proposed technology would be similar to an IPv4 NAT.
Significant consideration has been given to the privacy and security considerations of IPv6 assignment methodologies and supporting technologies.
However, inasmuch as IPv6 is intended to address the shortcomings of IPv4, the shortcomings related to crime attribution do not appear to have received sufficient consideration. In fact, the trajectory of the work reviewed during the production of this document would seem to indicate a significantly greater focus on architectural models to actively obfuscate the identity of endpoints using IPv6.
Whilst individual privacy is extremely important, total privacy would have significant negative implications for law enforcement ability to conduct investigations of criminal activity online as well as on the rights of victims of crime.
It is hoped that the production of this document will stimulate further discussion on the matter.
This memo includes no request to IANA.
Many of the cited documents contain security considerations for the technologies that they define or consider and from a technical perspective, this document does not introduce any additional security considerations.
On the other hand, this document considers the security features of those same technologies from a different perspective and in that respect, this entire document is a consideration of security implications of those technologies.
| [I-D.daveor-cgn-logging] | O'Reilly, D., "Approaches to Address the Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies", Internet-Draft draft-daveor-cgn-logging-04, April 2018. |
| [I-D.herbert-ipv6-prefix-address-privacy] | Herbert, T., "Privacy in IPv6 Network Prefix Assignment", Internet-Draft draft-herbert-ipv6-prefix-address-privacy-00, February 2018. |