Re: [Taps] Paul Wouters' Yes on draft-ietf-taps-interface-24: (with COMMENT)
Michael Welzl <michawe@ifi.uio.no> Tue, 02 January 2024 12:44 UTC
Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5E4C14F60A; Tue, 2 Jan 2024 04:44:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ifi.uio.no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czOc3iEc-bvE; Tue, 2 Jan 2024 04:44:16 -0800 (PST)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E0EC14F5F4; Tue, 2 Jan 2024 04:44:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ifi.uio.no; s=key2309; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=SsoKt/q0v37Us1aLyBc8iYRlF1yWqpNzCoJDjkx3/4M=; b=vs5kE9v+93o0+F/jOpJEm0L2Yv oKYSrkeqIh7VwfFL8Ofyb2t3xAUlgqyS1XVbio2FkRvfM0RgKF0iEZYY5tRKNV8lqLEbvhr+ibKKj 1tLTKbEyAhq2G48TyUkkE5CcaFsmlsEqhQIAsM+1OOr1VE5atwvFbT1rswDGMPw8B0ZqxR5FQSwa+ f3kQsMp/w7ufqJsYeFKZLoMCaqIRkJAqNbvPJlXxkpp38zO6dhIKNTYBkXcERisZdjZxwp7FdXNfN wbP0yq4gFF8Xo44gLbEoTeUHxFwhiLuA4jkLJ4SaIfzXAViXrbtTLuVOrgL/TSJFQhEhNCkrOe+GR DdgctN8Q==;
Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1rKe7u-005upM-1g; Tue, 02 Jan 2024 13:44:10 +0100
Received: from 91.141.75.11.wireless.dyn.drei.com ([91.141.75.11] helo=smtpclient.apple) by mail-mx03.uio.no with esmtpsa (TLS1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256) user michawe (Exim 4.96.2) (envelope-from <michawe@ifi.uio.no>) id 1rKe7t-000EkK-1l; Tue, 02 Jan 2024 13:44:10 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <170387665221.7686.4849346896720148608@ietfa.amsl.com>
Date: Tue, 02 Jan 2024 13:44:07 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps WG <taps@ietf.org>, anna.brunstrom@kau.se
Content-Transfer-Encoding: quoted-printable
Message-Id: <4762E64D-3C1A-4995-AE09-900996512684@ifi.uio.no>
References: <170387665221.7686.4849346896720148608@ietfa.amsl.com>
To: Paul Wouters <paul.wouters@aiven.io>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 91.141.75.11 is neither permitted nor denied by domain of ifi.uio.no) client-ip=91.141.75.11; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.035, TVD_RCVD_IP=0.001, T_SCC_BODY_TEXT_LINE=-0.01, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: E7AAADF54233132D279210AC6E3CFE8EFC5767A4
X-UiOonly: 56640C36B055F508D2383A347EFA3D7FD77423D6
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/rbApOAAC2UsWqOwsmFSOTcg-Y5k>
Subject: Re: [Taps] Paul Wouters' Yes on draft-ietf-taps-interface-24: (with COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Tue, 02 Jan 2024 12:44:22 -0000
Dear Paul, I now see what happened here. I have made this harder to track by answering the DISCUSS items only in my email - when, in fact, we have addressed or at least discussed everything on github. I’m sorry! There were so many emails, I also didn’t want to make the answers too long. As a general comment, for everyone else who might see this: if you miss answers to your COMMENTS, we’re sorry! - but you’re likely to find them fast by going to: https://github.com/ietf-tapswg/api-drafts/issues … removing “is:open” from the search field but instead writing your last name there. Paul, please see below: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I updated my discuss items to non-blocking comments. I'm still a bit concerned > that some security items are not fully addressed by the API or its Security > Considerations. Resolving my comments would make the document a bit more clear > and useful I think. > > 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. These are new comments as part of the COMMENT block. As with the others, we will file an issue on our github and resolve them there. Personally, I think we should use these comments to strengthen our security considerations section (e.g., to warn about the security risk when not using an FQDN. Indeed such a warning does now exist in the text, and using an FQDN is qualified with a SHOULD, but the security considerations section could point at it once again). Here comes an answer for the other COMMENT items on the basis of what happened on github: > 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"? Issue: https://github.com/ietf-tapswg/api-drafts/issues/1368 PR to resolve: https://github.com/ietf-tapswg/api-drafts/pull/1413 We hope that the text that we added makes this clear enough: this code block is an event handler for Connection C. Either it gets C as a parameter, or it’s in some other way associated to 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 ? Issue: https://github.com/ietf-tapswg/api-drafts/issues/1369 PR to resolve: https://github.com/ietf-tapswg/api-drafts/issues/1369 A Preconnection is just a data structure, used as a template to create a Connection - so, the call to Initiate() after adjustments wouldn’t affect the already ongoing Connection. We hope that the text that we added makes this clear enough now. > 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 ? Issue: https://github.com/ietf-tapswg/api-drafts/issues/1371 Commit: https://github.com/ietf-tapswg/api-drafts/commit/e1ca6015d25c8a2a3f78f99cfc552ed4fd63019e … this should be resolved now. > 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. Yes, good catch, thanks! - addressed: Issue: https://github.com/ietf-tapswg/api-drafts/issues/1374 PR: https://github.com/ietf-tapswg/api-drafts/pull/1431 > 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. Issue: https://github.com/ietf-tapswg/api-drafts/issues/1375 PR: https://github.com/ietf-tapswg/api-drafts/pull/1430 (this PR introduces client- and server- certificates) > 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 ? Issue: https://github.com/ietf-tapswg/api-drafts/issues/1377 PR: https://github.com/ietf-tapswg/api-drafts/pull/1437 This PR incorporates your suggestion by introducing three read-only properties: connState (to query for “Establishing”, “Established”, “Closing”, “Closed"), canSend, canReceive. > 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 ? We got a similar comment about this from Lars Eggert, so we discussed both in this issue: https://github.com/ietf-tapswg/api-drafts/issues/1346 This is a more general thing, affecting several properties. After trying and discussing (at an interim) a somewhat heavy-handed approach to solve this for all of them: https://github.com/ietf-tapswg/api-drafts/pull/1409 … we ended up with what we agreed was a better way to do it, in this PR: https://github.com/ietf-tapswg/api-drafts/pull/1410 Now it’s a non-negative Integer, with a defined special value of 0, and how to specify "Full Coverage” is explained in the text. I hope this helps - my apologies for not immediately answering how we addressed the COMMENT items ! Cheers, Michael
- [Taps] Paul Wouters' Yes on draft-ietf-taps-inter… Paul Wouters via Datatracker
- Re: [Taps] Paul Wouters' Yes on draft-ietf-taps-i… Michael Welzl
- Re: [Taps] Paul Wouters' Yes on draft-ietf-taps-i… Michael Welzl
- Re: [Taps] Paul Wouters' Yes on draft-ietf-taps-i… Paul Wouters