Network Working Group J. Haerri Internet-Draft EURECOM Intended status: Informational A. Petrescu Expires: January 9, 2017 CEA, LIST C. Huitema Microsoft July 8, 2016 Transmission of IPv6 Packets over IEEE 802.11-OCB Networks draft-haerri-ipv6-over-80211ocb-00.txt Abstract This document describes the mechanisms required by IPv6 to be transmitted on IEEE 802.11 OCB networks. 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 January 9, 2017. Copyright Notice Copyright (c) 2016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Haerri, et al. Expires January 9, 2017 [Page 1] Internet-Draft IPv6-over-80211OCB July 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 3 3.1. Vehicle ID . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Non IP Communications . . . . . . . . . . . . . . . . . . 3 3.3. Reliability Requirements . . . . . . . . . . . . . . . . 4 3.4. Privacy requirements . . . . . . . . . . . . . . . . . . 5 3.5. Authentication requirements . . . . . . . . . . . . . . . 6 3.6. Multiple interfaces . . . . . . . . . . . . . . . . . . . 6 3.7. MAC Address Generation . . . . . . . . . . . . . . . . . 7 3.8. Security Certificate Generation . . . . . . . . . . . . . 7 4. Mapping IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . 8 4.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 8 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 8 4.5. Address Mapping -- Unicast . . . . . . . . . . . . . . . 8 4.6. Address Mapping -- Multicast . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document describes the transmission of IPv6 packets on IEEE 802.11 OCB networks. 2. Terminology 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 RFC 2119 [RFC2119]. OCB - Outside the Context of a Basic-Service Set ID (BSSID). 802.11-OCB - IEEE 802.11-2012 [ieee802.11-2012] text flagged by "dot11OCBActivated". This means: IEEE 802.11e for quality of service; and 802.11p [ieee802.11p-2010] for operation in the 5.9 GHz band and in mode OCB. Haerri, et al. Expires January 9, 2017 [Page 2] Internet-Draft IPv6-over-80211OCB July 2016 3. Design Considerations The networks defined by 802.11-OCB are in many ways similar to other networks of the 802.11 family. In theory, the encapsulation of IPv6 over 802.11-OCB could be very similar to the operation of IPv6 over other networks of the 802.11 family. However, the high mobility, strong link asymetry and very short connection makes the 802.11-OCB link significantly different from that of other 802.11 networks. Also, the automotive applications have specific requirements for reliability, security and privacy, which further add to the particularity of the 802.11-OCB link. This section does not address safety-related applications, which are done on non-IP communications. However, this section will consider the transmission of such non IP communication in the design specification of IPv6 over IEEE 802.11-OCB. 3.1. Vehicle ID Automotive networks require the unique representation of each of their node. Accordingly, a vehicle must be identified by at least one unique ID. The current specification at ETSI and at IEEE 1609 identifies a vehicle by its MAC address uniquely obtained from the 802.11-OCB NIC. A MAC address uniquely obtained from a IEEE 802.11-OCB NIC implicitely generates multiple vehicle IDs in case of multiple 802.11-OCB NICs. A mechanims to uniquely identify a vehicle irrespectivey to the different NICs and/or technologies is required. 3.2. Non IP Communications In IEEE 1609 and ETSI ITS, safety-related communications CANNOT be used with IP datagrams. For example, Basic Safety Message (BSM, an IEEE 1609 datagram) and Cooperative Awareness Message (CAM, an ETSI ITS-G5 datagram), are each transmitted as payload of 802.11 messages, without an IP header. Each vehicle taking part of traffic (i.e. having its engine turned on and being located on a road) MUST use Non IP communication to periodically broadcast its status information (ID, GPS position, speed,..) in its immediate neighborhood. According to this mechanisms, vehicles become 'aware' of the presence of other vehicles in their immediate vincinity. Accordingly, IP communication being transmitted by vehicles taking part of traffic MUST co-exist with Non IP communication and SHOULD NOT break any Non IP mechanism, including 'harmful' interference on the channel. Haerri, et al. Expires January 9, 2017 [Page 3] Internet-Draft IPv6-over-80211OCB July 2016 The ID of the vehicle transmitting Non IP communication is transmitted in the src MAC address of the IEEE 1609 / ETSI Geonet datagrams. Accordingly, Non IP communications expose the ID of each vehicle, which may be considered as a privacy breach. IEEE 802.11-OCB bypasses the authentication mechanisms of IEEE 802.11 networks, in order for non IP communications to be transmitted without any delay. This may be considered as a security breach. IEEE 1609 and ETSI ITS provided strong security and privacy mechanisms for Non IP Communications. Security (authentication, encryption) is done by asymetric cryptography, where each vehicle attaches its public key and its certificate to all of its non IP messages. Privacy is enforced through the use of Pseudonymes. Each vehicle will be pre-loaded with a large (>1000s) of pseudonymes generated by a PKI, which will uniquely assign a pseudonyme to a certificate (and thus to a public/private key pair). Non IP Communication being developped for safety-critical applications, complex mechanisms have been provided for their support. These mechanisms are OPTIONAL for IP Communication, but SHOULD be used whenever possible. 3.3. Reliability Requirements The dynamically changing topology, short connectivity, mobile transmitter and receivers, different antenna heights, and many-to- many communication types, make IEEE 802.11-OCB links significantly different to other IEEE 802.11 links. Any IPv6 mechanism operating on IEEE 802.11-OCB link MUST support strong link asymetry, spatio- temporal link quality, fast address resolution and transmission. IEEE 802.11-OCB strongly differs from other 802.11 systems to operate outside of the context of a Basic Service Set. This means in practice that IEEE 802.11-OCB does not rely on a Base Station for all Basic Service Set management. In particular, IEEE 802.11-OCB SHALL NOT use beacons. Any IPv6 mechanism requiring L2 services from IEEE 802.11 beacons MUST support an alternative service. Channel scanning being disabled, IPv6 over IEEE 802.11-OCB MUST implement a mechanism for transmitter and receiver to converge to a common channel. Authentication being not possible, IPv6 over IEEE 802.11-OCB MUST implement an distributed mechanism to authenticate transmitters and receivers without the support of a DHCP server. Haerri, et al. Expires January 9, 2017 [Page 4] Internet-Draft IPv6-over-80211OCB July 2016 Time synchronization being not available, IPv6 over IEEE 802.11-OCB MUST implement a higher layer mechanism for time synchroniation between transmitters and receivers without the support of a NTP server. The IEEE 802.11-OCB link being asymetic, IPv6 over IEEE 802.11-OCB MUST disable management mechanisms requesting acknowledgements or replies. The IEEE 802.11-OCB link having a short duration time, IPv6 over IEEE 802.11-OCB MUST implement fast IPv6 mobility management mechanisms. 3.4. Privacy requirements Vehicles will move. As they move, each vehicle needs to regularly announce its network interface and reconfigure its local and global view of its network. L2 mechanisms of IEEE 802.11-OCB MAY be employed to assist IPv6 in discovering new network interfaces. L3 mechanisms over IEEE 802.11-OCB SHOULD be used to assist IPv6 in discovering new network interfaces. The headers of the L2 mechanisms of IEEE 802.11-OCB and L3 management mechanisms of IPv6 are not encrypted, and as such expose at least the src MAC address of the sender. In the absence of mitigations, adversaries could monitor the L2 or L3 management headers, track the MAC Addresses, and through that track the position of vehicles over time; in some cases, it is possible to deduce the vehicle manufacturer name from the OUI of the MAC address of the interface (with help of additional databases). It is important that sniffers along roads not be able to easily identify private information of automobiles passing by. Similary to Non IP safety-critical communications, the obvious mitigation is to use some form of MAC Address Randomization. We can assume that there will be "renumbering events" causing the MAC Addresses to change. Clearly, a change of MAC Address should induce a simultaneous change of IPv6 Addresses, to prevent linkage of the old and new MAC Addresses through continuous use of the same IP Addresses. The change of an IPv6 address also implies the change of the network prefix. Prefix delegation mechanisms should be available to vehicles to obtain new prefices during "renumbering events". Changing MAC and IPv6 addresses will disrupt communications, which goes against the reliability requirements expressed in [TS103097]. We will assume that the renumbering events happen only during "safe" periods, e.g. when the vehicle has come to a full stop. The Haerri, et al. Expires January 9, 2017 [Page 5] Internet-Draft IPv6-over-80211OCB July 2016 determination of such safe periods is the responsibility of implementors. In automobile settings it is common to decide that certain operations (e.g. software update, or map update) must happen only during safe periods. MAC Address randomization will not prevent tracking if the addresses stay constant for long intervals. Suppose for example that a vehicle only renumbers the addresses of its interface when leaving the vehicle owner's garage in the morning. It would be trivial to observe the "number of the day" at the known garage location, and to associate that with the vehicle's identity. There is clearly a tension there. If renumbering events are too infrequent, they will not protect privacy, but if their are too frequent they will affect reliability. We expect that implementors will eventually find the right balance. 3.5. Authentication requirements IEEE 802.11-OCB does not have L2 authentication mechanisms. Accordingly, a vehicle receiving a IPv6 over IEEE 802.11-OCB packet cannot check or be sure the legitimacy of the src MAC (and associated ID). This is a significant breach of security. Similarly to Non IP safety-critical communications, IPv6 over 802.11-OCB packets must contain a certificate, including at least the public key of the sender, that will allow the receiver to authenticate the packet, and guarantee its legitimacy. To satisfy the privacy requiremrents of Section 3.4, the certificate SHALL be changed at each 'renumbering event'. 3.6. Multiple interfaces There are considerations of 2 or more IEEE 802.11-OCB interface cards per vehicle. For each vehicle taking part of road traffic, one IEEE 802.11-OCB interface card MUST be fully allocated for Non IP safety- critical communication. Any other IEEE 802.11-OCB may be used for other type of traffic. The mode of operation of these other wireless interfaces is not clearly defined yet. One possibility is consider each card as an independent network interface, with a specific MAC Address and a set of IPv6 addresses. Another possibility is to consider the set of these wireless interfaces as a single network interface (not including the IEEE 802.11-OCB interface used by Non IP safety critical communications). This will require specific logic to ensure, for example, that packets meant for a vehicle in front are actually sent by the radio in the front, or that multiple copies of Haerri, et al. Expires January 9, 2017 [Page 6] Internet-Draft IPv6-over-80211OCB July 2016 the the same packet received by multiple interfaces are treated as a single packet. Treating each wireless interface as a separate network interface pushes such issues to the application layer. The privacy requirements of Section 3.4 imply that if these multiple interfaces are represented by many network interface, a single renumbering event SHALL cause renumbering of all these interfaces. If one MAC changed and another stayed constant, external observers would be able to correlate old and new values, and the privacy benefits of randomization would be lost. The privacy requirements of Non IP safety-critical communications imply that if a change of pseudonyme occurs, renumbering of all other interfaces SHALL also occur. 3.7. MAC Address Generation When designing the IPv6 over 802.11-OCB address mapping, we will assume that the MAC Addresses will change during well defined "renumbering events". The 48 bits randomized MAC addresses will have the following characteristics: o Bit "Local/Global" set to "locally admninistered". o Bit "Unicast/Multicast" set to "Unicast". o 46 remaining bits set to a random value, using a random number generator that meets the requirements of [RFC4086]. One possible way to meet the randomization requirements is to retain 46 bits from the output of a strong HASH function, such as SHA256, taking as input a 256 bit local secret, the "nominal" MAC Address of the interface, and a representation of the date and time of the renumbering event. 3.8. Security Certificate Generation When designing the IPv6 over 802.11-OCB address mapping, we will assume that the MAC Addresses will change during well defined "renumbering events". So MUST also the Security Certificates. Unless unavailable, the Security Certificate Generation mechanisms SHOULD follow the specification in IEEE 1609.2 [ieee16094] or ETSI TS 103 097 [TS103097]. These security mechanisms have the following characteristics: o Authentication - Elliptic Curve Digital Signature Algorithm (ECDSA) - A Secured Hash Function (SHA-256) will sign the message with the public key of the sender. Haerri, et al. Expires January 9, 2017 [Page 7] Internet-Draft IPv6-over-80211OCB July 2016 o Encryption - Elliptic Curve Integrated Encryption Scheme (ECIES) - A Key Derivation Function (KDF) between the sender's public key and the receiver's private key will generate a symetric key used to encrypt a packet. If the mechanisms described in IEEE 1609.2 [ieee16094] or ETSI TS 103 097 [TS103097] are either not supported or not capable of running on the hardware, an alternative approach based on Pretty-Good-Privacy (PGP) MAY be used as an alternative. 4. Mapping IPv6 over 802.11-OCB 4.1. Maximum Transmission Unit MTU is determined by the IEEE 802.11-2012 specification [ieee802.11-2012]. 4.2. Frame Format 4.3. Stateless Autoconfiguration 4.4. Link-Local Addresses 4.5. Address Mapping -- Unicast 4.6. Address Mapping -- Multicast 5. Security Considerations The source MAC address can be generated by the following random- number generation algorithm: f = ... 48bits. The output must not collide with existing allocations. For one 802.11-OCB interface multiple random MAC addresses MAY be generated. For each MAC address there is an associated certificate. 6. IANA Considerations Haerri, et al. Expires January 9, 2017 [Page 8] Internet-Draft IPv6-over-80211OCB July 2016 7. Acknowledgements The authors would like to acknowledge... 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . 8.2. Informative References [I-D.petrescu-its-scenarios-reqs] Petrescu, A., Janneteau, C., Boc, M., and W. Klaudel, "Scenarios and Requirements for IP in Intelligent Transportation Systems", draft-petrescu-its-scenarios- reqs-03 (work in progress), October 2013. [ieee16094] "1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management Messages; document freely available at URL https://standards.ieee.org/findstds/ standard/1609.2-2016.html retrieved on July 08th, 2016.". Haerri, et al. Expires January 9, 2017 [Page 9] Internet-Draft IPv6-over-80211OCB July 2016 [ieee802.11-2012] "IEEE Std 802.11-2012 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks-- Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; document freely available at URL http://standards.ieee.org/getieee802/ download/802.11-2012.pdf retrieved on July 08th, 2016.". [ieee802.11p-2010] "IEEE Std 802.11p(TM)-2010, IEEE Standard for Information Technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment 6: Wireless Access in Vehicular Environments; document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". [TS103097] "Intelligent Transport Systems (ITS); Security; Security header and certificate formats; document freely available at URL http://www.etsi.org/deliver/ etsi_ts/103000_103099/103097/01.01.01_60/ ts_103097v010101p.pdf retrieved on July 08th, 2016.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. From -00.txt to -00.txt: o first version. Authors' Addresses Jerome Haerri EURECOM Sophia-Antipolis 06904 France Phone: +33493008134 Email: Jerome.Haerri@eurecom.fr Haerri, et al. Expires January 9, 2017 [Page 10] Internet-Draft IPv6-over-80211OCB July 2016 Alexandre Petrescu CEA, LIST Communicating Systems Laboratory Gif-sur-Yvette , Ile-de-France 91190 France Phone: +33169089223 Email: Alexandre.Petrescu@cea.fr Christian Huitema Microsoft Redmond, WA 98052 U.S.A. Email: huitema@microsoft.com Haerri, et al. Expires January 9, 2017 [Page 11]