Re: [ipwave] Roman Danyliw's Discuss on draft-ietf-ipwave-vehicular-networking-29: (with DISCUSS and COMMENT)

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Roman,
Here is the revision of IPWAVE PS Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-30

I attach the revision letter for your convenience.

If you have something to improve in this draft,
please let me know.

Thanks.

Best Regards,
Paul


On Sat, Sep 24, 2022 at 1:05 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> 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.
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>