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

On Thu, Apr 27, 2017 at 3:19 PM, Christer Holmberg <
[email protected]> wrote:

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

I do prefer this option since excessive quoting of now irrelevant text
makes the document harder to read.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

The text in section 5.2 already says that client MUST be prepared to
receive DTLS ClientHello, so it is should be obvious that this can happen.
What the text does not do is say what should be done with this ClientHello.
I guess you are suggesting this can be left unspecified.


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

With ICE lite end point can send data as soon as it received a connectivity
check, so it is definitely possible to establish a DTLS association before
the answer to an offer from ICE lite end point is received. This is a
security and implementation issue, so it would be nice to specify what
should be done here.


> >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 agree, we can leave the multiple ClientHello handling for martin's draft.


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


If ClientHello is not cached, connection setup will be delayed by 5 sec
(DTLS re-transmit timer). This is quite noticeable and produces negative
client experience. So, caching or immediate handling is desired. If
ClientHello is cached, this will work with full ICE and will prevent
unverified media.

Regards,
______________
Roman Shpount

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