Re: [Pidloc] PIdLoc Webex

Tom Herbert <> Wed, 05 December 2018 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5C8F130DF7 for <>; Wed, 5 Dec 2018 14:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 QSavQQnO7gHW for <>; Wed, 5 Dec 2018 14:08:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2804012D4E8 for <>; Wed, 5 Dec 2018 14:08:39 -0800 (PST)
Received: by with SMTP id l14so18022712ioj.5 for <>; Wed, 05 Dec 2018 14:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kMaTCpQHuZVAgL9crCu8kcOsdlI89MH9tPOgKFxXk3Q=; b=i/cofCTyRw8BnkvOY3YMGkodHnCjuK37yN4/nUzKx7SLFDiN6OWBbNjChHPySUXWMm p0HPp+UMTUhYNg8JRT8EQKwOWeuaWE3f9baa6NaVqrCdiNLuIB6o4e54zNCb0ZqVLkdD o9S+QVPYqoFEvAY17ZyPp8zDnSxXqZjV6WZgzTG3I0lGGZ0/+N59c3pzQIwROHsVfm0w brAWDypKCHX0J5UgDtpUkhkZpPAHwhrWm5AdhmjHu+1LfgApnfB6/PmLmlnvuKQNghJ6 e+UzD/a2pbqR3S53BJiCsV35om1fx9ygdXM7PHzPFpa+ZuKctASZoYAC5Xsoj5ta+oyC 1owQ==
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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kMaTCpQHuZVAgL9crCu8kcOsdlI89MH9tPOgKFxXk3Q=; b=RHve0TgCUgfpHhBw1q6rhzjFcGSWA9yc5U6zy1AoPGXT40wqMZH3VdodtDz0ooNfnr WhnwCSe8t4FCxqp6C3Z81mwSOPX+MQXTINaSUT4TRt8xGn/E/tZ3kAWh3hO9iIt3G2wC BHAONy84xjkfpi6YtDespL85hxoZtuURerdHFgp7k2NhHVLrvyCRdoN6s7nOyeHJlwN0 ikbUrOrYDyfC/DTGvro56HaleCRdgZ+QQ7UmzxF6z52XcXpOWkjZb0o44qxJeDh5tbxn ffDVmEsHdrT51kACgTgbSPFBIREd1kN2Tm0LOAkbdMsdceBqw4foq+bSlgvRlXTLlO4M cNlA==
X-Gm-Message-State: AA+aEWaJ+1hany29vuUPibB0voyxbYnJY6JMHtS29Tu1RgOaXPRNENmd CVi6s04HhGS5ayE07XVzhr1/mf+FNW1Rabu9ntVt6w==
X-Google-Smtp-Source: AFSGD/Xwl4oZ6oNzmO6s5o93ncGFmMbFeN+UqLRXMKI5uZE0ZlydXHPdt+VSCQBZDvqwLqbVZNGqkYv1BnEDMGm1u3A=
X-Received: by 2002:a5e:8c1a:: with SMTP id n26mr9334255ioj.122.1544047718223; Wed, 05 Dec 2018 14:08:38 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 5 Dec 2018 14:08:26 -0800
Message-ID: <>
To: Dino Farinacci <>
Cc:,,, Shunsuke Homma <>, Behcet Sarikaya <>, Luigi Iannone <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Pidloc] PIdLoc Webex
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, 05 Dec 2018 22:08:41 -0000

On Wed, Dec 5, 2018 at 1:42 PM Dino Farinacci <> wrote:
> > DTLS could be applied to any UDP tunneling protocol, but that's not
> Just to let you know that is not what I was suggesting. LISP could be use DTLS for its UDP control messages. Not tunneled packets since RFC 8061 (LISP-crypto) solves that.
> > really where the privacy problem lies. Presuming that as much of the
> > packet is encrypted as possible, then the question becomes what can be
> > inferred from the non-encrypted portions of the packet to breach
> > someone's privacy. The obvious data that could be exploited are the IP
> > addresses in a packet. There's at least two possible exploits: 1)
> Yes for any protocol design.
> > Addresses allow correlations between two different flows that they are
> > originated by the same user 2) Geo-location of a user can be deduced
> > from observed addresses. The actual identity of a user isn't
> > immediately available in addresses, but there's a fairly simple method
> > to deduce identity using #1.
> Only in the case of interacting with the mapping system, an eavesdropper can determine that an IP address is talking to a map-server or map-resolver but doesn’t know why and for what endpoints.


Just run your mapping system in a closed and presumably secured
network. Every service provider can run their own mapping system and
there's no need or value to build global mapping databases.

> That’s the best any design can hope for. The IP header can only be sent in the clear.
In order to communicate with Internet hosts plain text addresses are
used in packets. The are identifiers in idloc terminology and they are
exposed to the whole Internet. It's the privacy properties of these
that are of interest. For instance, today many service providers
assign a /64 to their users. So, that means that if a third party on
the Internet observes two flow with source addresses sharing the same
sixty-four bit prefix they can deduce that the source is the same (the
same user in case of personal devices). What is really needed for
privacy is to use a different uncorrelatable address per flow. Under
certain conditions, CGNAT provides that today which is why law
enforcement agencies are terrified of it. In lieu of NAT, idloc could
key to provide this privacy without resorting to NAT. See


> Dino