Re: [Pidloc] Pidloc in IETF Prague #104

<Dirk.von-Hugo@telekom.de> Thu, 18 April 2019 14: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 6D53112034B for <pidloc@ietfa.amsl.com>; Thu, 18 Apr 2019 07:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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] 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 cXDms9L11gkE for <pidloc@ietfa.amsl.com>; Thu, 18 Apr 2019 07:42:56 -0700 (PDT)
Received: from mailout11.telekom.de (mailout11.telekom.de [194.25.225.207]) (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 B5AD1120346 for <pidloc@ietf.org>; Thu, 18 Apr 2019 07:42:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1555598575; x=1587134575; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Hzw/woE8uwSxe5vlcnsjAgBLM1flsVakTgqiAbxrKnA=; b=qWWZomcgm/NC/pXLeKTjlHBXraBIV/UKI2H/tImhzg76sxzLIeQtLVQ+ 22LGMCgfDKLGWOAOHnzV1KqE8SyTyA7qXP6ibNaX3U9n5M2nM5oUV+fcQ W8CQht+whO1CLwNZbEUPagxPaBMd6v80YSxgUKnX3IpCmYECVxEW7s2aw Qq0teJmNGQ+2cC97i5iv7/oy5Jw1P4EVhjb9ulWmDyOeC1m4uTsPsjgQF RgYWoneUjOQHTlYOUiMol0j4KqEzFaG6ZuWtPfK1t6V0a/vIFXU+wMr7y PNfqLyd9SpS9qAbPd1+QPg3jCY/BZXul+UqQM1PQRbesqsFlvJRfwJXeZ A==;
Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT11.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2019 16:42:52 +0200
X-MGA-submission: =?us-ascii?q?MDGYakeV9gEc859I5m4l9Qs36Iph+YFMOq5B12?= =?us-ascii?q?VQdrHS3HUtcMMsRZ23iij7HPTxmDoFu7ilq93keYZL/DToE4t0T9WMpx?= =?us-ascii?q?+Skc8PH75YUoRMdik2MQhxx93ebCAZHJCx780JIP15RaPYUiUexqb/YW?= =?us-ascii?q?xVTGCX8p6eM8qsG711jaBB7Q=3D=3D?=
Received: from he105872.emea1.cds.t-internal.com ([10.169.118.69]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 18 Apr 2019 16:42:52 +0200
Received: from HE101953.EMEA1.cds.t-internal.com (10.169.118.78) by HE105872.emea1.cds.t-internal.com (10.169.118.69) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 18 Apr 2019 16:42:52 +0200
Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE101953.EMEA1.cds.t-internal.com (10.169.118.78) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 18 Apr 2019 16:42:52 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.22) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 18 Apr 2019 16:42:52 +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:42:51 +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:42:51 +0000
From: <Dirk.von-Hugo@telekom.de>
To: <Marco.Liebsch@neclab.eu>, <sarikaya@ieee.org>
CC: <pidloc@ietf.org>, <marco.liebsch@netlab.nec.de>, <Umberto.Fattore@neclab.eu>
Thread-Topic: [Pidloc] Pidloc in IETF Prague #104
Thread-Index: AdTmQ1mz3M0UO0PHTCCpL9dcG6vIRwABpJ6AA4QP3kAABB9d4ABiJDnQ
Date: Thu, 18 Apr 2019 14:42:51 +0000
Message-ID: <LEJPR01MB09217E24E6E1BC019B449E58D1260@LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE>
References: <LEXPR01MB06697AD320805F58B004443FD15A0@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE> <CAC8QAcfZUiCfNwXf4vaTbdUg+AZMCayZKg40Tc3LUkgGk9Ctdg@mail.gmail.com> <FRXPR01MB066429AC69CED822C889A1ADD1240@FRXPR01MB0664.DEUPRD01.PROD.OUTLOOK.DE> <69756203DDDDE64E987BC4F70B71A26DE5AABBDD@Hydra.office.hd>
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26DE5AABBDD@Hydra.office.hd>
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: a00ef30c-fa26-4370-df7d-08d6c40c223a
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: 4
x-microsoft-antispam-prvs: <LEJPR01MB092355E42E00640B3F8CE90DD1260@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)(51914003)(55016002)(75402003)(9686003)(6306002)(54896002)(236005)(68736007)(74482002)(53936002)(476003)(486006)(2501003)(186003)(11346002)(446003)(54906003)(33656002)(7696005)(52396003)(110136005)(97736004)(2906002)(3846002)(6116002)(316002)(790700001)(86362001)(102836004)(53546011)(26005)(81156014)(81166006)(8936002)(8676002)(76176011)(229853002)(66574012)(5660300002)(4326008)(66066001)(93886005)(606006)(14454004)(5024004)(966005)(478600001)(7736002)(256004)(71190400001)(71200400001)(14444005)(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: Cf5c2Ouwd/x2A/JF9rGXLCiaiF/qBIiMVPxAKghmC7VHC+/ZdZ5GjpXHnKLKpvr4J/tNdVOulrZB38DXlX+CAMLtIBVDSHWKHYd/D4RUc9KL0VL2Z0elEqMCI1iQmvN038F666AUZ6nyvdRkv7HsuvGv5lz66KD3m57T/Me/BMAQTA2jIulg/qPVV9lQoUHZ+Jeu9NTtKfvcU6v7Gt94W4I1zkQ/AFtjfrAP61RpnjVryhHWEMslpHMSrjE+ZSfmWDuPUP9YCAQAzyQsfK//wbpg2cfP3+QqrEaO1dC63ePH5c4ZTxT+q19TGmCS+0SYNKecn6wevUnaQZHBoJxrVEMcQ6wRMQDZ45WFbcxWMxpKkmZYrGTfI19bKW4zP0L17OdWFEfViP3U79QP/415CB+D7nwyQhBJRNvg2lOqWd8=
Content-Type: multipart/alternative; boundary="_000_LEJPR01MB09217E24E6E1BC019B449E58D1260LEJPR01MB0921DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a00ef30c-fa26-4370-df7d-08d6c40c223a
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 14:42:51.1318 (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/JmpzbNcwUXHSFb-aVHU98ZnnJ3w>
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: Thu, 18 Apr 2019 14:43:01 -0000

Thanks Marco and Umberto,
for quick clarification!
Two issues came to my mind:

1)      In your security considerations an association between the DPN and the cellular system could be mentioned (or do you assume this being not use case specific should already be considered in general - elsewhere?)

2)      Maybe there could a section on ‘privacy issues’ added in the draft to describe the implications for requiring additional measures for UE location obfuscation here?


What do you think?
Thanks again and happy holidays!
Kind regards
Dirk

From: Marco Liebsch <Marco.Liebsch@neclab.eu>;
Sent: Dienstag, 16. April 2019 17:46
To: von Hugo, Dirk <Dirk.von-Hugo@telekom.de>;; sarikaya@ieee.org
Cc: pidloc@ietf.org; marco.liebsch@netlab.nec.de; Umberto Fattore <Umberto.Fattore@neclab.eu>;
Subject: RE: [Pidloc] Pidloc in IETF Prague #104

Hi Dirk,

Traffic Identifier can be also something broader and more aggregate, e.g. all data traffic associated with a single user
or a group of users. Depends on how fine granular treatment policies should apply. This can be for example a PDU session
identifier or the associated UE IP address. UPF/DPN as N6 endpoint, yes, that is the data plane anchor where downlink
traffic should be transported to. Dependent on its deployment, it can reveal more or less accurate location information.

Best regards,
marco


From: Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de> [mailto:Dirk.von-Hugo@telekom.de]
Sent: Dienstag, 16. April 2019 15:53
To: sarikaya@ieee.org<mailto:sarikaya@ieee.org>
Cc: pidloc@ietf.org<mailto:pidloc@ietf.org>; marco.liebsch@netlab.nec.de<mailto:marco.liebsch@netlab.nec.de>; Umberto Fattore
Subject: RE: [Pidloc] Pidloc in IETF Prague #104

Dear all,
sorry for delayed reply:
I agree that data plane will also be in scope of privacy issues for Id-Loc protocols – if I understood correctly the use case on ‘Location exposure of nearest User Plane Function to local (non-3GPP) Data Networks’ described by Marco and Umberto in https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/ addresses data plane issues.
@Marco and Umberto: ‘Traffic Identifier’ and ‘UPF/DPN N6 endpoint’ here serve as Id and Loc, right?
Thanks!
Kind regards
Dirk

From: Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>>
Sent: Freitag, 29. März 2019 17:10
To: von Hugo, Dirk <Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>>
Cc: pidloc@ietf.org<mailto:pidloc@ietf.org>
Subject: Re: [Pidloc] Pidloc in IETF Prague #104

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