Re: actpass redux
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxsmBj_c-rtYLk0Gjp2ZfV_w-MzkaKGbYbmLPz6uVVMxEQ@mail.gmail.com> |
Paul, I assume this is limited to anything which implements draft-ietf-mmusic-dtls-sdp, which means it covers UDP/TLS/*, UDP/DTLS/* or TDP/DTLS/* protocols such as UDP/TLS/RTP/SAVP, TCP/DTLS/RTP/SAVP, UDP/DTLS/SCTP, TCP/DTLS/SCTP. TCP/* and TLS/* protocols are not in scope of this discussion and they continue to be covered by RFC 4145 as far as setup attribute is concerned. Regards, _____________ Roman Shpount On Fri, Jun 2, 2017 at 5:33 PM, Paul Kyzivat <[email protected]> wrote: > 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 >> >> > _______________________________________________ > mmusic mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic