Re: actpass redux

Hi,

For subsequent offers, draft-dtls-sdp says SHOULD-use-actpass-MAY-use-something-else.

We can apply that SHOULD to initial offers if people want to.

Regards,

Christer

From: mmusic [mailto:[email protected]] On Behalf Of Roman Shpount
Sent: 02 June 2017 23:16
To: Eric Rescorla <[email protected]>
Cc: mmusic WG <[email protected]>
Subject: Re: [MMUSIC] actpass redux

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

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

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

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic