Re: [Pidloc] PIdLoc Webex

Dino Farinacci <> Wed, 05 December 2018 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88A88130E03 for <>; Wed, 5 Dec 2018 13:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 flRxT3EzG56Q for <>; Wed, 5 Dec 2018 13:42:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABB7312D4E7 for <>; Wed, 5 Dec 2018 13:42:54 -0800 (PST)
Received: by with SMTP id z23so10695608plo.0 for <>; Wed, 05 Dec 2018 13:42:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4wyNqAzFanp/vQQF7DdmW+9Yw9MIyDiPSayB6RXk9AA=; b=mplJxbW8I2Iu0rAjvdnDCOttXezRFNPm6ulE75/Jx1WucPksX1myyydIyEXmSr2lP3 gu+kRUyZlmD+p9SsRji9ui9wa5xm3sbNHBaTupemzYOLAJqiaYf/guBPrhNiLpqDjEnE bLSUrVy04AZ/s5xEqkTbF6M6soi/MRMlv1T57oXawGsOrHsOSgj5g5W1vNPHolCKJcjy MsLnKNbPpp6anqfcosHeVVmqyfWC5RbpPd0x7KTh5k03uFugdrbpmib/I//biXbiSIDB mpsNuEf6KsmddJYfsOeAF+WWFFJHgMGlyRJUidIi2mxZuDBAnyYQ3CXqgX4fEVUIOyf2 /vTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4wyNqAzFanp/vQQF7DdmW+9Yw9MIyDiPSayB6RXk9AA=; b=CvM57myjZkSM9KbpwhE9yy7PPmOhqmr5soASykHX+k9onmU2Ov5AI3utdamrFhALWV jKZhn99t1xN6ocwYPFlJQ4j7tLH69GAMomzsUODaR0BUQ7LFfMrrtsdA2G2bU9ow/T/8 RquNNXQ4xkYSfmzj+HA3addFabnGqzsR1WzchhrnUuaIRocRoXuKk/DH3IEcgzE/R6uO u8ggIf+3KfTsJNiTEBgzyhei9xfkTsRer98eXyVG1V6ddtTCIww4+S+Ak5nAH4DMyGbe qVx189Jta1vHBBjA6hpu8ItAkARq52jlxTmHTQzMTg0wKYoT5hVNBiMrRQlvFcAX+IXc aIqQ==
X-Gm-Message-State: AA+aEWZ2aB6+09/iOcD832jAd12SXg0sDD6QFjeC74xqVrOVA2vA0IIN uqO9SVGO5LBiv4r3iD9GY9Y=
X-Google-Smtp-Source: AFSGD/WTSV1KN+zahLsbr+q7jIn3n3CvMaljupS4XKYcA9Vcg5FXJ7pbGADKe5w/wC0eSe21p9uTqw==
X-Received: by 2002:a17:902:33c1:: with SMTP id b59mr25507788plc.220.1544046174201; Wed, 05 Dec 2018 13:42:54 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id v190sm30741633pfv.26.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 13:42:53 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <>
Date: Wed, 5 Dec 2018 13:42:53 -0800
Cc:,,, Shunsuke Homma <>, Behcet Sarikaya <>, Luigi Iannone <>,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
To: Tom Herbert <>
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 21:42:57 -0000

> 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. 

That’s the best any design can hope for. The IP header can only be sent in the clear.