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

[Christer Holmberg <[e-mail]>]

Hi,

A few questions, more related to the SDP usage than then mechanism itself.

---

Q1: Section 3.1 says:

srtp-context   = srtp-attr
                            srtp-tag
                            [srtp-ssrc";"]
                            [srtp-roc";"]
                            [srtp-seq";"]
                            [srtp-ext";"]

I don’t think this is what you want, because you would have to add “;” also after the last field.

Instead, you probably want something like:

srtp-context   = srtp-attr
                            srtp-tag
                            [srtp-param *(“;” srtp-param)]
srtp-param     = srtp-roc / srtp-seq / srtp-ext

---

Q2: Section 3.1 says:

srtp-ext       = 1*VCHAR "=" (1*VCHAR / "unknown")
...
VCHAR          = %x21-7E

I don't think you want to allow ";" (%x3B), because then one may not know whether it is part of the srtp-ext value or a separator between values.

---

Q3: Section 3.1 says:

   “The value of "unknown" MAY be used in place of any of the fields to
   indicate default behavior SHOULD be utilized by the receiving
   application” 

How is that different from when the field is not included to begin with?

Where are the default behaviors for the different fields defined?

---

Q4: Section 3.1 says:

   "The tag for an SRTP Context attribute MUST follow the peer SDP
   Security a=crypto tag for a given media stream (m=)."

It is unclear what "follow the tag" means. I assume you want to say that the SRTP Contect attribute MUST use the same tag value as the crypto attribute it is associated with?

---

Regards,

Christer





From: mmusic <[e-mail]> On Behalf Of Kyzer Davis (kydavis)
Sent: Monday, 9 October 2023 23.45
To: [e-mail]
Cc: Esteban Valverde (jovalver) <[e-mail]>
Subject: Re: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance

Group,

I have posted draft 01 which covers the items from my previous email.

Name:     draft-davis-mmusic-srtp-assurance
Revision: 01
Title:    Signaling Additional SRTP Context information via SDP
Date:     2023-10-09
Group:    Individual Submission
Pages:    21
URL:      https://www.ietf.org/archive/id/draft-davis-mmusic-srtp-assurance-01.txt
Status:   https://datatracker.ietf.org/doc/draft-davis-mmusic-srtp-assurance/
HTML:     https://www.ietf.org/archive/id/draft-davis-mmusic-srtp-assurance-01.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-davis-mmusic-srtp-assurance
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-davis-mmusic-srtp-assurance-01

Thanks,

From: mmusic <mailto:[e-mail]> On Behalf Of Kyzer Davis (kydavis)
Sent: Thursday, August 10, 2023 11:30 AM
To: mailto:[e-mail]
Cc: Esteban Valverde (jovalver) <mailto:[e-mail]>
Subject: [MMUSIC] Signaling Additional SRTP Context information via SDP - draft-davis-mmusic-srtp-assurance

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-security-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