Re: [Pearg] Measuring latency in IP privacy architectures

Tommy Pauly <tpauly@apple.com> Wed, 10 November 2021 13:30 UTC

Return-Path: <tpauly@apple.com>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5683A0FDE for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQguoyudiDx9 for <pearg@ietfa.amsl.com>; Wed, 10 Nov 2021 05:30:11 -0800 (PST)
Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F37C3A0FDB for <pearg@irtf.org>; Wed, 10 Nov 2021 05:30:11 -0800 (PST)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 1AADCS8N018558; Wed, 10 Nov 2021 05:30:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=WB15110D7N9TpgASvaerp/MU2cKy8HDj2yUK2+/J0/I=; b=VZJPpUVilsjVIComzT/v+jrn1vwmQYbT8Be6QpqX3E3o16Sj50OvFPe0ecvtpKI/66fV a9ou8cK7Cnom4EUIuKv09jyjc6l6P1YeRSfExNbF4ZVRCcsAWAC49M85TnMVUh1t3TGx lgmTfbnG/wzS/vStPS+IBwg/9QQeyJe4YXM22AYTVWz0c4Qyg4aeTkS4p6PeeA4bS8Ms k8ZcS08DFWoCMFPQgeV+Y66Mu6TvNJ5Z4Vdtes0vtTL/8CqVr4sfNQdWVFCBgKj2is6E 9VC9Ygg9m5TligEESgp/5LoHGIgBJi41MHDhAn6rXaIq7CVwg2YG+E9ULSK6NDyteA3O XQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3c7hdn1235-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Nov 2021 05:30:07 -0800
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R2C00KZIYU5LZE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 10 Nov 2021 05:30:05 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R2C00F00YQ1RZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 10 Nov 2021 05:30:05 -0800 (PST)
X-Va-A:
X-Va-T-CD: 96638e6463484e94f66ff91ed32de31c
X-Va-E-CD: a2278b358d0aae72a262bc7e78e3044f
X-Va-R-CD: f3fca15ad8e7c963c6972e8dd8c7db52
X-Va-CD: 0
X-Va-ID: 3ceb6b0b-7137-40d1-902e-8f28c93cdbe7
X-V-A:
X-V-T-CD: 96638e6463484e94f66ff91ed32de31c
X-V-E-CD: a2278b358d0aae72a262bc7e78e3044f
X-V-R-CD: f3fca15ad8e7c963c6972e8dd8c7db52
X-V-CD: 0
X-V-ID: 1c632f81-74a6-414d-b925-ccd885b99711
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-10_04:2021-11-08, 2021-11-10 signatures=0
Received: from smtpclient.apple (unknown [17.11.19.52]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R2C00RJGYU5J600@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 10 Nov 2021 05:30:05 -0800 (PST)
From: Tommy Pauly <tpauly@apple.com>
Message-id: <201C720B-CF90-4CF1-879B-7A668C132FB2@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_9F555C64-7BEC-4474-84DC-D8D6316A4193"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3691.0.3\))
Date: Wed, 10 Nov 2021 05:30:04 -0800
In-reply-to: <4a572a6067b841d5809b9cda9e8315b6@huawei.com>
Cc: "pearg@irtf.org" <pearg@irtf.org>
To: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
References: <036D2F47-3479-457A-AE30-9C117D75D8FB@apple.com> <4a572a6067b841d5809b9cda9e8315b6@huawei.com>
X-Mailer: Apple Mail (2.3691.0.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-11-10_04:2021-11-08, 2021-11-10 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/6j2Y7CSaaXDdyHltJyYwUyv20WM>
Subject: Re: [Pearg] Measuring latency in IP privacy architectures
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2021 13:30:16 -0000

Hello Antoine,

Thanks for the clarification! Good to know that this was theoretical. One thing that probably should be clarified is how public key cryptography is used in the various solutions. For example, in iCloud Private Relay, we use RSA Blind Signature tokens only as an HTTP authentication method into the relay at the start of a connection, which only requires the relay to do a verification of the user once for a proxy connection that can end up being reused for thousands of end-to-end proxied connections. Thus, the impact of setup (QUIC/TLS handshake to the proxy) is quite minimal. This has no impact on per-packet costs.

Changing your graph to cryptographic load would be an improvement, but I think that’s not a clearly linear axis, since we still need to distinguish between per-tunnel and per-packet overhead.

Best,
Tommy

> On Nov 10, 2021, at 5:21 AM, Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> wrote:
> 
> Hello Tommy,
>  
> As I am the author for this slide, I feel I am best suited to answer you.
>  
> My perception of the latency of the solutions I am presenting is for now rather theoretical. As Private relay and Gnatcatcher use public key cryptography algorithms, I made the assumption that the computation time dedicated to cryptographic operation is larger in this case that in TOR which uses symmetric key cryptography.
>  
> Yet, I agree with you that presenting this as latency while I can’t present figures might be misleading. To address this point, I propose to replace “latency” with “cryptographic load” in this schema to be more accurate with regards to what I really mean. Would you be OK with this change?
>  
> I agree with you on the performance / latency methodology we should agree on.
>  
> Best regards,
> 
> Antoine
>  
> From: Tommy Pauly [mailto:tpauly@apple.com] 
> Sent: Wednesday, November 10, 2021 2:11 PM
> To: pearg@irtf.org; Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
> Subject: Measuring latency in IP privacy architectures
>  
> Hello,
>  
> I was looking at the slides for one of the PEARG talks for tomorrow, and had some questions about one of the graphs. (I likely won’t be able to attend the meeting due to a conflict, so I thought I’d ask here!).
>  
> https://datatracker.ietf.org/meeting/112/materials/slides-112-pearg-state-of-the-art-on-privacy-preserving-techniques-used-at-the-network-layer-00 <https://datatracker.ietf.org/meeting/112/materials/slides-112-pearg-state-of-the-art-on-privacy-preserving-techniques-used-at-the-network-layer-00>
>  
> There’s a slide titled “Positioning SoA projects on a map”, with two axes—“attack class” and “latency”. While the “class” is a relatively subjective measurement, the latency metric should be pretty straightforward. I assume that the latency axis goes from lowest-latency on the left, and highest-latency on the right. There weren’t any numbers provided, but I was very surprised to see that both Gnatcatcher and iCloud Private Relay were listed further to the right than TOR! In the case of iCloud Private Relay, which I work on, our overall metrics show that the average page load time for the browser going through the relays is actually faster than going direct for most parts of world. To that end, our effective latency is quite good. Can anyone share insight into what the methodology was behind this graph?
> 
> 
> More generally, if we’re discussing latency for IP privacy solutions, it would be good to agree on what methodology is appropriate across very different technologies. IP-tunnelling can end up requiring more round trips for typical workflows (due to DNS and TCP handshakes over the tunnel) than CONNECT-style proxying (which can end up doing DNS+TCP+TLS in one round trip). That changes the experience of latency, in addition to the actual round-trip-time between hops.
>  
> Best,
> Tommy
>  
> -- 
> Pearg mailing list
> Pearg@irtf.org <mailto:Pearg@irtf.org>
> https://www.irtf.org/mailman/listinfo/pearg <https://www.irtf.org/mailman/listinfo/pearg>