Subject: [tsvwg] Roman Danyliw's No Objection on draft-ietf-tsvwg-rfc4960-bis-17: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 14 Dec 2021 12:02:46 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-tsvwg-rfc4960-bis-17: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to David Mandelberg for the SECDIR review.

** Section 2.5.3
  Once a user message has been fragmented, this fragmentation cannot be
  changed anymore.

This new text appears to have been added for clarity, but I don’t follow the
intent.

** Section 3.3.5
  When a HEARTBEAT chunk is being used for path
  verification purposes, it MUST hold a random nonce of length
  64-bit or longer ([RFC4086] provides some information on
  randomness guidelines).

As a carryover from RFC4960, the text makes clear that 64-bits is a minimum. 
Is there any guidance on the trade-space of why and when a larger nonce should
be used?

** Section 5.1.3
  Choosing a high performance
  MAC algorithm increases the resistance against cookie flooding
  attacks.  A MAC with acceptable security properties SHOULD be used.

Is “acceptable security properties” a use case specific decision and therefore
out of scope?  Taking the position of an implementer, I’m not sure how to act
on this normative “SHOULD”.

** Section 12.2.4 or 12.3. These sections appear to be establishing the
expectations for SCTP endpoints and middle-boxes.  Section 12.2.* discusses
denial of service attacks and associated mitigations via logging and statement
management by the end-points.  Would it be worth mentioning that middle-boxes
can also play a role in filtering and rate limiting if needed?

---

From: [email-masked]
Date: Wed, 15 Dec 2021 08:48:37 +0100

> On 14. Dec 2021, at 21:02, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
Hi Roman,

thanks for reading the document and providing comments. See my answers inline.

Best regards
Michael
> Thank you to David Mandelberg for the SECDIR review.
+1.
> This new text appears to have been added for clarity, but I don’t follow the
The text was added to address a comment by the former transport AD. As far
as I know it is intended to stress a difference between SCTP on the one side
and TCP and QUIC on the other side.
This limitation does exist since the initial specification of SCTP in RFC 2960
and hasn't been changed, even not by any extension.
> Is there any guidance on the trade-space of why and when a larger nonce should
This was also added to address a comment by the former transport AD. Personally
I think 64-bit are good enough, it doesn't hurt to allow for more. Please note
that the contents of the HEARTBEAT Information is not specified, but left
implementation dependent, since it is not relevant for interoperability.
> on this normative “SHOULD”.
This text is a result of the discussion following the security directorate review.
The point here is that an implementer might have to balance the CPU cycles which
are spent on generating the cookie and the ease (not sure it this is the correct
term) for an attacker to modify the cookie.
If you think, that the cited text could be improved, I'm open for text suggestions.
> can also play a role in filtering and rate limiting if needed?
I intention of these sections is to focus on how end points should behave,
possibly in the context interactions with middleboxes.
Filtering and/or rate limiting would be something doe by the middlebox and not
by the end-point.

If you prefer we can add a section describing what middleboxes can do, but that
would be a new subsection I think. Let me know if you want me such a subsection
to be addd.