Re: [Pidloc] draft-kjsun-ipwave-id-loc-separation

<Dirk.von-Hugo@telekom.de> Thu, 18 April 2019 14:51 UTC

Return-Path: <Dirk.von-Hugo@telekom.de>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B45F12034D for <pidloc@ietfa.amsl.com>; Thu, 18 Apr 2019 07:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.29
X-Spam-Level:
X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 6eFaF8aYaTGO for <pidloc@ietfa.amsl.com>; Thu, 18 Apr 2019 07:51:49 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B6212034B for <pidloc@ietf.org>; Thu, 18 Apr 2019 07:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1555599108; x=1587135108; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qnF3xBmxEbZsnqdMemciyNWfXdUN2ZIw2ll9jinFTMU=; b=DAIwvYvXV/bVnW/qBmI0QMlTW5XpuAM6YnzYcYpnbUpQHF+/7GrWTMad 7mqWv9U1yJD3uNybFrShemjjBlOd2WqfxowRmBG9gTeCuscfAeqjr2w0T A/aMlHGwNcAAs72ms0INfjwM9DL5Ofy2Olm/i7n6hmOfgsPgDfLlmnD2Z W1ZeLwDhWlKZKNdHXQpjZVcwPi0zI30oT7dR5YIsnMB73its+tBXKevOx +D/DvogbAPsqhabH9GHqp0z/Hp8cSjd1ad4yJD5a7IjTtoyHRkwatVgrO NHgQdSRcMyoxxqThtsujQtgIhjrkynoZX89EDpdQWMYbMT0SWu2fO5Fvk w==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2019 16:51:46 +0200
X-IronPort-AV: E=Sophos;i="5.60,366,1549926000"; d="scan'208,217";a="520042196"
X-MGA-submission: =?us-ascii?q?MDFBaLUkHZnT2P5R2rbxcfrPJZZJcU/nGlgTd4?= =?us-ascii?q?J2Ptp3prWmg/KkxQFSdFWHlk3eVTtv+QHbqtGQv/Mo6MvzH+h3IP5JLy?= =?us-ascii?q?4m4jbaI41oN5KRIl82Z7xKjG6X67R0kr41Ygk97OX7dRSV8Nq3Plc+oQ?= =?us-ascii?q?+4ZvhEkYtX1fUobcnEYnf1Ug=3D=3D?=
Received: from he106143.emea1.cds.t-internal.com ([10.169.119.77]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 18 Apr 2019 16:51:46 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE106143.emea1.cds.t-internal.com (10.169.119.77) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 18 Apr 2019 16:51:46 +0200
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 18 Apr 2019 16:51:46 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 18 Apr 2019 16:51:46 +0200
Received: from LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE (10.158.146.19) by LEJPR01MB0923.DEUPRD01.PROD.OUTLOOK.DE (10.158.146.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Thu, 18 Apr 2019 14:51:45 +0000
Received: from LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE ([fe80::ad86:b935:c2e7:2174]) by LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE ([fe80::ad86:b935:c2e7:2174%6]) with mapi id 15.20.1792.022; Thu, 18 Apr 2019 14:51:45 +0000
From: <Dirk.von-Hugo@telekom.de>
To: <gomjae@dcn.ssu.ac.kr>, <sarikaya@ieee.org>, <pidloc@ietf.org>
Thread-Topic: draft-kjsun-ipwave-id-loc-separation
Thread-Index: AQHU6jXaaS+n0VP6QU6jTEaLowkz8qYtFXcAgBHPIACAAlxjAIAA1SUg
Date: Thu, 18 Apr 2019 14:51:45 +0000
Message-ID: <LEJPR01MB092191E3C65D54D2F51D3243D1260@LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE>
References: <CAC8QAcfwqm+SdTBPsWdySAPgG_ciobr-C8rGs1kkDaX7ksF1TA@mail.gmail.com> <f63918e6-0269-425a-8952-fc84358a4ac0@getmailbird.com> <FRXPR01MB0664EEB95219B5EF7CE07133D1240@FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE> <6450b384-9847-467c-bd76-af2ca5765f3e@getmailbird.com>
In-Reply-To: <6450b384-9847-467c-bd76-af2ca5765f3e@getmailbird.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ad3edd0-73e4-4e78-2900-08d6c40d608d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:LEJPR01MB0923;
x-ms-traffictypediagnostic: LEJPR01MB0923:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <LEJPR01MB092380640736D5747623E40BD1260@LEJPR01MB0923.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 0011612A55
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(346002)(396003)(136003)(189003)(199004)(51444003)(55016002)(75402003)(9686003)(6306002)(54896002)(236005)(68736007)(74482002)(54556002)(53936002)(476003)(486006)(2501003)(186003)(11346002)(446003)(33656002)(7696005)(52396003)(110136005)(97736004)(733005)(2906002)(3846002)(6116002)(316002)(790700001)(86362001)(102836004)(53546011)(2201001)(26005)(81156014)(81166006)(8936002)(8676002)(76176011)(229853002)(5660300002)(66066001)(93886005)(606006)(14454004)(966005)(478600001)(7736002)(256004)(71190400001)(71200400001)(14444005)(413944005)(72206003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0923; H:LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hZnd5Vk3UKhiq7I84DViFbsBQDFxCMfkTDW5TVqy69RfQKNIx7NFRLlsOdJlJfsfsWTt8ElNlGclQhOmvDMVrgPIGgRFpLb+EDTvA6XcWGJ8dQEVE0LZ0MC9MECreFkWm2nDu+Dj8RRePR0GpV9Gd/B4EvFdr2OtEmBYyWQ2CadwreZy1xLzBIJanLV48niolCxGoewO+Muo69Q/PC5+KMdl3CXBP/gaXxaMVGLLbHZx+Zj/M6cSwgcUsq6VdtIGmG+DiluN7SkXTWdi2+uZBdjubO3R4p1cm6YTgzDoa35zrzYy1Y7/vHmiF4IrmesInX4xK+Ed6LpkS6UH+a4UvDbKK6D4yvsHjrqOA7yn8Kah7fZorh81JOz0MZuVl41o7qrxCKzbMpm6g11NIP4mFUFP5i1Ho4epE5i1aRNr1tI=
Content-Type: multipart/alternative; boundary="_000_LEJPR01MB092191E3C65D54D2F51D3243D1260LEJPR01MB0921DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ad3edd0-73e4-4e78-2900-08d6c40d608d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 14:51:45.1865 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0923
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/RVhU-cqHzWpM-mpNJAPjmaoLjro>
Subject: Re: [Pidloc] draft-kjsun-ipwave-id-loc-separation
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2019 14:51:52 -0000

Dear KJ,

Thanks for further elaboration. I agree that here multiple communication parameters play a role and the typical short-term session between vehicles only temporary in reach of each other (except for specific use cases as e.g. platooning etc.) helps to leverage impact of ID change rate (per session) on performance.
It would be great to describe the plentitude of privacy aspects in vehicular communication as one of the interesting use cases in a separate draft. I hope we can ask you for support and contribution when we start such a document.
Thanks again!
Kind regards
Dirk

From: KJ SUN <gomjae@dcn.ssu.ac.kr>;
Sent: Donnerstag, 18. April 2019 04:02
To: von Hugo, Dirk <Dirk.von-Hugo@telekom.de>;; sarikaya@ieee.org; pidloc@ietf.org
Subject: RE: draft-kjsun-ipwave-id-loc-separation

Dirk,

In my opinion, in vehicular network, there may be some trade-offs. Even changing ID is good to prevent its movement privacy, but at the same time locator also will change very frequently when vehicle moves in very high speed, ID/Loc mapping change occurs many times, and finally it can impacts their communication performance. So we need to cosider this when we allow ID/Loc modificatio mechanism.

From other point of view, I think that permanent ID is not needed for vehicular network since that its communication characteristics. When V2I case, we can use other identifiers transparent from packet header to authenticated by its vendor application. And between third-party or V2V, it is enough to use temporary identifier. It may also help to enhance privacy.

I think it will be good to include use case but we need to more clarifications.

Thanks.

Regards,

KJ.

Kyoungjae Sun / K. J. SUN (Ph. D. Student)

Distributed Computing Network laboratory (DCN Lab)

School of Electronic Engineering, Soongsil Univ.

369 Sangdo-ro, Dongjak-gu, Seoul.

Tel. +82-2-814-0151

Mobile +82-10-3643-5627

Email gomaje@dcn.ssu.ac.kr<mailto:gomaje@dcn.ssu.ac.kr>

On 2019-04-16 오후 11:09:14, dirk.von-hugo@telekom.de<mailto:dirk.von-hugo@telekom.de> <dirk.von-hugo@telekom.de<mailto:dirk.von-hugo@telekom.de>> wrote:
Hi KJ,
thanks for your detailed information – and sorry for my delayed reply!
I agree that in the vehicular case it is not so much the (static) location privacy which could be exhibited, but a movement tracking privacy as mentioned also in Eriks draft https://www.ietf.org/archive/id/draft-nordmark-id-loc-privacy-00.txt.
Especially on highways with kind of predictable movement also a simple change of ID could  allow for derivation of a prior ID and mapping of all the modified ones – which may in the end even resolve the modification mechanism.
Do you think this is worth including in the planned use case based requirements analysis?
Thanks!
Kind regards
Dirk

From: KJ SUN <gomjae@dcn.ssu.ac.kr<mailto:gomjae@dcn.ssu.ac.kr>>
Sent: Freitag, 5. April 2019 08:01
To: sarikaya@ieee.org<mailto:sarikaya@ieee.org>; pidloc@ietf.org<mailto:pidloc@ietf.org>
Cc: von Hugo, Dirk <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>>
Subject: Re: draft-kjsun-ipwave-id-loc-separation

Hello Behcet,

Thanks for giving me opportunity to introduce my draft "Considerations for ID/Location Separation Protocols in IP-based Vehicular Networks"
https://datatracker.ietf.org/doc/draft-kjsun-ipwave-id-loc-separation/

Purpose of this draft is to analyze applicability of ID/LOC protocols into vehicular network discussed in IPWAVE WG.

I considered LISP and ILNP as candidates protocols, and make use case based on vehicular network architecture described in IPWAVE PS doc (draft-ietf-ipwave-vehicular-networking)

In the Gap Analysis, I tried to follow issues described in PS doc, for each issue I referred d related ietf docs as possible solution.

Privacy issues in IPWAVE environment are well-described in PS doc. In that draft, they mentioned that tracking prevention should be supported with not only E2E continuity but also confidentiality. In my opinion, ID/LOC protocol may solve this problem easier since that ID information is not strongly bound to its location.

Honestly, I still have no idea for that and privacy issues were out of my interests. So, pidloc work could be helpful to analyze privacy issue and make solution for that.

I will more read related privacy documents and try to figure out for vehicular network use case. All comments and co-operations are welcome.

Regards,

KJ


Kyoungjae Sun / K. J. SUN (Ph. D. Student)

Distributed Computing Network laboratory (DCN Lab)

School of Electronic Engineering, Soongsil Univ.

369 Sangdo-ro, Dongjak-gu, Seoul.

Tel. +82-2-814-0151

Mobile +82-10-3643-5627

Email gomaje@dcn.ssu.ac.kr<mailto:gomaje@dcn.ssu.ac.kr>

On 2019-04-04 오전 12:56:50, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:
Hello Gomjae,

Today, we had a Webex session with Dirk and discussed about your draft
draft-kjsun-ipwave-id-loc-separation



in this draft you introduced architectures for the use of IDLOC protocols in

vehicular networks.

We consider this one of the significant use cases in our pidloc activity.

We know you attended pidloc side meeting in Prague last week, thanks for that.



We would appreciate if you could introduce your draft to the list shortly in

your reply?



Also any ideas on the privacy issues that arise in the vehicular networking

from the use IDLOC protocols?



Regards,



Behcet & Dirk



________________________________
[Image removed by sender. Avast logo]<https://www.avast.com/antivirus>


이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다.
www.avast.com<https://www.avast.com/antivirus>