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

Behcet Sarikaya <> Thu, 27 June 2019 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 340A51200F6 for <>; Thu, 27 Jun 2019 07:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.747
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LBtKxUf2xRIq for <>; Thu, 27 Jun 2019 07:40:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 188AF1200E5 for <>; Thu, 27 Jun 2019 07:40:57 -0700 (PDT)
Received: by 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;; 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;; 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$>
In-Reply-To: <004801d52676$79cc0d70$6d642850$>
From: Behcet Sarikaya <>
Date: Thu, 27 Jun 2019 09:40:45 -0500
Message-ID: <>
To: Shunsuke Homma <>
Cc:, Luigi Iannone <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000497cad058c4f266a"
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 14:41:00 -0000


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
SAAG meeting attracts a large audience, usually SEC area WG chairs shortly
present their sessions, and some additional presentations like proposed


On Wed, Jun 19, 2019 at 3:10 AM Shunsuke Homma <>; 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’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