W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2019

Re: [webrtc-pc] Should SCTP transport enter "closed" state when DTLS transport does? (#2360)

From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
Date: Fri, 06 Dec 2019 14:13:18 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-562586673-1575641597-sysbot+gh@w3.org>
In our particular stack, where there is no procedure for replacing or restarting the DTLS connection underlying the SCTP transport, I think it is correct to have the SCTP state machine go to "closed" when the DTLS state machine does.

There is a procedure for restarting an ICE transport (ICE restart), so stopping DTLS or SCTP when ICE transport goes to "failed" would not be appropriate

The only part of RFC 8261 that deals with shutting down seems to be this paragraph:
```
   o  All SCTP associations are single-homed, because DTLS does not
      expose any address management to its upper layer.
```
RFC 4960 section 8.1 says "The association is automatically closed when the peer endpoint becomes unreachable."

The particular situation I'm staring at now involves incoming error alerts according to RFC 8446 (TLS 1.3) section 6.2 - the RFC says that "Upon transmission or receipt of a fatal alert message, both parties MUST immediately close the connection."

I think section 6.2.5 (quoted above) should be invoked immediately when there is a DTLS error alert. The peer endpoint has just become unreachable.





-- 
GitHub Notification of comment by alvestrand
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2360#issuecomment-562586673 using your GitHub account
Received on Friday, 6 December 2019 14:13:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:34 UTC