[Pidloc] Comments on REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00

Shunsuke Homma <shunsuke.homma.fp@hco.ntt.co.jp> Wed, 19 June 2019 08:10 UTC

Return-Path: <shunsuke.homma.fp@hco.ntt.co.jp>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 579CD1203F5 for <pidloc@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kErrKF7FzFHp for <pidloc@ietfa.amsl.com>; Wed, 19 Jun 2019 01:10:54 -0700 (PDT)
Received: from dish-sg.nttdocomo.co.jp (dish-sg.nttdocomo.co.jp []) by ietfa.amsl.com (Postfix) with ESMTP id 590B8120391 for <pidloc@ietf.org>; Wed, 19 Jun 2019 01:10:54 -0700 (PDT)
X-dD-Source: Outbound
Received: from zssg-mailmd104.ddreams.local (zssg-mailmd900.ddreams.local []) 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 []) 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 []) 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 []) by IMSVA (Postfix) with ESMTP id 8ABD68E6054; Wed, 19 Jun 2019 17:10:53 +0900 (JST)
Received: from localhost (unknown []) 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 []) by IMSVA (Postfix) with ESMTP id B04A88E6058; Wed, 19 Jun 2019 17:10:52 +0900 (JST)
Received: from zssg-mailua102.ddreams.local (unknown []) by zssg-mailmf103.ddreams.local (Postfix) with ESMTP; Wed, 19 Jun 2019 17:10:52 +0900 (JST)
Received: from RDSVVDI0392 (unknown []) by zssg-mailua102.ddreams.local (dDREAMS) with ESMTPA id <0PTC01C926PO8T40@dDREAMS>; Wed, 19 Jun 2019 17:10:48 +0900 (JST)
From: Shunsuke Homma <shunsuke.homma.fp@hco.ntt.co.jp>
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' <ggx@gigix.net>, Dirk.von-Hugo@telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/Yf7bt-EnmRzOlCK8e9IdLxXvK5s>
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: <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: Wed, 19 Jun 2019 08:10:57 -0000


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’d 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,



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



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.




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

   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