Re: [Taps] New Transport Networking APIs in iOS 12 beta

Michael Welzl <michawe@ifi.uio.no> Fri, 15 June 2018 18:27 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9002130DBE for <taps@ietfa.amsl.com>; Fri, 15 Jun 2018 11:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mvKE24_e9rRJ for <taps@ietfa.amsl.com>; Fri, 15 Jun 2018 11:27:36 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 585A012F18C for <taps@ietf.org>; Fri, 15 Jun 2018 11:27:36 -0700 (PDT)
Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1fTtRe-0003xC-0f; Fri, 15 Jun 2018 20:27:34 +0200
Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.2]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1fTtRd-000Dj4-9l; Fri, 15 Jun 2018 20:27:33 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <4f82aa36-3196-1cae-d14d-b2970943dc9b@ninetiles.com>
Date: Fri, 15 Jun 2018 20:27:26 +0200
Cc: "taps@ietf.org" <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <73DDC7E8-5AD2-4AE2-AB9A-C8385FB1E32B@ifi.uio.no>
References: <1C14F32A-3ADC-4D35-B800-091697E83AD6@apple.com> <63A71B2E-96E4-402A-89E2-667DDF8B1D08@lurchi.franken.de> <268D7E06-1D1D-4F70-9336-98EAF1BB5605@apple.com> <3EEFA4C8-D9D2-45E8-98FD-55BEA12706E9@ifi.uio.no> <5A1D9981-B8C1-46C3-99AD-7F6C89C8B918@vidyo.com> <D75972DB-3F06-4955-8E78-1BD86992E5D7@ifi.uio.no> <7CBAD06E-5299-413C-BA01-9662EC9DE702@apple.com> <4f82aa36-3196-1cae-d14d-b2970943dc9b@ninetiles.com>
To: John Grant <j@ninetiles.com>
X-Mailer: Apple Mail (2.3273)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.2];
X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.091, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 208EDB8F0F7731F4A98CE3A031EB687B0F06FC82
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/-MioEk1oQ-aQUlWSlDJylpo_iww>
Subject: Re: [Taps] New Transport Networking APIs in iOS 12 beta
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2018 18:27:39 -0000

> On Jun 15, 2018, at 6:37 PM, John Grant <j@ninetiles.com> wrote:
> 
> On 15/06/2018 17:17, Tommy Pauly wrote:
> 
> [snip]
>> 
>> Adding back pressure to inbound connections is something that we do need to add. The approach Michael suggests, of just ignoring an inbound connection until we’re ready to process it, certainly would work. The downside is that this requires the caller of the API to manage their own array of pending inbound connections. One option we’ve considered is allowing the application to specify a “receive connection window size” on a listener, thus defining how many more inbound connections they’re ready to handle at a given time. What do people think about this approach?
> Yes, that should be effective. One thing that needs to be avoided is the possibility of an attacker (or software error) causing huge numbers of Connection objects to be created.

I believe that this could be dealt with in any case, by just allowing a max connection limit to be specified (and having a reasonable upper bound by default).
But I still prefer Tommy’s proposal over what I described, because it seems to me to be simpler to handle for the application developer.

Cheers,
Michael