dcsctp: Persist all state in state cookie

In the example below, the association is being established between peer
A and Z, and A is the initiating party.

Before this CL, when an association was about to be established, Z would
after having received the INIT chunk, persist state in the socket about
which verification tag and initial TSN that was picked. These would be
re-generated on every incoming INIT (that's fine), but when A had
extracted the cookie from INIT_ACK and sent a reply (COOKIE_ECHO) with
the state cookie, that could fail validation when it's received by Z, if
the sent cookie was not the most recent one or if the COOKIE_ECHO had a
verification tag coming not from the most recent INIT_ACK, because Z had
replaced the state in the socket with the one generated when the second
INIT_ACK chunk was generated - state it used for validation of future
received data.

In other words:
A -> INIT 1
A -> INIT 2 (retransmission of INIT 1)
INIT 1 -> Z - sends INIT_ACK 1 with verification_tag=1, initial_tsn=1,
              cookie 1 (and records these to socket state)
INIT 2 -> Z - sends INIT_ACK 2 with verification_tag=2, initial_tsn=2,
              cookie 2 (replaces socket state with the new data)
INIT_ACK 1 -> A -> sends COOKIE_ECHO with verification_tag=1, cookie 1
COOKIE_ECHO (cookie 1) -> Z <FAILS, as the state isn't as expected>.

The solution is really to do what RFC4960 says, to not maintain any
state as the receiving peer until COOKIE_ECHO has been received. This
was initially not done because the underlying reason why this is
important in SCTP is to avoid denial of service, and this is why SCTP
has the four-way handshake. But for Data Channels - SCTP over DTLS -
this attack vector isn't available. So the implementation was
"simplified" by keeping socket state instead of encoding it in the
state cookie, but that obviously had downsides.

So with this CL, the non-initiating peer in connection establishment
doesn't keep any socket state, and puts all that state in the state
cookie instead. This allows any COOKIE_ECHO to be received by Z.

Bug: webrtc:15712
Change-Id: I596c7330ce27292612d3c9f86b21c712f6f4e408
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330440
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41340}
6 files changed
tree: c927c79d19dd4344c58495bc5d1b59ed425bd011
  1. api/
  2. audio/
  3. build_overrides/
  4. call/
  5. common_audio/
  6. common_video/
  7. data/
  8. docs/
  9. examples/
  10. experiments/
  11. g3doc/
  12. infra/
  13. logging/
  14. media/
  15. modules/
  16. net/
  17. p2p/
  18. pc/
  19. resources/
  20. rtc_base/
  21. rtc_tools/
  22. sdk/
  23. stats/
  24. system_wrappers/
  25. test/
  26. tools_webrtc/
  27. video/
  28. .clang-format
  29. .git-blame-ignore-revs
  30. .gitignore
  31. .gn
  32. .mailmap
  33. .style.yapf
  34. .vpython
  35. .vpython3
  37. BUILD.gn
  39. codereview.settings
  40. DEPS
  44. license_template.txt
  45. native-api.md
  46. OWNERS
  49. PRESUBMIT.py
  50. presubmit_test.py
  51. presubmit_test_mocks.py
  52. pylintrc
  53. pylintrc_old_style
  54. README.chromium
  55. README.md
  57. webrtc.gni
  58. webrtc_lib_link_test.cc
  59. whitespace.txt

WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.


See here for instructions on how to get started developing with the native code.

Authoritative list of directories that contain the native API header files.

More info