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

[Gorry Fairhurst <[e-mail]>]

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