[ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-vehicular-networking-29: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Fri, 23 September 2022 16:04 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 4B809C1524DA; Fri, 23 Sep 2022 09:04:55 -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: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <166394909530.62950.16481124958317213050@ietfa.amsl.com>
Date: Fri, 23 Sep 2022 09:04:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/bnpfCL6Qa_RY_MBnFTWSQppPMdA>
Subject: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-vehicular-networking-29: (with DISCUSS and COMMENT)
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 23 Sep 2022 16:04:55 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-ipwave-vehicular-networking-29: 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: ---------------------------------------------------------------------- Thanks for all of the changes in -29 to address the DISCUSS points noted for -28. To help us talk these through the remaining issues, I have updated my ballot to remove issues that have already been resolved. I have also provided feedback on the new text in -29 intended to resolve the original DISCUSS points. (1) The Privacy Considerations are under-specified: (1.a) [per -28] 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? >From -29: 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 (such as IPv6 control messages including ND, DAD, NUD, and application layer messages) is necessary. In this way, a failure to prevent a cyberattack shall never happen on a vehicular network. Thus, we need to have an efficient zero-trust framework or mechanism for vehicular networks. I’m speculating that the second from last sentence, “[i]n this way, a failure to prevent a cyberattack shall never happen on a vehicular network” was added to partially respond to the above feedback. Saying that an attack will “never” success due to a zero-trust framework is not plausible. Could this please rephrased. (1.b) [per -28] 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? Thanks for adding the following text -29: The location information of a VRU from a smart device is multicasted only to the nearby vehicles. The true identifiers of a VRU's smartphone shall be protected, and only the type of the VRU, such as pedestrian, cyclist, and scooter, is disclosed to the nearby vehicles. To clarify, this “multicasted” in the IPv6 sense? The VRU’s smartphone is using some kind of “fake identifier” (source address?) to announce its presence so as not to reveal its “true identifier”? Is there a security consideration (attack) that these “fake identifiers” multicasting to nearby vehicles could convince that vehicle that they are surrounded by pedestrians (e.g., roughly https://www.abc.net.au/news/2020-02-04/man-creates-fake-traffic-jam-on-google-maps-by-carting-99-phones/11929136)? Can we state the security properties or provide a reference to handle this issue. I see the following text later in the section: 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. I don’t recognize the desired properties of protecting identifiers as being congruent with the above text. (2) 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. -- [per -28] Who are the parties in this verification protocol? What security properties is this verification providing? [new per -29] Thanks for adding this new text in -29 in response: To minimize this kind of risk, an augmented identification and verification protocol with extra means shall be implemented. These extra means can be certificate- based, biometric, credit-based, and one-time passcode (OTP) approaches in addition to a used approach [RFC8002]. The verification shall provide security properties such as confidentiality, integrity, authentication, authorization, and accounting [RFC7427]. I’m having trouble understanding this guidance. The architecture is suggesting “augmented identification and verification with extra means.” I don’t follow what “augmented means” or “extra” -- augmented or extra from what baseline? The security properties this provides is “confidentiality, integrity, authentication, authorization and accounting” don’t seem to match authentication and identity topics. To the specific examples, how does “credit-based” provide the stated security properties? I have the same question for the others. ** [per -28 and same for -29] 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. The explanation from the authors noted that the following text was added to Section 4.2 -29: “A malicious party can be a group of hackers, a criminal group, and a competitor for industrial espionage or sabotage.” “The verification shall provide security properties such as confidentiality, integrity, authentication, authorization, and accounting [RFC7427].” I’m having trouble understanding how this text addresses the safety properties. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Daniel Migault for the SECDIR review. Thanks for addressing the other COMMENTs in -29. ** Section 6.3. Per the proposed use of blockchain for "IPv6 transaction", thanks for making a few edits per the more granular feedback on -28. I leave it to the WG, but I think this guidance seems speculative, under-specified, and one of only a number of candidate architectures. It seems misplaced to be calling it out here.
- [ipwave] Roman Danyliw's Discuss on draft-ietf-ip… Roman Danyliw via Datatracker
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Erik Kline
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Mr. Jaehoon Paul Jeong
- Re: [ipwave] Roman Danyliw's Discuss on draft-iet… Mr. Jaehoon Paul Jeong