idnits 2.17.1 draft-jeong-ipwave-security-privacy-02.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 (November 2, 2020) is 1270 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-19 ** 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: May 6, 2021 J. Park 6 ETRI 7 November 2, 2020 9 Basic Support for Security and Privacy in IP-Based Vehicular Networks 10 draft-jeong-ipwave-security-privacy-02 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 May 6, 2021. 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 . . . . . . . . . . . . 5 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-01 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 deceive other 142 vehicles, which may put those vehicles in danger. Especially, a 143 representative example is Sybil attack. This Sybil attack makes 144 multiple false identities of non-existing vehicles (i.e., virtual 145 bogus vehicles) in order to confuse other real vehicles in safe 146 driving, and possibly make these real vehicles to make wrong maneuver 147 decisions, leading to fatalities. 149 A malicious vehicle can also create multiple virtual bogus vehicles, 150 and generate global IPv6 addresses and register them with a Mobility 151 Anchor (MA) via an RSU. This IP address autoconfiguration and 152 registration procedure from many virtual vehicles can occupy the 153 computation power and storage resources of a RSU and an MA and even 154 paralyze the two entities. Thus, the RSU and MA need to determine 155 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 To detect and mitigate this DoS attack, the vehicles need to 179 collaborate with each other to monitor a suspicious activity related 180 to the DoS attack, that is, the generation of messages more than the 181 expected threshold in a certain service. 183 3.4. Message Suspension Attack 185 Malicious vehicles can drop packets originated by other vehicles in 186 multihop V2V or V2I communications, which is called a Message 187 Suspension Attack. This packet dropping can hinder the data exchange 188 for safe driving in cooperative driving environments. Also, in 189 multihop V2V or V2I communications, this packet dropping can 190 interfere with the reliable data forwarding among the communicating 191 entities (e.g., vehicle, client, and server). 193 For the reliable data transfer, a vehicle performing the message 194 suspension attack needs to be detected by good vehicles and a good 195 RSU, and it should be excluded in vehicular communications. 197 3.5. Tampering Attack 199 An authorized and legitimate vehicle may be compromised by a hacker 200 so that it can run a malicious firmware or software (malware), which 201 is called a tampering attack. This tampering attack may endanger the 202 vehicle's computing system, steal the vehicle's information, and 203 track the vehicle. Also, such a malware can generate bogus data 204 traffic for DoS attack against other vehicles, and track other 205 vehicles, and collect other vehicles' information. 207 The forgery of firmware or software in a vehicle needs to be 208 protected against hackers. The forgery prevention of firmware such 209 as the bootloader of a vehicle's computing system can be performed by 210 a secure booting scheme. The safe update of the firmware can be 211 performed by a secure firmware update protocol. The abnormal 212 behaviors by the forgery of firmware or software can be monitored by 213 a remote attestation scheme. 215 3.6. Tracking 217 The MAC address and IPv6 address of a vehicle's wireless interface 218 can be used as an identifier. An hacker can track a moving vehicle 219 by collecting and tracing the data traffic related to the MAC address 220 or IPv6 address. 222 To avoid the illegal tracking by a hacker, the MAC address and IPv6 223 address of a vehicle need to be periodically updated. However, the 224 change of those addresses needs to minimize the impact of ongoing 225 sessions on performance. 227 4. Security Countermeasures 229 This section proposes countermeasures against the attacks of security 230 and privacy in IP-based vehicular networks. 232 4.1. Identification and Authentication 234 Good vehicles are ones having valid certificates (e.g., X.509 235 certificate), which can be validated by an authentication method 236 through an authentication server [RFC5280]. 238 Along with an X.509 certificate, a Vehicle Identification Number 239 (VIN) can be used as a vehicle's identifier to efficiently 240 authenticate the vehicle and its driver through a road infrastructure 241 node (e.g., RSU and MA), which is connected to an authentication 242 server in vehicular cloud. X.509 certificates can be used as 243 Transport Layer Security (TLS) certificates for the mutual 244 authentication of a TCP connection between two vehicles or between a 245 vehicle and a corresponding node (e.g., client and server) in the 246 Internet. 248 Good vehicles can also use a Decentralized Identifier (DID) with the 249 help of a verifiable claim service. In this case, vehicles can their 250 DID as a unique identifier, and then check the identity of any 251 joining vehicle with its verifiable claim. 253 4.2. Integrity and Confidentiality 255 For secure V2I or V2V communications, a secure channel between two 256 communicating entities (e.g., vehicle, RSU, client, and server) needs 257 to be used to check the integrity of packets exchanged between them 258 and support their confidentiality. For this secure channel, a pair 259 of session keys between two entities (e.g., vehicle, RSU, MA, client, 260 and server) needs to be set up. 262 For the establishment of the session keys in V2V or V2I 263 communications, an Internet Key Exchange Protocol version 2 (IKEv2) 264 can be used [RFC7296]. Also, for the session key generation, either 265 an RSU or an MA can play a role of a Software-Defined Networking 266 (SDN) Controller to make a pair of session keys and other session 267 parameters (e.g., a hash algorithm and an encryption algorithm) 268 between two communicating entities in vehicular networks 269 [ID-SDN-IPsec]. 271 4.3. Non-Repudiation 273 A malicious vehicle can disseminate bogus messages to its neighboring 274 vehicles as a Sybil attack. This Sybil attack announces wrong 275 information of a vehicle's existence and mobility information to 276 normal vehicles. This may cause accidents (e.g., vehicle collision 277 and pedestrian damage). In the case of the occurrence of an 278 accident, it is important to localize and identify the criminal 279 vehicle with a non-repudiation method through the logged data during 280 the navigation of vehicles. 282 For non-repudiation, the messages generated by a vehicle can be 283 logged by its neighboring vehicles. As an effective non-repudiation, 284 a blockchain technology can be used. Each message can be treated as 285 a transaction and the adjacent vehicles can play a role of peers in 286 consensus methods such as Proof of Work (PoW) and Proof of Stake 287 (PoS) [Bitcoin]. 289 4.4. Remote Attestation 291 To prevent a tampering attack by the forgery of firmware/software, a 292 secure booting can be performed by Root of Trust (RoT) and a remote 293 attestation can be performed through both the secure booting and RoT 294 [ID-NSF-Remote-Attestation][ID-Remote-Attestation-Arch]. 296 The secure booting can make sure that the bootloader of the vehicle's 297 computing system is a legitimate one with the digital signature of 298 the boofloader by using the RoT of Trusted Platform Module (TPM) 299 [ISO-IEC-TPM] or Google Titan Chip [Google-Titan-Chip]. 301 A firmware update service can be made in blockchain technologies 302 [Vehicular-BlockChain]. The validity of a brand-new firmware can be 303 proven by a blockchain of the firmware, having the version history. 304 Thus, This blockchain can manage a brand-new firmware or software and 305 distribute it in a secure way. 307 The remote attestation can monitor the behaviors of the vehicle's 308 computing system such that the system is working correctly according 309 to the policy and configuration of an administrator or user 310 [ID-NSF-Remote-Attestation][ID-Remote-Attestation-Arch]. For this 311 remote attestation, a secure channel should be established between a 312 verifier and a vehicle. 314 4.5. Privacy 316 To avoid the tracking of a vehicle with its MAC address, a MAC 317 address pseudonym can be used, which updates the MAC address 318 periodically. This update triggers the update of the vehicle's IPv6 319 address because the IPv6 address of a network interface is generated 320 with the interface's MAC address. The MAC address and IPv6 address 321 can be updated by the guideline in [RFC4086] and a method in 322 [RFC4941], respectively. 324 The update of the MAC address and the IPv6 address affects the on- 325 going traffic flow because the source node or destination node of the 326 packets of the flow are identified with the node's MAC address and 327 IPv6 address. This update on a vehicle requires the update of the 328 neighbor caches of the vehicle's neighboring vehicles for multihop 329 V2V communications, as well as the neighbor caches of the vehicle's 330 neighboring vehicles and the neighbor tables of an RSU, and an MA in 331 multihop V2I communications. 333 Without strong confidentiality, the update of the MAC address and 334 IPv6 address can be observed by an adversary, so there is no privacy 335 benefit in tracking prevention. The update needs to be notified to 336 only the trustworthy vehicles, RSU, and MA. 338 Also, for the continuity of an end-to-end (E2E) transport-layer 339 (e.g., TCP, UDP, and SCTP) session, the new IP address for the 340 transport-layer session can be notified to an appropriate end point 341 through a mobility management scheme such as Mobile IP Protocols 342 (e.g., Mobile IPv6 (MIPv6) [RFC6275] and Proxy MIPv6 (PMIPv6) 343 [RFC5213]). This mobility management overhead and impact of 344 pseudonyms should be minimized on the performance of vehicular 345 networking. 347 5. Security Considerations 349 This document discussed security considerations for IPWAVE security 350 and privacy in Section 3 and Section 4. 352 6. Acknowledgments 354 This work was supported by Institute of Information & Communications 355 Technology Planning & Evaluation (IITP) grant funded by the Ministry 356 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 357 Security Intelligence Technology Development for the Customized 358 Security Service Provisioning). 360 This work was supported in part by the MSIT under the Information 361 Technology Research Center (ITRC) support program (IITP- 362 2020-2017-0-01633) supervised by the IITP. 364 7. References 366 7.1. Normative References 368 [ID-IPWAVE-PS] 369 Jeong, J., "IPv6 Wireless Access in Vehicular Environments 370 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 371 ipwave-vehicular-networking-19 (work in progress), July 372 2020. 374 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 375 "Randomness Requirements for Security", RFC 4086, June 376 2005. 378 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 379 Extensions for Stateless Address Autoconfiguration in 380 IPv6", RFC 4941, September 2007. 382 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 383 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 384 RFC 5213, August 2008. 386 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 387 Housley, R., and W. Polk, "Internet X.509 Public Key 388 Infrastructure Certificate and Certificate Revocation List 389 (CRL) Profile", RFC 5280, May 2008. 391 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 392 Support in IPv6", RFC 6275, July 2011. 394 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 395 Kivinen, "Internet Key Exchange Protocol Version 2 396 (IKEv2)", RFC 7296, October 2014. 398 [RFC8691] Benamar, N., Haerri, J., Lee, J., and T. Ernst, "Basic 399 Support for IPv6 Networks Operating Outside the Context of 400 a Basic Service Set over IEEE Std 802.11", RFC 8691, 401 December 2019. 403 7.2. Informative References 405 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 406 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 408 [DSRC] ASTM International, "Standard Specification for 409 Telecommunications and Information Exchange Between 410 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 411 Range Communications (DSRC) Medium Access Control (MAC) 412 and Physical Layer (PHY) Specifications", 413 ASTM E2213-03(2010), October 2010. 415 [Google-Titan-Chip] 416 Google, "Titan in depth: Security in plaintext", URL: 417 https://cloud.google.com/blog/products/gcp/titan-in-depth- 418 security-in-plaintext, October 2018. 420 [ID-NSF-Remote-Attestation] 421 Pastor, A., Lopez, D., and A. Shaw, "Remote Attestation 422 Procedures for Network Security Functions (NSFs) through 423 the I2NSF Security Controller", draft-pastor-i2nsf-nsf- 424 remote-attestation-07 (work in progress), February 2019. 426 [ID-Remote-Attestation-Arch] 427 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 428 W. Pan, "Remote Attestation Procedures Architecture", 429 draft-ietf-rats-architecture-02 (work in progress), March 430 2020. 432 [ID-SDN-IPsec] 433 Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 434 Garcia, "Software-Defined Networking (SDN)-based IPsec 435 Flow Protection", draft-ietf-i2nsf-sdn-ipsec-flow- 436 protection-07 (work in progress), August 2019. 438 [IEEE-802.11-OCB] 439 "Part 11: Wireless LAN Medium Access Control (MAC) and 440 Physical Layer (PHY) Specifications", IEEE Std 441 802.11-2016, December 2016. 443 [ISO-IEC-TPM] 444 ISO/IEC JTC 1, "Information technology - Trusted Platform 445 Module - Part 1: Overview", ISO/IEC 11889-1:2015, August 446 2015. 448 [ISO-ITS-IPv6] 449 ISO/TC 204, "Intelligent Transport Systems - 450 Communications Access for Land Mobiles (CALM) - IPv6 451 Networking", ISO 21210:2012, June 2012. 453 [Vehicular-BlockChain] 454 Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, 455 "BlockChain: A Distributed Solution to Automotive Security 456 and Privacy", IEEE Communications Magazine, Vol. 55, No. 457 12, December 2017. 459 [WAVE-1609.0] 460 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 461 in Vehicular Environments (WAVE) - Architecture", IEEE Std 462 1609.0-2013, March 2014. 464 Appendix A. Changes from draft-jeong-ipwave-security-privacy-01 466 The following changes are made from draft-jeong-ipwave-security- 467 privacy-01: 469 o This version has a submission date update to maintain the active 470 status of the draft. 472 o This version updates the version numbers of the referenced drafts. 474 o In Section 3.1, the paragraphs are updated to more clearly explain 475 the false information attack. 477 o In Section 3.3, the 2nd paragraph is deleted for a better 478 presentation. 480 o In Section 3.4, the "multi-hop" is changed to "multihop" for 481 consistency. 483 o In Section 4.3, the "sybil attack" is changed to "Sybil attack" 484 for consistency. 486 Authors' Addresses 488 Jaehoon (Paul) Jeong (editor) 489 Department of Computer Science and Engineering 490 Sungkyunkwan University 491 2066 Seobu-Ro, Jangan-Gu 492 Suwon, Gyeonggi-Do 16419 493 Republic of Korea 495 Phone: +82 31 299 4957 496 Fax: +82 31 290 7996 497 EMail: pauljeong@skku.edu 498 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 500 Yiwen (Chris) Shen 501 Department of Computer Science and Engineering 502 Sungkyunkwan University 503 2066 Seobu-Ro, Jangan-Gu 504 Suwon, Gyeonggi-Do 16419 505 Republic of Korea 507 Phone: +82 31 299 4106 508 Fax: +82 31 290 7996 509 EMail: chrisshen@skku.edu 510 URI: http://iotlab.skku.edu/people-chris-shen.php 511 Jung-Soo Park 512 Electronics and Telecommunications Research Institute 513 218 Gajeong-Ro, Yuseong-Gu 514 Daejeon 34129 515 Republic of Korea 517 Phone: +82 42 860 6514 518 EMail: pjs@etri.re.kr