Subject: [MMUSIC] RFC4568 session parameter negotiation

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Apr 2008 15:18:59 -0700

Hi All,

I'm trying to understand the proper way to negotiate RFC4568 crypto
attribute
session parameters such as UNENCRYPTED_SRTP.  In section 5.1.2,
Generating the Initial Answer -Unicast Streams, the RFC says

    When the answerer receives the initial offer with one or more crypto
   attributes for a given unicast media stream, the answerer MUST either
   accept exactly one of the offered crypto attributes, or the offered
   stream MUST be rejected.

and

   Furthermore, any session parameters that are negotiated MUST be
   included in the answer.  Declarative session parameters provided by
   the offerer are not included in the answer; however, the answerer may
   provide its own set of declarative session parameters.

So this seems like maybe the answerer can insert its own declarative
session parameters into the crypto attribute in the answer, along with
its keying material, but I'm not clear if it is proper to insert a
negotiated
parameters such as UNENCRYPTED_SRTP, into a crypto attribute in the 
response.  

For example, suppose one receives an SDP offer like the following:

  v=0
  o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
  s=Session123
  i=A test session
  c=IN IP4 10.248.0.239
  t=0 0
  m=audio 5004 RTP/SAVP 0 8
  a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4

and the receiver of this offer is willing to support SRTP but not SRTP
encryption.  Then since
the offer does not include the UNENCRYPTED_SRTP session parameter should
the offer be rejected outright and the call terminated, or is it OK (not in
violation of the
RFC) to respond with an answer that inserts the UNENCRYPTED_SRTP parameter 
inserted into the answer crypto attribute as follows:

v=0
o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
s=Session323
i=A test session
c=IN IP4 10.248.0.240
t=0 0
m=audio 5004 RTP/SAVP 0 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:
Ukdkw1gfjslkeUvksjelKKkdjwekslkejLKE11dk|2^20|1:4 UNENCRYPTED_SRTP

In other words, per the RFC is it incumbent upon the offerer to explicitly
indicate
a willingness to do unencrypted SRTP, but a preference for encrypted SRTP,
by including
two crypto attriubutes as in

  v=0
  o=[email-masked] 52342343 9239423 IN IP4 10.248.0.251
  s=Session123
  i=A test session
  c=IN IP4 10.248.0.239
  t=0 0
  m=audio 5004 RTP/SAVP 0 8
  a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ljsdk1ksjld32368klksDSDkddKDKFsDskdldKKd|2^20|1:4
  a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:ya3k283klkWWdkjwFek2932ckdejlklkelksl233|2^20|1:4 UNENCRYPTED_SRTP

So then if such a parameter is not present in the offer the answerer can
assume that the offerer
is not willing to support it.

This seems better since it forces offerers to explicitly indicate what
they're willing to negotiate, but
I wanted to make sure whether or not inserting a negotiated session
parameter like UNENCRYPTED_SRTP
into a response is valid per RFC4568 or if the fact that it is a
"negotiated" parameter means
that it is not valid to insert it.

Regards,

Mike Taylor

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic