Re: [Taps] Paul Wouters' Discuss on draft-ietf-taps-interface-23: (with DISCUSS and COMMENT)

[Michael Welzl <[e-mail]>]

Dear Paul,

We have addressed all discuss as well as comment items by splitting emails up into github issues, and discussed and handled them all there.
As part of the process of addressing so many comments, it seems we have overlooked that we never actually formulated an email response to you; we’re very sorry!

Below, I’m answering your DISCUSS items by pointing at the relevant issue or PR, and summarizing the result of the discussion in line in the email:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> [updated for -24, although I feel most of my questions have not been discussed yet]
> 
> - netflows vs IP flows?
> 
> Is TAPS only meant for flows or does it also support IP transport.
> I don't see an example that would embody "setup a connection to 192.0.1.1 port
> 80, but require IPsec. I guess it could be added, eg a WithVPN("IPsec") or
> something, but I'm not sure you can specify credentials without those being
> interpreted to be for the port 80 in this example ? Is this specifically out
> of scope, or just not (yet) specified?
> 
> Related, lets say you want to only use a flow if it goes over TOR, I guess one
> could introduce a WithTOR() transport requirement. I'm a bit concerned that
> without an IANA registry for functions, this might cause conflicts in the future.

https://github.com/ietf-tapswg/api-drafts/issues/1357 <https://github.com/ietf-tapswg/api-drafts/issues/1357>

We think that the architecture described in draft-ietf-taps-arch allows for such things (IP transport or the TOR suggestion). One way of scoping to TOR or IPsec or a set of proxies with the interface that we have is by scoping to a PvD that provides those capabilities; specifying a PvD is supported by our interface.

Other than that, the interface document does not specify bindings for doing such things, and we see such extensions as a possibility for the future. Our consensus was also that creating an IANA registry can be done at such a later time (if needed, i.e. in case TAPS really does become a big success).


> - single credentials for multiple protocols?
> 
> Does this document cause encouraging of re-using of key pairs for
> different protocols (eg TLS and IKEv2, or TLS 1.2 and QUIC). This
> might have security implications (eg using RSA as RSA-PKCS1.5 as
> well as RSA-PSS)

https://github.com/ietf-tapswg/api-drafts/pull/1430 <https://github.com/ietf-tapswg/api-drafts/pull/1430>

Please refer to this separate thread:
https://mailarchive.ietf.org/arch/msg/taps/HDKOexqM0348TH_EQqTS85U4dX0/ <https://mailarchive.ietf.org/arch/msg/taps/HDKOexqM0348TH_EQqTS85U4dX0/>


> - Hostname vs FQDN
> 
> Can WithHostname be unqualified? (God I hope not!)
> If not, can the call WithHostname be renamed to WithFQDN ?
> If it can be unqualified, how does one deal with credentials
> and identifiers, eg with a 'search domain' containing multiple
> domains, RemoteSpecifier.WithHostname("mail") could end up on
> either mail.example.com <http://mail.example.com/> or mail.example.net <http://mail.example.net/> (or heaven forbid,
> the .mail TLD)
> 
> It seems a little text is added that says "RECOMMENDED to not use unqualified",
> but that raises the question on why even support it? It's just too
> dangerous imho.

https://github.com/ietf-tapswg/api-drafts/issues/1360 <https://github.com/ietf-tapswg/api-drafts/issues/1360>
and https://github.com/ietf-tapswg/api-drafts/pull/1398 <https://github.com/ietf-tapswg/api-drafts/pull/1398> 

Regarding “why even support it”, we think the reason to make this not a MUST is that sometimes there can be unqualified names provided by the user, etc, and the application might not even know it is unqualified, so we can’t really guarantee it won’t be. The system will have some behavior for this.


> - WithPort and WithService, but not WithProtocol
> 
> How does one choose their syslog service transport protocol, since syslog
> over udp and tcp are valid and both have the same service name? Or does
> WithService accept values like "514/udp" ?

https://github.com/ietf-tapswg/api-drafts/issues/1361 <https://github.com/ietf-tapswg/api-drafts/issues/1361>

Normally, an endpoint ought not to request a specific transport protocol or protocol stack. The Transport Services Implementation is responsible for mapping the API to a specific available transport Protocol Stack and managing the available network interfaces and paths. When specifically needed, this automated selection could be over-ridden (e.g., to test a specific protocol stack).

For such purposes, we have now added WithProtocol.


> - ALPN
> 
> I don't see a WithALPN method for setting the ALPN.

https://github.com/ietf-tapswg/api-drafts/issues/1362 <https://github.com/ietf-tapswg/api-drafts/issues/1362>
https://github.com/ietf-tapswg/api-drafts/pull/1399 <https://github.com/ietf-tapswg/api-drafts/pull/1399>

This is now there, but not as a “WithALPN” method - instead we decided to put this together with the security parameters.


> - Preconnection vs Listener

https://github.com/ietf-tapswg/api-drafts/issues/1363 <https://github.com/ietf-tapswg/api-drafts/issues/1363>
https://github.com/ietf-tapswg/api-drafts/pull/1429 <https://github.com/ietf-tapswg/api-drafts/pull/1429>

The comment here was: "The arch document talks about Preconnection, Connection and Listener but this document in Section 3 places Listener as a Preconnection.”
This was a misunderstanding, created from lack of clarity in our text: a Listener is created from a Preconnection.


Cheers,
Michael (on behalf of the authors)