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

Fernando Gont <fgont@si6networks.com> Fri, 05 August 2022 11:02 UTC

Return-Path: <fgont@si6networks.com>
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 4EE54C14F72D; Fri, 5 Aug 2022 04:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 2pKlGv5fswk3; Fri, 5 Aug 2022 04:02:08 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3322C14F73D; Fri, 5 Aug 2022 04:02:04 -0700 (PDT)
Received: from [IPV6:2001:67c:27e4:c::1001] (unknown [IPv6:2001:67c:27e4:c::1001]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id AE8B12802D9; Fri, 5 Aug 2022 11:01:58 +0000 (UTC)
Message-ID: <44f25f19-8ef4-8113-d854-0457e5ade6d6@si6networks.com>
Date: Fri, 5 Aug 2022 08:01:56 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: draft-ietf-taps-impl@ietf.org
Cc: taps@ietf.org
From: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/MoIH2kLR3gQoJYgwAkXeduH4qzY>
Subject: [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 11:02:12 -0000

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.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494