[tsvwg] Benjamin Kaduk's Discuss on draft-ietf-tsvwg-rfc4960-bis-17: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 16 December 2021 14:48 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F613A089F; Thu, 16 Dec 2021 06:48:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tsvwg-rfc4960-bis@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, gorry@erg.abdn.ac.uk
X-Test-IDTracker: no
X-IETF-IDTracker: 7.41.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163966609848.27749.5437634889896180266@ietfa.amsl.com>
Date: Thu, 16 Dec 2021 06:48:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1hA5mgmkO9cr-CscdreUEMpsZrA>
Subject: [tsvwg] Benjamin Kaduk's Discuss on draft-ietf-tsvwg-rfc4960-bis-17: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Dec 2021 14:48:20 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-tsvwg-rfc4960-bis-17: 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/blog/handling-iesg-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-tsvwg-rfc4960-bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My apologies for placing a Discuss so close to the telechat. I believe that both of these topics are comparatively minor and should be easy to resolve, but that it's important for the document to have a clear answer for them. I ask this with nospecific answer in mind that I need to hear -- per my comments on §5.1.3, what are the actual requirements on the (cryptographic) protection of the State Cookie? I feel like I got different signals from different parts of the document, and it would be good to have consistent messaging throughout. Section 15.5 establishes a registry for payload protocol identifiers, but I am not sure how this registry is supposed to be able to effectively avoid collisions when we do not specify the endianness in which the value is represented on the wire (per §3.3.1). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Peeking in the github repo for purposes of preparing an editorial PR, I see that the original RFC 4960 was prepared in nroff -- my thanks to the authors for the thankless work of converting it to XML! I'm also glad to see the robustness changes made to the procedures for handling INIT (and INIT ACK) chunks with invalid parameters. I am also sympathetic to Alvaro's point about obsoleting additional documents. I only got a chance to review the diff from RFC 4960 and a small selection of portions of this document, so this review is not as comprehensive as I would typically perform. That said, I trust that the document has received sufficient review and therefore am comfortable reballoting No Objection once my discuss points are resolved. I put some editorial suggestions in a PR on github: https://github.com/sctplab/rfc4960bis/pull/79 Abstract I see that Warren already remarked about the length of the Abstract. I have in my bookmarks https://www.rfc-editor.org/policy.html#policy.abstract that indicates "[a]n Abstract of more than 20 lines is generally not acceptable." Section 3.3.4 Cumulative TSN Ack: 32 bits (unsigned integer) The largest TSN, such that all TSNs smaller than or equal to it have been received and the next one has not been received. (nit) The "and the next one has not been received" is implied by "largest ... such that", since if the next one had been received, this one would not be the largest such that the condition holds. (This phrasing also seemse to appear in §3.3.8.) I didn't remove this in my editorial PR because it is plausible that the redundancy is desired for emphasis. Section 5.1.3 When would it be permissible to not include a MAC on the State Cookie data? It seems like we refer to it as essentially mandatory from other parts of the spec, so I was surprised to see it only as a "SHOULD" here. E.g., in §5.1.5 the first step in processing COOKIE ECHO is "compute a MAC [and compare it to the one in the cookie]" -- there's no point in doing that if there's no MAC in the cookie. Similarly, in §14.1 "Parameters Necessary for the SCTP Instance" we list a secret key for computing the MAC. Since the State Cookie is not encrypted, it MUST NOT contain information which is not being envisioned to be shared. What prevents the state cookie from being encrypted (other than performance concerns)? Perhaps we just need to require that *if* the state cookie is not encrypted, it doesn't contain such information. Section 6.2 An SCTP receiver MUST NOT generate more than one SACK chunk for every incoming packet, other than to update the offered window as the receiving application consumes new data. When the window opens up, an SCTP receiver SHOULD send additional SACK chunks to update the window even if no new data is received. The receiver MUST avoid sending a large number of window updates -- in particular, large bursts of them. [...] "a large number" feels somewhat subjective, such that the power of the "MUST"-level requirement is weakened. If an endpoint receives a DATA chunk with no user data (i.e., the Length field is set to 16), it MUST send an ABORT chunk with a "No User Data" error cause. An endpoint SHOULD NOT send a DATA chunk with no user data part. This avoids the need to be able to return a zero-length user message in the API, especially in the socket API as specified in [RFC6458] for details. This is just a COMMENT since the behavior was present in 4960, but why allow sending an empty data chunk when the receiver is required to abort because of it? This seems like the reverse of the Postel principle. Section 6.5 Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it SHOULD acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. [...] What other behaviors are permitted (i.e., why is this SHOULD vs MUST)? The Stream Sequence Number in all the outgoing streams MUST start from 0 when the association is established. [...] If we were starting from scratch this would probably be undesirable (a la draft-gont-numeric-ids-sec-considerations), but I guess it's not really changeable now, and we have to rely on the random initial TSN and verifiers to prevent off-path guessing. Section 11.2.5 Looking at the diff from RFC 4960, it seems that we no longer claim that there is a "data retrieval id" passed with the communication-lost notification. I don't have a great sense for whether this makes sense, e.g., due to an expectation that SEND-FAILURE events will be generated separately for all affected messages. Section 12 My apologies if I failed to find some relevant content in my somewhat-piecemeal review, but I note that we require each HEARTBEAT chunk to receive a corresponding HEARTBEAT ACK, so that (according to the protocol rules) an endpoint can force the peer to do work. Since the heartbeat is expected to only occur once every RTO or so (or less often), should we allow an endpoint to abort the association on receipt of too many heartbeats? It also looks like it's allowed for a sender to leave gaps in the TSN space when sending (non-fragmented) DATA chunks. This is also the case for QUIC (for the analogous numer space), and in QUIC's security considerations there is a note that a sender who suspects the peer of misbehaving (i.e., sending false/speculative ACKs) can deliberately leave such a gap and abort the association if the non-existent TSN is ACKed. Do we want to make such a statement here as well? Section 12.2.3 Whenever ESP is in use, application-level encryption is not generally required. I suggest removing this statement; we now have plenty of examples where double-encryption is actually the right solution, and advances in computing power have removed many reasons to desire avoiding it. Section 12.2.4.1 The design of SCTP is resistant to flooding attacks, particularly in its use of a four-way startup handshake, its use of a cookie to defer commitment of resources at the responding SCTP node until the handshake is completed, and its use of a Verification Tag to prevent insertion of extraneous packets into the flow of an established association. I suggest mentioning here that using distinct initial TSN and initiate tag values improves robustness against such attacks, by making attackers guess 32 more bits of values. (§3.2.2 and 3.2.3 do allow for the values to be the same, with concomitant reduced protection.) The IP Authentication Header and Encapsulating Security Payload might be useful in reducing the risk of certain kinds of denial-of-service attacks. Current IPSECME WG guidance is to prefer ESP with NULL encryption over AH, so I'd recommend not mentioning AH here. Section 12.4 INIT ACK chunk will be larger than the original INIT chunk. An SCTP implementation SHOULD attempt to make the INIT ACK chunk as small as possible to reduce the possibility of byte amplification attacks. The emerging consensus in QUIC and (D)TLS seems to be to limit the amplification factor to at most three times the received data; do we want to mention that heuristic here? Section 15.6 SCTP services can use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is requested to open the existing "Service Name and Transport Protocol Port Number Registry" for SCTP using the following rules, which we intend to mesh well with existing port-number registration procedures. [...] I don't really see anything following that looks like rules for IANA to follow. Is that phrase stale text from 4960? (Deferring the actual procedures to RFC 6335 seems like the right approach.) Section 18 Some of these references probably don't need to be classified as normative. e.g., RFC 3873 is the MIB for SCTP, but we don't require its implementation, and RFC 4301 is only referenced for "operators might consult [RFC4301]". Appendix A I'd consider updating the note about the modifications made to the sample code; noteworthy changes appear to include the use of fixed-width types and some general cleanup for modern C best practices. Also, it might be worth checking for undefined behavior -- "1 << (31 - i)" will be UB for i==1 on systems with 32-bit int, since 2**31 is not representable in (signed) int, which is the default type in which the expression will be evaluated, even if the result is going to be assigned to an unsigned type.
- [tsvwg] Benjamin Kaduk's Discuss on draft-ietf-ts… Benjamin Kaduk via Datatracker
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… tuexen
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… tuexen
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… tuexen
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [tsvwg] Benjamin Kaduk's Discuss on draft-iet… tuexen