--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-34.txt 2019-04-08 05:13:17.460439069 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-35.txt 2019-04-08 05:13:17.548441372 -0700 @@ -1,26 +1,26 @@ IPWAVE Working Group A. Petrescu Internet-Draft CEA, LIST Intended status: Standards Track N. Benamar -Expires: June 21, 2019 Moulay Ismail University +Expires: October 10, 2019 Moulay Ismail University J. Haerri Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - December 18, 2018 + April 8, 2019 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-34 + draft-ietf-ipwave-ipv6-over-80211ocb-35 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,25 +35,25 @@ 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 21, 2019. + This Internet-Draft will expire on October 10, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 @@ -62,48 +62,49 @@ 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 . . . . . . . . . . . . . . . . . . . . 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 + 4.4. Stateless Autoconfiguration . . . . . . . . . . . . . . . 7 + 4.5. Address Mapping . . . . . . . . . . . . . . . . . . . . . 8 + 4.5.1. Address Mapping -- Unicast . . . . . . . . . . . . . 8 + 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 8 + 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 10 - 5.2. MAC Address and Interface ID Generation . . . . . . . . . 10 + 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 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 - become a 802.11-OCB driver . . . 31 - Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 32 - Appendix F. Design Considerations . . . . . . . . . . . . . . . 33 - Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 33 + become a 802.11-OCB driver . . . 32 + Appendix E. Protocol Layering . . . . . . . . . . . . . . . . . 33 + Appendix F. Design Considerations . . . . . . . . . . . . . . . 34 + Appendix G. IEEE 802.11 Messages Transmitted in OCB mode . . . . 34 Appendix H. Examples of Packet Formats . . . . . . . . . . . . . 34 H.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 35 - H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 37 - Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 + H.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 38 + Appendix I. Extra Terminology . . . . . . . . . . . . . . . . . 40 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction This document describes the transmission of IPv6 packets on IEEE Std 802.11-OCB networks [IEEE-802.11-2016] (a.k.a "802.11p" see Appendix B, Appendix C and Appendix D). This involves the layering of IPv6 networking on top of the IEEE 802.11 MAC layer, with an LLC layer. Compared to running IPv6 over the Ethernet MAC layer, there is no modification expected to IEEE Std 802.11 MAC and Logical Link sublayers: IPv6 works fine directly over 802.11-OCB too, with an LLC @@ -116,33 +117,35 @@ 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.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 movement detection. For security and privacy recommendations see - Section 5 and Section 4.5. The subnet structure is described in + Section 5 and Section 4.4. The subnet structure is described in Section 4.6. The movement detection on OCB links is not described in this document. 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]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. IP-OBU (Internet Protocol On-Board Unit): an IP-OBU is a computer situated in a vehicle such as an automobile, bicycle, or similar. It has at least one IP interface that runs in mode OCB of 802.11, and that has an "OBU" transceiver. See the definition of the term "OBU" in section Appendix I. IP-RSU (IP Road-Side Unit): an IP-RSU is situated along the road. It has at least two distinct IP-enabled interfaces; the wireless PHY/MAC layer of at least one of its IP-enabled interfaces is configured to @@ -185,21 +188,22 @@ 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.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. + frames whose format is specified in IEEE 802.11(TM) -2016 + [IEEE-802.11-2016]. 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'). @@ -268,124 +272,111 @@ 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.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. + EUI-64 identifier, in particular during transition time. 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.4. Address Mapping - - Unicast and multicast address mapping MUST follow the procedures - specified for Ethernet interfaces in sections 6 and 7 of [RFC2464]. - -4.4.1. Address Mapping -- Unicast - - The procedure for mapping IPv6 unicast addresses into Ethernet link- - layer addresses is described in [RFC4861]. - -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.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.5. Stateless Autoconfiguration +4.4. 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.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. + time, in particular for IPv6 link-local addresses. The bits in the Interface Identifier have no generic meaning and the identifier should be treated as an opaque value. The bits 'Universal' and 'Group' in the identifier of an 802.11-OCB interface are significant, as this is an IEEE link-layer address. The details - 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]. + of this significance are described in [RFC7136]. 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. - - 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. + ([RFC2464], section 4), help avoid certain privacy risks (see the + risks mentioned in Section 5.1.1). If semantically opaque Interface + Identifiers are needed, they MAY be generated using the method for + generating semantically opaque Interface Identifiers with IPv6 + Stateless Address Autoconfiguration given in [RFC7217]. Typically, + an opaque Interface Identifier is formed starting from identifiers + different than the MAC addresses, and from cryptographically strong + material. Thus, privacy sensitive information is absent from + Interface IDs, because it is impossible to calculate back the initial + value from which the Interface ID was first generated (intuitively, + it is as hard as mentally finding the square root of a number, and as + impossible as trying to use computers to identify quickly whether a + large number is prime). Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose Interface 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.5. 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 + + The procedure for mapping IPv6 unicast addresses into Ethernet link- + layer addresses is described in [RFC4861]. + +4.5.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.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. 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]. - On another hand, the structure of the internal subnets in each car is + influenced by the mobility of vehicles: the hidden terminal effects + appear; the 802.11 networks in OCB mode may be considered as 'ad-hoc' + networks with an addressing model as described in [RFC5889]. On + another hand, the structure of the internal subnets in each car is relatively stable. As recommended in [RFC5889], when the timing requirements are very strict (e.g. fast drive through IP-RSU coverage), no on-link subnet prefix should be configured on an 802.11-OCB interface. In such 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 @@ -447,23 +438,37 @@ 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.5. This may help mitigate privacy risks to a certain + Section 4.4. This may help mitigate privacy risks to a certain level. +5.1.1. Privacy Risks of Meaningful info in Interface IDs + + The privacy risks of using MAC addresses displayed in Interface + Identifiers are important. 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. + 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 802.11-OCB interface is to-be-determined. For more information on the motivation of this policy please refer to the privacy discussion @@ -500,21 +505,21 @@ 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 This is discussed in Section 4.4 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 @@ -541,22 +546,23 @@ Emmanuel Baccelli, John Kenney, John Moring, Francois Simon, Dan Romascanu, Konstantin Khait, Ralph Droms, Richard 'Dick' Roy, Ray Hunter, Tom Kurihara, Michal Sojka, Jan de Jongh, Suresh Krishnan, Dino Farinacci, Vincent Park, Jaehoon Paul Jeong, Gloria Gwynne, Hans-Joachim Fischer, Russ Housley, Rex Buddenberg, Erik Nordmark, Bob Moskowitz, Andrew Dryden, Georg Mayer, Dorothy Stanley, Sandra Cespedes, Mariano Falcitelli, Sri Gundavelli, Abdussalam Baryun, Margaret Cullen, Erik Kline, Carlos Jesus Bernardos Cano, Ronald in 't Velt, Katrin Sjoberg, Roland Bless, Tijink Jasja, Kevin Smith, Brian Carpenter, Julian Reschke, Mikael Abrahamsson, Dirk von Hugo, - Lorenzo Colitti and William Whyte. Their valuable comments clarified - particular issues and generally helped to improve the document. + Lorenzo Colitti, Pascal Thubert and William Whyte. Their valuable + comments clarified particular issues and generally helped to improve + the document. Pierre Pfister, Rostislav Lisovy, and others, wrote 802.11-OCB drivers for linux and described how. For the multicast discussion, the authors would like to thank Owen DeLong, Joe Touch, Jen Linkova, Erik Kline, Brian Haberman and participants to discussions in network working groups. The authors would like to thank participants to the Birds-of- a-Feather "Intelligent Transportation Systems" meetings held at IETF @@ -673,20 +679,24 @@ [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References [ETSI-sec-archi] "ETSI TS 102 940 V1.2.1 (2016-11), ETSI Technical Specification, Intelligent Transport Systems (ITS); @@ -756,20 +766,31 @@ 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. + -35: addressing the the intarea review: clarified a small apparent + contradiction between two parts of text that use the old MAC-based + IIDs (clarified by using qualifiers from each other: transition time, + and ll addresses); sequenced closer the LL and Stateless Autoconf + sections, instead of spacing them; shortened the paragraph of Opaque + IIDs; moved the privacy risks of in-clear IIDs in the security + section; removed a short phrase duplicating the idea of privacy + risks; added third time a reference to the 802.11-2016 document; used + 'the hidden terminal' text; updated the Terminology section with new + BCP-14 text 'MUST' to include RFC8174. + -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