Minutes of the IPWAVE WG meeting at IETF 99 THURSDAY, July 20, 2017 1550-1750 Afternoon Session II, Athens/Barcelona Chairs: Russ Housley, Carlos J. Bernardos Minute takers: Danny Moses, Alex Petrescu, Jaehoon Paul Jeong Jabber scribe: Suresh Krishnan (SK), Behcet Sarikaya (BC) ------------------------------------------------------------------------ 15:50 Administrativia ............................................. 10 min Presenter: Chairs Russ Housley (RH): We need more reviews for the WG documents. OCB-Mode document will be under WGLC by the end of this September. Both Survey and Problem Statement documents should be reviewed by volunteers by the end of this September. Without reviews the document cannot advance. ------------------------------------------------------------------------ ** IPWAVE WG documents 16:00 Transmission of IPv6 Packets over IEEE 802.11 Networks in mode Outside the Context of a Basic Service Set (IPv6-over-80211ocb) 20 min Presenter: Alex Petrescu (AP) Draft: draft-ietf-ipwave-ipv6-over-80211ocb-03 AP presents, explaining minor textual issues in the revision. The goal is to be in WGLC by the end of September. This draft is about transmission of IPv6 packets over 802.11 OCB (Outside the Context of a Basic service set) networks. Issues from Chicago: - Minor text issues. - RSU - Road Side Unit. The draft has a definition of RSU since there were many discussions about RSUs, mainly regarding handoff between RSUs and RSU advertisement. Currently the draft does not include handoff and therefore there is no text regarding RSUs (other than the definition). As a result of previous comments, an RSU is defined to “may have additional wired or wireless links and may be an Internet router”. In other context they are not routers and must be disconnected from the Internet for security reasons. - There were some comments about the prohibition of using IPv6 on some IEEE 802.11OCB channels which are reserved for safety. New text about this prohibition. - Some misunderstanding about the term ‘interface’. The text clarifies the ‘interface’ is a networking interface card. Text added to clarify the use of several interfaces in a car and that one of them could be dedicated for non-IPv6 communication. - Text added to clarify more description regarding IEEE 802.11OCB packets. - Added a section of Address Mapping 0 Unicast - followed RFC4861. - One issue still on the table: Need to update references to all other related IEEE standards and to update the reference to most updated version of these specs. - Michel Wetterwald (MW): Need to revise additional references and make sure they are all up to date (ETSI, IEEE...) - AP: This draft is very important and is basis for trials and other work being done. The authors are requesting additional reviews of the document. * Sri Gundavelli (SG), Sandra Cespedes (SC) and Rahul Jahdav (RJ) volunteered to review. * RH: We plan to do WGLC by the end of this September. ------------------------------------------------------------------------ 16:20 Survey on IP-based Vehicular Networking for Intelligent Transportation Systems ........................................ 20 min Presenter: Jaehoon Paul Jeong (JJ) Draft: draft-ietf-ipwave-vehicular-networking-survey-00 JJ present the latest revision of the draft: - This is a report of a survey on IP-based vehicular networking for ITS. It is now a WG draft. It includes use cases for V2V and V2I. - The purpose is to monitor activities in academia and other SDOs regarding ITS. The assumptions for vehicular NWs: IEEE 802.11 serious OCB and Cellular links (#G, 4G and 5G). IPv6 is considered to be the network protocols, the RSUs are connected to the Internet and serve as AP to vehicles and the TCC (Traffic Control Center) is the central node for management. - Several topics are looked at: IP Address auto configuration, Vehicular NW architecture and routing, mobility management and security. - Some use cases: V2I - Navigation systems, Intersection management, Emergency NW system and Pedestrian protection. V2V – Driving safety systems, automated driving systems and vehicle-to-vehicle warning systems. - Summary and analysis (the appendix of the draft): Suitability of IPv6 over WAVE, need fast ND. The link is different for traditional IPv6 link. Plan to use ND over VANET. - With autonomous vehicles, navigation information can be shared. - Next steps: Include more papers and use cases. Include more SDOs related to automotive. Include taxonomy tables for each technology. - Authors will try WGLC in IETF 100. Carlos J. Bernardos (CB): Do we need the IPv6 link section? Can you sync with Alex? - AP: I will read it and then discuss and perhaps move it to the main document. Person from huawei (NONAME1): ND proxy section? included in 6lo. The authors can refer to 6lo work for the ND adaptation part for ND proxy. ------------------------------------------------------------------------ 16:40 Problem Statement for IP Wireless Access in Vehicular Environments ................................................ 20 min Presenter: Jaehoon Paul Jeong Draft: draft-ietf-ipwave-problem-statement-00 JJ presents the latest revision of the draft: - This is about merging drafts: draft-jeong-ipwave-v2i-problem-statement-00 and draft-petrescu-its-problem-03 into one draft. It is also a WG draft. - The objective of the draft is to specify the problem statement for IPv6-based V2I and V2V networking. The assumptions are similar to the previously presented survey. - The focus of this draft is on the one IP hop communication between vehicle and RSU or vehicle to vehicle. - The plan is now to expose the vehicle internal NW (CAN) to Internet (a subnet). - Vehicles may exchange navigation information among themselves to help avoid accidents. - Issues for IPv6 vehicular networking: * IPv6 addressing problem - local vs global addresses. Local addresses can be used for road networking and global addresses for general Internet services. * In vehicle addresses may be preconfigured or configured dynamically from a network that is deployed along the road. * Establishing a communication path between computers in different vehicles is a problem that needs resolving. * IP Prefix exchange should be performed. Need to consider SLAAC or DHCPv6. It looks like most people prefer the RA approach. * Another issue is host DNS configuration. * Another issue is IP mobility. Alternatives are MIP, PMIP or DMM. Parameter adjustment is required for high speed vehicles. * Another issue is: service discovery. Possible solutions: DNS-based service discovery, IPv6 ND extension for Prefix and Service discovery. There is additional info in the appendix. * Security and Privacy: We need fast and reliable authentication. We will use periodic changing of the IP and MAC address to prevent tracking. + SG:: How is the MAC exposed? In what scenario? Is the MAC address exposed to the outside NW? Not clear.. + JJ: Probably pseudo MAC address, no MAC address + AP: To answer the question - many packets expose MAC address (NS, RS, NA, RA). They are over the air between 2 cars, a car and RSU. Basically any one along the road with a laptop can listen and hear all these packets and MAC addresses. So they are exposed. + Seil Jeon (SJ): Are you talking about the traffic of vehicles or the users inside the vehicle as well. + JJ: Very good question. If the user is using a smartphone connected to internal WiFi, than users as well. + JJ: If users are also included, this has to be specified because MIP already has its own NW mobility solution, and PMIP also has prefix delegation for user inside. + SG: For the service point of view the identity of the car is truly about the egress device. There is no security relation to the inside devices only to the head unit which has a service relation. + Nancy Cam-Winget (NC): Rotation mac address do not resolve privacy. We should thinking about cars communicated with another car (or infrastructure), not head unit and not user. + NC: I’m trying to follow all this. I provided feedback in the 1609 that rotating MAC addresses does not really solve privacy. So why we believe rotating IP MAC address may provide privacy but to the question of the messaging here we have to be very careful in saying head-unit because of connotation. We should discuss a car communicating with another car and not speak about a head-unit. To the comment about users, I am not sure how humans come in the play, we are referring here to vehicle conversing with another vehicle or with an infrastructure - these are not humans, these are cars. + RH: If we didn’t change the IP address when we change the MAC address then any incremental privacy we are getting by changing the MAC address is lost. + SK: Adding to Russ, there is a human associated with the car who can be tracked by the car. So that’s why it is important not the tracking of the car. So this will break than link. + NC: So is an IP address tied to a human? A Different people might drive the same car, so no direct relationship between a car and a human. I have 5 cars and 4 drivers...With a public transport car (rental car)... + SK.: So, Nancy please send text to the authors. - NONAME2: On slide 15 you said that you can use the VIN as an authentication mechanism. You can get it by spoofing the CAN so it is not worth anything. Authentication is very important. - JJ: the ECU controller is somethign like a black box. And, the entertainment and navigation are somehow separated. - NONAME2: it takes more to than change the MAC address to get the privacy. - AP: The VIN can be taken from the CAN and from taking photos of the shield. - Dino Farinacci (DF): I don’t think we should be worried about MAC address tracking. We should worry about DoS attacks. - Brian Weis (BW): There is an IEEE 802 privacy document that is being worked on, I’ll send a reference. It takes a lot more than changing MAC address to get privacy. The reference is IEEE 802.1 Working Group, "DRAFT Recommended Practice for Privacy Considerations for IEEE 802 Technologies", Information at , 18 Mar 2017. - RH: IPsec and IKEv2 should consider the change of IP address and MAC address because this change may break the IPsec sessions. CB: Some problem statements (e.g., in ND section and IP mobility section) seem close to survey. Please make the text close to the problem statement. The level of detail in some sections is not enough. For example privacy has only a half a page. RH to BW: if the MAC and IP addresses are rotating, will ESP work? BW: This is a complication, but this could work. Need to add details. CB: We need reviewers for this draft. - MW, SG and RJ voluntereed to review. ------------------------------------------------------------------------