--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-32.txt 2018-12-17 05:13:16.452783686 -0800 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-33.txt 2018-12-17 05:13:16.532785613 -0800 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: June 13, 2019 Moulay Ismail University +Expires: June 20, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - December 10, 2018 + December 17, 2018 Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-32 + draft-ietf-ipwave-ipv6-over-80211ocb-33 Abstract In order to transmit IPv6 packets on IEEE 802.11 networks running outside the context of a basic service set (OCB, earlier "802.11p") there is a need to define a few parameters such as the supported Maximum Transmission Unit size on the 802.11-OCB link, the header format preceding the IPv6 header, the Type value within it, and others. This document describes these parameters for IPv6 and IEEE 802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB @@ -35,21 +35,21 @@ 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 June 13, 2019. + This Internet-Draft will expire on June 20, 2019. Copyright Notice 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 @@ -57,34 +57,34 @@ 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Communication Scenarios where IEEE 802.11-OCB Links are Used 4 - 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 5 - 4.2. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 5 - 4.3. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 - 4.3.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 6 - 4.4. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 - 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 - 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 - 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 - 4.6. Stateless Autoconfiguration . . . . . . . . . . . . . . . 8 - 4.7. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 11 + 4. IPv6 over 802.11-OCB . . . . . . . . . . . . . . . . . . . . 4 + 4.1. Maximum Transmission Unit (MTU) . . . . . . . . . . . . . 4 + 4.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2.1. Ethernet Adaptation Layer . . . . . . . . . . . . . . 5 + 4.3. Link-Local Addresses . . . . . . . . . . . . . . . . . . 7 + 4.4. Address Mapping . . . . . . . . . . . . . . . . . . . . . 7 + 4.4.1. Address Mapping -- Unicast . . . . . . . . . . . . . 7 + 4.4.2. Address Mapping -- Multicast . . . . . . . . . . . . 7 + 4.5. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 + 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 5.2. MAC Address and Interface ID Generation . . . . . . . . . 11 + 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 17 Appendix B. 802.11p . . . . . . . . . . . . . . . . . . . . . . 27 Appendix C. Aspects introduced by the OCB mode to 802.11 . . . . 27 Appendix D. Changes Needed on a software driver 802.11a to @@ -109,34 +109,31 @@ sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC layer. The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet, but there are two kinds of exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. To satisfy these exceptions, this document describes an Ethernet Adaptation Layer between Ethernet headers and 802.11 headers. The Ethernet Adaptation Layer is - described Section 4.3.1. The operation of IP on Ethernet is + described Section 4.2.1. The operation of IP on Ethernet is described in [RFC1042], [RFC2464] and [I-D.hinden-6man-rfc2464bis]. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. This has impacts on security, privacy, subnet structure and - handover behaviour. For security and privacy recommendations see - Section 5 and Section 4.6. The subnet structure is described in - Section 4.7. The handover behaviour on OCB links is not described + movement detection. For security and privacy recommendations see + Section 5 and Section 4.5. The subnet structure is described in + Section 4.6. The movement detection on OCB links is not described in this document. - The Security Considerations section describes security and privacy - aspects of 802.11-OCB. - In the published literature, many documents describe aspects and problems related to running IPv6 over 802.11-OCB: [I-D.ietf-ipwave-vehicular-networking-survey]. 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]. @@ -174,77 +171,53 @@ [I-D.ietf-ipwave-vehicular-networking-survey], that lists some scenarios and requirements for IP in Intelligent Transportation Systems. The link model is the following: STA --- 802.11-OCB --- STA. In vehicular networks, STAs can be IP-RSUs and/or IP-OBUs. While 802.11-OCB is clearly specified, and the use of IPv6 over such link is not radically new, the operating environment (vehicular networks) brings in new perspectives. - The mechanisms for forming and terminating, discovering, peering and - mobility management for 802.11-OCB links are not described in this - document. - 4. IPv6 over 802.11-OCB -4.1. Pseudonym Handling - - The demand for privacy protection of vehicles' and drivers' - identities, which could be granted by using a pseudonym or alias - identity at the same time, may hamper the required confidentiality of - messages and trust between participants - especially in safety - critical vehicular communication. - - o Particular challenges arise when the pseudonymization mechanism - used relies on (randomized) re-addressing. - - o A proper pseudonymization tool operated by a trusted third party - may be needed to ensure both aspects concurrently. - - o This is discussed in Section 4.6 and Section 5. - - o Pseudonymity is also discussed in - [I-D.ietf-ipwave-vehicular-networking-survey] in sections 4.2.4 - and 5.1.2. - -4.2. Maximum Transmission Unit (MTU) +4.1. Maximum Transmission Unit (MTU) The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. It is the same value as IPv6 packets on Ethernet links, as specified in [RFC2464]. This value of the MTU respects the recommendation that every link on the Internet must have a minimum MTU of 1280 octets (stated in [RFC8200], and the recommendations therein, especially with respect to fragmentation). -4.3. Frame Format +4.2. Frame Format IP packets MUST be transmitted over 802.11-OCB media as QoS Data frames whose format is specified in IEEE Std 802.11. The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded by a Logical Link Control (LLC) header and an 802.11 header. In the LLC header, and in accordance with the EtherType Protocol Discrimination (EPD, see Appendix E), the value of the Type field MUST be set to 0x86DD (IPv6). In the 802.11 header, the value of the Subtype sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of the QoS Control field of the 802.11 header MUST be set to binary 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK'). To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation Layer that translates Ethernet II frames to the 802.11 format and vice versa. An Ethernet Adaptation - Layer is described in Section 4.3.1. + Layer is described in Section 4.2.1. -4.3.1. Ethernet Adaptation Layer +4.2.1. Ethernet Adaptation Layer An 'adaptation' layer is inserted between a MAC layer and the Networking layer. This is used to transform some parameters between their form expected by the IP stack and the form provided by the MAC layer. An Ethernet Adaptation Layer makes an 802.11 MAC look to IP Networking layer as a more traditional Ethernet layer. At reception, this layer takes as input the IEEE 802.11 header and the Logical-Link Layer Control Header and produces an Ethernet II Header. At sending, @@ -290,65 +263,66 @@ | 802.11 MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 802.11 PHY | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Ethernet Adaptation Layer stacked with other layers (in the above figure, a 802.11 profile is represented; this is used also for 802.11-OCB profile.) -4.4. Link-Local Addresses +4.3. Link-Local Addresses There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. Among these types of addresses only the IPv6 link-local addresses MAY be formed using an EUI-64 identifier. If the IPv6 link-local address is formed using an EUI-64 identifier, then the mechanism of forming that address is the same mechanism as used to form an IPv6 link-local address on Ethernet links. This mechanism is described in section 5 of [RFC2464]. For privacy, the link-local address MAY be formed according to the mechanisms described in Section 5.2. -4.5. Address Mapping +4.4. Address Mapping Unicast and multicast address mapping MUST follow the procedures specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. -4.5.1. Address Mapping -- Unicast +4.4.1. Address Mapping -- Unicast The procedure for mapping IPv6 unicast addresses into Ethernet link- layer addresses is described in [RFC4861]. -4.5.2. Address Mapping -- Multicast +4.4.2. Address Mapping -- Multicast The multicast address mapping is performed according to the method specified in section 7 of [RFC2464]. The meaning of the value "3333" mentioned in that section 7 of [RFC2464] is defined in section 2.3.1 of [RFC7042]. Transmitting IPv6 packets to multicast destinations over 802.11 links proved to have some performance issues - [I-D.perkins-intarea-multicast-ieee802]. These issues may be - exacerbated in OCB mode. Solutions for these problems should + [I-D.perkins-intarea-multicast-ieee802], + [I-D.ietf-mboned-ieee802-mcast-problems]. These issues may be + exacerbated in OCB mode. Solutions for these problems SHOULD consider the OCB mode of operation. -4.6. Stateless Autoconfiguration +4.5. Stateless Autoconfiguration There are several types of IPv6 addresses [RFC4291], [RFC4193], that MAY be assigned to an 802.11-OCB interface. This section describes the formation of Interface Identifiers for IPv6 addresses of type 'Global' or 'Unique Local'. For Interface Identifiers for IPv6 - address of type 'Link-Local' see Section 4.4. + address of type 'Link-Local' see Section 4.3. The Interface Identifier for an 802.11-OCB interface is formed using the same rules as the Interface Identifier for an Ethernet interface; the RECOMMENDED method for forming stable Interface Identifiers (IIDs) is described in [RFC8064]. The method of forming IIDs described in section 4 of [RFC2464] MAY be used during transition time. The bits in the Interface Identifier have no generic meaning and the identifier should be treated as an opaque value. The bits @@ -357,36 +331,29 @@ of this significance are described in [RFC7136]. If semantically opaque Interface Identifiers are needed, a potential method for generating semantically opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration is given in [RFC7217]. Semantically opaque Interface Identifiers, instead of meaningful Interface Identifiers derived from a valid and meaningful MAC address ([RFC2464], section 4), MAY be needed in order to avoid certain privacy risks. - A valid MAC address includes a unique identifier pointing to a - company together with its postal address, and a unique number within - that company MAC space (see the oui.txt file). The calculation - operation of the MAC address back from a given meaningful Interface - Identifier is straightforward ([RFC2464], section 4). The Interface - Identifier is part of an IPv6 address that is stored in IPv6 packets. - - The IPv6 packets can be captured in the Internet easily. For these - reasons, an attacker may realize many attacks on privacy. One such - attack on 802.11-OCB is to capture, store and correlate Company ID - information of many cars in public areas (e.g. listen for Router - Advertisements, or other IPv6 application data packets, and record - the value of the source address in these packets). Further - correlation of this information with other data captured by other - means, or other visual information (car color, others) MAY constitute - privacy risks. + The IPv6 packets can be captured easily in the Internet and on-link + in public roads. For this reason, an attacker may realize many + attacks on privacy. One such attack on 802.11-OCB is to capture, + store and correlate Company ID information present in MAC addresses + of many cars (e.g. listen for Router Advertisements, or other IPv6 + application data packets, and record the value of the source address + in these packets). Further correlation of this information with + other data captured by other means, or other visual information (car + color, others) MAY constitute privacy risks. In order to avoid these risks, opaque Interface Identifiers MAY be formed according to rules described in [RFC7217]. These opaque Interface Identifiers are formed starting from identifiers different than the MAC addresses, and from cryptographically strong material. Thus, privacy sensitive information is absent from Interface IDs, and it is impossible to calculate the initial value from which the Interface ID was calculated. Some applications that use IPv6 packets on 802.11-OCB links (among @@ -394,21 +361,21 @@ Identifiers don't change too often. It is RECOMMENDED to use the mechanisms described in RFC 7217 to permit the use of Stable Interface Identifiers that do not change within one subnet prefix. A possible source for the Net-Iface Parameter is a virtual interface name, or logical interface name, that is decided by a local administrator. The way Interface Identifiers are used MAY involve risks to privacy, as described in Section 5.1. -4.7. Subnet Structure +4.6. Subnet Structure A subnet is formed by the external 802.11-OCB interfaces of vehicles that are in close range (not by their in-vehicle interfaces). This subnet MUST use at least the link-local prefix fe80::/10 and the interfaces MUST be assigned IPv6 addresses of type link-local. The structure of this subnet is ephemeral, in that it is strongly influenced by the mobility of vehicles: the 802.11 hidden node effects appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' networks with an addressing model as described in [RFC5889]. @@ -421,21 +388,21 @@ cases, the exclusive use of IPv6 link-local addresses is RECOMMENDED. Additionally, even if the timing requirements are not very strict (e.g. the moving subnet formed by two following vehicles is stable, a fixed IP-RSU is absent), the subnet is disconnected from the Internet (a default route is absent), and the addressing peers are equally qualified (impossible to determine that some vehicle owns and distributes addresses to others) the use of link-local addresses is RECOMMENDED. - The Neighbor Discovery protocol (ND) [RFC4861] is used over + The Neighbor Discovery protocol (ND) [RFC4861] MUST be used over 802.11-OCB links. Protocols like Mobile IPv6 [RFC6275] and DNAv6 [RFC6059], which depend on timely movement detection, might need additional tuning work to handle the lack of link-layer notifications during handover. This is for further study. 5. Security Considerations Any security mechanism at the IP layer or above that may be carried @@ -481,21 +448,21 @@ eavesdropping and subsequent correlation of data; this may reveal data considered private by the vehicle owner; there is a risk of being tracked. In outdoors public environments, where vehicles typically circulate, the privacy risks are more important than in indoors settings. It is highly likely that attacker sniffers are deployed along routes which listen for IEEE frames, including IP packets, of vehicles passing by. For this reason, in the 802.11-OCB deployments, there is a strong necessity to use protection tools such as dynamically changing MAC addresses Section 5.2, semantically opaque Interface Identifiers and stable Interface Identifiers - Section 4.6. This may help mitigate privacy risks to a certain + Section 4.5. This may help mitigate privacy risks to a certain level. 5.2. MAC Address and Interface ID Generation In 802.11-OCB networks, the MAC addresses MAY change during well defined renumbering events. In the moment the MAC address is changed on an 802.11-OCB interface all the Interface Identifiers of IPv6 addresses assigned to that interface MUST change. The policy dictating when the MAC address is changed on the @@ -518,20 +485,42 @@ of the interface, and a representation of the date and time of the renumbering event. A randomized Interface ID has the same characteristics of a randomized MAC address, except the length in bits. A MAC address SHOULD be of length 48 decimal. An Interface ID SHOULD be of length 64 decimal for all types of IPv6 addresses. In the particular case of IPv6 link-local addresses, the length of the Interface ID MAY be 118 decimal. +5.3. Pseudonym Handling + + The demand for privacy protection of vehicles' and drivers' + identities, which could be granted by using a pseudonym or alias + identity at the same time, may hamper the required confidentiality of + messages and trust between participants - especially in safety + critical vehicular communication. + + o Particular challenges arise when the pseudonymization mechanism + used relies on (randomized) re-addressing. + + o A proper pseudonymization tool operated by a trusted third party + may be needed to ensure both aspects simultaneously (privacy + protection on one hand and trust between participants on another + hand). + + o This is discussed in Section 4.5 and Section 5 of this document. + + o Pseudonymity is also discussed in + [I-D.ietf-ipwave-vehicular-networking-survey] in its sections + 4.2.4 and 5.1.2. + 6. IANA Considerations No request to IANA. 7. Contributors Christian Huitema, Tony Li. Romain Kuntz contributed extensively about IPv6 handovers between links running outside the context of a BSS (802.11-OCB links). @@ -714,20 +703,26 @@ over Ethernet Networks", draft-hinden-6man-rfc2464bis-02 (work in progress), March 2017. [I-D.ietf-ipwave-vehicular-networking-survey] Jeong, J., Cespedes, S., Benamar, N., Haerri, J., and M. Wetterwald, "Survey on IP-based Vehicular Networking for Intelligent Transportation Systems", draft-ietf-ipwave- vehicular-networking-survey-00 (work in progress), July 2017. + [I-D.ietf-mboned-ieee802-mcast-problems] + Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. + Zuniga, "Multicast Considerations over IEEE 802 Wireless + Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work + in progress), November 2018. + [I-D.perkins-intarea-multicast-ieee802] Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", draft-perkins-intarea-multicast-ieee802-03 (work in progress), July 2017. [IEEE-1609.2] "IEEE SA - 1609.2-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Security Services for Applications and Management Messages. Example URL @@ -768,20 +763,33 @@ document freely available at URL http://standards.ieee.org/getieee802/ download/802.11p-2010.pdf retrieved on September 20th, 2013.". Appendix A. ChangeLog The changes are listed in reverse chronological order, most recent changes appearing at the top of the list. + -33: substituted 'movement detection' for 'handover behaviour' in + introductory text; removed redundant phrase referring to Security + Considerations section; removed the phrase about forming mechanisms + being left out, as IP is not much concerned about L2 forming; moved + the Pseudonym section from main section to end of Security + Considerations section (and clarified 'concurrently'); capitalized + SHOULD consider OCB in WiFi multicast problems, and referred to more + recent I-D on topic; removed several phrases in a paragraph about + oui.txt and MAC presence in IPv6 address, as they are well known + info, but clarified the example of privacy risk of Company ID in MAC + addresses in public roads; clarified that ND MUST be used over + 802.11-OCB. + -32: significantly shortened the relevant ND/OCB paragraph. It now just states ND is used over OCB, w/o detailing. -31: filled in the section titled "Pseudonym Handling"; removed a 'MAY NOT' phrase about possibility of having other prefix than the LL on the link between cars; shortened and improved the paragraph about Mobile IPv6, now with DNAv6; improved the ND text about ND retransmissions with relationship to packet loss; changed the title of an appendix from 'EPD' to 'Protocol Layering'; improved the 'Aspects introduced by OCB' appendix with a few phrases about the