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

[Roman Danyliw via Datatracker <[e-mail]>]

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.