idnits 2.17.1 draft-jeong-ipwave-security-privacy-05.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (21 February 2022) is 794 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) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-25 ** Downref: Normative reference to an Informational draft: draft-ietf-ipwave-vehicular-networking (ref. 'I-D.ietf-ipwave-vehicular-networking') == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 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: 25 August 2022 J. Park 6 ETRI 7 21 February 2022 9 Basic Support for Security and Privacy in IP-Based Vehicular Networks 10 draft-jeong-ipwave-security-privacy-05 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 25 August 2022. 35 Copyright Notice 37 Copyright (c) 2022 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 (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Security Attacks . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. False Information Attack . . . . . . . . . . . . . . . . 4 55 3.2. Impersonation Attack . . . . . . . . . . . . . . . . . . 4 56 3.3. Denial-of-Service Attack . . . . . . . . . . . . . . . . 4 57 3.4. Message Suspension Attack . . . . . . . . . . . . . . . . 5 58 3.5. Tampering Attack . . . . . . . . . . . . . . . . . . . . 5 59 3.6. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Security Countermeasures . . . . . . . . . . . . . . . . . . 5 61 4.1. Identification and Authentication . . . . . . . . . . . . 6 62 4.2. Integrity and Confidentiality . . . . . . . . . . . . . . 6 63 4.3. Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. Remote Attestation . . . . . . . . . . . . . . . . . . . 7 65 4.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Changes from 72 draft-jeong-ipwave-security-privacy-04 . . . . . . . . . 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 [I-D.ietf-ipwave-vehicular-networking]. 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 [RFC9061]. 270 4.3. Non-Repudiation 272 A malicious vehicle can disseminate bogus messages to its neighboring 273 vehicles as a Sybil attack. This Sybil attack announces wrong 274 information of a vehicle's existence and mobility information to 275 normal vehicles. This may cause accidents (e.g., vehicle collision 276 and pedestrian damage). In the case of the occurrence of an 277 accident, it is important to localize and identify the criminal 278 vehicle with a non-repudiation method through the logged data during 279 the navigation of vehicles. 281 For non-repudiation, the messages generated by a vehicle can be 282 logged by its neighboring vehicles. As an effective non-repudiation, 283 a blockchain technology can be used. Each message can be treated as 284 a transaction and the adjacent vehicles can play a role of peers in 285 consensus methods such as Proof of Work (PoW) and Proof of Stake 286 (PoS) [Bitcoin]. 288 4.4. Remote Attestation 290 To prevent a tampering attack by the forgery of firmware/software, a 291 secure booting can be performed by Root of Trust (RoT) and a remote 292 attestation can be performed through both the secure booting and RoT 293 [I-D.pastor-i2nsf-nsf-remote-attestation][I-D.ietf-rats-architecture] 294 . 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 [I-D.past 310 or-i2nsf-nsf-remote-attestation][I-D.ietf-rats-architecture]. For 311 this remote attestation, a secure channel should be established 312 between a 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 the National Research Foundation of Korea 355 (NRF) grant funded by the Korea government, Ministry of Science and 356 ICT (MSIT) (No. 2020R1F1A1048263). 358 This work was supported by Institute of Information & Communications 359 Technology Planning & Evaluation (IITP) grant funded by the Ministry 360 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 361 Security Intelligence Technology Development for the Customized 362 Security Service Provisioning). 364 This work was supported in part by the MSIT under the Information 365 Technology Research Center (ITRC) support program (IITP- 366 2021-2017-0-01633) supervised by the IITP. 368 7. References 370 7.1. Normative References 372 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 373 "Randomness Requirements for Security", BCP 106, RFC 4086, 374 DOI 10.17487/RFC4086, June 2005, 375 . 377 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 378 Extensions for Stateless Address Autoconfiguration in 379 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 380 . 382 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 383 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 384 RFC 5213, DOI 10.17487/RFC5213, August 2008, 385 . 387 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 388 Housley, R., and W. Polk, "Internet X.509 Public Key 389 Infrastructure Certificate and Certificate Revocation List 390 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 391 . 393 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 394 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 395 2011, . 397 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 398 Kivinen, "Internet Key Exchange Protocol Version 2 399 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 400 2014, . 402 [RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic 403 Support for IPv6 Networks Operating Outside the Context of 404 a Basic Service Set over IEEE Std 802.11", RFC 8691, 405 DOI 10.17487/RFC8691, December 2019, 406 . 408 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- 409 Garcia, "A YANG Data Model for IPsec Flow Protection Based 410 on Software-Defined Networking (SDN)", RFC 9061, 411 DOI 10.17487/RFC9061, July 2021, 412 . 414 [I-D.ietf-ipwave-vehicular-networking] 415 (editor), J. (. J., "IPv6 Wireless Access in Vehicular 416 Environments (IPWAVE): Problem Statement and Use Cases", 417 Work in Progress, Internet-Draft, draft-ietf-ipwave- 418 vehicular-networking-25, 13 February 2022, 419 . 422 7.2. Informative References 424 [I-D.pastor-i2nsf-nsf-remote-attestation] 425 Pastor, A., Lopez, D. R., and A. L. Shaw, "Remote 426 Attestation Procedures for Network Security Functions 427 (NSFs) through the I2NSF Security Controller", Work in 428 Progress, Internet-Draft, draft-pastor-i2nsf-nsf-remote- 429 attestation-07, 11 February 2019, 430 . 433 [I-D.ietf-rats-architecture] 434 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 435 W. Pan, "Remote Attestation Procedures Architecture", Work 436 in Progress, Internet-Draft, draft-ietf-rats-architecture- 437 15, 8 February 2022, . 440 [ISO-IEC-TPM] 441 ISO/IEC JTC 1, "Information technology - Trusted Platform 442 Module - Part 1: Overview", ISO/IEC 11889-1:2015, August 443 2015. 445 [Google-Titan-Chip] 446 Google, "Titan in depth: Security in plaintext", URL: 447 https://cloud.google.com/blog/products/gcp/titan-in-depth- 448 security-in-plaintext, October 2018. 450 [ISO-ITS-IPv6] 451 ISO/TC 204, "Intelligent Transport Systems - 452 Communications Access for Land Mobiles (CALM) - IPv6 453 Networking", ISO 21210:2012, June 2012. 455 [DSRC] ASTM International, "Standard Specification for 456 Telecommunications and Information Exchange Between 457 Roadside and Vehicle Systems - 5 GHz Band Dedicated Short 458 Range Communications (DSRC) Medium Access Control (MAC) 459 and Physical Layer (PHY) Specifications", 460 ASTM E2213-03(2010), October 2010. 462 [WAVE-1609.0] 463 IEEE 1609 Working Group, "IEEE Guide for Wireless Access 464 in Vehicular Environments (WAVE) - Architecture", IEEE Std 465 1609.0-2013, March 2014. 467 [IEEE-802.11-OCB] 468 "Part 11: Wireless LAN Medium Access Control (MAC) and 469 Physical Layer (PHY) Specifications", IEEE Std 470 802.11-2016, December 2016. 472 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 473 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 475 [Vehicular-BlockChain] 476 Dorri, A., Steger, M., Kanhere, S., and R. Jurdak, 477 "BlockChain: A Distributed Solution to Automotive Security 478 and Privacy", IEEE Communications Magazine, Vol. 55, No. 479 12, December 2017. 481 Appendix A. Changes from draft-jeong-ipwave-security-privacy-04 483 The following changes are made from draft-jeong-ipwave-security- 484 privacy-04: 486 * Several sentences are rephrased and one author's information is 487 also updated. 489 * This version has updated the references to synchronize with other 490 drafts. 492 Authors' Addresses 494 Jaehoon (Paul) Jeong (editor) 495 Department of Computer Science and Engineering 496 Sungkyunkwan University 497 2066 Seobu-Ro, Jangan-Gu 498 Suwon 499 Gyeonggi-Do 500 16419 501 Republic of Korea 502 Phone: +82 31 299 4957 503 Email: pauljeong@skku.edu 504 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 506 Yiwen (Chris) Shen 507 Department of Computer Science and Engineering 508 Sungkyunkwan University 509 2066 Seobu-Ro, Jangan-Gu 510 Suwon 511 Gyeonggi-Do 512 16419 513 Republic of Korea 514 Phone: +82 31 299 4106 515 Email: chrisshen@skku.edu 516 URI: https://chrisshen.github.io 517 Jung-Soo Park 518 Electronics and Telecommunications Research Institute 519 218 Gajeong-Ro, Yuseong-Gu 520 Daejeon 521 34129 522 Republic of Korea 523 Phone: +82 42 860 6514 524 Email: pjs@etri.re.kr