Re: [ipwave] Review of https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14

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

Hi Nancy,
I sincerely appreciate your super good comments.
Most of your comments seem to be useful to improve our IPWAVE PS draft.
I will try to reflect your comments and questions on the revision.

Thanks.

Best Regards,
Paul

On Tue, Apr 21, 2020 at 9:58 AM Nancy Cam-Winget (ncamwing) <ncamwing=
[e-mail]> wrote:

> Hi,
>
> I have reviewed
> https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14 and
> have quite a few comments.
>
> Most of them relate to whether this document is meant to lay out
> challenges of using current IPv6 standards+extensions
>
> In vehicular networks only, or if requirements are to be listed.  The
> abstract and intro elude to requirements, but I didn’t
>
> see these listed out or if they did, they were not placed in any
> consistent way….
>
>
>
> Terminology:
>
> V2D vs. V2P: it would be good to better classify the “device” as IoT
> device types are many similarly for “person”.  Of interest here, especially
> for security and privacy considerations, is a device a M2M device or is it
> one where one can expect to be driven by a human (e.g. mobile phone).  I am
> presuming it is the former as you have V2P and I’m not sure the intent is
> that the vehicle communicates directly to a human but rather to a device
> that is being controlled by a human.
>
>
>
> There is a typo in “Edge Network (EN) : In” the “In” should be EN.
>
>
>
> Section 3:
>
> This sentence is awkward:
>
> “Thus, the IPv6
>
>    for these use cases should be extended for vehicular IPv6 such that
>
>    the IPv6 can support the functions of the network layer protocol such
>
>    as Vehicular Neighbor Discovery (VND), Vehicular Mobility Management
>
>    (VMM), and Vehicular Security and Privacy (VSP) in vehicular
>
>    networks.”
>
> I think the intent is for this document to describe the motivation for why
> IPv6 and its protocols need to be extended  in order to support “vehicular
> networks”.  I would suggest reworking this paragraph and the next to
> something like:
>
> “The use cases presented in this section serve as the description and
> motivation for the need to extend IPv6 and its protocols to facilitate
> ‘vehicular IPv6’. Section 5 summarizes the overall problem statement and
> IPv6 requirements.”
>
>
>
> Section 3.1
>
> ·         “ navigation for driving safety” :  should that be “safely” or
> “for providing driving safety plans”?
>
>
>
> The 2nd paragraph of this section doesn’t provide a rationale for why
> IPv6 needs to support single-hop or multi-hop in a wireless medium.  The
> wireless hops are controlled at the link not MAC layer (e.g. IPv6).  There
> is more clarification or description that better highlights why IPv6 (as a
> dependency with the link layer?) is relevant.
>
>    - While these use cases are relevant, the descriptions merely describe
>    the uses for the application layer signaling.  I presume that for
>    efficiency and expediency (e.g. to deal with minimal latency), the services
>    for establishing neighbors in a V2V topology it is best done at the IPv6
>    layer, vs. the 802.11p layer?  But that is not really well described or
>    clarified other than “Since IP is widely used among various computing
>    devices in the Internet, it is expected that the use cases in this section
>    need to work on top of IPv6 as the network layer protocol.” In the
>    beginning of this full section.  More motivation at the beginning of the
>    section for why it has to be at IPv6 layer should help to address the
>    neighbor discovery, but also a better description for why the security
>    scope for these scenarios will help provide the reasoning for why security
>    extensions in IPv6 are needed.
>
>
>
> Section 3.2 and 3.3
>
> ·         Similar to Section 3.1 a better explanation for why the
> “multi-hop” is required at IPv6 vs. at the link layer.  Some mesh networks
> establish the hops at the link layer….then there’s RPL (RFC 6550) that
> speaks to constrained connected entities needing to establish
> connectivity.  Their motivation is clear, while I’m not sure RPL can be
> used “as is”, their motivations seem similar so would expect to see some
> rationale for why the vehicular space is different than those listed in
> RFC6550 to help motivate the need for further work.
>
>
>
> Section 4.1
>
> Is the Traffic Control Center “all of the Vehicular Cloud” or is it meant
> to be 1 application or service in the cloud?  They way it is depicted, it
> equated TCC = Vehicle cloud but the description in this section “…(TCC) is
> connected to the Vehicular Cloud for the management of IP-RSUs and vehicles
> in the road network” infers that it is an application in the cloud used to
> manage the connections between IP-RSUs and vehicles, is that correct?
>
> Perhaps just use one of the terms (e.g. TCC) and define it as “TCC is a
> cloud application used to manage connections….”
>
>
>
> Section 5
>
> ·         There should be a space between “abovementioned”
>
> ·         I might argue that timing constraints for a session between 2
> vehicles or a moving vehicle to an IP-RSU would be in the same order of
> magnitude.  The presumption made, which should be made explicit, is that
> IP-RSU’s are geographically fixed and are not expected to move, where are
> vehicles are highly mobile.
>
> ·         I also believe the lifetime (or time-to-live) of a session
> should vary depending on the types of sessions being established, are there
> no considerations for these?
>
> ·         From the descriptions, I would tease out that the problem and
> challenges arise from: (1) highly mobile environments, to differentiate
> this from voice calls or cellular mobility, there are considerations to the
> packet delivery and to the session establishment  (2) the “units” (whether
> OBU or RSU) are highly constrained in cpu and memory (3) both the mobility
> and constrained environments should also bring in the considerations of the
> session lifetimes and key management used for these sessions.  If this is
> the case, I would prefer to see these requirements made more explicit.
>
> ·         But I am not seeing how these challenges provide a set of
> requirements.  A section that summarizes or turns these challenges to
> requirements would help; the alternative is to make these subsections
> crisper into the requirements needed to address the challenges or gaps
> presented in IPv6 of each section.
>
> Section 5.1
>
> ·         I am not sure what requirements or challenges the use cases are
> faced with to warrant IPv6 neighbor discovery.  Given the
> requirements/challenges I listed in a previous bullet, by the time you get
> a IPv6 ND packet and process it, that particular entity may be out of
> reach.  So, I think the problem or challenge faced here is that for these
> use cases, what is required is for a mechanism/protocol that allows for
> these nodes to securely advertise themselves (at the IP layer) with
> globally unique IPv6 addresses. I might counter that vehicle speed and
> density may be irrelevant if the goal for this requirement is to be able to
> get enough of the identity of the node you may want to connect to.  Having
> the long prose description of the problems is OK (although much of this I
> believe is also already in RFC 8691), but it is hard to determine what is
> actually needed to fulfil these use cases.
>
> Section 5.1.1
>
> ·         “wheh” should be “when”
>
> ·         Perhaps I’m being too literal, “…can have multiple links
> between pairs of vehicles with wireless communication range, as shown in
> Figure 4.”  I only see a single link between each vehicle pair?
>
>
>
> Section 6
>
> ·         Should this section follow the style of the “here are the
> requirements” that are not met in IPv6 security based on the challenges
> described? Or should this be more to provide the set of potential attacks
> that need to be addressed when considering the requirements (e.g. IPv6
> “vehicular” deployment scenarios)?  Neither come across strongly in this
> section.
>
> ·         2nd paragraph “ Vehicles and infrastructure must be authorized
> in order to participate in vehicular networking.” (e.g. must vs. need).
> Also, I see authorized, what about authenticated?  The receiver must have
> assurances that the information is authentic, perhaps using privacy
> preserving techniques.
>
> ·         The last sentence of the paragraph needs to be qualified; that
> is, as this is the security considerations section, there needs to be at
> minimum examples (not necessarily exhaustive) of the types of attacks
> possible.
>
> ·         Do vehicular networks need to provide confidentiality?  For
> privacy reasons, I think this is a hard requirement?  But there are some
> IEEE 1609 messages that are not encrypted?
>
> ·         3rd paragraph is somewhat confusing, I think it is trying to
> state: “Strong security measures against lying nodes are required.  As
> nodes communicate information that can be used by safety applications,
> protections to ensure the communication is authentic, protected from
> forgery and originates from an authorized node.” The “authorized node” will
> require special considerations given the nature of the highly transient
> connections.  I would argue that just because it is a valid certificate,
> does not make a vehicle “good”, but perhaps you are trying to state that
> the assessment of what makes a “good” or “trusted” vehicle is outside the
> scope of this charter?  Or is this meant to be a segue to the next
> paragraph, though that paragraph refutes using “valid certs” only.
>
> ·         I disagree that an unauthenticated VIN number is not sufficient
> to identify a car (note that there are instances in which VINs have changed
> when a vehicle’s engine, for instance, gets replaced).  Tighter
> requirements should be imposed as to when it is a Vehicle vs. a user on a
> device.  The draft describes a Vehicle as having its own network so it
> would seem that each element in that network should be authenticated….there
> needs to be a better description of this in the security section.  When
> describing a “Vehicle” are you identifying that network? A particular
> component of that network? A particular application in the host of the
> vehicle?  Authentication is strong requirement, both at the message,
> transport and entity level; these need to be distinctly called out.
>
> ·         Is the paragraph on pseudonym trying to assert that “In order
> to propagate the notion of pseudonym, the IPv6 address must also be updated
> periodically?”  This is the first paragraph where there is mention of a
> “long-living transport-layer session”.  The document should make clear the
> types of connections and their expected lifetimes….especially as it relates
> to pseudonyms and the expectation that an infrastructure (mobility case)
> would have to cache and manage these.
>
>
>
> Let me know if the comments need further elaboration or clarification.
>
>
>
> Warm regards, Nancy
>
>
>
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>