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

Hi Christer,

On Thu, Apr 27, 2017 at 1:48 AM, Christer Holmberg <
[email protected]> wrote:

> >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.  In the NEW TEXT I would put current text without "4. SDP
Offerer/Answerer Procedures".

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"

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 any case, the references from section names should be fixed to point to
original RFC, not to the current document.


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

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.

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

Regards,

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