[MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance

["Kyzer Davis (kydavis)" <[e-mail]>]

Hello all,

 

I presented draft-davis-valverde-srtp-assurance-00 at Dispatch and the
outcome was to dispatch to MMUSIC WG.

I have re-submitted draft-davis-valverde-srtp-assurance-00 as
draft-davis-mmusic-srtp-assurance-00 with no changes.

 

To view that session and/slides see below:

- https://youtu.be/KT3mMX9CMdA?t=3113

-
https://datatracker.ietf.org/meeting/117/materials/slides-117-dispatch-sdp-s
ecurity-assurance-for-secure-real-time-transport-protocol-srtp

- A quick slide note, before the dispatch session I was working on a
draft-01 which leveraged Solution A in these slides while draft-00 uses
Solution B.

  - Jonathan Lennox brought up a good point after the session which favors
solution B:

  - Paraphrasing: "We know how implementations will handle unknown SDP
attributes; we do not know well how well how implementations will handle
unknown SDP Security Session Parameters"

    - I dug into this a bit more and tend to agree. So draft-01 now
continues to use solution B (a=srtpctx) new SDP Attribute to convey the
required SRTP Context information alongside a=crypto.

      - I have a full write-up on GitHub with far more details:
https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/5

 

In addition, some other draft-01 actions items that were brought up in chat,
at the mic or in person 1:1:

- "Why this can't be a RTP Header Extension" from Richard Barnes.
(https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/11)

- "Discuss sending some update when ROC updates" from Jonathan Rosenberg.
(https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/10)

  - Already text in the draft around this; which covers "99.9% of
scenarios".

- "Method to Convey Multiple SSRCs for a given stream" from various
(https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/1)

  - Two solutions proposed in the GitHub issue

- A statement Cullen Jennings made about focusing on the problem statements.

  - I want to re-write the problem sections like RFC7744 where each problem
in a scenario is cited as Ux.y and then discussed (Section 2.1.1 and 2.1.2)

  - I took a stab at a rough draft of this in "Discuss why SEQ is signaled
in the SDP" via
(https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/9)

  - Overall item is in
https://github.com/kyzer-davis/srtp-assurance-rfc-draft/issues/13

 

Lastly, the following items are already merged into draft-01 over on GitHub:

- Change contact name from IESG to IETF in IANA Considerations #2

- Discuss RFC4568 "Late Joiner" in problem statement: #3

- Split Serial forking scenario into its own section #4

- Add MIKEY considerations to Protocol Design section #6

- Change doc title #7 (new title: "Signaling Additional SRTP Context
information via SDP")

- Add SEQ abbreviation earlier #8

  

Thanks,

 

---

Kyzer Davis