From nobody Mon Jun 3 07:42:28 2019 Return-Path: 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 4BF94120259 for ; Mon, 3 Jun 2019 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 pdysBb9EU69J for ; Mon, 3 Jun 2019 07:42:23 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 82C4A120258 for ; Mon, 3 Jun 2019 07:42:23 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id r128so1695987ywe.5 for ; Mon, 03 Jun 2019 07:42:23 -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; bh=mEFxGQzgNutIXM0zE4mZ1R00yP4FP/256MSwsAvGv1g=; b=dTO1W3pm+CnkZpX74FwgrwVPX3saLs+n9PKNI73ZMfS0EthvASLx007xTb3vilE7GL zHS9tO60y+gS03qZtDb+Wofy39uAcpejl0QdOuklQCc+53tK4h73NJUIok2vKO+WgQ1G 3MNJ7KVZ7HlccD+t4uybvjrvL/Ga9XUqB22NRHDKmiLQi/ZMTc/on7mIdzbjFhnRZrrO 2nB++K0a6jeWRhB0DeF0zxEuFsHhX1we+Pfi5zoDotSHLRx/e9gEr/mxPWURLe+BVifj Hpf20HOqG4Hr/n9/zOd0Nt1nyOOYrNxPtJiWNd72j/VY6a494biftalHQOTZbWYIcrTC M7Sw== 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; bh=mEFxGQzgNutIXM0zE4mZ1R00yP4FP/256MSwsAvGv1g=; b=bFCGvVXFLVtVNJ2c9YhpklZKgnAczL7av9tzlCf/ustfvQd9MZfF3EWAZ4tBitwDDt ksenP4K9WRuRwkdGm6kgBsbuR+MM/uyD2NJlLLAJP2VMzI0w2P50+tljxT/htM7SMQA3 C5DvpA/D7vbd4cUdESCJ6oen1D9I0s0z+aQ8povb+rKpanSU/ic8/sb6bWjpK0HDxNCg +yc0OyFxeU+Ai5F68I/AkojgfRBHc8R4MjL5nW+4UESvbEgdiNLt/U7gscYKl1yiQ02Y Lbr8WnZEgXSteLBq7cuR9aZ7G0oPRXsllpqkB05TuExvv/VXfiNt1I2EGMHRo2Drjr6v oKVA== X-Gm-Message-State: APjAAAXLvSh6NjEgLDJ5GDcslsdR8K8UMHnmTIe3LcSOSVSsH9j80xuT VTZ0yoXeK4fkgU9qdlzQXspbSLiH287jmRqLxeb0gYtG X-Google-Smtp-Source: APXvYqwQttqCZXmf6cIK4IaxcLMn13usXolhymeG84orA0uf2X1tE7dWc1FtWWyfm1h75iqUsGZeYrP3mgi1yn7ruak= X-Received: by 2002:a0d:d342:: with SMTP id v63mr13328411ywd.369.1559572942086; Mon, 03 Jun 2019 07:42:22 -0700 (PDT) MIME-Version: 1.0 References: <155957267715.24923.16661975431171328801.idtracker@ietfa.amsl.com> In-Reply-To: <155957267715.24923.16661975431171328801.idtracker@ietfa.amsl.com> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Mon, 3 Jun 2019 09:42:10 -0500 Message-ID: To: pidloc@ietf.org, "" Content-Type: multipart/alternative; boundary="00000000000036e634058a6c5f14" Archived-At: Subject: [Pidloc] Fwd: New Version Notification for draft-xyz-pidloc-ps-02.txt X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 14:42:26 -0000 --00000000000036e634058a6c5f14 Content-Type: text/plain; charset="UTF-8" Hi all, We have submitted Rev. 02 of pidloc PS draft. This revision is for a number of editorial corrections it also adds Section 3.4. To know more, please read ir and send your comments to the list. Thank you, Behcet & Dirk A new version of I-D, draft-xyz-pidloc-ps-02.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-xyz-pidloc-ps Revision: 02 Title: Problem Statement for Secure End to End Privacy in IdLoc Systems Document date: 2019-06-03 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-xyz-pidloc-ps-02.txt Status: https://datatracker.ietf.org/doc/draft-xyz-pidloc-ps/ Htmlized: https://tools.ietf.org/html/draft-xyz-pidloc-ps-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-ps Diff: https://www.ietf.org/rfcdiff?url2=draft-xyz-pidloc-ps-02 Abstract: Efficient and service aware flexible end-to-end routing in future communication networks is achieved by routing protocol approaches making use of Identifier Locator separation systems. Since these systems require a correlation between identifiers and location which might allow tracking and misusage of individuals' identities and locations such operation demands for highly secure measures to preserve privacy of users and devices. This document tries to identify and describe typical use cases and derive thereof a problem statement describing issues and challenges for application of privacy preserving Identifier-Locator split (PidLoc) approaches. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --00000000000036e634058a6c5f14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,
We have submitted Rev. 02 of pidloc PS draft. = This revision is for a number of editorial corrections it also adds Section= 3.4.
To know more, please read ir and send your comments to the = list.
Thank you,

Behcet & Dirk
=


A new version of I-D, draft-xyz-pidloc-ps-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-xyz-pidloc-ps
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Problem Statement for Secure End t= o End Privacy in IdLoc Systems
Document date:=C2=A0 2019-06-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-xyz-pidloc-ps-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-xyz-pidloc-ps/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.= ietf.org/html/draft-xyz-pidloc-ps-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/html/draft-xyz-pidloc-ps
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-xyz-pidloc-ps-02

Abstract:
=C2=A0 =C2=A0Efficient and service aware flexible end-to-end routing in fut= ure
=C2=A0 =C2=A0communication networks is achieved by routing protocol approac= hes
=C2=A0 =C2=A0making use of Identifier Locator separation systems.=C2=A0 Sin= ce these
=C2=A0 =C2=A0systems require a correlation between identifiers and location= which
=C2=A0 =C2=A0might allow tracking and misusage of individuals' identiti= es and
=C2=A0 =C2=A0locations such operation demands for highly secure measures to=
=C2=A0 =C2=A0preserve privacy of users and devices.=C2=A0 This document tri= es to
=C2=A0 =C2=A0identify and describe typical use cases and derive thereof a p= roblem
=C2=A0 =C2=A0statement describing issues and challenges for application of = privacy
=C2=A0 =C2=A0preserving Identifier-Locator split (PidLoc) approaches.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--00000000000036e634058a6c5f14-- From nobody Fri Jun 7 07:33:51 2019 Return-Path: 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 0D2B21201AE for ; Fri, 7 Jun 2019 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.306 X-Spam-Level: X-Spam-Status: No, score=-4.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_DKIMWL_WL_HIGH=-0.01, 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 kXKfvSYRNBlj for ; Fri, 7 Jun 2019 07:33:44 -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 CAFEE1201C8 for ; Fri, 7 Jun 2019 07:33: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=1559917998; x=1591453998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4Hbz6sVxRaTFPFSLBd1DtNTcQQVubPyZ0noWDS+3zG8=; b=Zgg3RX9Az+lEzTVb/Kds/Ks1kaPwSg97wqlMQ94OUZNWP2s6cya1qT7J 7kJPCnMT/YhVgS885Foj9OILtvPnR5nPaXYYWsk0TTGzyKwk9mjYd3sf6 IXycPO2MgE/jFo9x0p9MJnUG8C/8i97E/fQbORy5GmK9tmXtGLu/K6hrP Pt3R82BFtapYMtyKYa3pYX0rGevY6U8td4WZBwWmCvNqgZ4pB9VXa09cl /Q95owmQSMwMU+MDArlPFwSeOwFJvRx1ztUpY5bopSAIBQ0cn3H5cUeBA 26Qd2KpJvZsEf05LXlx1eQ6NRTY3cvntPWIigPrPLuhmbOmeRP8O61eZ4 Q==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2019 16:33:16 +0200 X-MGA-submission: =?us-ascii?q?MDEy2RXMpDU/+OsQrVscfDHqmgPkdHGkSMsgbt?= =?us-ascii?q?JjiWNcRRmLLQdmQhtmiZU+POBiVIBIUBZvbEqjXcYmJJJubZ3mVYlYOs?= =?us-ascii?q?O4QwidwqwXkOO43Zt2q12Y5pnjK6iRoOOTD0XLf5XPoKvmLwitxPcZlM?= =?us-ascii?q?EXp6OpZCACRF3l3UwiwhEMSA=3D=3D?= Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 07 Jun 2019 16:33:16 +0200 Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Jun 2019 16:33:16 +0200 Received: from HE104160.emea1.cds.t-internal.com (10.171.40.36) by HE105717.EMEA1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 7 Jun 2019 16:33:16 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.21) by O365mail03.telekom.de (172.30.0.232) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 7 Jun 2019 16:33:15 +0200 Received: from LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE (10.158.146.19) by LEJPR01MB0858.DEUPRD01.PROD.OUTLOOK.DE (10.158.145.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Fri, 7 Jun 2019 14:33:15 +0000 Received: from LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5dc5:23d6:e86b:5623]) by LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE ([fe80::5dc5:23d6:e86b:5623%3]) with mapi id 15.20.1965.011; Fri, 7 Jun 2019 14:33:15 +0000 From: To: CC: Thread-Topic: New Version Notification for draft-xyz-pidloc-ps-02.txt Thread-Index: AQHVGhn2EFOPw6wseUii6vV5wL+576aKANgAgAZFbRA= Date: Fri, 7 Jun 2019 14:33:15 +0000 Message-ID: References: <155957267715.24923.16661975431171328801.idtracker@ietfa.amsl.com> In-Reply-To: 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: 62e7f35c-1a20-4a33-315c-08d6eb5513d6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:LEJPR01MB0858; x-ms-traffictypediagnostic: LEJPR01MB0858: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(136003)(396003)(54164003)(199004)(53754006)(189003)(71200400001)(81156014)(66574012)(446003)(790700001)(74482002)(14444005)(5640700003)(73956011)(75402003)(6916009)(81166006)(52396003)(256004)(476003)(316002)(1730700003)(66556008)(64756008)(76116006)(66446008)(102836004)(68736007)(8676002)(66946007)(66476007)(2906002)(15650500001)(2420400007)(86362001)(71190400001)(11346002)(606006)(236005)(7696005)(66066001)(486006)(2501003)(7736002)(3846002)(6116002)(478600001)(9686003)(26005)(2351001)(5660300002)(53936002)(14454004)(53386004)(8936002)(7110500001)(4326008)(186003)(55016002)(6246003)(413944005)(33656002)(53546011)(966005)(54896002)(6306002)(72206003)(229853002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0858; H:LEJPR01MB0921.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 5GSYH01dNjq+RhyEALmhLMGF/2ttIE0UMkJ8c2XsiGk0u+QDXKEuveCVZTba8/iVxa3H5I/Z/wW59X8ICooT0loPYzNE6VyRK1RjLitL+GBHC/XgZreKLAMqregZd3XDLrA3lnmmqqHSr6HEaFzcSv8jRgYGS2ks2tpcdv3xkwFttGzAAPAgoE9yOEe+DMHof8zoLNY7Gz5Xk99S/jXKDwZQDf96N8qTKA6xgVCSaZcxhlmJb0LBLV5FSh7AHCB91+VU3lNnw9pxO0KvwoBKOOfxgAxA94E74E/ly9YbLjcCj6l630DFY3xzvShekPXNUCnK9/j2GSSE8Ifj6+KDpJK04IFCLgmF+JWC8ILJWdY+DuXKS55dZB6VNxzwFwEYlzROgrjul5uR2KGaimIaKMd7uO1KhQFg+Yc3fstpM2Y= Content-Type: multipart/alternative; boundary="_000_LEJPR01MB0921EEE042DEB89C2F0CE187D1100LEJPR01MB0921DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62e7f35c-1a20-4a33-315c-08d6eb5513d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 14:33:15.6575 (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-CrossTenant-userprincipalname: Dirk.von-Hugo@telekom.de X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0858 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Pidloc] New Version Notification for draft-xyz-pidloc-ps-02.txt X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 14:33:48 -0000 --_000_LEJPR01MB0921EEE042DEB89C2F0CE187D1100LEJPR01MB0921DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQpUaGFua3MgdG8gYWxsIHRoZSBjb250cmlidXRvcnMgdG8gdGhpcyBJTU8gY29u c2lkZXJhYmx5IGltcHJvdmVkIHZlcnNpb24uDQpXZSB3b3VsZCBsaWtlIHRvIGxldCB5b3Uga25v dyB0aGF0IHdlIHBsYW4gdG8gaGF2ZSBhIGRpc2N1c3Npb24gb24gaXQgYW5kIG90aGVyIHRvcGlj cyBkdXJpbmcgdXBjb21pbmcgSUVURiBtZWV0aW5nIDEwNSBpbiBNb250cmVhbCDigJMgZWl0aGVy IGluIGEgc2lkZSBtZWV0aW5nIGFzIGJlZm9yZSBvciBldmVuIGR1cmluZyBhIEJvRiAgLSBpZiBh cHByb3ZlZCA7LSkuDQpQbGVhc2UgbGV0IHVzIGtub3cgeW91ciBvcGluaW9uIGFuZCBhdmFpbGFi aWxpdHkuDQpUaGFua3MhDQpLaW5kIHJlZ2FyZHMg4oCTIGFsc28gb24gYmVoYWxmIG9mIEJlaGNl dA0KRGlyaw0KDQpGcm9tOiBCZWhjZXQgU2FyaWtheWEgPHNhcmlrYXlhMjAxMkBnbWFpbC5jb20+ DQpTZW50OiBNb250YWcsIDMuIEp1bmkgMjAxOSAxNjo0Mg0KVG86IHBpZGxvY0BpZXRmLm9yZzsg dm9uIEh1Z28sIERpcmsgPERpcmsudm9uLUh1Z29AdGVsZWtvbS5kZT4NClN1YmplY3Q6IEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14eXotcGlkbG9jLXBzLTAyLnR4dA0K DQpIaSBhbGwsDQpXZSBoYXZlIHN1Ym1pdHRlZCBSZXYuIDAyIG9mIHBpZGxvYyBQUyBkcmFmdC4g VGhpcyByZXZpc2lvbiBpcyBmb3IgYSBudW1iZXIgb2YgZWRpdG9yaWFsIGNvcnJlY3Rpb25zIGl0 IGFsc28gYWRkcyBTZWN0aW9uIDMuNC4NClRvIGtub3cgbW9yZSwgcGxlYXNlIHJlYWQgaXIgYW5k IHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4NClRoYW5rIHlvdSwNCg0KQmVoY2V0ICYg RGlyaw0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14eXotcGlkbG9jLXBzLTAyLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCZWhjZXQgU2FyaWtheWEgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0 LXh5ei1waWRsb2MtcHMNClJldmlzaW9uOiAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgIFByb2Js ZW0gU3RhdGVtZW50IGZvciBTZWN1cmUgRW5kIHRvIEVuZCBQcml2YWN5IGluIElkTG9jIFN5c3Rl bXMNCkRvY3VtZW50IGRhdGU6ICAyMDE5LTA2LTAzDQpHcm91cDogICAgICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMTENClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteHl6LXBpZGxvYy1wcy0wMi50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14 eXotcGlkbG9jLXBzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC14eXotcGlkbG9jLXBzLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14eXotcGlkbG9jLXBzDQpEaWZmOiAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXh5ei1waWRsb2MtcHMt MDINCg0KQWJzdHJhY3Q6DQogICBFZmZpY2llbnQgYW5kIHNlcnZpY2UgYXdhcmUgZmxleGlibGUg ZW5kLXRvLWVuZCByb3V0aW5nIGluIGZ1dHVyZQ0KICAgY29tbXVuaWNhdGlvbiBuZXR3b3JrcyBp cyBhY2hpZXZlZCBieSByb3V0aW5nIHByb3RvY29sIGFwcHJvYWNoZXMNCiAgIG1ha2luZyB1c2Ug b2YgSWRlbnRpZmllciBMb2NhdG9yIHNlcGFyYXRpb24gc3lzdGVtcy4gIFNpbmNlIHRoZXNlDQog ICBzeXN0ZW1zIHJlcXVpcmUgYSBjb3JyZWxhdGlvbiBiZXR3ZWVuIGlkZW50aWZpZXJzIGFuZCBs b2NhdGlvbiB3aGljaA0KICAgbWlnaHQgYWxsb3cgdHJhY2tpbmcgYW5kIG1pc3VzYWdlIG9mIGlu ZGl2aWR1YWxzJyBpZGVudGl0aWVzIGFuZA0KICAgbG9jYXRpb25zIHN1Y2ggb3BlcmF0aW9uIGRl bWFuZHMgZm9yIGhpZ2hseSBzZWN1cmUgbWVhc3VyZXMgdG8NCiAgIHByZXNlcnZlIHByaXZhY3kg b2YgdXNlcnMgYW5kIGRldmljZXMuICBUaGlzIGRvY3VtZW50IHRyaWVzIHRvDQogICBpZGVudGlm eSBhbmQgZGVzY3JpYmUgdHlwaWNhbCB1c2UgY2FzZXMgYW5kIGRlcml2ZSB0aGVyZW9mIGEgcHJv YmxlbQ0KICAgc3RhdGVtZW50IGRlc2NyaWJpbmcgaXNzdWVzIGFuZCBjaGFsbGVuZ2VzIGZvciBh cHBsaWNhdGlvbiBvZiBwcml2YWN5DQogICBwcmVzZXJ2aW5nIElkZW50aWZpZXItTG9jYXRvciBz cGxpdCAoUGlkTG9jKSBhcHByb2FjaGVzLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQo= --_000_LEJPR01MB0921EEE042DEB89C2F0CE187D1100LEJPR01MB0921DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRlYXIg YWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhhbmtzIHRvIGFsbCB0aGUgY29udHJpYnV0b3JzIHRvIHRoaXMgSU1PIGNvbnNpZGVy YWJseSBpbXByb3ZlZCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2Ugd291bGQgbGlrZSB0byBsZXQgeW91IGtub3cgdGhh dCB3ZSBwbGFuIHRvIGhhdmUgYSBkaXNjdXNzaW9uIG9uIGl0IGFuZCBvdGhlciB0b3BpY3MgZHVy aW5nIHVwY29taW5nIElFVEYgbWVldGluZyAxMDUNCiBpbiBNb250cmVhbCDigJMgZWl0aGVyIGlu IGEgc2lkZSBtZWV0aW5nIGFzIGJlZm9yZSBvciBldmVuIGR1cmluZyBhIEJvRiAmbmJzcDstIGlm IGFwcHJvdmVkIDstKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlBsZWFzZSBsZXQgdXMga25vdyB5b3VyIG9waW5pb24gYW5kIGF2YWls YWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzkiPktpbmQgcmVn YXJkcyDigJMgYWxzbyBvbiBiZWhhbGYgb2YgQmVoY2V0PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0RTc5Ij5EaXJrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJlaGNldCBTYXJpa2F5YSAmbHQ7c2FyaWth eWEyMDEyQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb250YWcsIDMuIEp1bmkg MjAxOSAxNjo0Mjxicj4NCjxiPlRvOjwvYj4gcGlkbG9jQGlldGYub3JnOyB2b24gSHVnbywgRGly ayAmbHQ7RGlyay52b24tSHVnb0B0ZWxla29tLmRlJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBG d2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHl6LXBpZGxvYy1wcy0wMi50 eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBzdWJtaXR0ZWQgUmV2 LiAwMiBvZiBwaWRsb2MgUFMgZHJhZnQuIFRoaXMgcmV2aXNpb24gaXMgZm9yIGEgbnVtYmVyIG9m IGVkaXRvcmlhbCBjb3JyZWN0aW9ucyBpdCBhbHNvIGFkZHMgU2VjdGlvbiAzLjQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBrbm93IG1vcmUs IHBsZWFzZSByZWFkIGlyIGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3Us PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJl aGNldCAmYW1wOyBEaXJrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXh5ei1waWRsb2MtcHMtMDIudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBCZWhjZXQgU2FyaWtheWEgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJl cG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2RyYWZ0LXh5ei1waWRsb2MtcHM8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDswMjxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgUHJvYmxlbSBTdGF0ZW1lbnQgZm9yIFNlY3VyZSBFbmQgdG8gRW5kIFByaXZhY3kgaW4g SWRMb2MgU3lzdGVtczxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTktMDYtMDM8YnI+DQpH cm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlz c2lvbjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMTE8YnI+ DQpVUkw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh5ei1waWRsb2MtcHMt MDIudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQteHl6LXBpZGxvYy1wcy0wMi50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC14eXotcGlkbG9jLXBzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh5ei1waWRsb2MtcHMvPC9hPjxicj4NCkh0 bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC14eXotcGlkbG9jLXBzLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh5ei1waWRsb2MtcHMtMDI8L2E+PGJyPg0K SHRtbGl6ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14eXotcGlkbG9jLXBzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC14eXotcGlk bG9jLXBzPC9hPjxicj4NCkRpZmY6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQteHl6 LXBpZGxvYy1wcy0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC14eXotcGlkbG9jLXBzLTAyPC9hPjxicj4NCjxicj4NCkFic3RyYWN0Ojxi cj4NCiZuYnNwOyAmbmJzcDtFZmZpY2llbnQgYW5kIHNlcnZpY2UgYXdhcmUgZmxleGlibGUgZW5k LXRvLWVuZCByb3V0aW5nIGluIGZ1dHVyZTxicj4NCiZuYnNwOyAmbmJzcDtjb21tdW5pY2F0aW9u IG5ldHdvcmtzIGlzIGFjaGlldmVkIGJ5IHJvdXRpbmcgcHJvdG9jb2wgYXBwcm9hY2hlczxicj4N CiZuYnNwOyAmbmJzcDttYWtpbmcgdXNlIG9mIElkZW50aWZpZXIgTG9jYXRvciBzZXBhcmF0aW9u IHN5c3RlbXMuJm5ic3A7IFNpbmNlIHRoZXNlPGJyPg0KJm5ic3A7ICZuYnNwO3N5c3RlbXMgcmVx dWlyZSBhIGNvcnJlbGF0aW9uIGJldHdlZW4gaWRlbnRpZmllcnMgYW5kIGxvY2F0aW9uIHdoaWNo PGJyPg0KJm5ic3A7ICZuYnNwO21pZ2h0IGFsbG93IHRyYWNraW5nIGFuZCBtaXN1c2FnZSBvZiBp bmRpdmlkdWFscycgaWRlbnRpdGllcyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7bG9jYXRpb25zIHN1 Y2ggb3BlcmF0aW9uIGRlbWFuZHMgZm9yIGhpZ2hseSBzZWN1cmUgbWVhc3VyZXMgdG88YnI+DQom bmJzcDsgJm5ic3A7cHJlc2VydmUgcHJpdmFjeSBvZiB1c2VycyBhbmQgZGV2aWNlcy4mbmJzcDsg VGhpcyBkb2N1bWVudCB0cmllcyB0bzxicj4NCiZuYnNwOyAmbmJzcDtpZGVudGlmeSBhbmQgZGVz Y3JpYmUgdHlwaWNhbCB1c2UgY2FzZXMgYW5kIGRlcml2ZSB0aGVyZW9mIGEgcHJvYmxlbTxicj4N CiZuYnNwOyAmbmJzcDtzdGF0ZW1lbnQgZGVzY3JpYmluZyBpc3N1ZXMgYW5kIGNoYWxsZW5nZXMg Zm9yIGFwcGxpY2F0aW9uIG9mIHByaXZhY3k8YnI+DQombmJzcDsgJm5ic3A7cHJlc2VydmluZyBJ ZGVudGlmaWVyLUxvY2F0b3Igc3BsaXQgKFBpZExvYykgYXBwcm9hY2hlcy48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8 YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LEJPR01MB0921EEE042DEB89C2F0CE187D1100LEJPR01MB0921DEUP_-- From nobody Thu Jun 13 08:50:11 2019 Return-Path: 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 1ECF51201E6 for ; Thu, 13 Jun 2019 08:50:10 -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_HELO_NONE=0.001, SPF_PASS=-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 1Pt4aYbzdg97 for ; Thu, 13 Jun 2019 08:50:08 -0700 (PDT) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 74FF7120141 for ; Thu, 13 Jun 2019 08:50:08 -0700 (PDT) Received: by mail-yw1-xc33.google.com with SMTP id k125so2186395ywe.5 for ; Thu, 13 Jun 2019 08:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to:cc; bh=sXhhSK6xzzYNsNG8cxWj1Rj7X3eVrCeKQHrKqvgCEQg=; b=IBi0vynpcbAaT5CkogjpBRrCGrkf5rwzV+fhuLEa8FRSgTLXvRmi9/hEQ2TEQmkUM/ 2eC2FnoF8pXolA9gezv2DQPL+pXVOVJW0TGboN+cFXrrMdwwc9dkvNfLudPqHzK+TFcE IEJ8KrpuUeit/dEjiDEtOJPgP4MfeowxW8XsoORGON9Tolkatj0iZFR1vZiJRY2A4Oz/ JccblDYAp1JmAyGpd0dT/LXoXL662f3z5yPJV38XsK5wVTRYyyStdGNxGFWp8HPJtL9L UYPq3qzkK+9DTkhX/FmuP90Plr/HP7Mvk1ZylND88HG0kNFk8harqgssj/hdSjiv5nsm Ia7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to:cc; bh=sXhhSK6xzzYNsNG8cxWj1Rj7X3eVrCeKQHrKqvgCEQg=; b=q4LZXDTGZeG+38cbDJez0DWZFzl0K0b2pDqa7a9J7Nb8kspHTepOYPBL0w70lmAjYi Y2d9a7WHsV349ObOo+uen08/Epqu0z/4h9cWoDBOLSL+Txx9BK4nipPlb1UePqrSDclC za3KqmAFRiAZy7zgy2zyjBw1mY+2szB9FOu6h/y21oFZOelINwjE/zP+RcNbxh4WcYe3 6ePTa2o1bpqKqnkyNBGCgQjZIn4bqsyEsQl7xRWiM9i3r8Q05mb6/SZ5PxpEepHh1NRZ FbHsEUtw66I4uvOpl6qsZojRSfbae2o2M0ZvFu+WtycxkCYbcezixUB/FQ3zltcIg0MH OS+g== X-Gm-Message-State: APjAAAWh5EDLVQbiZOIahpFwpByFVJmlbqB4scZhIe0UEv+t1/RSOB1q C8cZlsZIZBAebgnyDjPaBeL04mIO4OLcsm0S/oDlYkov X-Google-Smtp-Source: APXvYqx4Gkp6lcUBXo7oXmkD/vNt5IZAi5c2meYxVb3QK+XT78A7J1Ru7HHqqyLZ4FPj3Ze718hf1Al18gaIoy3+enc= X-Received: by 2002:a0d:df06:: with SMTP id i6mr33028219ywe.390.1560441007493; Thu, 13 Jun 2019 08:50:07 -0700 (PDT) MIME-Version: 1.0 Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Thu, 13 Jun 2019 10:49:56 -0500 Message-ID: To: pidloc@ietf.org Cc: "" Content-Type: multipart/alternative; boundary="000000000000f1d846058b367b07" Archived-At: Subject: [Pidloc] IETF 105 plans X-BeenThere: pidloc@ietf.org 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, 13 Jun 2019 15:50:10 -0000 --000000000000f1d846058b367b07 Content-Type: text/plain; charset="UTF-8" Folks, We are planning to organize a side meeting in Montreal. If you have a topic of interest please let me know. More detAils to follow. Regards, Behcet & Dirk --000000000000f1d846058b367b07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Folks,
We are planning to organize a side meeting = in Montreal.
If you have a topic of interest please=C2=A0let me k= now.
More detAils to follow.

Regards,

Behcet & Dirk=C2=A0
--000000000000f1d846058b367b07-- From nobody Wed Jun 19 01:10:58 2019 Return-Path: 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 579CD1203F5 for ; Wed, 19 Jun 2019 01:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kErrKF7FzFHp for ; Wed, 19 Jun 2019 01:10:54 -0700 (PDT) Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp [202.19.227.74]) by ietfa.amsl.com (Postfix) with ESMTP id 590B8120391 for ; Wed, 19 Jun 2019 01:10:54 -0700 (PDT) X-dD-Source: Outbound Received: from zssg-mailmd104.ddreams.local (zssg-mailmd900.ddreams.local [10.160.172.63]) by zssg-mailou104.ddreams.local (Postfix) with ESMTP id A8DDD1200FC; Wed, 19 Jun 2019 17:10:53 +0900 (JST) Received: from zssg-mailmf103.ddreams.local (zssg-mailmf900.ddreams.local [10.160.172.84]) by zssg-mailmd104.ddreams.local (dDREAMS) with ESMTP id <0PTC003K46Q59HF0@dDREAMS>; Wed, 19 Jun 2019 17:10:53 +0900 (JST) Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by zssg-mailmf103.ddreams.local (Postfix) with ESMTP id 8C2687E6036; Wed, 19 Jun 2019 17:10:53 +0900 (JST) Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8ABD68E6054; Wed, 19 Jun 2019 17:10:53 +0900 (JST) Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 7F94F8E605E; Wed, 19 Jun 2019 17:10:53 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: localhost:10026 Received: from zssg-mailmf103.ddreams.local (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B04A88E6058; Wed, 19 Jun 2019 17:10:52 +0900 (JST) Received: from zssg-mailua102.ddreams.local (unknown [10.160.172.62]) by zssg-mailmf103.ddreams.local (Postfix) with ESMTP; Wed, 19 Jun 2019 17:10:52 +0900 (JST) Received: from RDSVVDI0392 (unknown [10.171.80.137]) by zssg-mailua102.ddreams.local (dDREAMS) with ESMTPA id <0PTC01C926PO8T40@dDREAMS>; Wed, 19 Jun 2019 17:10:48 +0900 (JST) From: Shunsuke Homma Date: Wed, 19 Jun 2019 17:10:36 +0900 Message-id: <004801d52676$79cc0d70$6d642850$@hco.ntt.co.jp> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0049_01D526C1.E9B56320" X-Mailer: Microsoft Outlook 14.0 Thread-index: AdUmbWSs+c9Jg4Z+Ra6MZwsk5Iy8dw== Content-language: ja To: pidloc@ietf.org Cc: sarikaya@ieee.org, 'Luigi Iannone' , Dirk.von-Hugo@telekom.de X-TM-AS-GCONF: 00 Archived-At: Subject: [Pidloc] Comments on REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 X-BeenThere: pidloc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2019 08:10:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01D526C1.E9B56320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=20 It was disappointing that the BoF proposal could not get approval, but I = reviewed PS and Req drafts, and=20 send some comments. I felt that the situation where privacy problems would occur is = ambiguous, and thus I=E2=80=99d like propose following categorization on = deployment scenarios of ID-Loc as additional sections . ---- X. Deployment Scenarios of ID-Loc and Potential Risks=20 There are several variations on deployment of ID-Loc architecture. This = section describes the overviews of some deployment scenarios and their = potential risks. X.1. Internal of Single Administrative Domain In this scenario, all of ID Loc functions, such as mapping database or = ID-Loc node, run within a single administrative domain. For example, an = enterprise data center or a carrier network are categorized to this. The = locators are generally never know by 3rd parties, and there are few = risks that location or movement privacies are exposed.=20 X.2. Across Multiple Trust Domains In this scenario, ID-Loc functions are connected via domains of other = trusted administrators. For example, enterprise with multiple sites = connected via dedicated line is categorized to this. ID-Loc functions on = each site communicate over networks operated by other administrators, = and thus ID, locator, and the mapping may be grasped by the = administrators of the intermediate network. X.3. Across Un-Trusted Domains In this scenario, ID-Loc functions are connected via un-trusted domains = such as Internet. Both data and control planes of ID-Loc are = communicated via unspecified networks, and thus there are risks to be = stolen information about location or movement of ID by 3rd persons. X.4. Globally Distributed In this scenario, ID-Loc is used instead of current IP mechanism, and = every packet is forwarded based on locators independent from IDs. ID-Loc = mapping system runs as hierarchical or decentralized system to provide = mapping of ID and locator for ID-Loc nodes of multiple (administrators) = domains. (I.e., ID-Loc mapping system runs as similar with DNS server.) = In such case, ID-Loc mapping system should be accessible for unspecified = nodes, and this means unspecified nodes are able to get the mapping = information. In addition, it is possible to be a target of attacks such = as DDoS attack. ---- Also, I have some small comments as below. - The status of such documents should be "Informational". - Scalability is actually important requirement, but the meaning is very = wide. It would be able to be broken down into several aspects such as = system implementation and the number of accommodated users. - Flexibility can be broken down as well. If you have any questions or opinions, please feel free to contact me. Best regards, Shunsuke =20 From: Pidloc [mailto:pidloc-bounces@ietf.org] On Behalf Of Behcet = Sarikaya Sent: Tuesday, May 28, 2019 12:15 AM To: pidloc@ietf.org Cc: Padma Pillay-Esnault; Subject: [Pidloc] REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 SUBMISSION =20 Folks, Just now, we submitted the requirement draft Rev. 00. Please read it, it is very short. Send your comments, text contributions to the list. Have a nice Memorial Day. =20 Regards, Behcet A new version of I-D, draft-xyz-pidloc-reqs-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-xyz-pidloc-reqs Revision: 00 Title: Requirements to Secure End to End Privacy in IdLoc = Systems Document date: 2019-05-27 Group: Individual Submission Pages: 6 URL: = https://www.ietf.org/internet-drafts/draft-xyz-pidloc-reqs-00.txt Status: https://datatracker.ietf.org/doc/draft-xyz-pidloc-reqs/ Htmlized: https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00 Htmlized: = https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-reqs Abstract: Use of Identifier Locator separation systems is proposed for various use cases to allow for efficient and service aware flexible end-to- end routing. A statement on the issue of privacy preservation of both users and devices identity and location describes major challenges identified for this problem. This document attempts to derive requirements towards a potential solution space of approaches to preserve privacy in Identifier-Locator split (PidLoc) protocols. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ------=_NextPart_000_0049_01D526C1.E9B56320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

It was disappointing that the BoF proposal could not get = approval, but I reviewed PS and Req drafts, and
send some = comments.

I felt that the situation=C2=A0 where privacy problems = would occur is ambiguous, and thus I=E2=80=99d like propose following = categorization on deployment scenarios of ID-Loc as additional sections = .


----
X. Deployment Scenarios = of ID-Loc and Potential Risks

There are several variations on = deployment of ID-Loc architecture. This section describes the overviews = of some deployment scenarios and their potential risks.


X.1. = Internal of Single Administrative Domain
In this scenario, all of ID = Loc functions, such as mapping database or ID-Loc node, run within a = single administrative domain.  For example, an enterprise data = center or a carrier network are categorized to this. The locators are = generally never know by 3rd parties, and there are few risks that = location or movement privacies are exposed.

X.2. Across Multiple = Trust Domains
In this scenario, ID-Loc functions are connected via = domains of other trusted administrators. For example,  enterprise = with multiple sites connected via dedicated line is categorized to this. = ID-Loc functions on each site communicate over networks operated by = other administrators, and thus ID, locator, and  the mapping may be = grasped by the administrators of the intermediate = network.


X.3. Across Un-Trusted Domains
In this scenario, = ID-Loc functions are connected via un-trusted domains such as Internet. = Both  data and control planes of ID-Loc are communicated via = unspecified networks, and thus there are risks to be stolen information = about location or movement of ID by 3rd persons.

X.4. Globally = Distributed
In this scenario, ID-Loc is used instead of current IP = mechanism, and every packet is forwarded based on locators independent = from IDs. ID-Loc mapping system runs as hierarchical or decentralized = system to provide mapping of ID and locator for ID-Loc nodes of multiple = (administrators) domains. (I.e., ID-Loc mapping system runs as similar = with DNS server.) In such case, ID-Loc mapping system should be = accessible for unspecified nodes, and this means unspecified nodes are = able to get the mapping information. In addition, it is possible to be a = target of attacks such as DDoS attack.

----

Also, I have some small comments as = below.
- The status of such documents should be = "Informational".
- Scalability is actually important = requirement, but the meaning is very wide. It would be able to be broken = down into several aspects such as system implementation and the number = of accommodated users.
- Flexibility can be broken down  as = well.



If you have any questions or opinions, please feel free to = contact me.

Best = regards,

Shunsuke



 

From:= Pidloc = [mailto:pidloc-bounces@ietf.org] On Behalf Of Behcet = Sarikaya
Sent: Tuesday, May 28, 2019 12:15 AM
To: = pidloc@ietf.org
Cc: Padma Pillay-Esnault; = <Dirk.von-Hugo@telekom.de>
Subject: [Pidloc] REQUIREMENT = DRAFT draft-xyz-pidloc-reqs-00 SUBMISSION

 

Folks,


Just now, we submitted the = requirement draft Rev. 00.

Please read it, it is very = short.

Send your comments, text contributions to the = list.

Have a nice Memorial = Day.

 

Regards,

Behcet



A new version of I-D, = draft-xyz-pidloc-reqs-00.txt
has been successfully submitted by = Behcet Sarikaya and posted to the
IETF repository.

Name:  =         =  draft-xyz-pidloc-reqs
Revision:      =  00
Title:          Requirements to = Secure End to End Privacy in IdLoc Systems
Document date:  = 2019-05-27
Group:          Individual = Submission
Pages:          6
URL:  =           https://www.ietf.org/internet-drafts/draft-xyz-pidloc-r= eqs-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xyz-pidloc-reqs/=
Htmlized:       https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-= reqs


Abstract:
   Use of Identifier Locator = separation systems is proposed for various
   use cases to = allow for efficient and service aware flexible end-to-
  =  end routing.  A statement on the issue of privacy = preservation of
   both users and devices identity and = location describes major
   challenges identified for this = problem.  This document attempts to
   derive = requirements towards a potential solution space of approaches
  =  to preserve privacy in Identifier-Locator split (PidLoc) = protocols.




Please note that it may take a couple of = minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF = Secretariat

------=_NextPart_000_0049_01D526C1.E9B56320-- From nobody Thu Jun 27 06:40:57 2019 Return-Path: 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 2630612012C for ; Thu, 27 Jun 2019 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcn-ssu-ac-kr.20150623.gappssmtp.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 k5j2ohU4buWr for ; Thu, 27 Jun 2019 06:40:51 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 419A112013C for ; Thu, 27 Jun 2019 06:40:50 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id a93so1339338pla.7 for ; Thu, 27 Jun 2019 06:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dcn-ssu-ac-kr.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iJu3O47KYuCZWcc/lo1TKLmBbW/V+d4pIsBYBzBzirM=; b=DahVPG5CXWN3eFLLau+P5YcRvAE+HvNarw8CEjtz0VWR0/m1bDXaSQp1N16VpOtHuw H8Z2/yQwF3XqnGwZUZUIa0Bg0ZMdB7QG2rao6KaW/WZuQUfh0Zz4OsnMDjYHA6DSIbXU Sl5Q1Jmv4AKbDkX9cFFcv4b1k2a9MWTBK2AUiTs/gKQtdjJQ7ZlBGaNpzCayzSZBSaXJ cQ7jGLCgytZmkHgKRi+di8CCWHOrB1vDCYNqcBc3kzzdoxwpfzckqg3Q5BZx7OU+6Tjx 5xzipj3oNuTzWDEs085QPZtiNBbd/2DtYy/GLcj0l4mT+u7/ZfC6sWvJjxHg2cWBYKfq EGjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iJu3O47KYuCZWcc/lo1TKLmBbW/V+d4pIsBYBzBzirM=; b=nmeG0VR5xIEm1443257/7xtk0G99cqbkOTKLJRa4rQjew6RNciW8xanIBBasedt7dB +fYfpkHJ6+os2Ctw6hvb7+R+gc6aJHGe58pQGo6ij5NAZ6MJm27KrG2pE1b8xWeRjFXS sGV8xZIF1V2Iparhw8D12nxn1ZMtAQqq9iW/wD2VvXa+8tBd4VAH1D/gwHIjO0yVn6Wm 93FpJbCXG71gi064ab7Pzp+4kXPEFTTK1gc1+A/0MXinFh1tMZQEbd7QSVWubqeud/Dw T3xTs70Id3xKPhKU8ZCjp0HTt42jFuI9pkNR0v/w5B9mWAEQJOAHk4ZHCpomer+kMhmL +FWw== X-Gm-Message-State: APjAAAUM+98GDVNSKTHq5hNhkj7AqvoRjz8Ds85pGVhVkvl+30WiyDqv w7lbKOsKV3d+2gagyc67BUdujQ== X-Google-Smtp-Source: APXvYqwVduRYc8bgfR4+0NWL9PBpgMPCDgLggpdTMQtwdFBl7255rU/1BrQUyph0T7q/W+NZnxiHRA== X-Received: by 2002:a17:902:e65:: with SMTP id 92mr4594975plw.13.1561642850295; Thu, 27 Jun 2019 06:40:50 -0700 (PDT) Received: from [172.30.1.44] ([14.63.57.253]) by smtp.gmail.com with ESMTPSA id s24sm3006668pfh.133.2019.06.27.06.40.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 06:40:49 -0700 (PDT) From: =?utf-8?B?7ISg6rK97J6s?= Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B2278031-377C-4D29-B281-CFB95CC8C3C5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 22:40:45 +0900 In-Reply-To: <004801d52676$79cc0d70$6d642850$@hco.ntt.co.jp> Cc: pidloc@ietf.org, Luigi Iannone , sarikaya@ieee.org, Dirk.von-Hugo@telekom.de To: Shunsuke Homma References: <004801d52676$79cc0d70$6d642850$@hco.ntt.co.jp> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Pidloc] Comments on REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 X-BeenThere: pidloc@ietf.org 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, 27 Jun 2019 13:40:55 -0000 --Apple-Mail=_B2278031-377C-4D29-B281-CFB95CC8C3C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi behcet and Dirk, I am sorry to give comments for pidloc draft. When I read requirements document, I agree with Shunsuke=E2=80=99s = comment about =E2=80=9CFlexibility=E2=80=9D part. Not only privacy can be provided differ depending time and space, even = sometimes it has to be maintain stable privacy requirement when time or = space is changed. In my opinion, =E2=80=9CFlexibility=E2=80=9D part should be covered both = aspects. 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 gomjae@dcn.ssu.ac.kr > 2019. 6. 19. =EC=98=A4=ED=9B=84 5:10, Shunsuke Homma = =EC=9E=91=EC=84=B1: >=20 > Hi,=20 >=20 > It was disappointing that the BoF proposal could not get approval, but = I reviewed PS and Req drafts, and=20 > send some comments. >=20 > I felt that the situation where privacy problems would occur is = ambiguous, and thus I=E2=80=99d like propose following categorization on = deployment scenarios of ID-Loc as additional sections .. >=20 >=20 > ---- > X. Deployment Scenarios of ID-Loc and Potential Risks=20 >=20 > There are several variations on deployment of ID-Loc architecture. = This section describes the overviews of some deployment scenarios and = their potential risks. >=20 >=20 > X.1. Internal of Single Administrative Domain > In this scenario, all of ID Loc functions, such as mapping database or = ID-Loc node, run within a single administrative domain. For example, an = enterprise data center or a carrier network are categorized to this. The = locators are generally never know by 3rd parties, and there are few = risks that location or movement privacies are exposed.=20 >=20 > X.2. Across Multiple Trust Domains > In this scenario, ID-Loc functions are connected via domains of other = trusted administrators. For example, enterprise with multiple sites = connected via dedicated line is categorized to this. ID-Loc functions on = each site communicate over networks operated by other administrators, = and thus ID, locator, and the mapping may be grasped by the = administrators of the intermediate network. >=20 >=20 > X.3. Across Un-Trusted Domains > In this scenario, ID-Loc functions are connected via un-trusted = domains such as Internet. Both data and control planes of ID-Loc are = communicated via unspecified networks, and thus there are risks to be = stolen information about location or movement of ID by 3rd persons. >=20 > X.4. Globally Distributed > In this scenario, ID-Loc is used instead of current IP mechanism, and = every packet is forwarded based on locators independent from IDs. ID-Loc = mapping system runs as hierarchical or decentralized system to provide = mapping of ID and locator for ID-Loc nodes of multiple (administrators) = domains. (I.e., ID-Loc mapping system runs as similar with DNS server.) = In such case, ID-Loc mapping system should be accessible for unspecified = nodes, and this means unspecified nodes are able to get the mapping = information. In addition, it is possible to be a target of attacks such = as DDoS attack. >=20 > ---- >=20 > Also, I have some small comments as below. > - The status of such documents should be "Informational". > - Scalability is actually important requirement, but the meaning is = very wide. It would be able to be broken down into several aspects such = as system implementation and the number of accommodated users. > - Flexibility can be broken down as well. >=20 >=20 >=20 > If you have any questions or opinions, please feel free to contact me. >=20 > Best regards, >=20 > Shunsuke >=20 >=20 >=20 > =C2=A0 <> > From: Pidloc [mailto:pidloc-bounces@ietf.org = ] On Behalf Of Behcet Sarikaya > Sent: Tuesday, May 28, 2019 12:15 AM > To: pidloc@ietf.org > Cc: Padma Pillay-Esnault; > > Subject: [Pidloc] REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 = SUBMISSION > =20 > Folks, >=20 > Just now, we submitted the requirement draft Rev. 00. > Please read it, it is very short. > Send your comments, text contributions to the list. > Have a nice Memorial Day. > =20 > Regards, > Behcet >=20 >=20 > A new version of I-D, draft-xyz-pidloc-reqs-00.txt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. >=20 > Name: draft-xyz-pidloc-reqs > Revision: 00 > Title: Requirements to Secure End to End Privacy in IdLoc = Systems > Document date: 2019-05-27 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-xyz-pidloc-reqs-00.txt = > Status: = https://datatracker.ietf.org/doc/draft-xyz-pidloc-reqs/ = > Htmlized: https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-reqs = >=20 >=20 > Abstract: > Use of Identifier Locator separation systems is proposed for = various > use cases to allow for efficient and service aware flexible end-to- > end routing. A statement on the issue of privacy preservation of > both users and devices identity and location describes major > challenges identified for this problem. This document attempts to > derive requirements towards a potential solution space of = approaches > to preserve privacy in Identifier-Locator split (PidLoc) protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 > --=20 > Pidloc mailing list > Pidloc@ietf.org > https://www.ietf.org/mailman/listinfo/pidloc = --Apple-Mail=_B2278031-377C-4D29-B281-CFB95CC8C3C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi behcet and Dirk,

I am sorry to give comments for pidloc = draft.

When I = read requirements document, I agree with Shunsuke=E2=80=99s comment = about =E2=80=9CFlexibility=E2=80=9D part.

Not only privacy can be provided differ = depending time and space, even sometimes it has to be maintain stable = privacy requirement when time or space is changed.

In my opinion, = =E2=80=9CFlexibility=E2=80=9D part should be covered both = aspects.


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 = gomjae@dcn.ssu.ac.kr



2019. 6. 19. =EC=98=A4=ED=9B=84 5:10, Shunsuke Homma <shunsuke.homma.fp@hco.ntt.co.jp> =EC=9E=91=EC=84=B1:
Hi, 

It was disappointing that the BoF proposal could not get = approval, but I reviewed PS and Req drafts, and 
send some = comments.

I felt that the situation  = where privacy problems would occur is ambiguous, and thus I=E2=80=99d = like propose following categorization on deployment scenarios of ID-Loc = as additional sections ..


----
X. = Deployment Scenarios of ID-Loc and Potential Risks 

There are several variations on deployment of ID-Loc = architecture. This section describes the overviews of some deployment = scenarios and their potential risks.


X.1. Internal of Single Administrative Domain
In = this scenario, all of ID Loc functions, such as mapping database or = ID-Loc node, run within a single administrative domain.  For = example, an enterprise data center or a carrier network are categorized = to this. The locators are generally never know by 3rd parties, and there = are few risks that location or movement privacies are exposed. 

X.2. Across Multiple Trust Domains
In this = scenario, ID-Loc functions are connected via domains of other trusted = administrators. For example,  enterprise with multiple sites = connected via dedicated line is categorized to this. ID-Loc functions on = each site communicate over networks operated by other administrators, = and thus ID, locator, and  the mapping may be grasped by the = administrators of the intermediate network.


X.3. Across Un-Trusted Domains
In = this scenario, ID-Loc functions are connected via un-trusted domains = such as Internet. Both  data and control planes of ID-Loc are = communicated via unspecified networks, and thus there are risks to be = stolen information about location or movement of ID by 3rd persons.

X.4. Globally Distributed
In = this scenario, ID-Loc is used instead of current IP mechanism, and every = packet is forwarded based on locators independent from IDs. ID-Loc = mapping system runs as hierarchical or decentralized system to provide = mapping of ID and locator for ID-Loc nodes of multiple (administrators) = domains. (I.e., ID-Loc mapping system runs as similar with DNS server.) = In such case, ID-Loc mapping system should be accessible for unspecified = nodes, and this means unspecified nodes are able to get the mapping = information. In addition, it is possible to be a target of attacks such = as DDoS attack.

----

Also, I have some = small comments as below.
- The status of such documents = should be "Informational".
- Scalability is actually = important requirement, but the meaning is very wide. It would be able to = be broken down into several aspects such as system implementation and = the number of accommodated users.
- Flexibility can be = broken down  as well.



If = you have any questions or opinions, please feel free to contact me.

Best regards,

Shunsuke



 
From: Pidloc [mailto:pidloc-bounces@ietf.org] On Behalf = Of Behcet = Sarikaya
Sent: Tuesday, May 28, 2019 12:15 = AM
To: pidloc@ietf.org
Cc: Padma= Pillay-Esnault; <Dirk.von-Hugo@telekom.de>
Subject: [Pidloc] REQUIREMENT DRAFT = draft-xyz-pidloc-reqs-00 SUBMISSION
 
Folks,

Just now, we submitted the requirement draft Rev. 00.
Please read it, it is very short.
Send your comments, text contributions to the = list.
Have a nice Memorial = Day.
 
Regards,
Behcet



A new version of I-D, = draft-xyz-pidloc-reqs-00.txt
has been successfully = submitted by Behcet Sarikaya and posted to the
IETF = repository.

Name:      =      draft-xyz-pidloc-reqs
Revision:  =      00
Title:        =   Requirements to Secure End to End Privacy in IdLoc Systems
Document date:  2019-05-27
Group:  =         Individual Submission
Pages:          6
URL:            https://www.ietf.org/internet-drafts/draft-xyz-pidloc-reqs-00.t= xt
Status:         https://datatracker.ietf.org/doc/draft-xyz-pidloc-reqs/
Htmlized:       https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-reqs=


Abstract:
   Use of Identifier Locator separation systems is = proposed for various
   use cases to allow for = efficient and service aware flexible end-to-
  =  end routing.  A statement on the issue of privacy = preservation of
   both users and devices = identity and location describes major
  =  challenges identified for this problem.  This document = attempts to
   derive requirements towards a = potential solution space of approaches
   to = preserve privacy in Identifier-Locator split (PidLoc) protocols.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF Secretariat

-- 
Pidloc mailing list
Pidloc@ietf.org
https://www.ietf.org/mailman/listinfo/pidloc

= --Apple-Mail=_B2278031-377C-4D29-B281-CFB95CC8C3C5-- From nobody Thu Jun 27 07:41:02 2019 Return-Path: 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 340A51200F6 for ; Thu, 27 Jun 2019 07:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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_HELO_NONE=0.001, 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 LBtKxUf2xRIq for ; Thu, 27 Jun 2019 07:40:57 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 188AF1200E5 for ; Thu, 27 Jun 2019 07:40:57 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id k128so1573645ywf.2 for ; Thu, 27 Jun 2019 07:40:57 -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=tNOYtwagJWX2Qyq8+EF0rJVTPmt7r/o8IQSPHUqgVgA=; b=nLBHEwD70bYvjCo2rG6CCMDN5ieoje5kg4UlYx9AuTej8P8dPZCxmE4YIOB85PugXK BFQB56mx31poQFRgEY95P3M8WwBQYboJpTIr7f+++Q7HF+mfnwmrR56uQUhA2lb9i8nD HV0qz8hZQQb1MojNNsxZaAnLpo8xKZw1yRyopov3LmOxtwpnZgupHNF148ZBPXY0i0qV VaG/knx63f1aGuCPVgmOoJnrIDehaoAk1aUUaB12Wr8cq3eG6MnTjDlQX/D9PJeSgmv7 M+lkbfRG1NJQniLUsy9yEjWRNwpd24gPXVDaVdKdqUdvW1dTwhPQ25Iv3Q6Bh8mvHuX3 mqPw== 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=tNOYtwagJWX2Qyq8+EF0rJVTPmt7r/o8IQSPHUqgVgA=; b=nlU9xYn839IKEO5203Dg1a1myC1C9iMNiX4xuDk7XIYVc7cksiuKyweADKNTtX8YGQ tV3gjC9kE5XrO4gQ2mLf378fMItS/aeT1Cx2WPZ7vr/xEh3EBWe3GJG5xL3+99xrciWJ 4nkWRjS4wjofA2Yh18WROQBrPk3WtLo3SSoUgSWj2AZ5fbV97tTkDU9l7H3AlqvjqF2Y fwl1ImGCrAAfRYzU2EpSp5HzQnj24LwCcsXJykogwx1JskHAnL9oOIqwGkPYEslrjPXh sBHSH9LL86nnyTbuHX38EIzNtsvGOQJJ3bD871lr1cHvEuZZ64SVBoYPdcQSS4uZB74a akig== X-Gm-Message-State: APjAAAWpbknDVmQ4W2uEIS6USNgoltRtl0HJWeq2EB0O6vrD94xhF3Ib Y9mZz9Uh7v7t5E2sBewBV70Spx75xxecQMAGET0= X-Google-Smtp-Source: APXvYqwdDXbtxWXc4FNmCIc85uKQmLKnc8SYUK93Z52aN2s7xJjq1UzN1JdXTIsaqWS6G6tDebzfzV3EX+n6dpiZ4Kk= X-Received: by 2002:a81:6e88:: with SMTP id j130mr2537998ywc.509.1561646456207; Thu, 27 Jun 2019 07:40:56 -0700 (PDT) MIME-Version: 1.0 References: <004801d52676$79cc0d70$6d642850$@hco.ntt.co.jp> In-Reply-To: <004801d52676$79cc0d70$6d642850$@hco.ntt.co.jp> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Thu, 27 Jun 2019 09:40:45 -0500 Message-ID: To: Shunsuke Homma Cc: pidloc@ietf.org, Luigi Iannone , "" Content-Type: multipart/alternative; boundary="000000000000497cad058c4f266a" Archived-At: Subject: Re: [Pidloc] Comments on REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 X-BeenThere: pidloc@ietf.org 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, 27 Jun 2019 14:41:00 -0000 --000000000000497cad058c4f266a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Folks, Thanks for all the comments. Now that we received some feedback from SEC ADs, we need to consider those and take future steps based on that. One feedback was if I am not wrong there were too many use cases. Dirk is going to talk to the ADs during IETF 105 week next month and hopefully get a more clear picture of what they want. Let's see what they say. I think that any further action on the existing work should be delayed until that time. Right now I can say that we drop the side meeting plan and replace it with SAAG presentation on Thursday July 25. Those who are attending IETF 105 please make sure to be there at the SAAG meeting. SAAG meeting attracts a large audience, usually SEC area WG chairs shortly present their sessions, and some additional presentations like proposed BOFs. Regards, Behcet On Wed, Jun 19, 2019 at 3:10 AM Shunsuke Homma < shunsuke.homma.fp@hco.ntt.co.jp> wrote: > Hi, > > It was disappointing that the BoF proposal could not get approval, but I > reviewed PS and Req drafts, and > send some comments. > > I felt that the situation where privacy problems would occur is > ambiguous, and thus I=E2=80=99d like propose following categorization on = deployment > scenarios of ID-Loc as additional sections . > > > ---- > X. Deployment Scenarios of ID-Loc and Potential Risks > > There are several variations on deployment of ID-Loc architecture. This > section describes the overviews of some deployment scenarios and their > potential risks. > > > X.1. Internal of Single Administrative Domain > In this scenario, all of ID Loc functions, such as mapping database or > ID-Loc node, run within a single administrative domain. For example, an > enterprise data center or a carrier network are categorized to this. The > locators are generally never know by 3rd parties, and there are few risks > that location or movement privacies are exposed. > > X.2. Across Multiple Trust Domains > In this scenario, ID-Loc functions are connected via domains of other > trusted administrators. For example, enterprise with multiple sites > connected via dedicated line is categorized to this. ID-Loc functions on > each site communicate over networks operated by other administrators, and > thus ID, locator, and the mapping may be grasped by the administrators o= f > the intermediate network. > > > X.3. Across Un-Trusted Domains > In this scenario, ID-Loc functions are connected via un-trusted domains > such as Internet. Both data and control planes of ID-Loc are communicate= d > via unspecified networks, and thus there are risks to be stolen informati= on > about location or movement of ID by 3rd persons. > > X.4. Globally Distributed > In this scenario, ID-Loc is used instead of current IP mechanism, and > every packet is forwarded based on locators independent from IDs. ID-Loc > mapping system runs as hierarchical or decentralized system to provide > mapping of ID and locator for ID-Loc nodes of multiple (administrators) > domains. (I.e., ID-Loc mapping system runs as similar with DNS server.) I= n > such case, ID-Loc mapping system should be accessible for unspecified > nodes, and this means unspecified nodes are able to get the mapping > information. In addition, it is possible to be a target of attacks such a= s > DDoS attack. > > ---- > > Also, I have some small comments as below. > - The status of such documents should be "Informational". > - Scalability is actually important requirement, but the meaning is very > wide. It would be able to be broken down into several aspects such as > system implementation and the number of accommodated users. > - Flexibility can be broken down as well. > > > > If you have any questions or opinions, please feel free to contact me. > > Best regards, > > Shunsuke > > > > > > *From:* Pidloc [mailto:pidloc-bounces@ietf.org] *On Behalf Of *Behcet > Sarikaya > *Sent:* Tuesday, May 28, 2019 12:15 AM > *To:* pidloc@ietf.org > *Cc:* Padma Pillay-Esnault; > *Subject:* [Pidloc] REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 SUBMISSION > > > > Folks, > > > Just now, we submitted the requirement draft Rev. 00. > > Please read it, it is very short. > > Send your comments, text contributions to the list. > > Have a nice Memorial Day. > > > > Regards, > > Behcet > > > > A new version of I-D, draft-xyz-pidloc-reqs-00.txt > has been successfully submitted by Behcet Sarikaya and posted to the > IETF repository. > > Name: draft-xyz-pidloc-reqs > Revision: 00 > Title: Requirements to Secure End to End Privacy in IdLoc System= s > Document date: 2019-05-27 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-xyz-pidloc-reqs-00.txt > Status: https://datatracker.ietf.org/doc/draft-xyz-pidloc-reqs/ > Htmlized: https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-xyz-pidloc-reqs > > > Abstract: > Use of Identifier Locator separation systems is proposed for various > use cases to allow for efficient and service aware flexible end-to- > end routing. A statement on the issue of privacy preservation of > both users and devices identity and location describes major > challenges identified for this problem. This document attempts to > derive requirements towards a potential solution space of approaches > to preserve privacy in Identifier-Locator split (PidLoc) protocols. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > --000000000000497cad058c4f266a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Folks,

Thanks for all the comments.
Now that we received some feedback from SEC ADs, we need to consider= those and take future steps based on that. One feedback was if I am not wr= ong there were too many use cases.
Dirk is going to talk to the A= Ds during IETF 105 week next month and hopefully get a more clear picture o= f what they want.=C2=A0
Let's see what they say. I think that= any further action on the existing work should be delayed until that time.= =C2=A0

Right now I can say that we drop the side m= eeting plan and replace it with SAAG presentation on Thursday July 25.=C2= =A0
Those who are attending IETF 105 please make sure to be there= at the SAAG meeting.=C2=A0
SAAG meeting attracts a large audienc= e, usually SEC area WG chairs shortly present their sessions, and some addi= tional presentations like proposed BOFs.

Regards,<= /div>
Behcet

On Wed, Jun 19, 2019 at 3:10 AM Shunsuke Homma <shunsuke.homma.fp@hco.ntt.= co.jp> wrote:

Hi,

It was disappointing that the BoF proposal could = not get approval, but I reviewed PS and Req drafts, and
send some comme= nts.

I felt that the situation=C2=A0 where privacy problems would oc= cur is ambiguous, and thus I=E2=80=99d like propose following categorizatio= n on deployment scenarios of ID-Loc as additional sections .


---= -
X. Deployment Scenarios of ID-Loc and Pote= ntial Risks

There are several variations on deployment of ID-Loc ar= chitecture. This section describes the overviews of some deployment scenari= os and their potential risks.


X.1. Internal of Single Administra= tive Domain
In this scenario, all of ID Loc functions, such as mapping d= atabase or ID-Loc node, run within a single administrative domain.=C2=A0 Fo= r example, an enterprise data center or a carrier network are categorized t= o this. The locators are generally never know by 3rd parties, and there are= few risks that location or movement privacies are exposed.

X.2. Ac= ross Multiple Trust Domains
In this scenario, ID-Loc functions are conne= cted via domains of other trusted administrators. For example, =C2=A0enterp= rise with multiple sites connected via dedicated line is categorized to thi= s. ID-Loc functions on each site communicate over networks operated by othe= r administrators, and thus ID, locator, and =C2=A0the mapping may be graspe= d by the administrators of the intermediate network.


X.3. Across= Un-Trusted Domains
In this scenario, ID-Loc functions are connected via= un-trusted domains such as Internet. Both =C2=A0data and control planes of= ID-Loc are communicated via unspecified networks, and thus there are risks= to be stolen information about location or movement of ID by 3rd persons.<= br>
X.4. Globally Distributed
In this scenario, ID-Loc is used instea= d of current IP mechanism, and every packet is forwarded based on locators = independent from IDs. ID-Loc mapping system runs as hierarchical or decentr= alized system to provide mapping of ID and locator for ID-Loc nodes of mult= iple (administrators) domains. (I.e., ID-Loc mapping system runs as similar= with DNS server.) In such case, ID-Loc mapping system should be accessible= for unspecified nodes, and this means unspecified nodes are able to get th= e mapping information. In addition, it is possible to be a target of attack= s such as DDoS attack.

----

Also, I have some small comments as below.
- The = status of such documents should be "Informational".
- Scalabil= ity is actually important requirement, but the meaning is very wide. It wou= ld be able to be broken down into several aspects such as system implementa= tion and the number of accommodated users.
- Flexibility can be broken d= own =C2=A0as well.



If you have a= ny questions or opinions, please feel free to contact me.

Best regar= ds,

Shunsuke



=C2=A0

From: Pidloc [mailto:pidloc-bounces@ietf.org] On Behalf Of Behcet Sarikay= a
Sent: Tuesday, May 28, 2019 12:15 AM
To: pidloc@ietf.org
Cc: = Padma Pillay-Esnault; <Dirk.von-Hugo@telekom.de>
Subject: [Pidloc] R= EQUIREMENT DRAFT draft-xyz-pidloc-reqs-00 SUBMISSION

=C2=A0

Folks,


Just now, we su= bmitted the requirement draft Rev. 00.

<= p class=3D"MsoNormal">Please read it, it is very short= .

Send your comments, text contributions to the list.

Have a nice M= emorial Day.

=C2=A0

Regards,

Behcet

=

A new version of I-D, draft-xyz-pidloc-reqs-00.txt
has been succ= essfully submitted by Behcet Sarikaya and posted to the
IETF repository.=

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-xyz-pidloc-reqs=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Requirements to Secure End to End Privacy in IdLoc SystemsDocument date:=C2=A0 2019-05-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
= URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://= www.ietf.org/internet-drafts/draft-xyz-pidloc-reqs-00.txt
Status:=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/= draft-xyz-pidloc-reqs/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-xyz-pidloc-reqs-00
Htmlized:=C2= =A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/htm= l/draft-xyz-pidloc-reqs


Abstract:
=C2=A0 =C2=A0Use of Ide= ntifier Locator separation systems is proposed for various
=C2=A0 =C2=A0= use cases to allow for efficient and service aware flexible end-to-
=C2= =A0 =C2=A0end routing.=C2=A0 A statement on the issue of privacy preservati= on of
=C2=A0 =C2=A0both users and devices identity and location describe= s major
=C2=A0 =C2=A0challenges identified for this problem.=C2=A0 This = document attempts to
=C2=A0 =C2=A0derive requirements towards a potentia= l solution space of approaches
=C2=A0 =C2=A0to preserve privacy in Ident= ifier-Locator split (PidLoc) protocols.




Please note that= it may take a couple of minutes from the time of submission
until the h= tmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000497cad058c4f266a--