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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 16 Dec 2021 03:20:43 -0800

Éric Vyncke 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 for the work put into this document. I am copying Rob Wilton's text
as it also applies to my review:
       "Given my lack of familiarity with STCP, I have only quickly reviewed
        the diffs before this document and the base RFC, and do not have any
        significant comments that will improve this document."

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Gorry Fairhurst for the shepherd's write-up including the
section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 10 --
I wonder what is the purpose of this section dedicated to ICMP handling, e.g.,
ICMP1-5 are pretty obvious. It is of course not harmful to keep this section
but perhaps limit it to the important ones like ICMP6 and the rest ?

ICMP7: please s/v4/IPv4/ and s/v6/IPv6/ (also applicable in other parts). I
would also prefer s/an implementation MAY process/an implementation SHOULD
process/

-- Section 12.2.4.1. --
Suggest to use "ESP" wording as in 12.2.3

About "IP Authentication Header", I am unsure whether it is still commonly used
and adding a reference to RFC 4302 is probably required.

-- Section 7.2.1 --
Just curious about why the "cwd" is computed differently for IPv4 and IPv6 (I
do not understand the 60 bytes difference)

---

From: [email-masked]
Date: Thu, 23 Dec 2021 01:13:31 +0100

> On 16. Dec 2021, at 12:20, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 
Hi Éric,

thanks for your comments. See my answers below.

Best regards
Michael
> but perhaps limit it to the important ones like ICMP6 and the rest ?
The initial RFC 2960 did not contain any specification for the handling of ICMP
packet in relation to SCTP. This was added to RFC 4960. See
https://datatracker.ietf.org/doc/html/rfc4460#section-2.37

Basically, it describes the handling of ICMP packets. This includes also to
state which ICMP packets need to be processed and which don't. This is done
in the initial rules. But ICMP3 describes the handling of Port Unreachable
messages and this is different from the way stated in RFC 1122 for TCP.
When we wrote the text, it wasn't exactly clear to SCTP implementers how
to deal with ICMP. So the text was written in a detailed way.
So I would prefer to keep the text. Removing some of them would also require
a renumbering and I guess some code refers to the numbers (in comments).
> ICMP7: please s/v4/IPv4/ and s/v6/IPv6/ (also applicable in other parts). I
The v4 was referring to ICMPv4 and v6 to ICMPv6. To improve clarity, I changed the
text to:

<li><t>If the ICMP message is either an ICMPv6 message of type "Packet Too Big"
or an ICMPv4 message with type "Destination Unreachable" and code
"Fragmentation Needed", an implementation MAY process this information as
defined for PMTU discovery.</t></li>
> would also prefer s/an implementation MAY process/an implementation SHOULD
The v4 was referring to ICMPv4 and v6 to ICMPv6. Since we have text that PMTUD
SHOULD be done, I changed the text to:

<li><t>If the ICMP message is either an ICMPv6 message of type "Packet Too Big"
or an ICMPv4 message of type "Destination Unreachable" and code
"Fragmentation Needed", an implementation MAY process this information as
defined for PMTU discovery.</t></li>
> and adding a reference to RFC 4302 is probably required.
I changed
<t>The IP Authentication Header and Encapsulating Security Payload might be
useful in reducing the risk of certain kinds of denial-of-service attacks.</t>
to
<t>ESP might be useful in reducing the risk of certain kinds of
denial-of-service attacks.</t>
because Benjamin Kaduk said in his comments
"Current IPSECME WG guidance is to prefer ESP with NULL encryption over
AH, so I'd recommend not mentioning AH here."
> do not understand the 60 bytes difference)
The text in RFC 4960 was:
cwnd = min(4*MTU, max (2*MTU, 4380 bytes))
which was based on text from RFC 2581:
cwnd = min (4*SMSS, max (2*SMSS, 4380 bytes))
Since 4380 = 3 * 1460 and 1460 is the MSS when using an MTU of 1500 bytes and IPv4,
I used that to compute the limits for SCTP, where only the maximum DATA chunk size
is considered.
So for IPv4 and an MTU of 1500 bytes, you can have a DATA chunk of size 1500-20-12 = 1468
and for IPv6 we get 1500-40-12 = 1448. Using this results in
cwnd = min(4 * PMDCS, max(2 * PMDCS, 4404))
for IPv4, since 3 * 1468 = 4404, and for IPv6 we get
cwnd = min(4 * PMDCS, max(2 * PMDCS, 4344))
because 3 * 1448 = 4344.
In both cases it means for an IP level MTU of 1500 bytes that the initial congestion
window is 3 full sized packets. I guess this is what is intended.

Does this address your issues?