idnits 2.17.1 draft-jeong-ipwave-security-privacy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2020) is 1451 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-14 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'ID-IPWAVE-PS') ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-02 == Outdated reference: A later version (-14) exists of draft-ietf-i2nsf-sdn-ipsec-flow-protection-07 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group J. Jeong, Ed. 3 Internet-Draft Y. Shen 4 Intended status: Standards Track Sungkyunkwan University 5 Expires: November 8, 2020 J. Park 6 ETRI 7 May 7, 2020 9 Basic Support for Security and Privacy in IP-Based Vehicular Networks 10 draft-jeong-ipwave-security-privacy-01 12 Abstract 14 This document describes possible attacks of security and privacy in 15 IP Wireless Access in Vehicular Environments (IPWAVE). It also 16 proposes countermeasures for those attacks. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 8, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Security Attacks . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. False Information Attack . . . . . . . . . . . . . . . . 3 56 3.2. Impersonation Attack . . . . . . . . . . . . . . . . . . 4 57 3.3. Denial-of-Service Attack . . . . . . . . . . . . . . . . 4 58 3.4. Message Suspension Attack . . . . . . . . . . . . . . . . 4 59 3.5. Tampering Attack . . . . . . . . . . . . . . . . . . . . 5 60 3.6. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Countermeasures . . . . . . . . . . . . . . . . . . 5 62 4.1. Identification and Authentication . . . . . . . . . . . . 6 63 4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 6 64 4.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 6 65 4.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 7 66 4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Changes from draft-jeong-ipwave-security-privacy-00 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Vehicular networking has become popular by the enhancement of 78 Intelligent Transportation Systems (ITS) [ISO-ITS-IPv6]. The 79 vehicular networking can work based on Dedicated Short-Range 80 Communications (DSRC) [DSRC]. This DSRC is realized by the IEEE 81 Wireless Access in Vehicular Environments (WAVE) [WAVE-1609.0]. 82 Especially, IEEE 802.11-OCB (Outside the Context of Basic Support 83 Set) [IEEE-802.11-OCB] provides the Media Access Control (MAC) for 84 vehicles in vehicular networks. IP-based vehicular networking can be 85 supported with IPv6 over IEEE 802.11-OCB [RFC8691], which defines the 86 IPv6 Neighbor Discovery (ND), Maximum Transmission Unit (MTU), and 87 MAC layer adaptation. 89 Vehicles can construct Vehicular Ad Hoc Networks (VANET) by 90 themselves without any infrastructure node such as a Road-Side Unit 91 (RSU). Cooperative Adaptive Cruise Control and Autonomous Driving 92 (i.e., Self-Driving) services can take advantage of this vehicular 93 networking for safe driving through the wireless communications among 94 vehicles. 96 When using IP-based vehicular networks in self-driving environments, 97 the information exchange among self-driving vehicles are critical to 98 the safety of vehicles since the information received from other 99 vehicles may be used as inputs for vehicle maneuvers. Thus, 100 identifying potential loopholes in the IP-based vehicular networks 101 becomes crucial. 103 This document describes possible attacks on security and 104 vulnerabilities of privacy in IP Wireless Access in Vehicular 105 Environments (IPWAVE). It also proposes countermeasures for those 106 attacks and vulnerabilities. 108 2. Terminology 110 This document uses the definitions defined in the IPWAVE problem 111 statement document [ID-IPWAVE-PS]. 113 3. Security Attacks 115 This section explains possible attacks of security and 116 vulnerabilities of privacy in IP-based vehicular networks. 118 Security and privacy are very important in V2I, V2V, and V2X 119 communications in vehicular networks. Only identified and authorized 120 vehicles should be allowed to be involved in vehicular networking. 121 Furthermore, in-vehicle devices in a vehicle and mobile devices of a 122 driver and passengers are required to communicate with other devices 123 in VANET or the Internet in a secure and reliable way. 125 In reality, there are many possible security attacks in vehicular 126 networks. The exemplary security attacks are false information 127 attack, impersonation attack, denial-of-service attack, message 128 suspension attack, tampering attack, and tracking. By these attacks, 129 the vehicles can be put into dangerous situations by false 130 information and information loss. 132 For those attacks, security countermeasures are required to protect 133 vehicles. With these countermeasures, vehicles can exchange their 134 driving data with neighboring vehicles and infrastructure nodes 135 (e.g., edge computing device and cloud server) for safe driving as 136 well as efficient navigation in road networks. 138 3.1. False Information Attack 140 Malicious vehicles may intentionally disseminate false driving 141 information (e.g., location, speed, and direction) to let the driving 142 of other vehicles be unsafe and then other vehicles meet accidents. 143 Especially, a representative example is Sybil attack. This Sybil 144 attack makes multiple false identities of non-existing vehicles 145 (i.e., virtual bogus vehicles) in order to confuse other good 146 vehicles in safe driving, and makes these good vehicles take wrong 147 maneuvers, leading to fatalities. 149 In vehicular networks, a malicious vehicle can create multiple 150 virtual bogus vehicles, and generate global IPv6 addresses and 151 register them with a Mobility Anchor (MA) via an RSU. This IP 152 address autoconfiguration makes the RSU and MA waste their 153 computation power and storage resources for IP address 154 autoconfiguration and mobility management. Thus, the RSU and MA need 155 to determine whether a vehicle is genuine or bogus in the IP address 156 autoconfiguration and mobility management. 158 3.2. Impersonation Attack 160 Malicious vehicles can pretend to be other vehicles with forged IP 161 addresses or MAC address as IP address spoofing and MAC address 162 spoofing, respectively. This attack is called impersonation attack 163 to masquerade a vehicle and user. 165 To detect such an impersonation attack, an authentication scheme 166 needs to check whether the MAC address and IPv6 address of a vehicle 167 is associated with the vehicle's permanent identifier (e.g., a 168 driver's certificate identifier) or not. 170 3.3. Denial-of-Service Attack 172 Malicious vehicles (or compromised vehicles) can generate bogus 173 services requests to either a vehicle or a server in the vehicular 174 cloud so that either the vehicle or the server is extremely busy with 175 the requests, and cannot process valid request in a prompt way. This 176 attack is called Denial-of-Service (DoS) attack. 178 For example, in the IPv6 ND for vehicular networks, the vehicular- 179 network-wide DAD can be performed via an RSU and a MA to guarantee 180 that the IPv6 address of a vehicle's wireless interface is unique in 181 the vehicular network. The ND packets for the DAD process are 182 forwarded to other vehicles, an RSU, and an MA. 184 To detect and mitigate this DoS attack, the vehicles need to 185 collaborate with each other to monitor a suspicious activity related 186 to the DoS attack, that is, the generation of messages more than the 187 expected threshold in a certain service. 189 3.4. Message Suspension Attack 191 Malicious vehicles can drop packets originated by other vehicles in 192 multihop V2V or V2I communications, which is called a Message 193 Suspension Attack. This packet dropping can hinder the data exchange 194 for safe driving in cooperative driving environments. Also, in 195 multi-hop V2V or V2I communications, this packet dropping can 196 interfere with the reliable data forwarding among the communicating 197 entities (e.g., vehicle, client, and server). 199 For the reliable data transfer, a vehicle performing the message 200 suspension attack needs to be detected by good vehicles and a good 201 RSU, and it should be excluded in vehicular communications. 203 3.5. Tampering Attack 205 An authorized and legitimate vehicle may be compromised by a hacker 206 so that it can run a malicious firmware or software (malware), which 207 is called a tampering attack. This tampering attack may endanger the 208 vehicle's computing system, steal the vehicle's information, and 209 track the vehicle. Also, such a malware can generate bogus data 210 traffic for DoS attack against other vehicles, and track other 211 vehicles, and collect other vehicles' information. 213 The forgery of firmware or software in a vehicle needs to be 214 protected against hackers. The forgery prevention of firmware such 215 as the bootloader of a vehicle's computing system can be performed by 216 a secure booting scheme. The safe update of the firmware can be 217 performed by a secure firmware update protocol. The abnormal 218 behaviors by the forgery of firmware or software can be monitored by 219 a remote attestation scheme. 221 3.6. Tracking 223 The MAC address and IPv6 address of a vehicle's wireless interface 224 can be used as an identifier. An hacker can track a moving vehicle 225 by collecting and tracing the data traffic related to the MAC address 226 or IPv6 address. 228 To avoid the illegal tracking by a hacker, the MAC address and IPv6 229 address of a vehicle need to be periodically updated. However, the 230 change of those addresses needs to minimize the impact of ongoing 231 sessions on performance. 233 4. Security Countermeasures 235 This section proposes countermeasures against the attacks of security 236 and privacy in IP-based vehicular networks. 238 4.1. Identification and Authentication 240 Good vehicles are ones having valid certificates (e.g., X.509 241 certificate), which can be validated by an authentication method 242 through an authentication server [RFC5280]. 244 Along with an X.509 certificate, a Vehicle Identification Number 245 (VIN) can be used as a vehicle's identifier to efficiently 246 authenticate the vehicle and its driver through a road infrastructure 247 node (e.g., RSU and MA), which is connected to an authentication 248 server in vehicular cloud. X.509 certificates can be used as 249 Transport Layer Security (TLS) certificates for the mutual 250 authentication of a TCP connection between two vehicles or between a 251 vehicle and a corresponding node (e.g., client and server) in the 252 Internet. 254 Good vehicles can also use a Decentralized Identifier (DID) with the 255 help of a verifiable claim service. In this case, vehicles can their 256 DID as a unique identifier, and then check the identity of any 257 joining vehicle with its verifiable claim. 259 4.2. Integrity and Confidentiality 261 For secure V2I or V2V communications, a secure channel between two 262 communicating entities (e.g., vehicle, RSU, client, and server) needs 263 to be used to check the integrity of packets exchanged between them 264 and support their confidentiality. For this secure channel, a pair 265 of session keys between two entities (e.g., vehicle, RSU, MA, client, 266 and server) needs to be set up. 268 For the establishment of the session keys in V2V or V2I 269 communications, an Internet Key Exchange Protocol version 2 (IKEv2) 270 can be used [RFC7296]. Also, for the session key generation, either 271 an RSU or an MA can play a role of a Software-Defined Networking 272 (SDN) Controller to make a pair of session keys and other session 273 parameters (e.g., a hash algorithm and an encryption algorithm) 274 between two communicating entities in vehicular networks 275 [ID-SDN-IPsec]. 277 4.3. Non-Repudiation 279 A malicious vehicle can disseminate bogus messages to its neighboring 280 vehicles as a sybil attack. This sybil attack announces wrong 281 information of a vehicle's existence and mobility information to 282 normal vehicles. This may cause accidents (e.g., vehicle collision 283 and pedestrian damage). In the case of the occurrence of an 284 accident, it is important to localize and identify the criminal 285 vehicle with a non-repudiation method through the logged data during 286 the navigation of vehicles. 288 For non-repudiation, the messages generated by a vehicle can be 289 logged by its neighboring vehicles. As an effective non-repudiation, 290 a blockchain technology can be used. Each message can be treated as 291 a transaction and the adjacent vehicles can play a role of peers in 292 consensus methods such as Proof of Work (PoW) and Proof of Stake 293 (PoS) [Bitcoin]. 295 4.4. Remote Attestation 297 To prevent a tampering attack by the forgery of firmware/software, a 298 secure booting can be performed by Root of Trust (RoT) and a remote 299 attestation can be performed through both the secure booting and RoT 300 [ID-NSF-Remote-Attestation][ID-Remote-Attestation-Arch]. 302 The secure booting can make sure that the bootloader of the vehicle's 303 computing system is a legitimate one with the digital signature of 304 the boofloader by using the RoT of Trusted Platform Module (TPM) 305 [ISO-IEC-TPM] or Google Titan Chip [Google-Titan-Chip]. 307 A firmware update service can be made in blockchain technologies 308 [Vehicular-BlockChain]. The validity of a brand-new firmware can be 309 proven by a blockchain of the firmware, having the version history. 310 Thus, This blockchain can manage a brand-new firmware or software and 311 distribute it in a secure way. 313 The remote attestation can monitor the behaviors of the vehicle's 314 computing system such that the system is working correctly according 315 to the policy and configuration of an administrator or user 316 [ID-NSF-Remote-Attestation][ID-Remote-Attestation-Arch]. For this 317 remote attestation, a secure channel should be established between a 318 verifier and a vehicle. 320 4.5. Privacy 322 To avoid the tracking of a vehicle with its MAC address, a MAC 323 address pseudonym can be used, which updates the MAC address 324 periodically. This update triggers the update of the vehicle's IPv6 325 address because the IPv6 address of a network interface is generated 326 with the interface's MAC address. The MAC address and IPv6 address 327 can be updated by the guideline in [RFC4086] and a method in 328 [RFC4941], respectively. 330 The update of the MAC address and the IPv6 address affects the on- 331 going traffic flow because the source node or destination node of the 332 packets of the flow are identified with the node's MAC address and 333 IPv6 address. This update on a vehicle requires the update of the 334 neighbor caches of the vehicle's neighboring vehicles for multihop 335 V2V communications, as well as the neighbor caches of the vehicle's 336 neighboring vehicles and the neighbor tables of an RSU, and an MA in 337 multihop V2I communications. 339 Without strong confidentiality, the update of the MAC address and 340 IPv6 address can be observed by an adversary, so there is no privacy 341 benefit in tracking prevention. The update needs to be notified to 342 only the trustworthy vehicles, RSU, and MA. 344 Also, for the continuity of an end-to-end (E2E) transport-layer 345 (e.g., TCP, UDP, and SCTP) session, the new IP address for the 346 transport-layer session can be notified to an appropriate end point 347 through a mobility management scheme such as Mobile IP Protocols 348 (e.g., Mobile IPv6 (MIPv6) [RFC6275] and Proxy MIPv6 (PMIPv6) 349 [RFC5213]). This mobility management overhead and impact of 350 pseudonyms should be minimized on the performance of vehicular 351 networking. 353 5. Security Considerations 355 This document discussed security considerations for IPWAVE security 356 and privacy in Section 3 and Section 4. 358 6. Acknowledgments 360 This work was supported by Institute of Information & Communications 361 Technology Planning & Evaluation (IITP) grant funded by the Ministry 362 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 363 Security Intelligence Technology Development for the Customized 364 Security Service Provisioning). 366 This work was supported in part by the MSIT under the Information 367 Technology Research Center (ITRC) support program (IITP- 368 2019-2017-0-01633) supervised by the IITP. 370 7. References 372 7.1. Normative References 374 [ID-IPWAVE-PS] 375 Jeong, J., "IPv6 Wireless Access in Vehicular Environments 376 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 377 ipwave-vehicular-networking-14 (work in progress), March 378 2020. 380 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 381 "Randomness Requirements for Security", RFC 4086, June 382 2005. 384 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 385 Extensions for Stateless Address Autoconfiguration in 386 IPv6", RFC 4941, September 2007. 388 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 389 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 390 RFC 5213, August 2008. 392 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 393 Housley, R., and W. Polk, "Internet X.509 Public Key 394 Infrastructure Certificate and Certificate Revocation List 395 (CRL) Profile", RFC 5280, May 2008. 397 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 398 Support in IPv6", RFC 6275, July 2011. 400 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 401 Kivinen, "Internet Key Exchange Protocol Version 2 402 (IKEv2)", RFC 7296, October 2014. 404 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 405 Support for IPv6 Networks Operating Outside the Context of 406 a Basic Service Set over IEEE Std 802.11", RFC 8691, 407 December 2019. 409 7.2. Informative References 411 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 412 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 414 [DSRC] ASTM International, "Standard Specification for 415 Telecommunications and Information Exchange Between 416 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 417 Range Communications (DSRC) Medium Access Control (MAC) 418 and Physical Layer (PHY) Specifications", 419 ASTM E2213-03(2010), October 2010. 421 [Google-Titan-Chip] 422 Google, "Titan in depth: Security in plaintext", URL: 423 https://cloud.google.com/blog/products/gcp/titan-in-depth- 424 security-in-plaintext, October 2018. 426 [ID-NSF-Remote-Attestation] 427 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 428 Procedures for Network Security Functions (NSFs) through 429 the I2NSF Security Controller", draft-pastor-i2nsf-nsf- 430 remote-attestation-07 (work in progress), February 2019. 432 [ID-Remote-Attestation-Arch] 433 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 434 W. Pan, "Remote Attestation Procedures Architecture", 435 draft-ietf-rats-architecture-02 (work in progress), March 436 2020. 438 [ID-SDN-IPsec] 439 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 440 Garcia, "Software-Defined Networking (SDN)-based IPsec 441 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 442 protection-07 (work in progress), August 2019. 444 [IEEE-802.11-OCB] 445 "Part 11: Wireless LAN Medium Access Control (MAC) and 446 Physical Layer (PHY) Specifications", IEEE Std 447 802.11-2016, December 2016. 449 [ISO-IEC-TPM] 450 ISO/IEC JTC 1, "Information technology - Trusted Platform 451 Module - Part 1: Overview", ISO/IEC 11889-1:2015, August 452 2015. 454 [ISO-ITS-IPv6] 455 ISO/TC 204, "Intelligent Transport Systems - 456 Communications Access for Land Mobiles (CALM) - IPv6 457 Networking", ISO 21210:2012, June 2012. 459 [Vehicular-BlockChain] 460 Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, 461 "BlockChain: A Distributed Solution to Automotive Security 462 and Privacy", IEEE Communications Magazine, Vol. 55, No. 463 12, December 2017. 465 [WAVE-1609.0] 466 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 467 in Vehicular Environments (WAVE) - Architecture", IEEE Std 468 1609.0-2013, March 2014. 470 Appendix A. Changes from draft-jeong-ipwave-security-privacy-00 472 The following changes are made from draft-jeong-ipwave-security- 473 privacy-00: 475 o This version has a submission date update to maintain the active 476 status of the draft. 478 o This version updates the version numbers of the referenced drafts. 480 Authors' Addresses 482 Jaehoon (Paul) Jeong (editor) 483 Department of Computer Science and Engineering 484 Sungkyunkwan University 485 2066 Seobu-Ro, Jangan-Gu 486 Suwon, Gyeonggi-Do 16419 487 Republic of Korea 489 Phone: +82 31 299 4957 490 Fax: +82 31 290 7996 491 EMail: pauljeong@skku.edu 492 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 494 Yiwen (Chris) Shen 495 Department of Computer Science and Engineering 496 Sungkyunkwan University 497 2066 Seobu-Ro, Jangan-Gu 498 Suwon, Gyeonggi-Do 16419 499 Republic of Korea 501 Phone: +82 31 299 4106 502 Fax: +82 31 290 7996 503 EMail: chrisshen@skku.edu 504 URI: http://iotlab.skku.edu/people-chris-shen.php 506 Jung-Soo Park 507 Electronics and Telecommunications Research Institute 508 218 Gajeong-Ro, Yuseong-Gu 509 Daejeon 34129 510 Republic of Korea 512 Phone: +82 42 860 6514 513 EMail: pjs@etri.re.kr