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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 05 August 2022 15:00 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 398C2C13CCC1; Fri, 5 Aug 2022 08:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDjm2Dr5sgt7; Fri, 5 Aug 2022 08:00:48 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id F293EC157B42; Fri, 5 Aug 2022 08:00:33 -0700 (PDT)
Received: from [192.168.1.64] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 164951B00137; Fri, 5 Aug 2022 16:00:25 +0100 (BST)
Message-ID: <91cd7c54-9f0f-1f48-d2e7-22b9d2bcf428@erg.abdn.ac.uk>
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 <fgont@si6networks.com>, draft-ietf-taps-impl@ietf.org
Cc: taps@ietf.org
References: <44f25f19-8ef4-8113-d854-0457e5ade6d6@si6networks.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <44f25f19-8ef4-8113-d854-0457e5ade6d6@si6networks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/W7cvGimMmqXkIzamknc87BiyCC8>
Subject: Re: [Taps] Some comments on draft-ietf-taps-impl-12
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
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, 05 Aug 2022 15:00:52 -0000

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

... 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 4.2.1.1. Local Endpoint candidates
>
> You should probably consider PCP/UPnP here. see e.g. 
> https://www.ietf.org/id/draft-gont-v6ops-ipv6-addressing-considerations-02.html#name-support-for-firewall-traver 
>
>
>
> * 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: 
> https://datatracker.ietf.org/doc/html/rfc5461
>
>
> 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
> https://www.rfc-editor.org/rfc/rfc6056.html#page-8
>
> 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,

Gorry