Re: [AVT] RFC4568 session parameter negotiation

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: Mike Taylor [mailto:[e-mail]] 
> Sent: Friday, April 11, 2008 2:27 PM
> To: 'Dan Wing'; [e-mail]
> Subject: RE: [AVT] RFC4568 session parameter negotiation
> 
> Hi Dan, 
> 
> Thanks for the response but I think you might have misunderstood
> my concern.
> 
> > > For example, suppose one receives an SDP offer like the following:
>   > >   v=0
>   > >   o=[e-mail] 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 not willing to support SRTP
> > > encryption.
> > >
> > > Then should
> > > the offer be rejected outright and the call terminated,
> > 
> 
> > Yes; it is the "m=" line itself, which says RTP/SAVP, that 
> causes the
> > rejection.  That is not specific to RFC4568.
> 
> I think you missed the "encryption" in the "not willing to 
> support SRTP encryption".  The offer says RTP/SAVP and the
> answerer is willing to support SRTP (RTP/SAVP) but just doesn't
> want to do encryption of the RTP.  Maybe it is a legacy phone, 
> for example, and if it has to do encryption that impacts the 
> audio quality to the extent that he phone isn't really usable.
> Whatever the case may be, it doesn't want to do encryption
> but will support authentication of RTP and RTCP.

Ah.  Ok.  You are right, I had misunderstood.  Thank you for
clarifying.

> So in other words, ideally it would like the offerer to include
> UNENCRYPTED_SRTP in the offered crypto attribute but in the
> example shown above it did not.

If the phone can not receive encrypted SRTP (for whatever reason),
it needs to do the same thing it would do if it cannot receive
G.938 (that is a codec that will be invented in the year 2043) --
it needs to reject the call setup request (in SIP, probably
with a 415 response code).  I believe the problem you are 
describing is similar to my made-up G.938 codec:  you want the 
offerer to send out an incomplete offer, and have the answerer 
guess that the offerer really has additional capabilities than it
advertised in its offer -- specifically, you want an offer to
only mention encrypting SRTP, and you want the answerer to
presume the offerer has the ability to send both 
encrypted+authenticated SRTP, and also has the (silent)
ability to send unencrypted, authenticated SRTP.

This is mentioned in Section 7.1.2 of RFC4568:

  "Furthermore, all parameters (crypto-
   suite, key parameter, and mandatory session parameters) MUST be
   acceptable to the answerer in order for the offered media stream to
   be accepted."

> So then is the answerer allowed by RFC4568 to insert UNENCRYPTED_SRTP 
> into the answer even though it wasn't present in the offer?

Yes, so long as the phone can receive encrypted SRTP, it can go ahead
and send encrypted SRTP.  This is because UNENCRYPTED_SRTP is negotiated 
(Section 6.3.2 of RFC4568), and negotiated parameters can be different 
between the offerer and the answerer (Section 5.1.2):

   Furthermore, any session parameters that are negotiated MUST be
   included in the answer.  

> Or must it reject the offer under the assumption that RFC4568
> dictates that if the offerer preferred to encrypt the RTP but would
> be willing not to, then it would have made the offer with two
> crypto attributes as shown here:
> 
>    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
>
> Then the answerer could choose the second attribute since it
> doesn't want to do encryption of the RTP. 

Right.  That would be the best thing to do if you want to have 
unencrypted SRTP in both directions.

> If the RFC was very
> explicit about this then I think the latter approach would be
> better since it allows a full expression of one's preferences
> and doesn't require any guesswork on the part of the answerer.

Right.  It also aligns with how offers for other things (e.g.,
codecs) works -- the offer is supposed to contain everything the
offerer is willing to support.  The answerer then picks and 
chooses from that list.

-d


> Maybe this is the intent of RFC4568 but I wanted to get 
> clarification.
> 
> Regards,
> 
> Mike Taylor
> 
> > >
> > > 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.  I'm certainly hoping that it isn't
> > > valid since it would simplify the logic and
> > >
> > > probably greatly increase the chances of successful negotiation.
> > 
> > But it requires the answerer to understand RTP/SAVP, and to 
> understand
> > enough
> > of RFC4568 to generate an answer containing 
> UNENCRYPTED_SRTP.  That seems
> > a
> > pretty high bar.
> > 
> > 
> > draft-ietf-mmusic-sdp-capability-negotiation is the best 
> way to increase
> > the
> > chances of successful negotiation.  That draft includes 
> some examples of
> > SDP
> > offers that contain both SRTP and RTP.
> > 
> > -d
> > 
> > 
> > > Regards,
> > >
> > > Mike Taylor
> > >
> > >
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt