Re: [Taps] Some comments on draft-ietf-taps-impl-12

Gorry Fairhurst <> Fri, 05 August 2022 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 398C2C13CCC1; Fri, 5 Aug 2022 08:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pDjm2Dr5sgt7; Fri, 5 Aug 2022 08:00:48 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id F293EC157B42; Fri, 5 Aug 2022 08:00:33 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 164951B00137; Fri, 5 Aug 2022 16:00:25 +0100 (BST)
Message-ID: <>
Date: Fri, 5 Aug 2022 16:00:25 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
To: Fernando Gont <>,
References: <>
From: Gorry Fairhurst <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Taps] Some comments on draft-ietf-taps-impl-12
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Aug 2022 15:00:52 -0000

Thanks, I added trhese as issues #1054-1057, so we don't forget these 

... I also have one specific query below...

On 05/08/2022 12:01, Fernando Gont wrote:
> Folks,
> Some comments/feedback on the aforementioned I-D:
> * Section Local Endpoint candidates
> You should probably consider PCP/UPnP here. see e.g. 
> * Section 4.3.3. Failover
> I haven't recently checked what's the status of current TCP 
> implementations. But at least at some point in time there are some 
> that would failover more quickly based on notifications from the 
> network (e.g., ICMP errors). see: 
> Section 4.7:
>> 4.7. Implementing listeners When an implementation is asked to 
>> Listen, it registers with the system to wait for incoming traffic to 
>> the Local Endpoint. If no Local Endpoint is specified, the 
>> implementation should use an ephemeral port.
> Note: there are implications of using a port number from the ephemeral
> port range. See e.g. Section 3.1 of
> TL;DR; The general idea is that one should use the same range to pick
> port for outgoing connections than to pick ports for listening endpoints.
>> If the Selection Properties do not require a single network
>> interface or path, but allow the use of multiple paths, the Listener
>> object should register for incoming traffic on all of the network
>> interfaces or paths that conform to the Properties. The set of
>> available paths can change over time, so the implementation should
>> monitor network path changes, and change the registration of the
>> Listener across all usable paths as appropriate. When using multiple
>> paths, the Listener is generally expected to use the same port for
>> listening on each.
> I'd probably stress this a bit more e.g., quite often the port needs 
> to be registered somewhere (e.g., directory service), so having 
> different ports for each interface would seem problematic.
> Section 4.7.2.:
>> On platforms with facilities to create a "virtual connection" for
>> connectionless protocols implementations should use these mechanisms
>> to minimise the handling of datagrams intended for already created
>> Connection objects.
> I don't necessarily disagree, but you should probably elaborate here 
> -- e.g., on one hand, "stateless" is good in the sense that you don't 
> tie system resources unnecessarily. However, it's also more prone to 
> spoofing, to the extent that an attacker might require "a lot of work" 
> from a server without even proving that it can receive the return 
> packets.

I'm not quite sure what you are asking here. What I think was intended 
was very similar to the way UDP sockets in BSD can be used with 
"connect", is there something else you were expecting to see in the text?

> Thanks!
> Cheers,