Re: [MMUSIC] actpass redux

[Paul Kyzivat <[e-mail]>]

The scope for this discussion isn't defined. Is this just for SRTP? Or 
also for SCTP? Or also for TCP and TLS?

	Thanks,
	Paul

On 6/2/17 5:16 PM, Roman Shpount wrote:
> Just to provide the historic background for this change. We have 
> discussed setup role in subsequent offers with Christer before IETF95 
> and decided to remove the text that setup MUST be actpass in all the 
> offers. This removed this requirement from the initial offers as well 
> (even though they weren't discussed at that time).
> 
> Now we have three options:
> 
> 1. setup can be whatever application wants in all offers (current text)
> 2. setup MUST be actpass in initial offer and whatever application wants 
> in subsequent (or, alternatively actpass or negotiated role in 
> subsequent offers).
> 3. setup MUST be actpass in all the offers (back to RFC 5763)
> 
> My top preference is that setup SHOULD be actpass in all the offers. 
> Second preference is 1 and hope that application will do the right thing.
> 
>  From my point of view 2 is strange, since there is no principal 
> difference between initial and subsequent offers, especially when 3pcc 
> comes into play. Any offer can end up being subsequent for one end point 
> and initial for another.
> 
> I also think that RFC 5763 requirement is too strong. There are 
> implementations which send offers without actpass so it is already 
> violated. There are also legitimate scenarios where sending current role 
> (subsequent offers without ICE restart) or active (endpoints with basic 
> UDP behind NAT) makes more sense.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Fri, Jun 2, 2017 at 2:02 PM, Roman Shpount <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Hi All,
> 
>     There was a discussion regarding the setup attribute value in
>     subsequent offers when establishing new DTLS association is not
>     desired. Based on that discussion it was decided that setup value
>     can be either currently negotiated value or actpass. There are also
>     UDP/DTLS without STUN NAT traversal scenarios that only work when
>     end point behind NAT is active. I think sending actpass in offers is
>     a generally safer option, but I think SHOULD here is more
>     appropriate then MUST.
> 
>     Please note that https://tools.ietf.org/html/rfc5763#section-5
>     <https://tools.ietf.org/html/rfc5763#section-5> says:
> 
>         The endpoint MUST use the setup attribute defined in [RFC4145].
>         The endpoint that is the offerer MUST use the setup attribute
>         value of setup:actpass and be prepared to receive a client_hello
>         before it receives the answer.
> 
> 
>     This applies not only to initial but to ALL offers.
> 
>     Finally, I can double check, but I am fairly sure there are current
>     implementation that violate this rule.
> 
>     Regards,
> 
>     _____________
>     Roman Shpount
> 
>     On Fri, Jun 2, 2017 at 12:44 PM, Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>> wrote:
> 
>         Hi folks,
> 
>         RFC 5763 required (and JSEP imported) that all offers include
> 
>            a=setup:actpass
> 
>         However, assuming I am reading:
>         https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24
>         <https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
>         correctly, S 4.2 allows the initial offer to contain anything,
>         though encourages actpass:
> 
>             When an offerer sends the initial offer, the offerer MUST
>         insert an
>             SDP 'setup' attribute according to the procedures in
>         [RFC4145], and
>             one or more SDP 'fingerprint' attributes according to the
>         procedures
>             in [RFC8122].  In addition, the offerer MUST insert in the
>         offer an
>             SDP 'tls-id' attribute with a unique value.
> 
>             If the offerer inserts the SDP 'setup' attribute with an
>         'actpass' or
>             'passive' attribute value, the offerer MUST be prepared to
>         receive a
>             DTLS ClientHello message (if a new DTLS association is
>         established by
>             the answerer) from the answerer before the offerer receives
>         the SDP
>             answer.
> 
>         For subequent offers, it also gives flexibility but points at 4145.
> 
> 
>         So...
> 
>         1. Changing the behavior for initial offers seems like it presents
>         a serious interop risk, because previously you could depend on
>         the offer being actpass.
> 
>         2. JSEP requires actpass for all offers, so at least it's stricter.
> 
> 
>         What was the rationale for these changes? Feel free to point me
>         at the
>         mailing list discussion where that happened.
> 
>         -Ekr
>           Hi folks,
> 
>         RFC 5763 required (and JSEP imported) that all offers include
> 
>            a=setup:actpass
> 
>         However, assuming I am reading:
>         https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24
>         <https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24>
>         correctly, S 4.2 allows the initial offer to contain anything,
>         though encourages actpass:
> 
>             When an offerer sends the initial offer, the offerer MUST
>         insert an
>             SDP 'setup' attribute according to the procedures in
>         [RFC4145], and
>             one or more SDP 'fingerprint' attributes according to the
>         procedures
>             in [RFC8122].  In addition, the offerer MUST insert in the
>         offer an
>             SDP 'tls-id' attribute with a unique value.
> 
>             If the offerer inserts the SDP 'setup' attribute with an
>         'actpass' or
>             'passive' attribute value, the offerer MUST be prepared to
>         receive a
>             DTLS ClientHello message (if a new DTLS association is
>         established by
>             the answerer) from the answerer before the offerer receives
>         the SDP
>             answer.
> 
>         For subequent offers, it also gives flexibility but points at 4145.
> 
> 
>         So...
> 
>         1. Changing the behavior for initial offers seems like it presents
>         a serious interop risk, because previously you could depend on
>         the offer being actpass.
> 
>         2. JSEP requires actpass for all offers, so at least it's stricter.
> 
> 
>         What was the rationale for these changes? Feel free to point me
>         at the
>         mailing list discussion where that happened.
> 
>         -Ekr
> 
>         _______________________________________________
>         mmusic mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>