Early arriving media before 200 OK

["Rob Raymond" <robin@xxxxxxxxxxxxxxx>]

I have some concerns regarding the DTLS. Some of the topics have been
discussed previously but I wanted to jump in and add my $0.02.

One issue is regarding early arriving media before the 200 OK has arrived.
As everyone is aware there is a window of opportunity where an RTP stream
can be sent to a client before the 200 OK arrives.


          Proxy
          /    \  ^
         /      \  \
        /        \  \
       /          \  200 OK
      /            \  \
Client A          Client B
       <--- DTLS + media -- (not validated until 200 OK arrives)


The trouble I have is with the proposed solutions offered thus far for this
issue. From my perspective they are not adequate solutions.

First, the potential damage from such a scenario is large. Client A is
placing a secure call, but the call isn't secure until the 200 OK arrives.
All media before this is not validated and anyone can send in bogus media
(including a nasty audio conversation) before the 200 OK arrives.

The window is actually fairly large because the window extends from the time
client B is ringing to the time it answers and the 200 OK traverses back to
client A. Further, adding someone with network abilities in the mix can
suppress the 200 OK from even arriving. Even without that added complexity
the window is still large enough to do damage. What damage can happen during
that time? Lots - the caller could be told some nasty things (including
things that could destroy personal/business relationships) by someone
pretending to be client B. Client A might even hang up the call because of
the fraud and might never even know that a fraud occurred as the 200 OK
arrives after the hang-up.

Adding to the complexity is that the client A never knows how long a period
of time it will take from the arrival of media to the time the 200 OK will
arrive.

BTW, I'm talking exclusively about early arriving media from the 200 OK and
not about early media.

Here are the solutions that I've heard:
1) Discard all media before the 200 OK - not acceptable, that early arriving
media often includes the "hello" which if lost causes a very poor user call
experience. Horrible in fact. I'm already concerned by the amount of data
loss during the round-trips for DTLS negotiation and the required SIP
signaling for ICE before a path change, let alone adding to the trouble.

2) Play a tone in the background while media is insecure. If the tone is too
loud then the audio is unrecognizable and it interferes and if the audio is
too low then not all users will be able to hear it (including those with
some hearing impairments). Tones interfere with signals such as FAX tones.
Besides, who is to say it's an audio media stream at all.

This is not a metaphor users are familiar. Typically tones indicate other
things, such as toll costs, but never an indication of a current security
level. I think this proposal was more about early media than early arriving
media but still the idea is still not good.

3) Visually indicate to the user that the call is not yet secure. I dislike
this one most of all. The user will engage "secure" mode and expect all
calls placed to be secure, especially if they have a mode which is "only
allow secure calls".

With modern USB devices and other such devices, the user doesn't even have
to look at a computer or LCD screen anymore. This method assumes the user is
actively paying attention to the subtlety of a user interface change. When a
user places a secure call, they expect the call to be secure, not partly
secure, or secure after a few seconds.

Further, this ruins the reputation of security. If the call is secure then
nobody should be able to interfere especially with bogus media. Allowing
media propagated from the likes of spammers, fraudsters, hackers and
hoaxsters is not acceptable. This is not a good impression of what security
should look like.


I propose that the bar be raised and that this limitation be rejected in
favour of something that ensures all early arriving media is at least the
recipient of the INVITE.

I understand that DTLS separates the keys negotiation from the SIP
signaling, and the desire to keep them separate. However, it might be a good
idea to introduce something that only allows the establishment of a DTLS
session from someone whom has actually seen the INVITE. Thus all DTLS
connections that get established are guaranteed to only come from clients
that were able to see the INVITE's SDP. 


Regards,

Robin Raymond
Chief Architect
CounterPath Solutions, Inc.