Re: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt

Uma Chunduri <> Mon, 09 October 2017 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C45BB134731 for <>; Mon, 9 Oct 2017 10:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zp6X2sc9Ac17 for <>; Mon, 9 Oct 2017 10:38:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33DFF13470B for <>; Mon, 9 Oct 2017 10:38:52 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DQF12873; Mon, 09 Oct 2017 17:38:50 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 9 Oct 2017 18:38:50 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Mon, 9 Oct 2017 10:38:47 -0700
From: Uma Chunduri <>
To: Tom Herbert <>, "" <>
Thread-Topic: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt
Thread-Index: AQHTPWoK1Z2fXPw0LEeyZ0a8im8qkKLbzLCg
Date: Mon, 9 Oct 2017 17:38:47 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59DBB42A.01C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6202a1057af89771528f2f12e17db8ea
Archived-At: <>
Subject: Re: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Oct 2017 17:38:55 -0000

> I've posted a draft to develop a software daemon that could control various mapping systems and identifier/locator protocols.

It seems you are contradicting yourself in couple of e-mails posted in IDEAS.
Not sure where you want to standardize the below "idlocd" mapping system.

>From Page 9:

	>5  Security Considerations

   	>Security is very important in identifier-locator mapping protocols.
   	>Any mapping system must be protected from authorized access that
   	>could lead to forged mapping entries or leak other data. ilocd should
   	>therefore run only with admin privileges and software signing should
   	>be used if idlocd were to allow dynamically loadable modules. Any
   	>access to a mapping system should have appropriate security. For an
   	>application to write into a mapping system its credentials must be

[Uma]:  This is what is being proposed in IDEAS - credential verification AKA authentication. It doesn't matter if this if the ID is the one used  in data plane directly (EID) or ephemeral one. 
                  The moment you authenticate (credential verification in your language), this can be construed is tracking the user of the ID,  as it's been discussed now.
                Sure, if this is deployed in a secure and local environment in a DC (for VM mobility), you may not needed.
                But your draft seems more generically applied to all ID/LOC protocols from Section 2 (LISP, ILNP, ILA...)

	>and the network communications for this should be encrypted.

[Uma]: Yes.

Uma C.

-----Original Message-----
From: Ideas [] On Behalf Of Tom Herbert
Sent: Wednesday, October 04, 2017 4:39 PM
Subject: [Ideas] Fwd: New Version Notification for draft-herbert-idlocd-00.txt


I've posted a draft to develop a software daemon that could control various mapping systems and identifier/locator protocols. I hope to have same code to make public in near future.


---------- Forwarded message ----------
From:  <>
Date: Wed, Oct 4, 2017 at 4:35 PM
Subject: New Version Notification for draft-herbert-idlocd-00.txt
To: Tom Herbert <>

A new version of I-D, draft-herbert-idlocd-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository.

Name:           draft-herbert-idlocd
Revision:       00
Title:          Identifier-locator control daemon
Document date:  2017-10-04
Group:          Individual Submission
Pages:          11

   Identifier-locator protocols rely on a mapping system that is able to
   map identifiers to locators. Such a mapping system is a type of
   key/value store. This draft proposes a design and implementation for
   an Identifier-Locator control daemon (idlocd). The intent is to
   provide an open source implementation that would be a basis for
   experimentation, development, and eventual deployment of identifier-
   locator solutions at large scale.

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

Ideas mailing list