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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 21 Apr 2020 00:58:11 +0000

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 22 Apr 2020 01:13:53 +0900

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=
[email-masked]> 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
>
> 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.
>
>
>
> 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
>
> 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
>
> ·         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
>
> ·         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.
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 30 Apr 2020 18:23:31 +0000

Hi Paul,
Happy to help if you have further questions.
Warm regards, Nancy

From: its <[email-masked]> on behalf of "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tuesday, April 21, 2020 at 9:14 AM
To: "Nancy Cam-Winget (ncamwing)" <ncamwing=[email-masked]>
Cc: skku-iotlab-members <[email-masked]>, "Mr. Jaehoon Paul Jeong" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ipwave] Review of https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-14

Hi Nancy,

Thanks.

Best Regards,
Paul

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

Terminology:

Section 3:

Section 3.1

•         “ navigation for driving safety” :  should that be “safely” or  “for providing driving safety plans”?

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

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.

Warm regards, Nancy

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php<http://cpslab.skku.edu/people-jaehoon-jeong.php>