Individual L. Keri Internet-Draft BUTE Expires: November 14, 2004 May 16, 2004 Privacy Enhanced Local Ethernet Network with Protocol Anonymization draft-keri-local-anon-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 14, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The privacy requirement of anonymity is much harder to achieve than security goals like confidentiality or authentication, since network routing has to take place between well known spots of the network. There are solutions providing anonymity on the Internet implemented on the application level, but there's also a possibility to achieve local anonymity on Ethernet networks without the introduction of new anonymous protocols by following a protocol anonymizing approach described in this document. Protocol anonymization is a simple network operation mode, which can provide local client anonymity on Ethernet networks under certain circumstances by eliminating the host identification capabilities of widely used local network protocols. Keri Expires November 14, 2004 [Page 1] Internet-Draft LAN with Protocol Anonymization May 2004 1. Introduction The requirement of privacy is often used as a synonym for security in the networking literature. Network privacy is equated to the safeguarding of the confidentiality of the communication content and the authentication of the communicating parties, which in fact are security requirements. Privacy or rather its informational aspect, i.e. data protection means more than that in technological terms: it also means the protection of the identity of the communicating parties, consequently the anonymity of the communication. During network communication a communicating person often can be correlated with a host, so primarily the addressing elements of the network protocols, which are indispensable for routing the traffic across the network are fundamentally contradicting the requirement of anonymity. Privacy hadn't been taken into account during the creation of network protocols and while the confidentiality and authentication security requirements have been enforced since by supplementing protocols, the issue of anonymity hasn't surfaced on the protocol level, despite the growing privacy concerns and the everyday presence of network communications. Although there are numerous solutions for the media of interconnected networks implementing Chaum's Mix concept [1], but primarily on the application level. Onion routing is also a Mix, which uses complex layered encryption, virtual circuits and special infrastructure for IP level anonymization, also in the context of the Internet. Contrary to these, this document discusses an anonymity scheme which achieves the anonymity of communication on local Ethernet networks, namely local anonymity, not by the introduction of new anonymous protocols, but rather through the anonymization of existing ones. Keri Expires November 14, 2004 [Page 2] Internet-Draft LAN with Protocol Anonymization May 2004 2. Local anonymity On local networks clients are using the shared resources of servers which could be an Internet gateway performing network address translation. The traffic of local networks can be easily monitored by the network's operator or even by the user of a host using the appropriate methods, even in a switched environment. As the protocols on local networks below the application layer are containing a number of elements usually capable of identifying the communicating hosts, they aren't suitable under normal conditions, even using encryption on the application or IP level, for the anonymous operation of local networks since the connection between the hosts and users is usually known. On local networks the addresses of servers must be considered as publicly known to enable the usage of their services, while the addresses of clients needn't be public to achieve this. The local protocol anonymization scheme pursued here consequently implements sender or client anonymity, that is, the information disclosed by the protocols themselves enables only the identification of the server side host and not that of the client. When using this scheme the limited number of protocols under the application layer are anonymized on the client side, the application layer showing a great variety of protocols being not affected. Although the elements of these application level protocols and the content of the communication could also reveal the client host and its user, this can be avoided by using an encrypting application level protocol variant providing confidentiality, which is usually available in the case of Internet application level protocols. Keri Expires November 14, 2004 [Page 3] Internet-Draft LAN with Protocol Anonymization May 2004 3. Protocol elements with identification capabilities The lower level protocols on an Ethernet network contain a number of elements capable of identifying the communicating hosts that can be used by an eavesdropper to invade privacy. These are the following elements. 3.1 Ethernet layer The Ethernet layer uses the 48 bit MAC address to identify the network interfaces of the hosts. The MAC address is not necessarily, but usually made up of the globally unique combination of the 24 bit manufacturer identifier and the 24 bit serial number of the adapter. Therefore knowing the local network's interface identifiers the source and destination hosts can be determined from the frames' Ethernet addressing. 3.2 IP layer When static IP address allocation is used the source and destination IP address of an IP packet are definite host identifiers. When using dynamic IP address allocation the operator can easily determine which IP address was assigned to a given host or rather MAC address at a given time from the logs of the DHCP server, but in view of the constant MAC addresses, this isn't even necessary. The IPv6 Stateless Autoconfiguration Protocol even combines the MAC address with the 128 bit IP address. 3.3 Transport layer: TCP and UDP The TCP and UDP port numbers are specifying the communicating applications binding to the ports of an IP host. Most protocol stack implementations are using simple incrementation of the previous allocated port number when determining the newly opened sockets' port number. This simple incrementation method enables the linking of the packets of different communications to the same originating host simply by observing the growing port numbers, because the individual hosts of a local network are placed with great probability on a well identifiable spot in the 16 bit port range. In some early TCP implementations the TCP initial sequence number generation at the beginning of a new TCP connection used predictable algorithms which made IP spoofing attacks feasible against the server [2]. This security problem would also mean host identification possibilities similar to that of the port numbers, but today the generation of the initial sequence number is sufficiently random to eliminate this kind of threat. Keri Expires November 14, 2004 [Page 4] Internet-Draft LAN with Protocol Anonymization May 2004 3.4 Operating system fingerprints Analyzing the differences in the behaviour of the TCP/IP stack implementations of the various operating systems, i.e. OS fingerprinting results in the possibility of determining the communicating hosts' operating systems [3]. This method can reveal the client's identity if it's known that a minority operating system is used by one or only a few clients on a network. Although the TCP/ IP behaviour can be uniformized to lessen this problem, this isn't the subject of this discussion. Keri Expires November 14, 2004 [Page 5] Internet-Draft LAN with Protocol Anonymization May 2004 4. Protocol anonymization In brief, by monitoring the MAC addresses, IP addresses and TCP/UDP port numbers, the source and destination hosts can be easily determined or, in case of port numbers, different communications can be linked together as belonging to the same host. To achieve local client anonymity the identification capabilities of these elements must be eliminated, while the network service provided by the protocols must remain unaffected. The host identification capability of the above mentioned elements results from their constant, predictable nature and their known relation to the physical hosts. However, replacing them regularly with a new value could break the known link between the physical host interface and the MAC, IP addresses and port numbers eliminating their identifying capability. The changing of these values evidently could only be performed simultaneously, changing only the IP address is useless if the MAC address remains unchanged and the changing of the IP and MAC address pair is also of no effect if the old and new address pair could be matched by the monitoring of the predictably incremented port numbers. The new addresses and port numbers should be generated in an unpredictably random manner while taking into account certain limitations. The lowest bit of the new MAC address' first half, which is the unicast-multicast bit, must be set to 0, the address selection therefore is restricted to a 47 bit range. On a normal sized local network the randomly generated new MAC addresses aren't likely to collide. The new IP address can be arbitrarily chosen in the host range determined by the netmask, i.e. on those bits of the IP address that are 0 in the netmask. The smaller the part of the IP address designating the subnetwork, the larger the possible host range. If the local network is connected to the Internet, the 10.x.x.x private network range provides the largest, 24 bit address space. The allocation of the 16 bit port numbers for the new TCP and UDP sockets must be performed in such a way that the new ports opened after the MAC-IP address pair change cannot be correlated to the port numbers allocated before. Therefore if the port numbers were incremented by one before the address change, adding an appropriately large random number or setting to a fixed value during the change could break the connection between the old and new port numbers. Keri Expires November 14, 2004 [Page 6] Internet-Draft LAN with Protocol Anonymization May 2004 5. Implementation guidelines Protocol anonymization, namely the above mentioned swapping of identifying protocol elements can be implemented in many ways depending on the circumstances. The level of anonymity gained by protocol anonymization is determined by two factors: the time interval between address changes and the synchronization of the changes between the clients. The simplest solution for the address change synchronization is if there's none, with the clients swapping addresses independently from each other at arbitrary intervals. This can ensure that the examination of one packet's addressing fields doesn't reveal the client host immediately, but if the clients are communicating persistently, the dropped and newly adopted addresses become traceable, with the analysis of the network traffic one could easily establish which new address pair showed up in place of another vanished at a given point. This could be got around by the synchronization of the clients' address changes, in this manner the clients could mingle with the address changing crowd. The simplest way to achieve this is the performing of collective address changes at fixed times, which can ensure without any additional protocols that there doesn't remain any connection between the former and later addresses, if the client hosts' clocks are properly synchronized. However it must be taken into account, that with the unavoidably performed address changes all open network connections are lost also, these communications are interrupted and must be reestablished. The synchronization can be refined by performing the address change only when there aren't any open network connections on the clients, but this means, that there is a need to introduce a new address change synchronization protocol, which in its simplest form may consist of notification packets sent out to a broadcast address by client hosts with open network connections before the given address swapping times, signalling that they aren't ready to change addresses. If only one such packet is picked up, address change won't be performed on the next possible occasion. The closing of permanently open connections, which are not involved in active communication can be the subject of further consideration. The randomly generated new MAC and IP addresses raise also the question of address collisions. In the case of MAC addresses, where the potential address space is big enough, the probability of address collisions is very little. In the case of IPv4 address, if the number of hosts on the subnetwork allowed by the netmask substantially exceeds the number of actual hosts, the probability of collisions is also low, but certainly cannot be disregarded completely. IPv6 has a much larger address space. Keri Expires November 14, 2004 [Page 7] Internet-Draft LAN with Protocol Anonymization May 2004 If the probability of a collision is low indeed, then a simple mechanism that recognizes the collision state and regenerates the random addresses is sufficient. A more elaborate solution would be the reservation of new addresses in advance by a broadcast announcement from a faked source address, so that the other hosts exclude these from the random address generation. New IP address could also be requested from a DHCP server with the renewed MAC address, also eliminating the possibility of IP address collisions. From the perspective of anonymity, the less time elapses between address changes, the more reliable will the anonymity become. Although the addresses which once have been untraceably renewed, won't reveal the communicating host later either, but the higher protocols (e.g. their authentication elements) and the communication content is also continually compromising the host and its user, if the higher protocols used aren't encrypted protocol variants. Consequently the longer an address pair is used, the easier the identification of its user will become, the more frequent the address change, the more difficult the identification will become. Contrarily, the breaking up of network connections caused by the address change deteriorates the usability of the network, accordingly the optimal address change interval suiting the actual circumstances must be chosen with both considerations in mind. For the local Ethernet anonymity to be feasible by the discussed protocol anonymization, certain requirements must be met by the network infrastructure also. The switches must tolerate the changes of MAC addresses accessible on its ports, that is to say, the switch has to update its port-MAC table immediately after the hosts have changed their addresses. The other restriction is that the switch's port-MAC table mustn't be queryable, since this would make it possible to determine what MAC and IP address a host uses at a given time and logging this information would make the whole protocol anonymization procedure futile. Consequently, local client anonymity achieved by protocol anonymization is a simple network operation mode, which requires some special arrangements to be made. An implementation can choose between numerous solutions ranging from a simple custom software to the support of the OS's TCP/IP stack. Keri Expires November 14, 2004 [Page 8] Internet-Draft LAN with Protocol Anonymization May 2004 6. Related work The changing of MAC addresses has already been suggested [4] to solve the data protection concerns raised by the IP addresses with built-in MAC addresses generated by the IPv6 Stateless Autoconfiguration Protocol, which would make the MAC addresses globally unique and traceable identifiers. Local Ethernet anonymity also requires this procedure and more than that, as on local networks the whole cross section of the network protocol hierarchy could be monitored. Keri Expires November 14, 2004 [Page 9] Internet-Draft LAN with Protocol Anonymization May 2004 7. Security considerations Real anonymity has far reaching security consequences, but the communication's privacy and security are different requirements, often contradicting each other. Privacy usually serves the communicating data subject, while security is based on the interest of the infrastructure provider. On an anonymized local network the provider must trust the potential users of the clients to provide them with the anonymous use of the shared resources. If the anonymous network has an Internet connection, the provider must take the responsibility for the actions of its users. It follows that protocol anonymization is only desirable in those few cases, where the requirement of local network privacy is a priority consideration. 8 References [1] Chaum, D., "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms", Communications of the ACM vol. 24 no. 2, February 1981. [2] Belovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996. [3] Fyodor, "Remote OS detection via TCP/IP Stack FingerPrinting", http://www.insecure.org/nmap/nmap-fingerprinting-article.html , June 2002. [4] Narten, T. and R. Atkinson, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. Author's Address Laszlo Keri Budapest University of Technology and Economics Department of Information and Knowledge Management Stoczek u. 2. St. Ep. 1. em. 117 Budapest 1111 Hungary EMail: klc@freemail.hu URI: http://www.itm.bme.hu Keri Expires November 14, 2004 [Page 10] Internet-Draft LAN with Protocol Anonymization May 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Keri Expires November 14, 2004 [Page 11] Internet-Draft LAN with Protocol Anonymization May 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Keri Expires November 14, 2004 [Page 12]