[Tsv-art] draft-deshpande-secevent-http-multi-set-push-03 ietf last call Tsvart review

[Martin Duke via Datatracker <[e-mail]>]

Document: draft-deshpande-secevent-http-multi-set-push
Title: Push-Based Delivery For Multiple Security Event Tokens (SET) Using HTTP
Reviewer: Martin Duke
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

This document tries to mildly improve the wire efficiency of RFC 8935 by
allowing multiple Security Event Tokens (SETs) in a single POST request, and
multiple acknowledgement/error messages for such tokens in a single POST
response. This saves some bytes, which IMO is not a big deal. The real benefit
is that it prevents head-of-line blocking when pipelining SETs over HTTP/1.1.

In this reviewer's opinion, simply switching to a multi-stream protocol (HTTP/2
or 3) would achieve much of these gains without requiring a lot of bespoke
code. Nevertheless, the design is workable, but raises certain transport topics
that could use more attention.

1) Flow control: when there is one SET per request as in RFC 8935, HTTP/2 and 3
intrinsically flow control SETs by limiting the number of open request streams.
In this draft, this system no longer works, requiring out of band flow control
information.

There is also the possibility that a POST is so large (see Sec 7.1) that either
the response is delayed by the extended latency of the transfer, or a response
is sent before the server recognizes a 413 is in order.

2) Retransmission: The draft appears to introduce much more scope for
retransmissions than RFC 8935. The RFC discusses retry after error or
connection failure, while Section 6 of the draft implies that a transmitter
should send SETs again if the response is much delayed. If not simply poorly
worded, this is a major expansion of the mechanic. I have two concerns: first,
HTTP goes over reliable transports, so barring connection failure or
application-layer error, there should be no need for an app layer
retransmission. Second, if there is to be some sort of timer-based response to
missing ACKs, something like BCP 233 should be a consideration in the design.
As it stands, any such timer-based system is wildly underspecified. I would
recommend that the document more closely adhere to the conventions of RFC 8935,
which does not attempt to preempt transport-layer retransmissions.

3) Hanging POSTs. One of the examples shows that a common pattern may be that a
request includes multiple SETs and only some of them may be closed in the
response. If acks/errors are outstanding when all requests have responses, the
client will have to send one or more "Hanging POSTs" to elicit a Response that
has the remaining information. While this will work, it is inferior to properly
full-duplex designs like WebSockets or WebTransport.

If a client *doesn't* send a hanging POST, then a server could be stuck with
pending ACKs indefinitely. Is there a DoS attack in there?

4) Mapping ACKs to responses. The ack(s) for a POST can be completely detached
from the response to that POST. Say the protocol uses HTTP/2 and there are five
POSTs sent out on different streams in rapid succession; as acks are readied
for the SETs in them, are there any best practices for how to respond to those
POSTS? e.g. should the acks get grouped into the response to the POST that
carried the SET? Should all available ACKs be batched into one response so that
other streams are still open for future responses? Once all acks are ready,
should the server strive to make sure all the streams are closed?