--- 1/draft-ietf-ipwave-vehicular-networking-09.txt 2019-07-08 17:18:32.344191654 -0700 +++ 2/draft-ietf-ipwave-vehicular-networking-10.txt 2019-07-08 17:18:32.404193171 -0700 @@ -1,19 +1,19 @@ IPWAVE Working Group J. Jeong, Ed. Internet-Draft Sungkyunkwan University -Intended status: Informational May 24, 2019 -Expires: November 25, 2019 +Intended status: Informational July 8, 2019 +Expires: January 9, 2020 IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases - draft-ietf-ipwave-vehicular-networking-09 + draft-ietf-ipwave-vehicular-networking-10 Abstract This document discusses the problem statement and use cases of IP- based vehicular networking for Intelligent Transportation Systems (ITS). The main scenarios of vehicular communications are vehicle- to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to- everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, it makes a problem statement about key aspects in IP-based vehicular networking, such as @@ -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 November 25, 2019. + This Internet-Draft will expire on January 9, 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 @@ -57,37 +57,37 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Vehicular Networks . . . . . . . . . . . . . . . . . . . . . 7 4.1. Vehicular Network Architecture . . . . . . . . . . . . . 8 - 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 9 - 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 11 + 4.2. V2I-based Internetworking . . . . . . . . . . . . . . . . 10 + 4.3. V2V-based Internetworking . . . . . . . . . . . . . . . . 12 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Neighbor Discovery . . . . . . . . . . . . . . . . . . . 13 5.1.1. Link Model . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. MAC Address Pseudonym . . . . . . . . . . . . . . . . 16 5.1.3. Prefix Dissemination/Exchange . . . . . . . . . . . . 16 5.1.4. Routing . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Mobility Management . . . . . . . . . . . . . . . . . . . 17 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 7. Informative References . . . . . . . . . . . . . . . . . . . 19 + 7. Informative References . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes from draft-ietf-ipwave-vehicular- - networking-08 . . . . . . . . . . . . . . . . . . . 25 - Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 25 - Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 25 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27 + networking-09 . . . . . . . . . . . . . . . . . . . 26 + Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 + Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 27 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction Vehicular networking studies have mainly focused on improving safety and efficiency, and also enabling entertainment in vehicular networks. The Federal Communications Commission (FCC) in the US allocated wireless channels for Dedicated Short-Range Communications (DSRC) [DSRC] in the Intelligent Transportation Systems (ITS) with the frequency band of 5.850 - 5.925 GHz (i.e., 5.9 GHz band). DSRC- based wireless communications can support vehicle-to-vehicle (V2V), @@ -365,21 +365,24 @@ Figure 1: A Vehicular Network Architecture for V2I and V2V Networking 4.1. Vehicular Network Architecture Figure 1 shows an architecture for V2I and V2V networking in a road network. As shown in this figure, RSUs as routers and vehicles with OBU have wireless media interfaces for VANET. Also, it is assumed that such the wireless media interfaces are autoconfigured with a global IPv6 prefix (e.g., 2001:DB8:1:1::/64) to support both V2V and - V2I networking. + V2I networking. Note that 2001:DB8::/32 is a documentation prefix + [RFC3849] for example prefixes in this document, and also that any + routable IPv6 address needs to be routable in a VANET and a vehicular + network including RSUs. Especially, for IPv6 packets transporting over IEEE 802.11-OCB, [IPv6-over-802.11-OCB] specifies several details, such as Maximum Transmission Unit (MTU), frame format, link-local address, address mapping for unicast and multicast, stateless autoconfiguration, and subnet structure. Especially, an Ethernet Adaptation (EA) layer is in charge of transforming some parameters between IEEE 802.11 MAC layer and IPv6 network layer, which is located between IEEE 802.11-OCB's logical link control layer and IPv6 network layer. This IPv6 over 802.11-OCB can be used for both V2V and V2I in IP-based @@ -483,26 +486,28 @@ information. The link layer information includes wireless link layer parameters, such as wireless media (e.g., IEEE 802.11-OCB and LTE- V2X) and a transmission power level. The MAC layer information includes the MAC address of an external network interface for the internetworking with another vehicle or RSU. The IP layer information includes the IP address and prefix of an external network interface for the internetworking with another vehicle or RSU. Once the network parameter discovery and prefix exchange operations have been performed, packets can be transmitted between the vehicle's - moving network and the RSU's fixed network. DNS services should be - supported to enable name resolution for hosts or servers residing - either in the vehicle's moving network or the RSU's fixed network. - It is assumed that the DNS names of in-vehicle devices and their - service names are registered into a DNS server in a vehicle or an - RSU, as shown in Figure 2. + moving network and the RSU's fixed network. A DNS service should be + supported for the DNS name resolution of in-vehicle devices within a + vehicle's internal network as well as for the DNS name resolution of + those devices from a remote host in the Internet for on-line + diagnosis (e.g., an automotive service center server). It is assumed + that the DNS names of in-vehicle devices and their service names are + registered into a DNS server in a vehicle or an RSU, as shown in + Figure 2. Figure 2 shows internetworking between the vehicle's moving network and the RSU's fixed network. There exists an internal network (Moving Network1) inside Vehicle1. Vehicle1 has the DNS Server (DNS1), the two hosts (Host1 and Host2), and the two routers (Router1 and Router2). There exists another internal network (Fixed Network1) inside RSU1. RSU1 has the DNS Server (DNS2), one host (Host3), the two routers (Router3 and Router4), and the collection of servers (Server1 to ServerN) for various services in the road networks, such as the emergency notification and navigation. Vehicle1's Router1 @@ -632,29 +637,32 @@ ND time-related parameters such as router lifetime and Neighbor Advertisement (NA) interval should be adjusted for high-speed vehicles and vehicle density. As vehicles move faster, the NA interval should decrease (e.g., from 1 sec to 0.5 sec) for the NA messages to reach the neighboring vehicles promptly. Also, as vehicle density is higher, the NA interval should increase (e.g., from 0.5 sec to 1 sec) for the NA messages to reduce collision probability with other NA messages. - When ND is used in vehicular networks, the communication delay (i.e., - latency) between two vehicles should be bounded to a certain - threshold (e.g., 500 ms) for collision-avoidance message exchange - [CASD]. For IP-based safety applications (e.g., context-aware - navigation, adaptive cruise control, and platooning) in vehicular - network, this bounded data delivery is critical. The real - implementations for such applications are not available yet. Thus, - ND needs to appropriately operate to support IP-based safety - applications. + According to a report from the National Highway Traffic Safety + Administration (NHTSA) [NHTSA-ACAS-Report], an extra 0.5 second of + warning time can prevent about 60% of the collisions of vehicles + moving closely in a roadway. A warning message should be exchanged + every 0.5 seconds. Thus, if the ND messages (e.g., NS and NA) are + used as warning messages, they should be exchanged every 0.5 second. + + For IP-based safety applications (e.g., context-aware navigation, + adaptive cruise control, and platooning) in vehicular network, this + bounded data delivery is critical. The real implementations for such + applications are not available yet. Thus, ND needs to appropriately + operate to support IP-based safety applications. 5.1.1. Link Model IPv6 protocols work under certain assumptions for the link model that do not necessarily hold in a vehicular wireless link [VIP-WAVE] [RFC5889]. For instance, some IPv6 protocols assume symmetry in the connectivity among neighboring interfaces. However, interference and different levels of transmission power may cause unidirectional links to appear in vehicular wireless links. As a result, a new vehicular link model is required for a dynamically changing vehicular wireless @@ -677,43 +685,38 @@ because of the multihop network connectivity. Thus, in this case, the concept of a on-link IPv6 prefix does not hold because two vehicles with the same on-link IPv6 prefix cannot communicate directly with each other. Also, when two vehicles are located in two different VANETs with the same IPv6 prefix, they cannot communicate with each other. When these two VANETs are converged into one VANET, the two vehicles can communicate with each other in a multihop fashion. Therefore, a vehicular link model should consider the frequent partitioning and merging of VANETs due to vehicle mobility. - An IPv6 prefix can be used in a multi-link subnet as an extended - subnet. IPv6 Stateless Address Autoconfiguration (SLAAC) needs to be - performed even in the multiple links where all of the links are - configured with the same subnet prefix [RFC4861][RFC4862]. Thus, a - vehicular link model can consider a multi-hop V2V (or V2I) over a - multi-link subnet in a vehicular network having multiple VANETs and - RSUs, as shown in Figure 1. For example, in this figure, vehicles - (i.e., Vehicle1, Vehicle2, and Vehicle3) in Subnet1 and Subnet2 - having RSU1 and RSU2, respectively, construct a multi-link subnet - with VANETs and RSUs. Vehicle1 and Vehicle3 can also communicate - with each other via either multi-hop V2V or multi-hop V2I2V. When - two vehicles (e.g., Vehicle1 and Vehicle3 in Figure 1) are connected - in a VANET, it will be more efficient for them to communicate with - each other via VANET rather than RSUs. On the other hand, when two - vehicles (e.g., Vehicle1 and Vehicle3) are far away from the - communication range in separate VANETs and under two different RSUs, - they can communicate with each other through the relay of RSUs via - V2I2V. - - Therefore, IPv6 ND needs to be extended for an efficient Vehicular - Neighbor Discovey (VND) to support the concept of an IPv6 link - corresponding to an IPv6 prefix even in a multi-link subnet - consisting of multiple vehicles and RSUs [ID-Vehicular-ND]. + The vehicular link model needs to support the multihop routing in a + connected VANET where the vehicles with the same global-scope IPv6 + prefix are connected in one hop or multiple hops. It also needs to + support the multhop routing in multiple connected VANETs via an RSU + that has the wireless connectivity with each VANET. For example, + assume that Vehicle1, Vehicle 2, and Vehicle3 are configured with + their IPv6 addresses based on the same global-scope IPv6 prefix. + Vehicle1 and Vehicle3 can also communicate with each other via either + multi-hop V2V or multi-hop V2I2V. When two vehicles (e.g., Vehicle1 + and Vehicle3 in Figure 1) are connected in a VANET, it will be more + efficient for them to communicate with each other via VANET rather + than RSUs. On the other hand, when two vehicles (e.g., Vehicle1 and + Vehicle3) are far away from the communication range in separate + VANETs and under two different RSUs, they can communicate with each + other through the relay of RSUs via V2I2V. Thus, two separate VANETs + can merge into one network via RSU(s). Also, newly arriving vehicles + can merge two separate VANETs into one VANET if they can play a role + of a relay node for those VANETs. 5.1.2. MAC Address Pseudonym For the protection of drivers' privacy, the pseudonym of a MAC address of a vehicle's network interface should be used, with the help of which the MAC address can be changed periodically. The pseudonym of a MAC address affects an IPv6 address based on the MAC address, and a transport-layer (e.g., TCP) session with an IPv6 address pair. However, the pseudonym handling is not implemented and tested yet for applications on IP-based vehicular networking. @@ -754,28 +757,29 @@ networks without a vehicular ad hoc routing protocol (e.g., AODV [RFC3561] and OLSRv2 [RFC7181]). 5.1.4. Routing For multihop V2V communications in a VANET (or a multi-link subnet), a vehicular ad hoc routing protocol (e.g., AODV and OLSRv2) may be required to support both unicast and multicast in the links of the subnet with the same IPv6 prefix. However, it will be costly to run both vehicular ND and a vehicular ad hoc routing protocol in terms of - control traffic overhead. As a feasible approach, Vehicular ND can - be extended to accommodate routing functionality with a prefix - discovery option. In this case, there is no need to run a separate - vehicular ad hoc routing protocol in VANETs. The ND extension can - allow vehicles to exchange their prefixes in a multihop fashion - [ID-Vehicular-ND]. With the exchanged prefixes, they can compute - their routing table (or IPv6 ND's neighbor cache) for the multi-link - subnet with a distance-vector algorithm [Intro-to-Algorithms]. + control traffic overhead [ID-Multicast-Problems]. As a feasible + approach, Vehicular ND can be extended to accommodate routing + functionality with a prefix discovery option. In this case, there is + no need to run a separate vehicular ad hoc routing protocol in + VANETs. The ND extension can allow vehicles to exchange their + prefixes in a multihop fashion [ID-Vehicular-ND]. With the exchanged + prefixes, they can compute their routing table (or IPv6 ND's neighbor + cache) for the multi-link subnet with a distance-vector algorithm + [Intro-to-Algorithms]. Also, an efficient, rapid DAD needs to be supported in a vehicular network having multiple VANETs (or a multi-link subnet) to prevent or reduce IPv6 address conflicts in such a subnet. A feasible approach is to use a multi-hop DAD optimization for the efficient vehicular- network-wide DAD [RFC6775][RFC8505]. 5.2. Mobility Management The seamless connectivity and timely data exchange between two end @@ -824,23 +828,25 @@ 5.3. Security and Privacy Strong security measures shall protect vehicles roaming in road networks from the attacks of malicious nodes, which are controlled by hackers. For safety applications, the cooperation among vehicles is assumed. Malicious nodes may disseminate wrong driving information (e.g., location, speed, and direction) to make driving be unsafe. Sybil attack, which tries to illude a vehicle with multiple false identities, disturbs a vehicle in taking a safe maneuver. This sybil attack should be prevented through the cooperation between good - vehicles and RSUs. Applications on IP-based vehicular networking, - which are resilient to such a sybil attack, are not developed and - tested yet. + vehicles and RSUs. Note that good vehicles are ones with valid + certificates that are determined by the authentication process with + an authentication server in the vehicular network. Applications on + IP-based vehicular networking, which are resilient to such a sybil + attack, are not developed and tested yet. Security and privacy are paramount in the V2I, V2V, and V2X networking in vehicular networks. Only authorized vehicles should be allowed to use vehicular networking. Also, in-vehicle devices and mobile devices in a vehicle need to communicate with other in-vehicle devices and mobile devices in another vehicle, and other servers in an RSU in a secure way. A Vehicle Identification Number (VIN) and a user certificate along with in-vehicle device's identifier generation can be used to @@ -862,20 +868,33 @@ address and the corresponding IPv6 address as suggested in [RFC4086][RFC4941]. Such an update of the MAC and IPv6 addresses should not interrupt the E2E communications between two vehicular nodes (e.g., vehicle and RSU) in terms of transport layer for a long- living higher-layer session. However, if this pseudonym is performed without strong E2E confidentiality, there will be no privacy benefit from changing MAC and IP addresses, because an adversary can see the change of the MAC and IP addresses and track the vehicle with those addresses. + For the IPv6 ND, the vehicular-network-wide DAD is required for the + uniqueness of the IPv6 address of a vehicle's wireless interface. + This DAD can be used as a flooding attack that makes the DAD-related + ND packets are disseminated over the VANET and vehicular network + including the RSU and the MA. The vehicles and RSUs need to filter + out suspicious ND traffic in advance. + + For the mobility management, a malicious vehicle constructs multiple + virtual bogus vehicles, and register them with the RSU and the MA. + This registration makes the RSU and MA waste their resources. The + RSU and MA need to determine whether a vehicle is genuine or bogus in + the mobility management. + 6. Security Considerations This document discussed security and privacy for IP-based vehicular networking. The security and privacy for key components in IP-based vehicular networking, such as neighbor discovery and mobility management, need to be analyzed in depth. 7. Informative References @@ -939,31 +958,37 @@ First Responder Network Authority, "FY 2017: ANNUAL REPORT TO CONGRESS, Advancing Public Safety Broadband Communications", FirstNet FY 2017, December 2017. [Fuel-Efficient] van de Hoef, S., H. Johansson, K., and D. V. Dimarogonas, "Fuel-Efficient En Route Formation of Truck Platoons", IEEE Transactions on Intelligent Transportation Systems, January 2018. + [ID-Multicast-Problems] + Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. + Zuniga, "Multicast Considerations over IEEE 802 Wireless + Media", draft-ietf-mboned-ieee802-mcast-problems-06 (work + in progress), July 2019. + [ID-Vehicular-MM] Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular Mobility Management for IP-Based Vehicular Networks", - draft-jeong-ipwave-vehicular-mobility-management-00 (work - in progress), March 2019. + draft-jeong-ipwave-vehicular-mobility-management-01 (work + in progress), July 2019. [ID-Vehicular-ND] - Jeong, J., Ed., Shen, Y., and Z. Xiang, "IPv6 Neighbor - Discovery for IP-Based Vehicular Networks", draft-jeong- - ipwave-vehicular-neighbor-discovery-06 (work in progress), - March 2019. + Jeong, J., Ed., Shen, Y., and Z. Xiang, "Vehicular + Neighbor Discovery for IP-Based Vehicular Networks", + draft-jeong-ipwave-vehicular-neighbor-discovery-07 (work + in progress), July 2019. [Identity-Management] Wetterwald, M., Hrizi, F., and P. Cataldi, "Cross-layer Identities Management in ITS Stations", The 10th International Conference on ITS Telecommunications, November 2010. [IEEE-802.11-OCB] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std @@ -974,35 +999,43 @@ Physical Layer (PHY) Specifications - Amendment 6: Wireless Access in Vehicular Environments", IEEE Std 802.11p-2010, June 2010. [Intro-to-Algorithms] H. Cormen, T., E. Leiserson, C., L. Rivest, R., and C. Stein, "Introduction to Algorithms, 3rd ed.", The MIT Press, July 2009. [IPv6-over-802.11-OCB] - Benamar, N., Haerri, J., Lee, J., and T. Ernst, - "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-45 (work in progress), April 2019. + Benamar, N., Haerri, J., Lee, J., and T. Ernst, "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 (work + in progress), July 2019. [ISO-ITS-IPv6] ISO/TC 204, "Intelligent Transport Systems - Communications Access for Land Mobiles (CALM) - IPv6 Networking", ISO 21210:2012, June 2012. + [NHTSA-ACAS-Report] + National Highway Traffic Safety Administration (NHTSA), + "Final Report of Automotive Collision Avoidance Systems + (ACAS) Program", DOT HS 809 080, August 2000. + [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, July 2003. + [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix + Reserved for Documentation", RFC 3849, July 2004. + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. @@ -1104,31 +1137,52 @@ [WAVE-1609.3] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Networking Services", IEEE Std 1609.3-2016, April 2016. [WAVE-1609.4] IEEE 1609 Working Group, "IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation", IEEE Std 1609.4-2016, March 2016. -Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-08 +Appendix A. Changes from draft-ietf-ipwave-vehicular-networking-09 The following changes are made from draft-ietf-ipwave-vehicular- - networking-08: + networking-09: - o This version is revised based on the comments from Charlie Perkins - and Sri Gundavelli. + o This version is revised based on the comments from Charlie + Perkins. - o This version focuses on the problem statement about IP-based - vehicular networking, such as IPv6 neighbor discovery, mobility - management, and security & privacy. + o For the question on the preference on a multi-link subnet model, + the revision does not suggest the multi-link subnet model as a + possible solution, focusing on the characteristics and + requirements for a vehicular link model. + + o The motivation about DNS in a vehicle network is addressed + clearly. + + o The timing importance of ND is addressed with a reference to + [NHTSA-ACAS-Report]. + + o The Security Considerations are expanded with cross references to + other parts of the document such as IPv6 ND and mobility + management. + + o 2001:DB8::/32 is a reserved prefix for use in documentation + [RFC3849]. Any routable IPv6 address needs to be routable in a + VANET and a vehicular network including RSUs. + + o With an example in Figure 1, it is suggested that two separate + VANETs can merge into one network. + + o A suggestion is made about how to distinguish good nodes from bad + nodes with an authentication process. Appendix B. Acknowledgments This work was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (2017R1D1A1B03035885). This work was supported in part by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2019-2017-0-01633) supervised by the IITP