Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-14.txt

YongJoon Joe <standard@yongjoon.net> Thu, 09 April 2020 06:18 UTC

Return-Path: <standard@yongjoon.net>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F433A0C28 for <its@ietfa.amsl.com>; Wed, 8 Apr 2020 23:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yongjoon.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK7LuHghaZqh for <its@ietfa.amsl.com>; Wed, 8 Apr 2020 23:18:45 -0700 (PDT)
Received: from sender4-of-o54.zoho.com (sender4-of-o54.zoho.com [136.143.188.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AE13A0C27 for <its@ietfa.amsl.com>; Wed, 8 Apr 2020 23:18:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1586413121; cv=none; d=zohomail.com; s=zohoarc; b=YFP4mXFlfVamnmhwqrthsjwSNCIcspvxmqwHZNCoIIEGx0SFVtRWSXjZ5eyKug1etU/gg/b14xrLuu8oZQ7A2RmwAWKzQx947anZkrX5Dceq59X0q5CxIKNVoPWYA0nI5ZnNOpZWI3rXVhUegaLo7hGNzZaNZ9e7AEFf1n1LpZc=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1586413121; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To; bh=RjVHe2vKPjErjS7nLxKjtrvXFJbUSkZ/PK571YvVmLc=; b=dTKn32AzToNXbA+gFhgS45fx/PK9kJZ7FcNDFm9+jkXNAfIwCYpbvp3Mm7W2gKr4pQeDmzItWbXQz6ypj3YwHUq70wCf40gqnKBzn3uoxbqc44+z4m5igschX03Wzrg4h+eoMJaUqGXlAR9jRhM/BNly4aA+TcIW3BducnqRuRI=
ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=yongjoon.net; spf=pass smtp.mailfrom=standard@yongjoon.net; dmarc=pass header.from=<standard@yongjoon.net> header.from=<standard@yongjoon.net>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1586413121; s=default; d=yongjoon.net; i=standard@yongjoon.net; h=Date:From:To:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=RjVHe2vKPjErjS7nLxKjtrvXFJbUSkZ/PK571YvVmLc=; b=PAxtRB4zHI5h6Ar6V0HQ3ZuEeKTGEw1l0NLvJpCR/ff7aGCv6yZZaJWUZe4zya7y J1QAA2g9hwu1ZPoWj43ZKSbdbW4euNRYsVug+dpemKUBLYVRNeQraoUkRkn1aQotBgc 6NIKqo3A7lqPrRPn7URxCvMiojS7HNKjZ4gYgODQ=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1586413113301309.171610278496; Wed, 8 Apr 2020 23:18:33 -0700 (PDT)
Date: Thu, 09 Apr 2020 15:18:33 +0900
From: YongJoon Joe <standard@yongjoon.net>
To: its <its@ietfa.amsl.com>
Message-ID: <1715d970fd3.ca4ae4c344727.5103462606282388911@yongjoon.net>
In-Reply-To:
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Importance: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/SmNowO1UrNGEsJ7fzgnxUtJxMos>
Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-14.txt
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 09 Apr 2020 06:18:47 -0000

Hello, 

I reviewed your revised draft, and here are my comments which focused on Section 6.


[Page 22]
(1)
>> "~~ need to communicate with other in-vehicle devices and mobile devices in another vehicle, [and -> and/or] other servers in an IP-RSU in a secure way."
When we do not have to connect to both in-vehicle devices and mobile devices, then 'and/or' is better than 'and'.

(2)
>> "Even a perfectly authorized and legitimate vehicle may be hacked to run malicious applications to track and collect its and other vehicles' information."
The whole sentence is enclosed in 'Even'. 'Even a vehicle is perfectly authorized and legitimate, the vehicle may be hacked' is better than 'Even ~ may be hacked'.
When a hacker's object is tracking and collecting and running malicious applications is only the method, 'for running malicious applications' is better than 'to run malicious application'.

(3)
>> "For safety applications, "
'For safety applications' could be shown as a security software as like as anti-virus.
'For application safety' seems to be proper for original intention.
(4)
>> "the cooperation among vehicles is assumed"
In general, the representation 'cooperation' seems to be no problem.
However, in the Game Theory field, the word 'cooperation' does not always mean only '(full and friendly) cooperation', but also '()'.
Of course, this document is not for economic/game theory.
However, who is working in the security area may tackle this representation.
When you want to represent this clearly, 'cooperative action' may be better.
(5)
>> "Malicious nodes may disseminate wrong driving information (e.g., location, speed, and direction) to make driving be unsafe."
As like my comment (2), making someone(or a vehicle) unsafe is not the object of a hacker but a means for the original purpose.
In this assumption, 'for disturbing safe drive' is proper than 'to make driving be unsafe'.
For example, a hacker would take a 'moderate' attack such as disseminating fake traffic info to neighbor vehicles to make other vehicles away from the front of the hacker by themselves.
This case would be fit for a Sybil attack. (This could occur frequently because this is not so harmful to the others too much)
Of course, this would be related to the path-finding algorithm and traffic-control algorithm.
In my lab, we have studied a mechanism design such as False-Name Proofness in game theory.

(6)
>> "This Sybil attack needs to be prevented through the cooperation between good vehicles and IP-RSUs. Note that good vehicles are ones with valid certificates that are determined by the authentication process with an authentication server in the vehicular cloud."
I'm not sure that the representation 'good vehicle' is a common terminology, and the sentence is too long.
How about 'This Sybil attack needs to be prevented through the cooperation between [good -> certified] vehicles and IP-RSUs. Note that vehicles would be certified by an authentication server in the vehicular cloud authenticate ????'


[Page 23]
(7)
>> "To identify the genuineness of vehicles against malicious vehicles, an authentication method is required."
I think 'To identify the genuineness of malicious vehicles', 'To identify a malicious vehicle from vehicles', or 'To identify the genuineness of malice from vehicles' seems to be better than the original form because of the expression 'genuineness'.
Because we could not genuine malice but false(bogus) identity by an authentication.
Of course, we could infer/decide a specific identity would be malice based on long-term observation.
But I don't think this representation wants to say such a thing.

I think authentication is a solution that is specialized for identifying false(bogus) identity to prevent Sybil attack, but not for the general solution against other malicious actions.

 >> A Vehicle Identification Number (VIN) and a user certificate along with an in-vehicle device's identifier generation can be used to efficiently authenticate a vehicle or a user through a road infrastructure node (e.g., IP-RSU) connected to an authentication server in the vehicular cloud. Also, Transport Layer Security (TLS) certificates can be used for vehicle authentication to allow secure E2E vehicle communications. To identify the genuineness of vehicles against malicious vehicles, an authentication method is required. For vehicle authentication, information available from a vehicle or a driver (e.g., Vehicle Identification Number (VIN) and Transport Layer Security (TLS) certificate [RFC8446]) needs to be used to efficiently authenticate a vehicle or a user with the help of a road infrastructure node (e.g., IP-RSU) connected to an authentication server in the vehicular cloud."

(8)
>> "Also, Transport Layer Security (TLS) certificates can be used for the vehicle authentication to allow secure E2E vehicle communications"
In my knowledge, TLS is not for authentication but for channel(communication) security.
Of course, during the TLS process, authentication by the certificate is performed.
If this representation intends to say about the authentication by certificate, then it should refer to PKI[RFC5280].

(9)
>> "A Vehicle Identification Number (VIN) and a user certificate along with an in-vehicle device's identifier generation can be used to efficiently authenticate a vehicle or a user through a road infrastructure node (e.g., IP-RSU) connected to an authentication server in the vehicular cloud."
In a driving environment, communication partners are changed frequently. (an IP-RSU would be a long-term communicating partner)
In such a circumstance, I have a question that TLS is really efficient.
Yes, when the vehicle wants to authenticate AND establish a secure channel at once, TLS seems to be only a solution presently.
But, any vehicles which are not driving in the same direction, there would not enough time for establishing the TLS channel.
(I'm not familiar with 5G and its hardware)

And, I have another question that PKI(or TLS certificate) is not enough solution against Sybil attack (using False identifier)
PKI could identify the bogus certificate.
However, when a hacker uses EXIST and VALID certificate(such as using certificates of the hacker's 2nd, 3rd, 4th car which is sleeping in his garage) for emitting fake information, PKI is not helpful because those certificates have no problem.

(10)
>> "For secure V2I communication, a secure channel between a mobile router ..."
I think TLS should be emphasized in this paragraph.

(11)
MAC address pseudonym needs to be provided to [the -> each] vehicle

(12)
>>" For the mobility management, a malicious vehicle can construct multiple virtual bogus vehicles, and register them with IP-RSUs and MA. This registration makes the IP-RSUs and MA waste their resources. The IP-RSUs and MA need to determine whether a vehicle is genuine or bogus in the mobility management. Also, the confidentiality of control packets and data packets among IP-RSUs and MA, the E2E paths (e.g., tunnels) need to be protected by secure communication channels. In addition, to prevent bogus IP-RSUs and MA from interfering IPv6 mobility of vehicles, the mutual authentication among them needs to be performed by certificates (e.g., TLS certificate)."

I think this paragraph should be following after the first paragraph of page 23 "To identify the genuineness ~~".


Typos:

Have to unify representation about
* 'one-hop' and 'one hop'
* 'multi-hop' and 'multihop'

Page #3
~~ to motivate [_ -> the] development of key protocols for IPWAVE.
A vehicle can make [_ -> a] safety plan by classifying
Page #6
'management' and 'security' is uncountable
VMM: It is [an -> _] IPv6-based mobility management for vehicular networks.
VSP: It is [an -> _] IPv6-based security and privacy for vehicular networks.
Page #7
an interactive way through V2V networking in order to avoid [_ -> a] collision.
Platooning can maximize the throughput of vehicular traffic in a highway and reduce [the -> _] gas consumption
Page #8
such as VND and VSP are [prerequisite -> prerequisites] for the IPv6-based packet exchange
Page #9
will be available for V2I and V2V in [_ -> the] near future.
are [prerequisite -> prerequisites] for the IPv6-based packet exchange
Page #16
Figure 3 shows [_ -> an] internetworking between the moving networks of two neighboring vehicles
Page #17
protocol exchanges need to be completed in a time relatively [small -> short] compared to the lifetime of a link between a vehicle
'support' is uncountable
It assumes [an -> _] efficient and reliable support
Page #18
****
The merging and partitioning of VANETs [occurs frequently -> frequently occurs] in vehicular networks
to [efficiently -> _ ] work to support IPv6-based safety applications [ _ -> efficiently].
Page #19
A VANET can have multiple links between pairs of vehicles within [_ -> the] wireless communication range,
for example, [wheh -> when] they are Vehicle1 and Vehicle3, as shown in Figure 4.
to directly communicate with each other via VANET rather than indirectly via IP-RSUs.
Page #20
to [directly -> _ ] communicate with each other via VANET rather than indirectly via IP-RSUs [ _ -> directly].
TCP [and and -> and] SCTP
Page #21
between to end points requires [an -> _] efficient mobility management
Most [of -> _] vehicles [are equipped with -> equip] a GPS receiver
the assistance [from -> of] the IP-RSUs or a cellular system
With a GPS navigator, [an -> _] efficient mobility management
for [the -> _] efficient mobility management
Page #22
The security and privacy [is one of -> are part of] key components

Maybe: 
Only authorized vehicles to need to be allowed to use the vehicular [networking -> networkings]
[For -> In] this case
the aftermath of [the -> _] malicious behaviors
For example, [_ -> a] Sybil attack, which tries to confuse a vehicle with multiple false identities, disturbs a vehicle in taking a safe maneuver.
This [sybil -> Sybil] attack
Page #23
to such a [sybil -> Sybil] attack,
a user certificate along with [_ -> an] in-vehicle device's identifier generation
Transport Layer Security (TLS) certificates can be used for [the -> _] vehicle authentication
Page #24
For [the -> _] mobility management
in [the -> _] mobility management
Page #29
The definition of Mobility Anchor (MA) is clarified with [a -> _] reference to PMIPv6.
with [the -> _] reference to