Re: [MMUSIC] actpass redux

[Roman Shpount <[e-mail]>]

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 <[e-mail]>
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 <[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
>>
>>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>