[ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-vehicular-networking-28: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 06 April 2022 03:17 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: its@ietf.org
Delivered-To: its@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E04243A07FE; Tue, 5 Apr 2022 20:17:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ipwave-vehicular-networking@ietf.org, ipwave-chairs@ietf.org, its@ietf.org, Carlos Bernardos <cjbc@it.uc3m.es>, cjbc@it.uc3m.es
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <164921506585.21160.14252794142493088937@ietfa.amsl.com>
Date: Tue, 05 Apr 2022 20:17:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/5x5gUg9u0bWbBTG17qHZmjB5-DA>
Subject: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-vehicular-networking-28: (with DISCUSS and COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2022 03:17:46 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-ipwave-vehicular-networking-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I had difficulty in understanding the bounds for the scope of the use cases and proposed architecture. At times I had trouble understanding what was an example of related work, and what was narrative formally describing the gaps in IPv6 for vehicular networking. In that spirit: ** The Privacy Considerations are under-specified: -- Section 6.3 suggests the needs for logging, “To deal with this kind of security issue, for monitoring suspicious behaviors, vehicles' communication activities can be recorded in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) along with other vehicles or infrastructure. To solve the issue ultimately, we need a solution where, without privacy breakage, …”. Some discussion on the “privacy breakage” is needed. What exactly would be the trade offs between a centralized vs. distributed log? Who would get to see this information? What is sensitive about this information? -- Section 5.1.2 and 6.3 highlights the use of MAC address pseudonyms. This is helpful. More discussion is needed about the associate privacy threat being mitigated. Section 6.3 mentions an “adversary from tracking a vehicle” which I think means a passive observer of the path. However, there are other entities in which ecosystem – what is the privacy exposure to the TCC, V2I, etc? The opening in Section 6 notes that “vehicles and infrastructure must be authenticated” and those credentials (perhaps bound to even MAC pseudonyms) would also facilitate tracking even given MAC pseudonyms. Section 6.1 explicit comments on using VINs in certificates. Who are the assumed trusted actors? -- Section 3.3 notes a V2P use case where the pedestrian’s smart-phone is sharing unspecified information. Does that include location information? Who gets it? What kind of identifiers are shared? ** Section 4.2 Note that it is dangerous if the internal network of a vehicle is controlled by a malicious party. To minimize this kind of risk, an reinforced identification and verification protocol shall be implemented. -- What are these dangers? -- What is a ‘reinforced identification’? -- Who are the parties in this verification protocol? What security properties is this verification providing? ** Section 6. Vehicles and infrastructure must be authenticated in order to participate in vehicular networking. Authenticated with respect to whom? Vehicles to infrastructure and vice-versa? Or to someone else? ** Section 6 makes references to “secure communication” – what is the expected key management approach and is that in scope? ** The need for safety properties (very helpful) is asserted multiple times but not further discussed in the Security Considerations: -- Section 3: In addition, IPv6 security needs to be extended to support those V2V use cases in a safe, secure, privacy-preserving way. -- Section 3.1: To support applications of these V2V use cases, the required functions of IPv6 include IPv6-based packet exchange and secure, safe communication between two vehicles. -- Section 3.3: To support applications of these V2X use cases, the required functions of IPv6 include IPv6-based packet exchange, transport-layer session continuity, and secure, safe communication between a vehicle and a pedestrian either directly or indirectly via an IP-RSU. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Daniel Migault for the SECDIR review. ** Section 1. Editorial Vehicular networking studies have mainly focused on improving safety and efficiency, and also enabling entertainment in vehicular networks. This first sentence is unrelated to the reset of the paragraph which is focused on spectrum allocation. ** Section 1. Most countries and regions in the world have adopted the same frequency allocation for vehicular networks. This statement seems incongruent with the previous two sentences which describe how the US and EU have allocated very similar but not “same” spectrum (5.850 – 5.925 vs. 5.875 vs. 5.905). ** Section 2. Edge Computing is defined but doesn’t seem to be used in the rest of the document beyond in ECD. Is it needed? ** Section 2. IP-OBU: "Internet Protocol On-Board Unit": An IP-OBU denotes a computer situated in a vehicle Is this “computer” the same as an ECD defined earlier in the section? ** Section 3.1. Editorial. These five techniques will be important elements for autonomous vehicles, which may be either terrestrial vehicles or UAM end systems. This sentence seems to suggest that all give techniques are relevant to both terrestrial and UAMs. As far as I can tell, the first three (1 – 3) are terrestrial related, the fourth is relevant to both terrestrial and UAM, and the fifth is UAM only. ** Section 3.1 To encourage more vehicles to participate in this cooperative environmental sensing, a reward system will be needed. Sensing activities of each vehicle need to be logged in either a central way through a logging server (e.g., TCC) in the vehicular cloud or a distributed way (e.g., blockchain [Bitcoin]) through other vehicles or infrastructure. In the case of a blockchain, each sensing message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin][Vehicular-BlockChain]. I’m struggling to link this proposed solution to stated uses case or gap-analysis for IPv6. Can the IPv6 enablers be described. ** Section 3.2. Typo? s/air firmware/over-the-air firmware/. If not a typo, what is an “air firmware/software update”? ** Section 3.2. Editorial? For this battery charging schedule, a UAM end system can communicate with an infrastructure node (e.g., IP-RSU) toward a cloud server via V2I communications. Is there is a missing word here. What does it mean to “... communicate with an infrastructure node … toward a cloud server” ** Section 4.2 It is reasonable to consider the interaction between the internal network and an external network within another vehicle or an EN. Can the intent of this be clarified? Isn’t something on the internal vehicle network talking to another vehicle the definition of V2V per Section 3.1? ** Section 4.2. Is there any expectation of any perimeter-based policy enforcement between this internal network and the edge network (e.g., firewall?). ** Section 4.3. Is there implicit trust between the platooning vehicles? Security impact if one becomes untrusted? ** Section 5. For safe driving, vehicles need to exchange application messages every 0.5 second [NHTSA-ACAS-Report] to let drivers take an action to avoid a dangerous situation (e.g., vehicle collision), so IPv6 protocol exchanges need to support this order of magnitude for application message exchanges. This is a helpful performance envelope. Can this be more tightly linked to IPv6? It seems like this kind of performance is related to the capabilities of the link layer to move the IPv6 packets fast enough. ** Section 5.1.1 For instance, some IPv6 protocols assume symmetry in the connectivity among neighboring interfaces [RFC6250]. RFC6250 (Section 3.1.1) seems to be saying the opposite of this sentence which is that symmetry can’t be assumed. What protocols are making this assumption? ** Section 5.1.2 However, the pseudonym handling is not implemented and tested yet for applications on IP-based vehicular networking. No issues. However, isn’t this true for all of the VIP and VND work (as in, it needs more testing)? ** Section 6. For the authentication in vehicular networks, vehicular cloud needs to support a kind of Public Key Infrastructure (PKI) in an efficient way. What does the qualifier of “a kind of” PKI mean? ** Section 6 Also, in-vehicle devices (e.g., ECU) and a driver/passenger's mobile devices (e.g., smartphone and tablet PC) in a vehicle need to communicate with other in-vehicle devices and another driver/passenger's mobile devices in another vehicle, or other servers behind an IP-RSU in a secure way. Is securing arbitrary communication between a smartphone-A in vehicle-1 and smartphone-B in vehicle-2 in scope? ** Section 6. Even though a vehicle is perfectly authenticated and legitimate, What does it mean for a vehicle to be legitimate? Authenticated to whom? ** Section 6 Note that when driver/passenger's mobile devices are connected to a vehicle's internal network, the vehicle may be more vulnerable to possible attacks from external networks. This doesn’t seem framed right. Why is it _more vulnerable_? More relative to what? I think the central idea is that like any network (e.g., public library, IETF conference network), the end-node assumes risk of its packets transiting a network it doesn’t control, and exposes itself to “local network/segment” attacks of any peer nodes on the network. ** Section 6.3 Alternatively, for completely secure vehicular networks, we shall embrace the concept of "zero-trust" for vehicles in which no vehicle is trustable and verifying every message is necessary. For doing so, we shall have an efficient zero-trust framework or mechanism for vehicular networks. -- What is a “completely secure vehicular network”? -- There seems to be an architecture mismatch in this aspirational zero trust architecture. How does the premise of “verifying every message” align with focus of this document being IPv6 protocol mechanisms. What is an “IPv6 message”? Is that a packet? It would seem to me that these messages would be application layer matters. ** Section 6.3 Each message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin] [Vehicular-BlockChain]. Same comment as for ZT -- what is an “IPv6 message” that could be put on a blockchain? ** Section 6.3 For the non-repudiation of the harmful activities of malicious nodes, a blockchain technology can be used [Bitcoin]. Each message from a vehicle can be treated as a transaction and the neighboring vehicles can play the role of peers in a consensus method of a blockchain [Bitcoin] [Vehicular-BlockChain]. For a blockchain's efficient consensus in vehicular networks having fast moving vehicles, a new consensus algorithm needs to be developed or an existing consensus algorithm needs to be enhanced. Given the architecture layout in Figures 1 – 5? Where does this block live? Who checks it? Under what circumstances? It isn’t clear how this architectural construct is linked a gap analysis of IPv6 for vehicular networking.
- [ipwave] Roman Danyliw's Discuss on draft-ietf-ip… Roman Danyliw via Datatracker