--- 1/draft-ietf-ipwave-ipv6-over-80211ocb-49.txt 2019-07-21 07:14:21.034196850 -0700 +++ 2/draft-ietf-ipwave-ipv6-over-80211ocb-50.txt 2019-07-21 07:14:21.106198669 -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 9, 2020 Eurecom +Expires: January 21, 2020 Eurecom J. Lee Sangmyung University T. Ernst YoGoKo - July 8, 2019 + July 20, 2019 Basic Support for IPv6 over IEEE Std 802.11 Networks Operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB) - draft-ietf-ipwave-ipv6-over-80211ocb-49 + draft-ietf-ipwave-ipv6-over-80211ocb-50 Abstract This document provides methods and settings, and describes limitations, for using IPv6 to communicate among nodes in range of one another over a single IEEE 802.11-OCB link. This support does only require minimal changes to existing stacks. Optimizations and usage of IPv6 over more complex scenarios is not covered in this specification and is subject of future work. @@ -30,21 +30,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 9, 2020. + This Internet-Draft will expire on January 21, 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 @@ -69,58 +69,58 @@ 4.5.2. Address Mapping -- Multicast . . . . . . . . . . . . 6 4.6. Subnet Structure . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 8 5.1.1. Privacy Risks of Meaningful info in Interface IDs . . 9 5.2. MAC Address and Interface ID Generation . . . . . . . . . 9 5.3. Pseudonym Handling . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. 802.11p . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Aspects introduced by the OCB mode to 802.11 . . . . 16 Appendix C. Changes Needed on a software driver 802.11a to - become a 802.11-OCB driver . . . 21 + become a 802.11-OCB driver . . . . . . . . . . . . . 21 Appendix D. Protocol Layering . . . . . . . . . . . . . . . . . 22 Appendix E. Design Considerations . . . . . . . . . . . . . . . 23 Appendix F. IEEE 802.11 Messages Transmitted in OCB mode . . . . 23 Appendix G. Examples of Packet Formats . . . . . . . . . . . . . 23 G.1. Capture in Monitor Mode . . . . . . . . . . . . . . . . . 24 G.2. Capture in Normal Mode . . . . . . . . . . . . . . . . . 27 Appendix H. Extra Terminology . . . . . . . . . . . . . . . . . 29 Appendix I. Neighbor Discovery (ND) Potential Issues in Wireless Links . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction This document provides a baseline with limitations 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. - Concretly, the document describes the layering of IPv6 networking on + 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 [RFC 2464], 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], [RFC2464] . + described in [RFC1042] and [RFC2464]. 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. Security and privacy recommendations are discussed 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. Likewise, ND Extensions and IPWAVE optimizations for vehicular communications are not in scope. The expectation is that further specifications will be edited to cover more complex vehicular networking scenarios. @@ -152,23 +152,21 @@ An IP-RSU is similar to an Access Network Router (ANR) defined in [RFC3753], and a Wireless Termination Point (WTP) defined in [RFC5415]. OCB (outside the context of a basic service set - BSS): is a mode of operation in which a STA is not a member of a BSS and does not utilize IEEE Std 802.11 authentication, association, or data confidentiality. 802.11-OCB: refers to the mode specified in IEEE Std 802.11-2016 when - the MIB attribute dot11OCBActivited is 'true'. Note: compliance with - standards and regulations set in different countries when using the - 5.9GHz frequency band is required. + the MIB attribute dot11OCBActivited is 'true'. 3. Communication Scenarios where IEEE 802.11-OCB Links are Used The IEEE 802.11-OCB networks are used for vehicular communications, as 'Wireless Access in Vehicular Environments'. In particular, we refer the reader to [I-D.ietf-ipwave-vehicular-networking], that lists some scenarios and requirements for IP in Intelligent Transportation Systems (ITS). The link model is the following: STA --- 802.11-OCB --- STA. In @@ -176,42 +174,43 @@ are assumed to be P2P and multiple links can be on one radio interface. While 802.11-OCB is clearly specified, and a legacy IPv6 stack can operate on such links, the use of the operating environment (vehicular networks) brings in new perspectives. 4. IPv6 over 802.11-OCB 4.1. Maximum Transmission Unit (MTU) The default MTU for IP packets on 802.11-OCB is inherited from - RFC2464 and is, as such, 1500 octets. 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 + [RFC2464] and is, as such, 1500 octets. 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 802.11 spec [IEEE-802.11-2016]. The IPv6 packet transmitted on 802.11-OCB are 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 D), the value of the Type field MUST be set to - 0x86DD (IPv6). The mapping to the 802.11 data service MUST use a - 'priority' value of 1, which specifies the use of QoS with a - 'Background' user priority. + 0x86DD (IPv6). The mapping to the 802.11 data service SHOULD use a + 'priority' value of 1 (QoS with a 'Background' user priority), + reserving higher priority values for safety-critical and time- + sensitive traffic, including the ones listed in [ETSI-sec-archi]. To simplify the Application Programming Interface (API) between the operating system and the 802.11-OCB media, device drivers MAY - implement IPv6-over-Ethernet as per RFC 2464 and then a frame + 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. @@ -220,40 +219,40 @@ used to form an IPv6 link-local address on Ethernet links. Moreover, whether or not the interface identifier is derived from the EUI-64 A identifier, its length is 64 bits as is the case for Ethernet [RFC2464]. 4.4. Stateless Autoconfiguration The steps a host takes in deciding how to autoconfigure its interfaces in IPv6 are described in [RFC4862]. 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' are discussed in Section 4.3. + of type 'Global' or 'Unique Local'. Interface Identifiers for IPv6 + address of type 'Link-Local' are discussed in Section 4.3. 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, in particular for IPv6 link-local addresses. Regardless of how - to form the IID, its length is 64 bits, as is the case of the IPv6 - over Ethernet [RFC2464]. + to form the IID, its length is 64 bits, similarely to IPv6 over + Ethernet [RFC2464]. The bits in the IID have no specific 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]. Semantically opaque IIDs, instead of meaningful IIDs derived from a valid and meaningful MAC address ([RFC2464], Section 4), help avoid certain privacy risks (see the risks mentioned in Section 5.1.1). If - semantically opaque IIDs are needed, they MAY be generated using the + semantically opaque IIDs are needed, they may be generated using the method for generating semantically opaque IIDs with IPv6 Stateless Address Autoconfiguration given in [RFC7217]. Typically, an opaque IID 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. Some applications that use IPv6 packets on 802.11-OCB links (among other link types) may benefit from IPv6 addresses whose IIDs don't @@ -271,51 +270,56 @@ 4.5.1. Address Mapping -- Unicast This document is scoped for Address Resolution (AR) and Duplicate 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 in that section 7 of [RFC2464] is defined in section 2.3.1 - of [RFC7042]. + 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 should consider solutions for these problems. 4.6. Subnet Structure - A subnet may be formed over 802.11-OCB interfaces of vehicles that - are in close range (not by their in-vehicle interfaces). A Prefix + 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. - An IPv6 subnet on which Neighbor Discovery protocol (ND) can be - mapped on an OCB network if all nodes share a single broadcast - Domain, which is generally the case for P2P OCB links; The extension - to IPv6 ND operating on a subnet that covers multiple OCB links and - not fully overlapping (NBMA) is not in scope. + IPv6 Neighbor Discovery protocol (ND) requires reflexive properties + (bidirectional connectivity) which is generally, though not always, + the case for P2P OCB links. IPv6 ND also requires transitive + properties for DAD and AR, so an IPv6 subnet can be mapped on an OCB + network only if all nodes in the network share a single physical + broadcast domain. The extension to IPv6 ND operating on a subnet + that covers multiple OCB links and not fully overlapping (NBMA) is + not in scope. Finally, IPv6 ND requires a permanent connectivity of + all nodes in the subnet to defend their addresses, in other words + very stable network conditions. The structure of this subnet is ephemeral, in that it is strongly 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 vehicle 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 + 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 (i.e., a default route is absent), and the addressing peers are equally qualified (that is, it is impossible to determine that some vehicle owns and distributes addresses to others) the use of link-local addresses is RECOMMENDED. @@ -333,114 +337,118 @@ which depend on a 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 out for the general case of IPv6 may also be carried out for IPv6 operating over 802.11-OCB. - The OCB operation is stripped off of all existing 802.11 link-layer - security mechanisms. There is no encryption applied below the - network layer running on 802.11-OCB. At the application layer, the - IEEE 1609.2 document [IEEE-1609.2] provides security services for - certain applications to use; application-layer mechanisms are out-of- - scope of this document. On another hand, a security mechanism - provided at networking layer, such as IPsec [RFC4301], may provide - data security protection to a wider range of applications. + The OCB operation does not use existing 802.11 link-layer security + mechanisms. There is no encryption applied below the network layer + running on 802.11-OCB. At the application layer, the IEEE 1609.2 + document [IEEE-1609.2] provides security services for certain + applications to use; application-layer mechanisms are out of scope of + this document. On another hand, a security mechanism provided at + networking layer, such as IPsec [RFC4301], may provide data security + protection to a wider range of applications. 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). Any attacker can therefore just - sit in the near range of vehicles, sniff the network (just set the - interface card's frequency to the proper range) and performs attacks - without needing to physically break any wall. Such a link is less - protected than commonly used links (wired link or protected 802.11). - - The potential attack vectors are: MAC address spoofing, IP address - and session hijacking, and privacy violation Section 5.1. A previous - work at SAVI WG identifies some threats [RFC6959], while SeND - presented in [RFC3971] and [RFC3972] is a solution against address - theft but it is complex and not deployed. + 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 carda€™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). - More IETF protocols are available in the toolbox of the IP security - protocol designer. Some ETSI protocols related to security protocols - in ITS are described in [ETSI-sec-archi]. + Therefore, any node can join a subnet, directly communicate with any + nodes on the subset to include potentially impersonating another + node.A 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]), the identifier of an 802.11-OCB interface may involve privacy, MAC address spoofing and IP hijacking risks. A vehicle embarking an IP- OBU whose egress interface is 802.11-OCB may expose itself to - eavesdropping and subsequent correlation of data; this may reveal + 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.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 + pricavy concerns, ([RFC8065]) recommends using an address generation scheme rather than addresses generated from a fixed link-layer - address. + 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 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 + 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 + 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 - in Appendix B. + 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 "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. A randomized Interface ID has the same characteristics of a - randomized MAC address, except the length in bits. An Interface ID - SHOULD be of length specified in other documents. + randomized MAC address, except the length in bits. 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 @@ -481,20 +489,23 @@ 8. Acknowledgements The authors would like to thank Alexandre Petrescu for initiating this work and for being the lead author until the version 43 of this draft. The authors would like to thank Pascal Thubert for reviewing, proofreading and suggesting modifications of this document. + The authors would like to thank Mohamed Boucadair for proofreading + and suggesting modifications of this document. + The authors would like to thank Witold Klaudel, Ryuji Wakikawa, 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, @@ -511,135 +522,117 @@ 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 in 2016. Human Rights Protocol Considerations review by Amelia Andersdotter. 9. References + 9.1. Normative References + [IEEE-802.11-2016] + "IEEE Standard 802.11-2016 - 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. Status - Active Standard. Description + retrieved freely; the document itself is also freely + available, but with some difficulty (requires + registration); description and document retrieved on April + 8th, 2019, starting from URL + https://standards.ieee.org/findstds/ + standard/802.11-2016.html". + [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, DOI 10.17487/RFC1042, February 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, + November 2005, . + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, . - [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, - "Internet X.509 Public Key Infrastructure Certificate - Management Protocol (CMP)", RFC 4210, - DOI 10.17487/RFC4210, September 2005, - . - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . - [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, - DOI 10.17487/RFC4302, December 2005, - . - - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, DOI 10.17487/RFC4303, December 2005, - . - [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . - [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast - Extensions to the Security Architecture for the Internet - Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, - . - [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, . - [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing - Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, - September 2010, . - [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, . [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, . - [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address - Validation Improvement (SAVI) Threat Scope", RFC 6959, - DOI 10.17487/RFC6959, May 2013, - . - [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . - [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, . - [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- - Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, - 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 @@ -650,28 +643,28 @@ Security; ITS communications security architecture and security management, November 2016. Downloaded on September 9th, 2017, freely available from ETSI website at URL http://www.etsi.org/deliver/ etsi_ts/102900_102999/102940/01.02.01_60/ ts_102940v010201p.pdf". [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-09 (work in progress), May + 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-05 (work - in progress), April 2019. + Media", draft-ietf-mboned-ieee802-mcast-problems-06 (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] "IEEE SA - 1609.3-2016 - IEEE Standard for Wireless Access @@ -679,34 +672,20 @@ Example URL http://ieeexplore.ieee.org/document/7458115/ accessed on August 17th, 2017.". [IEEE-1609.4] "IEEE SA - 1609.4-2016 - IEEE Standard for Wireless Access in Vehicular Environments (WAVE) -- Multi-Channel Operation. Example URL http://ieeexplore.ieee.org/document/7435228/ accessed on August 17th, 2017.". - [IEEE-802.11-2016] - "IEEE Standard 802.11-2016 - 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. Status - Active Standard. Description - retrieved freely; the document itself is also freely - available, but with some difficulty (requires - registration); description and document retrieved on April - 8th, 2019, starting from URL - https://standards.ieee.org/findstds/ - standard/802.11-2016.html". - [IEEE-802.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, @@ -723,20 +702,38 @@ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . + [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing + Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, + September 2010, . + + [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address + Validation Improvement (SAVI) Threat Scope", RFC 6959, + DOI 10.17487/RFC6959, May 2013, + . + + [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, . + 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 @@ -822,21 +818,21 @@ true, then it is actually referring to OCB aspects introduced to 802.11. In order to delineate the aspects introduced by 802.11-OCB to 802.11, we refer to the earlier [IEEE-802.11p-2010]. The amendment is concerned with vehicular communications, where the wireless link is similar to that of Wireless LAN (using a PHY layer specified by 802.11a/b/g/n), but which needs to cope with the high mobility factor inherent in scenarios of communications between moving vehicles, and between vehicles and fixed infrastructure deployed along roads. - While 'p' is a letter identifying the Ammendment, just like 'a, b, g' + While 'p' is a letter identifying the Amendment, just like 'a, b, g' and 'n' are, 'p' is concerned more with MAC modifications, and a little with PHY modifications; the others are mainly about PHY modifications. It is possible in practice to combine a 'p' MAC with an 'a' PHY by operating outside the context of a BSS with OFDM at 5.4GHz and 5.9GHz. The 802.11-OCB links are specified to be compatible as much as possible with the behaviour of 802.11a/b/g/n and future generation IEEE WLAN links. From the IP perspective, an 802.11-OCB MAC layer offers practically the same interface to IP as the 802.11a/b/g/n and @@ -1359,24 +1355,24 @@ claims its address, which is done by sending a NS multicast message, and can hear any future claim for that address by another party within the scope for the duration of the address ownership. In the case of OCB, there is a potentially a need to define a scope that is compatible with DAD, and that cannot be the set of nodes that a transmitter can reach at a particular time, because that set varies all the time and does not meet the DAD requirements for a link local address that could possibly be used anytime, anywhere. The generic expectation of a reliable multicast is not ensured, and the operation - of DAD and AR (Address Resolution) as specificed by RFC 4861 cannot - be guaranteed. Moreoever, multicast transmissions that rely on - broadcast are not only unreliable but are also often detrimental to - unicast traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). + of DAD and AR (Address Resolution) as specified by RFC 4861 cannot be + guaranteed. Moreover, multicast transmissions that rely on broadcast + are not only unreliable but are also often detrimental to unicast + traffic (see [draft-ietf-mboned-ieee802-mcast-problems]). Early experience indicates that it should be possible to exchange IPv6 packets over OCB while relying on IPv6 ND alone for DAD and AR (Address Resolution) in good conditions. In the absence of a correct DAD operation, a node that relies only on IPv6 ND for AR and DAD over OCB should ensure that the addresses that it uses are unique by means others than DAD. It must be noted that deriving an IPv6 address from a globally unique MAC address has this property but may yield privacy issues.