search

ietf-tapswg / api-drafts

Architecture, interface, and implementation drafts for the definition of an abstract API for IETF TAPS
Other
24 stars 15 forks source link

Remaining comments from Paul Wouters #1460

Closed mwelzl closed 10 months ago

mwelzl commented 11 months ago

New comments in the COMMENT part of the review from Paul Wouters: (Note, he mentioned that he'll move his Ballot to Yes once we've published an updated draft)

I'm not sure that the model really expands from netflows to IP flows (or TOR)
in the future.

I'm not sure the Security Considerations warn enough about re-using the same
credentials with different protocols/auth mechanisms. (eg TLS and IKEv2, or TLS
1.2 and QUIC, or using RSA as RSA-PKCS1.5 as well as RSA-PSS)

Unqualified Hostname vs FQDN seems a security risk punted mostly to the
application.
mwelzl commented 11 months ago

I think that the second and third paragraph call for expanding the security considerations section some more. About the first, I'm not sure what to do?

mwelzl commented 10 months ago

Our email answer to the first item:

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).

Is there anything else we should or could do here?

mwelzl commented 10 months ago

The one comment left standing and unaddressed is:

I'm not sure that the model really expands from netflows to IP flows (or TOR)
in the future.

...and I don't think there's anything that's not potentially very disruptive to the entire API surface that we can do about this.

On this basis, I suggest to close this issue.