[Taps] Paul Wouters' Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
Paul Wouters via Datatracker <noreply@ietf.org> Thu, 07 September 2023 14:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: taps@ietf.org
Delivered-To: taps@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD51EC1519A3; Thu, 7 Sep 2023 07:00:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, anna.brunstrom@kau.se, anna.brunstrom@kau.se
X-Test-IDTracker: no
X-IETF-IDTracker: 11.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <169409523276.39053.17894661993321299237@ietfa.amsl.com>
Date: Thu, 07 Sep 2023 07:00:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/rNdOjS2do4yuiNP6iQ1vyLrC73Q>
Subject: [Taps] Paul Wouters' Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 07 Sep 2023 14:00:32 -0000
Paul Wouters has entered the following ballot position for draft-ietf-taps-interface-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ this review is still incomplete, but I wanted to at least file what I have here ] - 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. - 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) - identity and server-certificate forces same use over different protocols? The current API kind of forces re-use of credentials for different protocols, eg: SecurityParameters.Set(server-certificate, myCertificate) // Specifying a Remote Endpoint is optional when using Listen Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) Let's say that a server only supports TLS 1.2 with RSA-PKCS-1.5 and TLS 1.3 with RSASSA-PSS. We shouldn't use 1 RSA key from 1 certificate for these two different RSA operations. Would this mean we could never tell the TAPS API "TLS 1.2 or 1.3 is fine". Maybe that is okay and we should pick an keypair that works the same in 1.2 and 1.3, but we don't know what the future will hold. If we could set multiple identities, TAPS could pick the appropriate one. eg: SecurityParameters.Set(identity, myIdentity) SecurityParameters.Set(server-certificate, []myCertificate) (and possibly multiple identities too?) - 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 or mail.example.net (or heaven forbid, the .mail TLD) - 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" ? - ALPN I don't see a WithALPN method for setting the ALPN. - Preconnection vs Listener The arch document talks about Preconnection, Connection and Listener but this document in Section 3 places Listener as a Preconnection. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Camelcase vs Dromedariescase Why is it RemoteSpecifier.WithHostname and not RemoteSpecifier.WithHostName, while it is RemoteSpecifier.WithIPAddress and not RemoteSpecifier.WithIPaddress ? String: Instances are represented in a way that is common to the programming language, e.g. UTF-8. Why doesn't it define this just like the other basic types? eg: "Instances are represented in UTF-8" Also, how would that work for things like DNS (Ulabel vs Alabel) IP Address: An IPv4 or IPv6 address. Maybe reference RFC5952 ? It is not necessary for an application to handle all events; some events may have implementation-specific default handlers. The application should not assume that ignoring events (e.g., errors) is always safe. What is "ignoring events" vs "having a default handler for events" ? Wouldn't default handlers be handled outside the application, and thus not trigger an event towards the application? So that applications "ignoring events" would be unrelated to "implementation-specific default handlers"? Perhaps the last sentence should just start in a new paragraph to indicate these two things are separate unrelated notes? SecurityParameters.Set(identity, myIdentity) I assume myIdentity would be an array of Type and Value? Eg type=fqdn or type=RDN ? I don't understand this code: Connection := Preconnection.Initiate() Connection2 := Connection.Clone() Connection -> Ready<> Connection2 -> Ready<> //---- Ready event handler for any Connection C begin ---- C.Send(messageDataRequest) Where does "C" come from in "C.Send" ? The comment says "any Connection C"? I have a question on this code: Preconnections are reusable after being used to initiate a Connection, whether this Connection was closed or not. Hence, it would be correct to continue as follows after the above example: //.. carry out adjustments to the Preconnection, if desired Connection := Preconnection.Initiate() What would happen here? I can imagine a "compiler" turning this into a noop. I can also see it would kill the existing Connection state and start a new one. This could be to a different IP address (eg if the DNS name has A and AAAA). When starting a new one, what would happen to any Message or Event queues for Connection ? What is "credentials" (especially because previously we have myCertificate, so it is unclear if this now contains myKey and if so, where in the previous example myKey was conveyed to TAPS. Preconnection.AddRemote(RemoteCandidates) Should this not technically be: Preconnection.AddRemote([]RemoteCandidates) as the array contains at least a host and a stun server candidate? Maybe this is just the difference between you using the variable you define that has been assigned, versus a more C like prototype format, eg: Preconnection := NewPreconnection([]LocalEndpoint, So I guess if your example here had set LocalEndpoint := [a,b] you would not have used [] in the call ? Section 4.1: For the purposes of this document, these names are alphanumeric strings Is there another purpose? If it is outside this document, why does this document care? Does it try to set a standard here to ensure interoperable names? Maybe just remove the "For the purposes of this document," ? Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace What if Vendor Foo has a non-standard tcp property MagicSmoke? Does it go under tcp.Foo.MagicSmoke or under Foo.tcp.MagicSmoke or something else? Section 6.1 An Endpoint object can be configured with the following identifiers: * Hostname (string): This starts with listing endpoint identifiers with types (eg string and 16-bit integers) but then stops specifying their types further down. I guess WithService(), WithIPAddress() and WithInterface take a (string) Section 6.1.4 Perhaps it would be useful to add a Local Endpoint with ephemeral port before the Local Endpoint with static port example, as the ephemeral port should be the far more common case. Right now the examples might give the wrong impression a local port MUST be specified. SecurityParameters.Set() seems to allow to set our identiy and our certificate, but not the remote peer's identity or certificate? For example, one might want to pin a remote certificate and not just rely on a WithHostname() identifier being present as subjectAltname on a certificate. If security is opportunistic, it will allow Connections without transport security, but will still attempt to use security if available. I assume what is meant is "but will still attempt to use unauthenticated security if available" ? The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed. I think the text in Section 8 should more clearly show the property names if the goal is to have different implementations use the identical name. Eg in this case, why not write: The Connection state ("state"). The next two entries are similarly lacking a clear keyword to use: Whether the Connection can be used to send data. Whether the Connection can be used to receive data. eg. why not define words for these to implementations will use the same words, in this case perhaps ReadySend and ReadyRcv ? Writing that now, perhaps "state" should be "State" then ? Section 8.1.1: If this property is an Integer It is best to define the actual type in this document and not let implementations choose, if the goal is to try and harmonize implementations. I also see no non-integer value being given here ? A higher value reflects a higher priority. This is uncommon in IETF protocols. Normally priority is down with lower numbers being higher priority. Why reverse it here? [ review to be continued from 8.1.3 ] NITS: Wouldn't the American spelling be "rendezvouzing" instead of "rendezvousing" :-)
- [Taps] Paul Wouters' Discuss on draft-ietf-taps-i… Paul Wouters via Datatracker