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

"KJ SUN" <> Thu, 18 April 2019 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B30412028E for <>; Wed, 17 Apr 2019 19:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_REMOTE_IMAGE=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cu_WxWTVPb4P for <>; Wed, 17 Apr 2019 19:02:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 021EB120288 for <>; Wed, 17 Apr 2019 19:02:07 -0700 (PDT)
Received: by with SMTP id w25so334825pfi.9 for <>; Wed, 17 Apr 2019 19:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:date:message-id:subject:from:to:in-reply-to:references :user-agent; bh=4Ekv1FBtXoOr2vcbOP74PjHcMBGJho+55ugzqJO91FY=; b=HxMtOiCnulR0F9QdJRLLl8hnLI1WBI57hLFyHzm//DnIWuEkPtwMdHZGZvJZtKke8Y 8zwjD+6RF8B8SdFEeMpUWfkDUCRaiIemoNWdt311D0cuWiBaK7lpZZdx4DDuhHiA5eX5 BqNqD4z4OjRZCl6tGE1QfWXdhyRMLecJBfaCF5R9s3NfEz554UjCakuhAKUTTpM4udXr FBYD/q9sKTTn8M1SwPGHhj6X2oA8v2cgjUEDpbFrD+qNhIHG/Q0+sRBrGTIXDb0HI2hT PDj4By2Kpy/6iF147YpzP+XX1U5pgJ+HeKtwds/oEz0eO5S9zIO5wXe8exUakhFYpLV9 1AFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :in-reply-to:references:user-agent; bh=4Ekv1FBtXoOr2vcbOP74PjHcMBGJho+55ugzqJO91FY=; b=JiZqH7sIIYCel2V8jpKry+o0KbdHFVOixef3y72GyXUHTvDp/w5d+a7D3I+hUbca7D 0CHwGqApYD/QBsoYucZ6wSilUNOint43ZWoNioIk83+Cu+SPmilSM1BtJTcv46bPrhVj tUDMgjQ1K7Vh9/97cTwOoP2uRDBJVRxQGgVK40tvEbezTt54M1T6rbc6EpS7VN3j7Z6j yrMpd+u9L1eGzrekK8+btzyKX84Zu/xRoumYrx7YuB+bvzSs6K6+CQw6te8YUwsPSMIQ n0jeIyA1zDS6sfX0MbBdVQZJu9mTKeeLI38RpH9KbOLD0MPy0aaVnqsFUqkculYpFiuj Qklg==
X-Gm-Message-State: APjAAAX+gxgKzapdhPvO2pCjVqFwaX77H2ZBKw9C1fQPUQeIhXZshQYT HUBTFb8oQZpqvgR+ci3Py24pYw==
X-Google-Smtp-Source: APXvYqyyLI4DC627cu0aa3LT0J3smNBov/XL0FcHNoh0MzhLbiBm36wNIxmI6k0j8ZAp+RWteX9OUg==
X-Received: by 2002:a63:2c09:: with SMTP id s9mr82366869pgs.411.1555552927251; Wed, 17 Apr 2019 19:02:07 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id l1sm387218pgp.9.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 19:02:06 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----=_NextPart_64657981.718775550853"
MIME-Version: 1.0
Date: Thu, 18 Apr 2019 11:01:56 +0900
Message-ID: <>
From: "KJ SUN" <>
To: "" <>, "" <>, "" <>
In-Reply-To: <FRXPR01MB0664EEB95219B5EF7CE07133D1240@FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE>
References: <> <> <FRXPR01MB0664EEB95219B5EF7CE07133D1240@FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE>
User-Agent: Mailbird/
X-Antivirus: Avast (VPS 190417-4, 2019-04-18), Outbound message
X-Antivirus-Status: Clean
Archived-At: <>
Subject: Re: [Pidloc] draft-kjsun-ipwave-id-loc-separation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2019 02:02:12 -0000


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.



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
On 2019-04-16 오후 11:09:14, <> 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 [].
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?
Kind regards
From: KJ SUN <>
Sent: Freitag, 5. April 2019 08:01
Cc: von Hugo, Dirk <>
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"
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.
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
On 2019-04-04 오전 12:56:50, Behcet Sarikaya <> wrote:
Hello Gomjae,
Today, we had a Webex session with Dirk and discussed about your draft
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?
Behcet & Dirk
[Image removed by sender. Avast logo] []
이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다. []

이 이메일은 Avast 안티바이러스 소프트웨어로 바이러스 검사를 완료했습니다.