--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-51.txt 2019-08-09 12:13:43.535063640 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-52.txt 2019-08-09 12:13:43.611065572 -0700 @@ -1,24 +1,24 @@ IPWAVE Working Group N. Benamar Internet-Draft Moulay Ismail University of Meknes Intended status: Standards Track J. Haerri -Expires: January 25, 2020 Eurecom +Expires: February 10, 2020 Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - July 24, 2019 + August 9, 2019 Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic Service Set - draft-ietf-ipwave-ipv6-over-80211ocb-51 + draft-ietf-ipwave-ipv6-over-80211ocb-52 Abstract This document provides methods and settings, for using IPv6 to communicate among nodes within range of one another over a single IEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios is not covered in this specification and is subject of future work. @@ -31,21 +31,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 January 25, 2020. + This Internet-Draft will expire on February 10, 2020. Copyright Notice 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 @@ -98,23 +98,23 @@ 1. Introduction This document provides a baseline for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link [IEEE-802.11-2016] (a.k.a., "802.11p" see Appendix A, Appendix B and Appendix C) with minimal changes to existing stacks. Moreover, the document identifies limitations of such usage. Concretely, the document describes the layering of IPv6 networking on top of the IEEE Std 802.11 MAC layer or an IEEE Std 802.3 MAC layer with a frame - translation underneath. The resulting stack inherits from IPv6 over - Ethernet [RFC2464], but operates over 802.11-OCB to provide at least - P2P (Point to Point) connectivity using IPv6 ND and link-local + translation underneath. The resulting stack is derived from IPv6 + over Ethernet [RFC2464], but operates over 802.11-OCB to provide at + least P2P (Point to Point) connectivity using IPv6 ND and link-local addresses. The IPv6 network layer operates on 802.11-OCB in the same manner as operating on Ethernet with the following exceptions: o Exceptions due to different operation of IPv6 network layer on 802.11 than on Ethernet. The operation of IP on Ethernet is described in [RFC1042] and [RFC2464]. o Exceptions due to the OCB nature of 802.11-OCB compared to 802.11. @@ -207,21 +207,23 @@ operating system and the 802.11-OCB media, device drivers MAY implement IPv6-over-Ethernet as per [RFC2464] and then a frame translation from 802.3 to 802.11 in order to minimize the code changes. 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 can be formed using an - EUI-64 identifier, in particular during transition time. + EUI-64 identifier, in particular during transition time, (the time + spent before an interface starts using a different address than the + LL one). 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. Moreover, whether or not the interface identifier is derived from the EUI-64 identifier, its length is 64 bits as is the case for Ethernet [RFC2464]. 4.4. Stateless Autoconfiguration @@ -276,23 +278,22 @@ Address Detection (DAD) per [RFC4862]. 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 there 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.A A future improvement to this specification + exacerbated in OCB mode. A future improvement to this specification should consider solutions for these problems. 4.6. Subnet Structure When vehicles are in close range, a subnet may be formed over 802.11-OCB interfaces (not by their in-vehicle interfaces). A Prefix List conceptual data structure ([RFC4861] Section 5.1) is maintained for each 802.11-OCB interface. IPv6 Neighbor Discovery protocol (ND) requires reflexive properties @@ -357,21 +358,22 @@ 802.11-OCB does not provide any cryptographic protection, because it operates outside the context of a BSS (no Association Request/ Response, no Challenge messages). Therefore, an attacker can sniff or inject traffic while within range of a vehicle or IP-RSU (by setting an interface card's frequency to the proper range). Also, an attacker may not heed to legal limits for radio power and can use a very sensitive directional antenna; if attackers wishe to attack a given exchange they do not necessarily need to be in close physical proximity. Hence, such a link is less protected than commonly used - links (wired link or protected 802.11). + links (wired link or aforementioned 802.11 links with link-layer + security). Therefore, any node can join a subnet, directly communicate with any nodes on the subset to include potentially impersonating another node. This design allows for a number of threats outlined in Section 3 of [RFC6959]. While not widely deployed, SeND [RFC3971], [RFC3972] is a solution that can address Spoof-Based Attack Vectors. 5.1. Privacy Considerations As with all Ethernet and 802.11 interface identifiers ([RFC7721]), @@ -383,22 +385,22 @@ 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.4. An example of change policy is to change the MAC address of the OCB interface each time the system boots up. This may - help mitigate privacy risks to a certain level. Futhermore, for - pricavy concerns, ([RFC8065]) recommends using an address generation + help mitigate privacy risks to a certain level. Furthermore, for + privacy concerns, ([RFC8065]) recommends using an address generation scheme rather than addresses generated from a fixed link-layer address. However, there are some specificities related to vehicles. Since roaming is an important characteristic of moving vehicles, the use of the same Link-Local Address over time can indicate the presence of the same vehicle in different places and thus leads to location tracking. Hence, a vehicle should get hints about a change of environment (e.g. , engine running, GPS, etc..) and renew the IID in its LLAs. 5.1.1. Privacy Risks of Meaningful info in Interface IDs @@ -422,32 +424,32 @@ on an 802.11-OCB interface all the Interface Identifiers of IPv6 addresses assigned to that interface MUST change. Implementations should use a policy dictating when the MAC address is changed on the 802.11-OCB interface. For more information on the motivation of this policy please refer to the privacy discussion in Appendix B. A 'randomized' MAC address has the following characteristics: - o Bit "Local/Global" set to "locally admninistered". + o Bit "Local/Global" set to "locally administered". o Bit "Unicast/Multicast" set to "Unicast". o The 46 remaining bits are set to a random value, using a random number generator that meets the requirements of [RFC4086]. To meet the randomization requirements for the 46 remaining bits, a - hash function may be used. For example, the SHA256 hash function may - be used with 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. + hash function may be used. For example, the [SHA256] hash function + may be used with 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. A randomized Interface ID has the same characteristics of a randomized MAC address, except the length in bits. 5.3. Pseudonymization impact on confidentiality and trust Vehicles 'and drivers' privacy relies on pseudonymization mechanisms such as the ones described in Section 5.2. This pseudonymization means that upper-layer protocols and applications SHOULD NOT rely on layer-2 or layer-3 addresses to assume that the other participant can @@ -640,21 +642,21 @@ [I-D.ietf-ipwave-vehicular-networking] Jeong, J., "IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases", draft-ietf- ipwave-vehicular-networking-11 (work in progress), July 2019. [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-06 (work + Media", draft-ietf-mboned-ieee802-mcast-problems-07 (work in progress), July 2019. [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 http://ieeexplore.ieee.org/document/7426684/ accessed on August 17th, 2017.". [IEEE-1609.3] @@ -711,20 +713,25 @@ [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, . [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, . + [SHA256] "Secure Hash Standard (SHS), National Institute of + Standards and Technology. + https://csrc.nist.gov/CSRC/media/Publications/fips/180/2/ + archive/2002-08-01/documents/fips180-2.pdf". + Appendix A. 802.11p The term "802.11p" is an earlier definition. The behaviour of "802.11p" networks is rolled in the document IEEE Std 802.11-2016. In that document the term 802.11p disappears. Instead, each 802.11p feature is conditioned by the IEEE Management Information Base (MIB) attribute "OCBActivated" [IEEE-802.11-2016]. Whenever OCBActivated is set to true the IEEE Std 802.11-OCB state is activated. For example, an 802.11 STAtion operating outside the context of a basic service set has the OCBActivated flag set. Such a station, when it @@ -1267,21 +1276,21 @@ to the applications. It adapts 802.11 LLC/MAC headers to Ethernet II headers. In further detail, this adaptation consists in the elimination of the Radiotap, 802.11 and LLC headers, and in the insertion of the Ethernet II header. In this way, IPv6 runs straight over LLC over the 802.11-OCB MAC layer; this is further confirmed by the use of the unique Type 0x86DD. Appendix H. Extra Terminology The following terms are defined outside the IETF. They are used to - define the main terms in the main terminology section Section 2. + define the main terms in the main terminology Section 2. DSRC (Dedicated Short Range Communication): a term defined outside the IETF. The US Federal Communications Commission (FCC) Dedicated Short Range Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 47, Parts 90 and 95. This Code is referred in the definitions below. At the time of the writing of this Internet Draft, the last update of this Code was dated October 1st, 2010. DSRCS (Dedicated Short-Range Communications Services): a term defined outside the IETF. The use of radio techniques to transfer data over