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

<Dirk.von-Hugo@telekom.de> Tue, 16 April 2019 15:43 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 69780120E9C for <pidloc@ietfa.amsl.com>; Tue, 16 Apr 2019 08:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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, URIBL_BLOCKED=0.001] 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 f-TMUlgdC6VJ for <pidloc@ietfa.amsl.com>; Tue, 16 Apr 2019 08:43:21 -0700 (PDT)
Received: from mailout21.telekom.de (mailout21.telekom.de [194.25.225.215]) (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 27CE9120AA4 for <pidloc@ietf.org>; Tue, 16 Apr 2019 07:09:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1555423759; x=1586959759; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WVlQiScNzPviKQyIzyevsQP3yoKFuMYe4N2kpM3VBP4=; b=bq+fcOEooe+8JdBZn+G4+TAOpwVMl3BUurbVkHaDTJQPu/JDDCH+f06S 1pC9FC33HI0PB/ZtNhbEQeqoKU5OE21KpI9IZOlJo/cG0FTgXn/a0Canb WTxP8wn8R7hBFRHQyb4WM7IXs8vVUYL92zduAI62nh/MDvBrpi3Gx8i9O k7Nfp2foc77beCqxdlWOfXDkeh/PCGUN3mMFKYdVWayYwqlU/0ptlEwKj amCz3Q1vh/fB2KFFbocqSzUB5WS7hMQcFRYZW7lY8q4xbjLFKoHBKQfkj XiUP+oBr241DoVrb0cg6PoUACbqf7UoLWoUJ4MMSPYoP2zDi9coUZGTuJ g==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2019 16:09:13 +0200
X-IronPort-AV: E=Sophos;i="5.60,358,1549926000"; d="jpg'145?scan'145,208,217,145";a="269355280"
X-MGA-submission: MDFObutWozRzTyXv/W/arh1ZeFoCvi0nIeIBfg9U2WrXAb1j97xTQOuXzpvXsEeGCE3Ope+6I9/i23C5fxvXm1xvSPCK6lhOnTnphUld2U9chVgA1RyQsx6UwyDWByvJYanvEkppCXsyCnOmk+OvJWfjJt36iLeZjCORKcdK5zZbIw==
Received: from he105709.emea1.cds.t-internal.com ([10.169.118.41]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 16 Apr 2019 16:09:13 +0200
Received: from HE101951.EMEA1.cds.t-internal.com (10.169.118.77) by HE105709.emea1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Apr 2019 16:09:12 +0200
Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE101951.EMEA1.cds.t-internal.com (10.169.118.77) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 16 Apr 2019 16:09:13 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Apr 2019 16:09:10 +0200
Received: from FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.16) by FRXPR01MB0663.DEUPRD01.PROD.OUTLOOK.DE (10.158.154.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Tue, 16 Apr 2019 14:09:12 +0000
Received: from FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2983:138f:af66:7084]) by FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE ([fe80::2983:138f:af66:7084%2]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 14:09:12 +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+n0VP6QU6jTEaLowkz8qYtFXcAgBHPIAA=
Date: Tue, 16 Apr 2019 14:09:12 +0000
Message-ID: <FRXPR01MB0664EEB95219B5EF7CE07133D1240@FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE>
References: <CAC8QAcfwqm+SdTBPsWdySAPgG_ciobr-C8rGs1kkDaX7ksF1TA@mail.gmail.com> <f63918e6-0269-425a-8952-fc84358a4ac0@getmailbird.com>
In-Reply-To: <f63918e6-0269-425a-8952-fc84358a4ac0@getmailbird.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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: ffdfa313-20a0-401a-fe96-08d6c27519eb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:FRXPR01MB0663;
x-ms-traffictypediagnostic: FRXPR01MB0663:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <FRXPR01MB066377C94FFBB11FD66EA64BD1240@FRXPR01MB0663.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(346002)(136003)(396003)(189003)(199004)(14454004)(316002)(71200400001)(110136005)(52396003)(66066001)(2906002)(71190400001)(229853002)(81166006)(11346002)(3846002)(790700001)(5660300002)(8676002)(186003)(68736007)(8936002)(33656002)(74482002)(26005)(486006)(7696005)(476003)(75402003)(6246003)(256004)(7736002)(53546011)(106356001)(105586002)(6116002)(2501003)(53936002)(81156014)(446003)(236005)(966005)(72206003)(6306002)(54896002)(9686003)(54556002)(55016002)(102836004)(2201001)(86362001)(99936001)(478600001)(606006)(97736004)(733005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0663; H:FRXPR01MB0664.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: QQXf01lLuuubidRZ+MpQuHu9/OLfNNTcZILte1xPGVEQs05sxuJwB82GI8JpIWoDB2NQiPISS5sYqvczZVc/u6zTK7wMAjeWAjGp14ZdURSAlJzVhxSy9Mf9DaXn3Lfo8mJk96x40vUcaZtaOc831I7v6oT0rJIizg3+KFqV2VEmTiFVs05AxqGbWrVoyc0Qa/oeP9DmH3axuIHNX9mpNzDjtQjEpyAhm6jQ9BMZJyXfaIv8Q4yU5gGThBtMB5oEd98YJC/TXVGSWtPK9VLLuZaU+EiAkxOFu9i1SaBKVV1vWWmZ3YnJplhnPyNczZ9q/XizTTdn2hAr2/Tj3mgV18vptpv+bP+oRjztJq2w6VPa5J/RGipXXcuom4nXXQhxZIK8aZlqiWqWBaxP2fo1XPfpcwIls6pJeDZohPQgrQ8=
Content-Type: multipart/related; boundary="_004_FRXPR01MB0664EEB95219B5EF7CE07133D1240FRXPR01MB0664DEUP_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ffdfa313-20a0-401a-fe96-08d6c27519eb
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 14:09:12.0712 (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: FRXPR01MB0663
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/RiS72O2mQcYVOYOwI6JyP-ZTGQQ>
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: Tue, 16 Apr 2019 15:43:30 -0000

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>
Sent: Freitag, 5. April 2019 08:01
To: sarikaya@ieee.org; pidloc@ietf.org
Cc: von Hugo, Dirk <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

On 2019-04-04 오전 12:56:50, Behcet Sarikaya <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>