Subject: Re: [Pidloc] Pidloc in IETF Prague #104

From: <[email-masked]>
Date: Fri, 29 Mar 2019 15:49:48 +0000

Dear all,
as announced before we actually had our side meeting here in Prague and some fruitful discussions.
I’d like to share with you some notes of the 1-hour session where seven people attended on site and about four more on the phone/webex. Sorry for the inconvenience of a sub-optimum audio connection.
I will also attach the slides shown and the link provided by Marco.

Dirk presented chairs slides - focus was more on the open questions (gaps and problems) to be solved than on solutions.
Erik commented on use cases as edge computing in IoT (location is an issue here) and consumers sharing voluntarily Id and Location on application layer – which of course also should not be leaked beyond intended recipients.
VPN like closed groups pose less problem than rather consumer scale device numbers (walled garden or separate domains).

Shunsuke presented 5G use case attempting to include Id-Loc compatible with 3GPP architecture.
Location exposure of nearest UPF to local (non-3GPP) Data Networks (maybe untrusted) may raise privacy issues on related location information (from UPF to derive that of UE).

Next steps might be a more complete collection and classification of use cases and thereof identification of a requirements set to be demanded from potential solutions.

Marco and Umberto promised and meanwhile did to provide a link to related slides in DMM (draft at https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt) pointing to the LDN problem:

ID-LOC applies to the data network’s DPN and the user’s current (edge) UPF (serving as session anchor).

https://datatracker.ietf.org/meeting/104/materials/slides-104-dmm-control-data-plane-for-n6-traffic-steering-00

A question was whether slicing shall be provided via Id-Loc? Rather than that a low latency service on DP/UP would be the goal.
Somebody mentioned that also tunneling between two endpoints could be seen as Id-Loc approach.
Thanks for comments and updates/corrections by all participants.
Let’s continue discussion on the list.

Kind regards
Dirk

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Mar 2019 11:10:27 -0500

Hi Dirk,

Thanks for the minutes.

Let me add that there was some discussion on whether we should concentrate
the privacy work on the control or data plane.
I thought the conclusion was control plane. However, thinking a little bit
more on this, I came to the conclusion that we also need to work on the
data plane.
The reason being as some previous work has shown, changing
identifiers/locators that the UE uses from one session to another  improves
a lot the privacy issues.

What do you think?

Regards,
Behcet

On Fri, Mar 29, 2019 at 10:52 AM <[email-masked]> wrote:

> I’d like to share with you some notes of the 1-hour session where seven
> people attended on site and about four more on the phone/webex. Sorry for
> the inconvenience of a sub-optimum audio connection.
>
> Dirk presented chairs slides - focus was more on the open questions (gaps
> and problems) to be solved than on solutions.
>
> Erik commented on use cases as edge computing in IoT (location is an issue
> here) and consumers sharing voluntarily Id and Location on application
> layer – which of course also should not be leaked beyond intended
> recipients.
>
> VPN like closed groups pose less problem than rather consumer scale device
> numbers (walled garden or separate domains).
>
>
>
> Location exposure of nearest UPF to local (non-3GPP) Data Networks (maybe
> untrusted) may raise privacy issues on related location information (from
> UPF to derive that of UE).
>
>
>
> Next steps might be a more complete collection and classification of use
> cases and thereof identification of a requirements set to be demanded from
> potential solutions.
>
>
>
> Marco and Umberto promised and meanwhile did to provide a link to related
> slides in DMM (draft at
> https://www.ietf.org/id/draft-fattore-dmm-n6-trafficsteering-01.txt)
> pointing to the LDN problem:
>
>
>
> A question was whether slicing shall be provided via Id-Loc? Rather than
> that a low latency service on DP/UP would be the goal.
>
> --
> Pidloc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pidloc
>