Subject: Re: [ipwave] Restructuring of the Problem Statement Document

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 2 Apr 2018 23:26:26 +0900

Hi AB, Sandra, Rex, and Dirk,
Thanks for your comments.

With your comments, I will revise the contents of the problem statement
document
this week and let you know the revised one this week.

Thanks.

Best Regards,
Paul

On Tue, Mar 27, 2018 at 1:08 AM, <[email-masked]> wrote:

> Dear all,
> regarding the mentioned 'other aspects/problems of interest/future scope'
> I think it would be worth to add a section for 5G / C-V2X (also revealed as
> an important technology) also with respect to interoperability and access
> heterogeneity (and since IEEE 802.11whatsoever may be widely seen as part
> of 5G access variants) and include it in the charter discussion.
> Thanks!
> Best Regards
> Dirk
>
> -----Original Message-----
> From: its [mailto:[email-masked]] On Behalf Of Rex Buddenberg
> Sent: Sonntag, 25. März 2018 22:46
> To: Sandra Céspedes <[email-masked]>; [email-masked]
> Subject: Re: [ipwave] Restructuring of the Problem Statement Document
>
> Agree with Sandra's observation.  Recommend specifically include multicast
> within the charter.
>
>
> On Fri, 2018-03-23 at 21:23 -0300, Sandra Céspedes wrote:
> >
> >
> > On 3/23/2018 5:55 PM, Abdussalam Baryun wrote:
> > >
> > >
> > > On Fri, Mar 23, 2018 at 11:50 AM, Mr. Jaehoon Paul Jeong <jaehoon..
> > > [email-masked]> wrote:
> > > > Hi IPWAVEers,
> > > > Here is a proposed restructuring of the Problem Statement
> > > > Document:
> > > > https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networkin
> > > > g-02
> > > >
> > > > Sri and I discussed the current structure of the document. We
> > > > thought the current document is too big with unnecessary content
> > > > (i.e., 52 pages).
> > > > We think we should reduce it to around 10 pages with concise
> > > > content with
> > > >
> > > even if it gets to 20p it can be ok,
> > >
> > > > key problems for our IPWAVE WG.
> > > > We come with the following structure with the revised title.
> > > >
> > > > ---------------------------------------------------------------
> > > > ---------------------------------------------
> > > > Title: IP Wireless Access in Vehicular Environments (IPWAVE):
> > > > Problem Statement and Use Cases
> > > >
> > > I prefer we start with use cases then problems, so title:
> > >
> > >  Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use
> > > Cases and Problem Statements
> > >
> > > >
> > > > Abstract
> > > > 1. Introduction
> > > > 2. Terminology
> > > >    //each item: at most 4 lines
> > > > 3. Use Cases: V2V, V2I, V2X
> > > > 4. Current Architectures and Protocols
> > > >  - General Problems: Latency, No security, No pseudonym handling,
> > > > No IP support, ...
> > > >
> > > why architecture in this draft, I suggest take this out, it is
> > > better in another draft, just focus on the aim an objectives of the
> > > draft, the architecture needs another draft so if we update in
> > > future we just update architecture or update use cases,
> > >
> > >
> > > > 5. Problem Exploration
> > > >  - IPv6 over IEEE 802.11-OCB
> > > >  - Neighbor Discovery
> > > >    . Link Model
> > > >    .. MAC Address Pseudonym
> > > >    . Prefix Dissemination/Exchange
> > > >    . Routing
> > > >  - Mobility Management
> > > >    . E2E Connectivity over V2I
> > > >  - Vehicle Identity Management
> > > >  - Multihop V2X
> > > >  - Service Discovery
> > > >  - Security and Privacy
> > > >  - Others
> > > >
> > > please make them as problem statements sections so 5.1, 5.2, .....
> > > also they need to cover our available charter only,
> >  During the meeting in London the suggestion was to consider not only
> > the current charter but also other aspects/problems of interest/future
> > scope for this group.
> > >
> > > >  6. Security Considerations
> > > > ---------------------------------------------------------------
> > > > ---------------------------------------------
> > > >
> > > > Please give us your comments on it.
> > > >
> > > > With the agreed content, we authors will move forward for the
> > > > documentation..
> > > >
> > > >
> > > thanks
> > >
> > > AB
> > >
> > >
> > > > Thanks.
> > > >
> > > > Best Regards,
> > > > Paul
> > > > --
> > > > ===========================
> > > > Mr. Jaehoon (Paul) Jeong, Ph.D.
> > > > Assistant 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.ph
> > > > p
> > > >
> > > > _______________________________________________
> > > > its mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/its
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > its mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/its
> >       Libre de virus. www.avast.com
> >  _______________________________________________
> > its mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant 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: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 9 Apr 2018 10:18:57 +0900

Hi IPWAVEers,
Here is the revised contents structure for our problem statement document,
based on the comments from AB, Sandra, Rex, and Dirk:

-----------------------------------------------------------------------------------------------
Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and
Problem Statement

Abstract
1. Introduction
2. Terminology
   (Note: each item has at most 4 lines.)
3. Use Cases
 3.1 V2V
 3.2 V2I
 3.3 V2X
4. Analysis for Current Protocols
 4.1 Current Protocols for Vehicular Networking
 4.2 General Problems
   . Latency
   . No Security
   . No Pseudonym Handling
   . No IP Support
5. Problem Exploration
 5.1 IPv6 over IEEE 802.11-OCB
 5.2 Neighbor Discovery
   . Link Model
   . MAC Address Pseudonym
   . Prefix Dissemination/Exchange
   . Routing
 5.3 Mobility Management
   . E2E Connectivity over V2I
 5.4 Vehicle Identity Management
 5.5 Multihop V2X
 5.6 Multicast
 5.7 DNS Naming Services and Service Discovery
 5.8 IPv6 over Cellular Networks
   . Cellular V2X (C-V2X) Using 4G-LTE
   . Cellular V2X (C-V2X) Using 5G
 5.9 Security and Privacy
 6. Security Considerations
-----------------------------------------------------------------------------------------------

If you don't have further comments, I will work for the revision of our
document
with the above contents along with the co-authors.

Thanks.

Best Regards,
Paul

On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

>> Agree with Sandra's observation.  Recommend specifically include
>> multicast within the charter.
>>
>>

---

From: John Kenney <[email-masked]>
Date: Mon, 9 Apr 2018 06:31:19 -0700

Hi Jaehoon,

Reading the contents outline, I could infer that IETF considers that a
"general problem" with "current protocols for vehicular networking" is that
there is "no security."  Is that a correct inference?

If yes, then I disagree. Current protocols clearly include security.

If my inference is incorrect, then I suggest the wording of the contents
outline be modified to avoid that impression.  I have the same comment
about the other "general problems".

Thanks,
John Kenney

On Sun, Apr 8, 2018 at 6:18 PM, Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases
> and Problem Statement
>
> Abstract
> 1. Introduction
> 2. Terminology
>>> regarding the mentioned 'other aspects/problems of interest/future
>>> scope' I think it would be worth to add a section for 5G / C-V2X (also
>>> revealed as an important technology) also with respect to interoperability
>>> and access heterogeneity (and since IEEE 802.11whatsoever may be widely
>>> seen as part of 5G access variants) and include it in the charter
>>> discussion.
>>> Thanks!
>>> Best Regards
>>> Dirk
>>>
>>> > > please make them as problem statements sections so 5.1, 5.2, ......

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: [email-masked]
Date: Mon, 9 Apr 2018 06:45:58 -0700

> 
> Reading the contents outline, I could infer that IETF considers that a "general problem" with "current protocols for vehicular networking" is that there is "no security."  Is that a correct inference?  
> 
> If my inference is incorrect, then I suggest the wording of the contents outline be modified to avoid that impression.  I have the same comment about the other "general problems”.

I think it would be more fair to say that what we’ve seen of security proposals break all things IP.

But it’s probably not worth worrying about the wording of the outline. I suggest we wait to see the text.

T

---

From: [email-masked]
Date: Mon, 9 Apr 2018 07:51:15 -0700

Again, I look forward to seeing the text.

The mechanisms that I’ve seen implement privacy by rotating the MAC address. AFAICT, that’s pretty much fatal to everything above it.

And I’ll be the first to stipulate that there is no security in IP anyway.  Partly because we can’t get people to deploy it.  ;-)

Tony

> On Apr 9, 2018, at 7:14 AM, Dick Roy <[email-masked]> wrote:
> 
> FYI, NOTHING about the current ITS security standards or their
> implementation "breaks anything IP"!  I have no idea where that thought came
> from, however it is simply wrong. 1609.2 is essentially "application level"
> security.  While nothing prevents lower layers from using those security
> services, there is NO implementation to date that does so, nor is there a
> good reason to do so.  
> 
> Perhaps the issue is with IPsec? That after all is network layer security:^)
> 
> RR
> 
> From: its [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, April 9, 2018 6:46 AM
> To: John Kenney
> Cc: Rex Buddenberg; [email-masked]; its; Sandra
> Cespedes; [email-masked]; Mr. Jaehoon Paul Jeong; Abdussalam
> Baryun
> outline be modified to avoid that impression.  I have the same comment about
> the other "general problems".
> 
> 
> I think it would be more fair to say that what we've seen of security
> proposals break all things IP.
> 
> But it's probably not worth worrying about the wording of the outline. I
> suggest we wait to see the text.
> 
> T
> 
>

---

From: [email-masked]
Date: Mon, 9 Apr 2018 08:41:13 -0700

> When sessions of any kind are established, tumbling of MAC addresses is
> either suspended, or the session terminates abruptly.  It's up to station
> management to decide which of the outcomes is optimal, then execute on that
> plan.  Generally, tumbling will be suspended until the session terminates
> normally, but that doesn't have to be the case!

What happens in the case of long-lived sessions?

Streaming comes to mind as a common case in point.

If tumbling is suspended, then privacy protection is effectively disabled. That seems problematic.  It tumbling isn’t suspended, then the phone rings with irate users saying the network doesn’t work.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Apr 2018 18:36:21 +0200

> there is "no security."  Is that a correct inference?

IMO we should agree on this, because IETF considers what we in this WG will
decide.

> If yes, then I disagree. Current protocols clearly include security.

I support that, thanks

> about the other "general problems".

I agree, so we are able to edit the draft. Please send your ideas and edits
to the draft so we discuss them,

AB

---

From: <[email-masked]>
Date: Mon, 9 Apr 2018 16:39:48 +0000

Hi all,
perhaps we should say: 'no optimum/efficient support' since for IP on application layer there is a lot of tunneling and encapsulation in between ...
Thanks!
Best Regards
Dirk

From: Dick Roy [mailto:[email-masked]]
Sent: Montag, 9. April 2018 16:38
To: 'Mr. Jaehoon Paul Jeong' <[email-masked]>; [email-masked]; 'Abdussalam Baryun' <[email-masked]>; 'Sandra Cespedes' <[email-masked]>; 'Rex Buddenberg' <[email-masked]>; von Hugo, Dirk <[email-masked]>
Cc: [email-masked]
Subject: RE: [ipwave] Restructuring of the Problem Statement Document

Also, where did the idea that there is currently no support for IP come from?  The current ITS standards and implementations all support IP(v^).

RR

________________________________
From: its [mailto:[email-masked]] On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Sunday, April 8, 2018 6:19 PM
To: [email-masked]<mailto:[email-masked]>; Abdussalam Baryun; Sandra Cespedes; Rex Buddenberg; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Mr. Jaehoon Paul Jeong
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Hi IPWAVEers,

-----------------------------------------------------------------------------------------------
Title: IP Wireless Access in Vehicular Environments (IPWAVE): Use Cases and Problem Statement

Abstract
1. Introduction
2. Terminology

If you don't have further comments, I will work for the revision of our document
with the above contents along with the co-authors.

Thanks.

Best Regards,
Paul

On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong <[email-masked]<mailto:[email-masked]>> wrote:
Hi AB, Sandra, Rex, and Dirk,
Thanks for your comments.

With your comments, I will revise the contents of the problem statement document
this week and let you know the revised one this week.

Thanks.

Best Regards,
Paul

On Tue, Mar 27, 2018 at 1:08 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
regarding the mentioned 'other aspects/problems of interest/future scope' I think it would be worth to add a section for 5G / C-V2X (also revealed as an important technology) also with respect to interoperability and access heterogeneity (and since IEEE 802.11whatsoever may be widely seen as part of 5G access variants) and include it in the charter discussion.
Thanks!
Best Regards
Dirk

-----Original Message-----
From: its [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. März 2018 22:46
To: Sandra Céspedes <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Agree with Sandra's observation.  Recommend specifically include multicast within the charter.

On Fri, 2018-03-23 at 21:23 -0300, Sandra Céspedes wrote:
> > [email-masked]<mailto:[email-masked]>> wrote:
> > > Hi IPWAVEers,
> > > Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]> Personal
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
>       Libre de virus. www.avast.com<http://www.avast.com>
> [email-masked]<mailto:[email-masked]>

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

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant 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>

--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant 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>

---

From: Rex Buddenberg <[email-masked]>
Date: Mon, 09 Apr 2018 11:26:16 -0700

Tony,

You're right -- Paul was just publishing an outline, not the text.
Secondly, you're right in that we have good security tools, but they're
not deployed/used.  I've advised myself hoarse about security nazis
busily (and arrogantly) solving the wrong problem...

To get constructive -- RR has things right:

The first problem is lack of a sorting model.  The short version is
that any security measures at layers 1-5 protect infrastructure.  Layer
6/7 security measures protect data ... and are infrastructure
independent and agnostic.  

The second problem is defining requirements.  IPSec is indeed layer 3
-- good for VPN tunnels.  That doesn't get security that's particularly
useful in the use case.  The discussion seems to mix security and
privacy without ever defining the terms.  Further, security usually
seems to mean confidentiality.  I share your dubiousness about MAC
address rotation -- convince me first that it doesn't make the message
security problem worse.
     The foundation security problem is authenticity of the data.
Therefore, _message signing_ is the first solution; anything else is
secondary.

b

On Mon, 2018-04-09 at 07:51 -0700, [email-masked] wrote:
> The mechanisms that I’ve seen implement privacy by rotating the MAC
> address. AFAICT, that’s pretty much fatal to everything above it.
> 
> And I’ll be the first to stipulate that there is no security in IP
> anyway.  Partly because we can’t get people to deploy it.  ;-)
> 
> Tony
> 
> 
> >

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 16 Apr 2018 22:28:42 +0900

Hi John,
I am sorry for late reply because I was busy with my university work.

You are right.
The current protocols for vehicular networking have some levels of security.
In this document, we will address what security aspects will be addressed
and investigated more.

Thanks.

Best Regards,
Paul

On Mon, Apr 9, 2018 at 10:31 PM, John Kenney <[email-masked]>
wrote:

> <https://maps.google.com/?q=465+Bernardo+Avenue+%0D%0A+Mountain+View,+CA+94043&entry=gmail&source=g>
> Mountain View, CA 94043
> <https://maps.google.com/?q=465+Bernardo+Avenue+%0D%0A+Mountain+View,+CA+94043&entry=gmail&source=g>

---

From: François Simon <[email-masked]>
Date: Wed, 18 Apr 2018 17:12:50 -0400

Comments in the e-mail text.  Fygs.

From: its <[email-masked]> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Sunday, April 08, 2018 9:19 PM
To: [email-masked]; Abdussalam Baryun <[email-masked]>; Sandra Cespedes <[email-masked]>; Rex Buddenberg <[email-masked]>; [email-masked]
Cc: [email-masked]; Mr. Jaehoon Paul Jeong <[email-masked]>
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

Hi IPWAVEers,

[Fygs: Actually, this re-structure of the IPWAVE document as per outline make more sense.  The “applications” (use cases) are being analyzed first and from the application requirements, a communication service is identified to meet the requirements (e.g.; IPv6 and OCB).].

Abstract

1. Introduction

2. Terminology

3. Use Cases

[Fygs: Is not really possible to cover all cases. Personally, I prefer logical and/or mathematical models as it permits analysis of most cases.]

 3.1 V2V

 3.2 V2I

 3.3 V2X

 4.2 General Problems

   . Latency [Fygs: This is not a “problem” but a fact in any system.]

   . No Security [Fygs: actually, Security is addressed in most current protocols]

   . No Pseudonym Handling

   . No IP Support [Fygs: This is not a really a general problem.]

5. Problem Exploration

 5.1 IPv6 over IEEE 802.11-OCB [Fygs: I do not think the purpose (applications) of the communication services offered by IPv6 and IEEE 802.11 – OCB has been seriously explored.]

 5.2 Neighbor Discovery [Fygs: Sorry about my ignorance on this subject.]

   . Link Model

   . MAC Address Pseudonym

   . Routing

 5.3 Mobility Management

 5.5 Multihop V2X

 5.6 Multicast

 5.8 IPv6 over Cellular Networks [Fygs: Originally, cellular and other communications services where to be addressed separately from IEEE 802.11-OCB.]

 5.9 Security and Privacy

Thanks.

Best Regards,

Paul

On Mon, Apr 2, 2018 at 11:26 PM, Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]> > wrote:

Thanks.

Best Regards,

Paul

On Tue, Mar 27, 2018 at 1:08 AM, <[email-masked] <mailto:[email-masked]> > wrote:

Dear all,

-----Original Message-----
From: its [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Rex Buddenberg
Sent: Sonntag, 25. März 2018 22:46
To: Sandra Céspedes <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] Restructuring of the Problem Statement Document

On Fri, 2018-03-23 at 21:23 -0300, Sandra Céspedes wrote:
> > [email-masked] <mailto:[email-masked]> > wrote:
> > > Hi IPWAVEers,
> > > Email: [email-masked] <mailto:[email-masked]> , [email-masked] <mailto:[email-masked]>  Personal
> > > [email-masked] <mailto:[email-masked]> 
> > [email-masked] <mailto:[email-masked]> 
>       Libre de virus. www.avast.com <http://www.avast.com> 
> [email-masked] <mailto:[email-masked]> 

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

-- 

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

-- 

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