Re: [AVT] RFC4568 session parameter negotiation

["Mike Taylor" <[e-mail]>]

Hi Dan,

> > 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."

Well, the thing is that I think the operative word here is "mandatory"
which is another aspect of RFC4568 that leaves me wanting.  It discusses
how *new* session parameters are mandatory by default, but doesn't
really say much else about what mandatory means, or if *new" refers to
the session parameters defined in the RFC itself.  

And in paragraphs 6.3.2 and 6.3.3 which discuss the UNENCRYPTED_SRTP 
et. al. parameters it certainly never says that they are mandatory, 
only that they are negotiated.  In fact, now that I search it again I 
can't find where any of the session parameters defined in RFC4568 are
described as mandatory.  However, I just came across this

   Declarative session parameters may be added to the answer as usual;
   however, the answerer SHOULD NOT add any mandatory session parameter
   (see Section 6.3.6) that might be unknown to the offerer.

So then maybe the shortcoming in the RFC is that it fails to define
exactly what a mandatory session parameter is and fails to state whether 
any of those such as UNENCRYPTED_SRTP are mandatory.  By common English
usage one would expect a mandatory parameter to be something that must
absolutely be present in the offer but clearly that isn't the case
for UNENCRYPTED_SRTP.  One might think that it doesn't bother to explain
what a mandatory session parameter is very clearly because it is defined
in RFC4566 or RFC3264 but I don't find the term defined in either of those.

> 
> > 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):

I'm not so sure that I agree with that.  According to the RFC the
very definition of negotiated session parameters is that they apply
to the session as a whole, i.e., to the media in *both* directions.
According to Par. 4.4

   Negotiated parameters apply to data sent in both directions, whereas
   declarative parameters apply only to media sent by the entity that
   generated the SDP.

So it seems that it is not permitted to do, for example, unencrypted
SRTP in one direction and encrypted in the other direction.

So I'm afraid that I am still left wanting.  Based on the part about
how the answerer SHOULD NOT add any mandatory session parameter I am 
leaning towards believing that maybe the definition of "mandatory" is
not the common sense definition and instead is almost synonymous for
"negotiated" but I can't tell from the RFC what either of the two terms
really means and neither seems to be defined in either of the other
"core" SDP RFCs.  Have you seen formal definitions of these terms in some
other RFCs besides 4566, 4568 and 3264?  

Regards,

Mike Taylor


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