Re: actpass redux
Paul Kyzivat <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/mmusic > <https://www.ietf.org/mailman/listinfo/mmusic> > > > > > > _______________________________________________ > mmusic mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mmusic >