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

선경재 <> Thu, 27 June 2019 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2630612012C for <>; Thu, 27 Jun 2019 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k5j2ohU4buWr for <>; Thu, 27 Jun 2019 06:40:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 419A112013C for <>; Thu, 27 Jun 2019 06:40:50 -0700 (PDT)
Received: by 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;; 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;; 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 [] ([]) by with ESMTPSA id s24sm3006668pfh.133.2019. (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$>
Cc:, Luigi Iannone <>,,
To: Shunsuke Homma <>
References: <004801d52676$79cc0d70$6d642850$>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Pidloc] Comments on REQUIREMENT DRAFT draft-xyz-pidloc-reqs-00
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

Hi behcet and Dirk,

I am sorry to give comments for pidloc draft.

When I read requirements document, I agree with Shunsuke’s comment about “Flexibility” 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, “Flexibility” part should be covered both aspects.



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

> 2019. 6. 19. 오후 5:10, Shunsuke Homma <> 작성:
> 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’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,
> Shunsuke
>   <>
> From: Pidloc [ <>] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, May 28, 2019 12:15 AM
> To: <>
> 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 Systems
> Document date:  2019-05-27
> Group:          Individual Submission
> Pages:          6
> URL:   <>
> Status: <>
> Htmlized: <>
> Htmlized: <>
> 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 <>.
> The IETF Secretariat
> -- 
> Pidloc mailing list
> <>
> <>