The maximum message size parameter about draft-westerlund-tsvwg-dtls-over-sctp-bis

[tuexen]

What kind of use case do you have in mind? Limiting the record size could be done using RFC 8449. So isn't the suggested extension useful for transport protocols, which are message oriented and support large messages using multiple records. Right now I don't see any, which would carry DTLS.

[gloinul]

So our draft currently defines a SCTP parameter "dtls_over_sctp_maximum_message_size" that provides a limit on the total user message size for the upper layer protocol. This is defined prior to DTLS fragmentation and expansion due to the DTLS record overhead. So this parameter is basically to provide the peer indication of implementation limits in handling certain messages sizes.

From a upper layer protocol perspective this challenge exists in general independently if DTLS is used or not. That is why I am asking if this should be generalized as mechanism so that it could be applied even if this DTLS/SCTP was not used. However, with DTLS in the mix the supported maximum message size becomes a combination of several factors. What the ULP is capable of buffering and processing assuming that the lower layers (DTLS and SCTP) is not the limiting factor. And if DTLS or SCTP or combination if implementation is the limiting factor the limit for that combination.

So limitations that could arise without making assumption on implementation are:

• Buffering in DTLS sender or receiver if the ULP to DTLS API does not support partial message handling.
• SCTP buffering if its API does not support partial message handling

I hope this makes it clear that I think we have limitations if the implementations all the way are optimal, and even in this case we might want a method for the ULP to express limitations to the peer.

[teiclap]

Limitations due to implementation or the execution environment and the relationship with the SCTP User are implementation specific and not covered by the present recommendation.
Text has been added for this.

[emanjon]

To me it would make sense to define this SCTP parameter as "sctp_maximum_message_size" instead.

[gloinul]

So to make it clear. The currently in text proposed parameter is an DTLS parameter for maximum message size in this SCTP context. So I think the question, one that we likely should ask the WG for input about if we are not all on one side is.

A) Have a DTLS parameter specifically for this contexts Maximum Message Size

B) Have a generic SCTP User Message Size parameter defined as an SCTP parameter agreed on during handshake.

So B) is generic and could be used in any context also not for DTLS. However, we would need to provide a interpretation here for the value in regards to the DTLS overhead, which for A) is obviously message size above DTLS. Secondly when defining B) we would need to have more consideration for third party attacks. In the DTLS context we could consider verifying the value. But, it is a potential Denial of Service threat by third party to reduce the value.

So I do wonder if going down the general SCTP route here is the best. But lets discuss and I think this issue can be worth an email the the TSVWG mailing list.

[tuexen]

So to make it clear. The currently in text proposed parameter is an DTLS parameter for maximum message size in this SCTP context. So I think the question, one that we likely should ask the WG for input about if we are not all on one side is.

A) Have a DTLS parameter specifically for this contexts Maximum Message Size

B) Have a generic SCTP User Message Size parameter defined as an SCTP parameter agreed on during handshake.

So B) is generic and could be used in any context also not for DTLS. However, we would need to provide a interpretation here for the value in regards to the DTLS overhead, which for A) is obviously message size above DTLS. Secondly when defining B) we would need to have more consideration for third party attacks. In the DTLS context we could consider verifying the value. But, it is a potential Denial of Service threat by third party to reduce the value.

So I do wonder if going down the general SCTP route here is the best. But lets discuss and I think this issue can be worth an email the the TSVWG mailing list.

But what is the semantic of the SCTP parameter? SCTP supports transferring arbitrary large user messages by using the partial delivery API. So this might be an upper layer issue. Why should SCTP care? Also DTLS only processes DTLS messages. DTLS only has to pass through the MSG_EOR. This can be use by some reassembly layer on top of the application or just by the application itself. The message size limit is a property of the reassembly layer or the application. Basically what sits on top of DTLS.

SCTP would just pass the parameter through.

What is the application we are considering? Diameter? Does Diameter have a message size limit negotiated at the beginning?

[gloinul]

So the first issue is the partial delivery requirement. That is not mandated but clearly good to have when the ULP message size goes up. However, if one doesn't have partial delivery then one are in the hands of the combination of receiver window and the application's stream and user message pattern.

So from SCTPs stand point the parameter is not needed as it is ULPs problem. With DTLS we have a shim security layer that interacts between the SCTP API and the ULP capabilities and that could cause issues if there are true limitations on the RFC 6083bis reassembly layer if the ULP is not supporting partial delivery of user messages also, or on a granularity that doesn't match DTLS record sizes.

So from my perspective I think a DTLS level parameter for RFC6083bis message sizes do make sense as this is the layer in the stack where the interaction becomes problematic and it has the possibility to communicate both upwards and downwards to agree on restrictions.

If we move it down, the message size limitation could possible be re-used by ULPs that forgot to include it in the ULP protocol and later realizes that it needs to know limitations.

I think an important aspect of this is the fact that we end up in a situation where we might not be able to provide a feedback signal that the receiver failed to decrypt the message because it run out of memory so the original sender needs to resend the message. Once the receiver have cumulative ACKed the data the sender will assume that we have provided the data to the ULP. With this reassembly and decryption this can in fact fail.

I haven't dug into the 3GPP Specs for the various protocols that can theoretically hit the DTLS limit in future deployments. But the 3GPP interface protocols that we are talking about are: F1, E1, Xn, NG-C.

So I have no strong opinion if the message size limit should be in SCTP or DTLS, but to my understanding we need the signalling.

[tuexen]

I have been contemplating about this for a while...

If I understand the issue correctly, we are discussing the introduction of a message (at the SCTP layer, the DTLS layer, or at higher layers), which indicate the maximum size a receiver is willing to accept.
What are the consequences of having it?

• For the receiver I do not see any. It has to deal with receiving larger messages anyway and protect itself. The peer can not honour the limit due to bugs or even intentionally. So I guess it has to monitor things and abort the communication if the peer sends messages being too large.
• For the sender I'm not sure. Either the size is sufficient, then there is no impact. Or it might not be. Then the sender can perform the communication and had to stop once it has to send a message exceeding the limit.

So in both cases the result is the same as in the case where the receiver only protects itself, which it has to do anyway.
From an implementation perspective, SCTP supports arbitrary large user messages using the partial delivery API. DTLS has not that much of a problem, since it has to deal with about 16 KB messages. So the simplest implementation at that layer would be to parse for DTLS records and just pass the MSG_EOR flag from the SCTP to the upper layer of DTLS.
So it comes to the application layer. If looking, for example, at Diameter/TLS/TCP, the Diameter layer has to protect it self (or support messages up to 16 MB). This is not done by TCP or TLS.

In summary, I think the layer at the receiver doing the reassembly of the application layer message MUST protect itself and terminate the communication if its limits are reached. Adding signalling of this limit, does not make the receiver simpler. So I would vote for not adding such a limit to any layer...

[gloinul]

@tuexen I would also prefer to avoid this message if possible. However, I think we have two issues. The first is that there so far has been limited support for mandating the implementation of the partial delivery. Maybe that was a misunderstanding of why and was removed for being poorly motivated.

However, if one does not mandate that one can end up in a situation where the DTLS receiver layer gets stuck with the data and can't hand it over properly to the higher layer. There are two issues here, the first the question of what API there exist between the DTLS layer and the ULP on the receiver side. That is implementation dependent and if that is not partially delivery then the buffering happens in the DTLS layer.

Secondly we have the issue with the signalling related to the partially delivered messages. So on the receiver side and when the DTLS layer reads an MSG_EOR, yes then it knows that it should be able to complete the decrypt and integrity verification and provide the message upwards and if that is successful then it clearly can give the ULP a MSG_EOR also. However, the issue I am worried here is related to if the failure occur in the receiver DTLS Layer when it attempts to read from the SCTP but runs out of memory. How does it gracefully deal with this situation if you overrun the receivers capability. I think there are two cases here. The first if it can't read more from a user message due to memory limitations and needs to drop the message. What error are exchanged and can the sender determine that this has happend? The other case is if the DTLS layer would be able to read all of the protected user message from the lower layer, but be unable to complete the deprotection operation and need to drop the message. Are there any way out of this other than terminating the association to force the ULP to recover the state?

These issues are mainly the reason I see a need to introduce a message size limitation to help avoid failures. I think this issue needs further discussion.

[tuexen]

@tuexen I would also prefer to avoid this message if possible. However, I think we have two issues. The first is that there so far has been limited support for mandating the implementation of the partial delivery. Maybe that was a misunderstanding of why and was removed for being poorly motivated.

Lets look at buffering within the SCTP stack. We need to distinguish two cases:

1. Using DATA chunks: If the stack does not support partial delivery, the maximum message size is basically the advertised receiver window (modulo chunk overhead). Such a stack will have a very limited performance in transferring maximum sized packets and is has to use reneging. RFC 4960 says:

Note: If the data receiver runs out of buffer space while still
waiting for more fragments to complete the reassembly of the message,
it should dispatch part of its inbound message through a partial
delivery API (see Section 10), freeing some of its receive buffer
space so that the rest of the message may be received.

RFC 4960bis will change the should to a SHOULD. Please note that all general purpose implementations I'm aware of support partial delivery.

2. Using I-DATA chunks: It gets very hard to implement a stack which does not support partial delivery and does not deadlock. That is why you interleave messages from different streams per default. See RFC 8260.

So I see no reason not to require the support of partial delivery.

However, if one does not mandate that one can end up in a situation where the DTLS receiver layer gets stuck with the data and can't hand it over properly to the higher layer. There are two issues here, the first the question of what API there exist between the DTLS layer and the ULP on the receiver side. That is implementation dependent and if that is not partially delivery then the buffering happens in the DTLS layer.

Messages must be reassembled by either the DTLS layer or the application layer. Lets call the layer, which is doing this, the reassembly layer.

Since there is no specified upper layer API specified for DTLS, we need to be generic here. Either the reassembly layer is DTLS and the application gets complete messages or the reassembly layer is the application layer and the application gets fragments, an indication which fragments belong together (like the incoming SID) and an indication if the fragments are the final one of a message. But don't have to specify anything, we just need to be sure it can be done.

Secondly we have the issue with the signalling related to the partially delivered messages. So on the receiver side and when the DTLS layer reads an MSG_EOR, yes then it knows that it should be able to complete the decrypt and integrity verification and provide the message upwards and if that is successful then it clearly can give the ULP a MSG_EOR also.

I think the only thing the DTLS receiver needs to do, is

1. Verify that a DTLS record ends at the end of the message.
2. Pass the end indication up to the application if DTLS is not the reassembly layer.

If the first check does not pass, one could use a DTLS Alert message to signal this a gracefully terminate the SCTP association. Maybe we should register a message via IANA.

However, the issue I am worried here is related to if the failure occur in the receiver DTLS Layer when it attempts to read from the SCTP but runs out of memory. How does it gracefully deal with this situation if you overrun the receivers capability. I think there are two cases here. The first if it can't read more from a user
message due to memory limitations and needs to drop the message. What error are exchanged and can the sender determine that this has happend? The other case is if the DTLS layer would be able to read all of the protected user message from the lower layer, but be unable to complete the deprotection operation and need to drop the message. Are there any way out of this other than terminating the association to force the ULP to recover the state?

There can be two issues as you mention:

1. DTLS encounters an issue while processing a record. We can signal this with an DTLS Alert and gracefully shutdown the association.
2. The reassembly layer runs out of resources. We need to terminate the association. I'm not sure about the usefulness of a specific error message. One could use an DTLS Alert or send an SCTP ABORT with a User Initiated abort cause.

These issues are mainly the reason I see a need to introduce a message size limitation to help avoid failures. I think this issue needs further discussion.

Yes, let us discuss this tomorrow. I just wrote up the above to have a base for the discussion.

[gloinul]

Author discussion conclusion:

• Require SCTP partial delivery support.
• Remove message size limitation signalling
• Make clear that if receiver fails to reassembly it MUST to detect it. Receivers reaction may include aborting the SCTP association.
• In case there is a missmatch between SCTP user message end and DTLS record end, this also needs to be handled. This should be signalled likely in the DTLS record, with an Alert. Find a matching or defining a new.

[gloinul]

I would appreciate if someone took a look at the PR #48 as it is quite big before we merge it. I think it address all that was agreed on.

[tuexen]

Done. I provided concrete suggestions. Please go through the comments, address them if you find them appropriate. Then I'm fine with the PR being merged.

[gloinul]

I will merge the PR, but for your information I did rewrite one sentence significantly. I also added a paragraph in "Mapping of DTLS Records" section on PR-SCTP.