On Sun, Jan 24, 2021 at 11:56 AM Peter van Dijk <[email protected]> wrote:
> Hello, > > On Thu, 2021-01-21 at 08:54 -0500, Tim Wicinski wrote: > > This starts a Working Group Last Call for draft-ietf-dprive-xfr-over-tls > > > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > > > The Current Intended Status of this document is: Standards Track > > > > Please review the draft and offer relevant comments. > > I like most of the draft. Some of it seems 'obvious' but often 'obvious' > differs from reader to reader, so it's good to be explicit about a lot of > things. So, I'm not here to say 'all of this is so obvious that the draft > does not need to exist at all'. > > However, there's one part that bothers me. The 'intermingling' of multiple > XFRs over a single connection (which is a SHOULD, not a MUST, so the > document 'gets away with it', or conversely, implementations will get away > with not implementing it) feels to me like a lot of additional code > complexity for a gain that is not clear to me. XFRs are not latency > sensitive to the point that TLS setup is an impediment. > I'm not one of the authors, but re-reading the draft with "intermingling" in focus, I think the issues are: - The intermingling aspect originates in RFC5936 (over TCP) - They want parity between TCP and XoT (which is reasonable) - Interoperability is assumed and not negotiated > > In other words, I do not think the goal 'minimize the number of TCP > connections between a primary and secondary' warrants the complexity of > intermingling XFRs. I'd much rather have a few more TCP connections, a few > more TLS states, and a much simpler code base. > > We (PowerDNS) do not think we will implement the parts of the draft that > call for such code complexity, and thus, we will serialise XFRs (serial > connection reuse does make sense to me) and/or in fact open multiple TLS > connections (like we do with TCP today). At least in our code base, TLS > setup would never be the bottleneck for transfers anyway. > The relevant sections appear to be the text at the top of section 6.2, and all of 6.3.2. Servers MUST be able to handle multiple XFR requests. Clients MUST be able to handle intermingled responses. However, Servers MAY intermingle, rather than must, on the responses. I concur with the code base complexity concern, particularly on the client side. I think this might be possible to accommodate with guidance (i.e. suggested text to the following effect): "NB: If clients do not want to support intermingled responses, a compliant client could serialize requests to avoid multiple outstanding XFR requests. If only one XFR is outstanding, no intermingling will ever occur." Similarly, server-side guidance could be added: "NB: if servers do not want to implement intermingled responses, they can serialize the full XFR responses to individual XFR requests, and this would be compliant. Similarly, reordering of XFR responses versus XFR requests is allowed but not required (in order to be compliant)." > > Do any other vendors actually plan to implement such thorough connection > reuse, with primaries actually intermingling multiple XFR responses over a > single TCP/TLS session, and with secondaries actually firing off several > XFR requests on a single connection to receive the zone chunks in whichever > order they may come? It is not clear if our (internal) implementations will do so, or how (intermingling out-of-order serialized-but-not-interleaved, versus fully interleaving of multiple XFR responses). One possibility is the use of TLS proxies, which could multiplex multiple XFR over TCP streams, such as from multiple TCP clients to multiple TCP servers, across "shared" TLS XFR sessions (site to site). But that is conjecture only at this point. Brian
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
