Re: [Pidloc] Pidloc in IETF Prague #104

Behcet Sarikaya <sarikaya2012@gmail.com> Fri, 29 March 2019 16:10 UTC

Return-Path: <sarikaya2012@gmail.com>
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 B6E73120447 for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 09:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 C3K3dSVgF268 for <pidloc@ietfa.amsl.com>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B52C120464 for <pidloc@ietf.org>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id a84so1029973ybg.10 for <pidloc@ietf.org>; Fri, 29 Mar 2019 09:10:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=9l0t/CezPHpCAg+NG71kCpL/nv1DQyFrZepB7Q3JsK0=; b=Itm5o6BOrz3MW7ajy3wz4hiAcoc22pqvoyT6bZ96IvrcKqA7W/1kX/4pIm3UK55H2P LIX6dFC6giYitAkD6TJY0CEKc3Op91lGoixJbO6Fry1HaiJr65xN5A9c61Jc8dgO1l67 UbOfKKP2mIJTFBEGII8w7yWmu3EftZuUqCB01TiXsoyMD6eXzJeU2puWD7P8BcdwerJ3 LjhfYZ3ROvPEM0asjDWvZQARk+RbcuCfIgUmhJXIDPMESCD/UkTFyM59v+NyS9nyjTt0 GA6gXhAOjdam0MDK+ijx6N3ekSUHByKAM5cxXT3IjMklj5Oh5AKfD1tGtkaD7u1RLOW1 cYfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=9l0t/CezPHpCAg+NG71kCpL/nv1DQyFrZepB7Q3JsK0=; b=C1cPcDYjzLDvZA4lboQi7R5DBc9MYKvokfKmbebhGgzWwpAH73cJtm70c4eVaGXSx+ 5NLHxKZC10BvCxrrG5orwZrbxqQdJ3rSt5afUWywtFpcl8ZwXxahFwhdUn4rWYkNw3GN 9uqvYDbrL4ix/pvXUubeH9t8m6Ug0V8NhQOoRMiAY+d/INpJ2RR47nYA/1gpjyLjZ6ok 2w3xdt6rGdjcTS/3OmnD23uhgxLNUrhLMkBhbb4UzQ92WeIBBTw03/C/6o5STQRMAkjr HUZeyfhldX94/uGvtipYse/cCYUHjW+ZSzCr0u0Z/ANeWkCSBs061VaVmVmgokDI4nEZ xtRA==
X-Gm-Message-State: APjAAAW6HoBHliAnnBL1qhU3aUICjckVMYGIVgXBbmSh0XPHMFC2CBG7 gEy20wmBdFVTpr7vFUFLaazbZ9g2y8j7IVHKxH4=
X-Google-Smtp-Source: APXvYqzi5qGBvysD2uO9MVr2KOR2i/Vih1jvz8pkE2FpL761d6IZaYCoq7CvcxknMHqF6DsR2hZsELeBCWEVwDjmrNM=
X-Received: by 2002:a5b:643:: with SMTP id o3mr11697788ybq.410.1553875838440; Fri, 29 Mar 2019 09:10:38 -0700 (PDT)
MIME-Version: 1.0
References: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Fri, 29 Mar 2019 11:10:27 -0500
Message-ID: <CAC8QAcfZUiCfNwXf4vaTbdUg+AZMCayZKg40Tc3LUkgGk9Ctdg@mail.gmail.com>
To: "<Dirk.von-Hugo@telekom.de>" <Dirk.von-Hugo@telekom.de>
Cc: pidloc@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006017f605853de9e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/MMuWtwXW0O2eOcQ9WOxYH9grrQI>
Subject: Re: [Pidloc] Pidloc in IETF Prague #104
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: Fri, 29 Mar 2019 16:10:42 -0000

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 <Dirk.von-Hugo@telekom.de> wrote:

> 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
>
>
> --
> Pidloc mailing list
> Pidloc@ietf.org
> https://www.ietf.org/mailman/listinfo/pidloc
>