Add Appendix further discussing why SDP Security Session Parameters extension not used

[kyzer-davis]

From RFC4568

6.3.7.  Defining New SRTP Session Parameters
   New SRTP session parameters are by default mandatory.  A newly
   defined SRTP session parameter that is prefixed with the dash
   character ("-"), however, is considered optional and MAY be ignored.
   If an SDP crypto attribute is received with an unknown session
   parameter that is not prefixed with a "-" character, that crypto
   attribute MUST be considered invalid.
   
7.1.1.  Generating the Initial Offer - Unicast Streams
   The offerer MAY include one or more other SRTP session parameters, as
   defined in Section 6.3.  Note, however, that if any SRTP session
   parameters are included that are not known to the answerer, but that
   are nonetheless mandatory (see Section 6.3.6), the negotiation will
   fail if the answerer does not support them.
   
9.2.  SRTP "Crypto" Attribute Grammar
      srtp-session-extension = ["-"] 1*(VCHAR)  ;visible chars [RFC4234]
                               ; first character must not be dash ("-")

10.3.2.2.  SRTP Session Parameter Registration
   The IANA has created a new subregistry for SRTP session parameters
   under the SRTP transport of the SDP Security Descriptions.  An IANA
   SRTP session parameter registration MUST indicate the session
   parameter name (srtp-session-extension as defined in Section 9.2);
   the name MUST NOT begin with the dash character ("-"). 

---

Examples of theoretical declarative SDP Security Session Parameters for ROC, SEQ, SSRC conveyance:

a=crypto:1 [..omitted..] SSRC=0x00845FED ROC=0x00000000 SEQ=0x005D

a=crypto:1 AEAD_AES_256_GCM \
 inline:3/sxOxrbg3CVDrxeaNs91Vle+wW1RvT/zJWTCUNP1i6L45S9qcstjBv+eo0=\
 |2^20|1:32 SSRC=0x00845FED ROC=0x0000 SEQ=0x0150

a=crypto:1 AES_CM_128_HMAC_SHA1_80 \	
  inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2:18\	
  ;inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|21|3:4 \	
  KDR=23 FEC_ORDER=SRTP_FEC UNENCRYPTED_SRTP \	
  SSRC=0xDD148F16 ROC=0x0 SEQ=0x5A53	
a=crypto:2 AES_CM_128_HMAC_SHA1_32 \	
  inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20 \	
  FEC_KEY=inline:QUJjZGVmMTIzNDU2Nzg5QUJDREUwMTIzNDU2Nzg5|2^20|2:4 \	
  WSH=60 SSRC=0xD903 ROC=0x0002 SEQ=0xB043	
a=crypto:3 AEAD_AES_256_GCM \	
  inline:HGAPy4Cedy/qumbZvpuCZSVT7rNDk8vG4TdUXp5hkyWqJCqiLRGab0KJy1g= \	
  UNAUTHENTICATED_SRTP SSRC=0x05 ROC=0x02 SEQ=unknown	
a=crypto:4 AEAD_AES_128_GCM \	
  inline:bQJXGzEPXJPClrd78xwALdaZDs/dLttBLfLE5Q== \	
  UNENCRYPTED_SRTCP SSRC=0x6500

---

My Analysis:

• If you put these in the a=crypto then other side has to support it else they are obligated to fail the session (assuming no alternative exist) e.g a=crypto1: ... ROC=0x1 being unknown could break things if that is the only a=crypto option in the SDP.
• You can add a dash char at the start to mark this session parameter as optional so the remote side can safely ignore it e.g a=crypto1: ... -ROC=0x1
  • However in the ABNF and IANA sections a dash character is explicitly disallowed conflicting with the previous statement...
  • I can only assume the original authors meant that they only wanted to register the mandatory MUST know to implement extension with IANA and dash ones are free-for all implementation specific (kind of like the X- experimental header...
  • This conflicting statement is problematic and implementations may not even support the dash at all
• Now back to the first point I could see offering one with and without the ROC since an unknown ROC= would mean crypto:1 is invalid and fallback to crypto:2 which is the same thing as crypto 1... kind of like what I see now with UNAUTHENTICATED_SRTP where a party may send two identical lines with and without the postfix....

a=crypto:1 AEAD... inline:abcd... ROC=0x1
a=crypto:2 AEAD... inline:abcd... 

So in closing:

• So if this is going potentially to be destructive to sessions/applications AND cause duplicate SDP lines lets just cut to the chase and make this its own SDP attribute a=srtcpctx loosely coupled with the crypto line of choice by mapping tags.
• We could leverage the dash but nobody has ever done this (that I can find) so it still may be destructive to a session/application.
• We should ensure the text states that values conveyed by our SDP attribute can be ignore if sufficient logic alternative exists.
  • For SSRC/ROC/SEQ use the RTP Packet and late binding techniques

Would also need to consider how this scales as per #1, the a=crypto gets very long even if you coupled them nicely wrapped in start/stop delimiters.

[kyzer-davis]

Paraphrasing feedback from IETF individual discussions:
"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"

[valvo27]

Nothing to add here, this is more of a discovery based on feedback, if Jonathan Lennox sees this as a potential interop issue, I rather go with the least impacting for better adoption.