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)
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
