Re: 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp

Hi,

>>3. I think in section 10 RFC Updates it would look better if the title of
>>the section would be formatted like
>>"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel² and
>>then "OLD TEXT:/NEW TEXT:" sections without
>>titles or section numbers. This way section numbers from previous RFC
>>will not interrupt section flow of the current
>>document. Also, "RFC 5763 Section 5" should reference to section 5 of RFC
>>5763, not to the unexciting section number in the current draft.
>
>How would you fix section 10.3.1, where the old text refers to multiple
>sections (4., 4.1., etc)?
>
>For the section 10.3.1 I would name it "Update to Section 4: SDP Offerer/Answerer Procedures". I will make sure that "Section 4" points to the RFC 7345 Section 4, not >Section 4 in the current document. Within OLD TEXT, I would not include "4. SDP Offerer/Answerer Procedures" since it is already part of the common header and I would >list sub-section heading, such as "General" and Generating The Initial Offer" without section numbers.
>
>I know this is not ideal but will remove the section number confusion. The other options are:
>
>a) Put prefix in front of each subsection such as "RFC 7345: 4.1. General"

I don't like that, since the NEW TEXT would be empty.

>b) For this particular update simply put "The content of RFC 7345 Section 4 SDP Offerer/Answerer Procedures is replaced in its entirety with the following text:" and then >put the new text without the heading.
>
>In the NEW TEXT I would put current text without "4. SDP Offerer/Answerer Procedures".

I'd prefer something like that: simply add text saying that sub-sections 4.1 - 4.5 are removed, without actually including the old text itself. 

-----
 
>>>4. I think there is a lot of confusion on the list about handling of
>>>ClientHello before the answer is received. Should we
>>>add the following text to section 5.2 or 5.4:
>>>
>>> If DTLS ClientHello message is received before the answer is received
>>>ClientHello message MUST be cached, but not
>>> processed. When the answer is received and if SDP 'setup' attribute in
>>>the answer is 'passive', then DTLS handshake
>>> MUST proceed by processing the cached DTLS ClientHello message. If SDP
>>>'setup' attribute in the answer is 'active¹,
>>> the cached DTLS ClientHello message must be discarded and offerer MUST
>>>initiate a new DTLS handshake by sending a
>>> DTLS ClientHello message towards the answerer.
>>
>>Is that supported by DTLS? Shouldn¹t it be considered an error if you
>>receive a ClientHello that you shouldn¹t receive?
>
>Also, has the WG community agreed on the procedure you suggest? This WGLC
>is not about adding new functionality that has not been discussed.
>
>>Let me rephrase this as a more generic question. Section 5.2 currently says:
>>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.
>>
>>What does offerer supposed to do with the ClientHello which is received before the answer? 
>>Does it suppose to proceed with the handshake or cache it? Or do we prefer not to specify?

We can point out that it can happen, but I don't think we should specify procedures how to handle it. 

>This is not a theoretical problem, since client will get DTLS ClientHello before the answer on a large portion
>of the calls, since DTLS ClientHello is sent at the same time as an answer. Answer typically needs to got to
>signaling server and then back to offerer. ClientHello is sent directly from answerer to offerer, so it has one
>less hop to travel. This is a race condition and ClientHello has a shorter path to travel, especially when two
>end points are located on the same local network, but the signaling server is remote.
>
>The problem with immediately proceeding with DTLS handshake is that in case of full ICE or "pure" UDP, 
>offerer does not know where to send ServerHello. In case of full ICE, remote password is not known so 
>consent to send cannot be obtained. In case of of "pure" UDP, remote address is not known, since end 
>points do not have to use the same IP:port to send and receive data.
>
>On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP, offerer can send ServerHello. We can
>either allow offerer to proceed with DTLS Handshake in these cases or specify that CleintHello should
>be cached anyway and handshake should not be initiated until the answer is received.

With ICE, don't you have to do at least one successful connectivity check before you can send anything?

>Finally, there is the issue on what should be done if multiple ClientHello messages are received due to either
>forking (sequential or parallel) or due to a denial of service attack (if attacker knows that ClientHello can force
>end point to initiate connection which will prevent legitimate connection from running, it can spray the server
>with fake ClientHello messages). If ClientHello is cached, then in combination with SDP UKS, cached ClientHello
>messages can be correlated with answer SDP and fake ClientHello messages discarded. Caching ClientHello can
>also cleanly resolve on what should happen when answer with setup:passive is received after ClientHello (which
>could be due to attack or forking).

I think Martin's draft could say that SDP UKS can be used to detect fake ClientHello messages.

>I understand this issue should have been brought up earlier, but I have not thought about it until Bernard
>brought up the issue of unverified media. Which brings the question, should this draft propose the solution
>for the unverified media issue and can this solution be just caching ClientHello until answer is received?

As Martin said, the ClientHello will be re-transmitted, so I don't think we should mandate caching. As I said above, we can point out that it can occur, and it will then be an implementation issue how to handle it.

Regards,

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