[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.