Subject: [MMUSIC] draft-garcia-mmusic-sdp-cs-02: thoughts on correlation

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 12:04:25 -0600

The current version of garcia-mmusic-sdp-cs details two potential 
correlation mechanisms (caller-id and UUI), both of which are known to 
fail under some relatively common circumstances.

It REQ-5 is actually a MUST (instead of a SHOULD), I would guess that we 
need a reliable backup mechanism that we can use in case the other two 
fail -- perhaps exchanging a short series of DTMF digits over the CS 
connection for correlation purposes?

I would imagine you could have some signaling over the IP side of things 
that semantically means, "I just got an incoming CS connection, but 
can't tell whether it is you because both the correlation mechanisms 
failed. Please send the DTMF digit string "36254" on your outbound 
connection so I can tell whether this is you."

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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 14 Nov 2008 09:57:46 +0100

Hi Adam:

Thanks for your comment.

First, you are right in your analysis. None of the provided correlation 
mechanisms are able to guarantee 100% of success.

We thought about the DTMD digits, but it brings some other problems. 
First, you can only exchange DTMF digits once the circuit (bearer) is 
setup, as opposed to the two specified mechanisms that operate prior or 
during the setup of the bearer. The implication is that you are delaying 
the session establishment time. In addition, this mechanism would require 
some additional mechanism to "hide" those DTMF tones from the user, so, 
not playing them. Alternatively, one could use some sort of subaudible 
tones such as CTCSS. Honestly, I think this will increase the complexity 
of implementations. Furthermore, I don't think anyone will implement it.

So, I guess what we have in the spec is simple but not 100% secure. It's 
better than nothing.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Bob Gilman <[email-masked]>
Date: Sat, 15 Nov 2008 13:09:21 -0700

Miguel, Adam -
Why not make the use of DTMF digits (part of) the initial correlation
mechanism?  The digits can be included in SDP as part of the initial
exchange.  Some of the advantages would be:
1. If the receiver of the DTMF specifies the digits, they can be
    guaranteed unique (permitting shorter strings than a "random"
    choice.)
2. The receiver would know that digits are coming, so it could delay
    cut-through to its endpoint until the digits are received.  DTMF
    receivers typically filter digits anyway.
3. This avoids the complexity of a failure/fallback mechanism.
4. This allows the use of different types of PSTN and/or private
    facilities, independent of ISDN or caller-id.
5. If necessary (and at somewhat greater expense), the digit exchange
    could be made cryptographically secure to prevent some sort of
    call-injection attack.
Agreed, cut-through is delayed, but not by much (signalling rates are
between 3 and 9 digits per second) when it's not a secondary mechanism
that requires extra out-of-band signalling.

The consequences of a mix-up of calls might be merely annoying, but it
could be disastrous, so I think it's worth taking steps to make the
possibility as small as possible.

Does this make sense?
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

Miguel A. Garcia wrote:
> the session establishment time. In addition, this mechanism would 
> require some additional mechanism to "hide" those DTMF tones from the 
> user, so, not playing them. Alternatively, one could use some sort of 
> subaudible tones such as CTCSS. Honestly, I think this will increase the 
> complexity of implementations. Furthermore, I don't think anyone will 
> implement it.
> 
>> It REQ-5 is actually a MUST (instead of a SHOULD), I would guess that 
>> we need a reliable backup mechanism that we can use in case the other 
>> two fail -- perhaps exchanging a short series of DTMF digits over the 
>> CS connection for correlation purposes?
>>
>> I would imagine you could have some signaling over the IP side of 
>> things that semantically means, "I just got an incoming CS connection, 
>> but can't tell whether it is you because both the correlation 
>> mechanisms failed. Please send the DTMF digit string "36254" on your 
>> outbound connection so I can tell whether this is you."
>>
>> /a
>

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 17 Nov 2008 09:20:24 +0100

Hi Bob:

I guess this is exactly what Adam was proposing. At least, I haven't seen 
a difference with original Adam's proposal.

I still have the same concerns:

1) The session setup time is increased. Ok, it might be only a couple of 
seconds, but still it is.

2) Who is going to implement this mechanism?

3) If we add the cryptographic exchange, who is going to implement this 
mechanism?

4) If one of the endpoints is a decomposed entity where the signaling is 
decoupled from the media part, it adds far much complexity, because you 
need to upgrade the interface in between these two boxes. This might be 
the case of a third party call controller.

5) Yes, it solves the problem in all known scenarios, but at a very high 
cost compared to the other mechanisms.

My proposal is pragmatical: Let's live with what we have specified today. 
It is not perfect, but will work in high number of scenarios. The draft 
already documents the imperfections of the system. Let's make sure that 
we leave the door open for this mechanism to be standardize when we have 
a bit more of operational experience and we know whether we want that 
mechanism or not.

/Miguel

Bob Gilman wrote:
>> First, you are right in your analysis. None of the provided 
>> correlation mechanisms are able to guarantee 100% of success.
>>
>> setup, as opposed to the two specified mechanisms that operate prior 
>> or during the setup of the bearer. The implication is that you are 
>> delaying the session establishment time. In addition, this mechanism 
>> would require some additional mechanism to "hide" those DTMF tones 
>> from the user, so, not playing them. Alternatively, one could use some 
>> sort of subaudible tones such as CTCSS. Honestly, I think this will 
>> increase the complexity of implementations. Furthermore, I don't think 
>> anyone will implement it.
>>
>> So, I guess what we have in the spec is simple but not 100% secure. 
>> It's better than nothing.
>>
>> /Miguel
>>
>> Adam Roach wrote:
>>> correlation mechanisms (caller-id and UUI), both of which are known 
>>> to fail under some relatively common circumstances.
>>>
>>> things that semantically means, "I just got an incoming CS 
>>> connection, but can't tell whether it is you because both the 
>>> correlation mechanisms failed. Please send the DTMF digit string 
>>> "36254" on your outbound connection so I can tell whether this is you."
>>>
>>> /a
>>
> 
>

---

From: <[email-masked]>
Date: Tue, 18 Nov 2008 00:33:02 +0200

>-----Original Message-----
>From: ext Miguel A. Garcia [mailto:[email-masked]] 
>Sent: 17 November, 2008 10:20
>To: Bob Gilman
>Cc: Adam Roach; Veikkolainen Simo (Nokia-D/Helsinki); mmusic
>Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-cs-02: thoughts 
>on correlation
>
>Hi Bob:
>
>I guess this is exactly what Adam was proposing. At least, I 
>haven't seen a difference with original Adam's proposal.
>
>1) The session setup time is increased. Ok, it might be only a 
>couple of seconds, but still it is.
>
>3) If we add the cryptographic exchange, who is going to 
>implement this mechanism?
>
>4) If one of the endpoints is a decomposed entity where the 
>signaling is decoupled from the media part, it adds far much 
>complexity, because you need to upgrade the interface in 
>between these two boxes. This might be the case of a third 
>party call controller.
>
>5) Yes, it solves the problem in all known scenarios, but at a 
>very high cost compared to the other mechanisms.
>
>It is not perfect, but will work in high number of scenarios. 
>The draft already documents the imperfections of the system. 
>Let's make sure that we leave the door open for this mechanism 
>to be standardize when we have a bit more of operational 
>experience and we know whether we want that mechanism or not.
>
>/Miguel

Today in the MMUSIC session folks expressed interest in defining a
DTMF-based mechanism for correlation purposes. So, we will add this in
the next version of the document. The details, however, are still to be
ironed out.

-Simo

>>> from the user, so, not playing them. Alternatively, one could use 
>>> some sort of subaudible tones such as CTCSS. Honestly, I think this 
>>> will increase the complexity of implementations. 
>Furthermore, I don't 
>>> think anyone will implement it.
>>>
>>>> It REQ-5 is actually a MUST (instead of a SHOULD), I would guess 
>>>> that we need a reliable backup mechanism that we can use 
>in case the 
>>>> other two fail -- perhaps exchanging a short series of DTMF digits 
>>>> over the CS connection for correlation purposes?
>>>>

---

From: Bob Gilman <[email-masked]>
Date: Mon, 17 Nov 2008 16:21:10 -0700

Miguel-
My comments below.
-Bob

Miguel A. Garcia wrote:
> Hi Bob:
> 
> I guess this is exactly what Adam was proposing. At least, I haven't 
> seen a difference with original Adam's proposal.
[rrg]: As I read Adam's email, he was suggesting DTMF as a backup
        mechanism in case that CID and/or UUI didn't work.  It seemed
        better to me to use the scheme at the start so an additional
        signalling exchange (with it's associated delay) isn't needed.
> seconds, but still it is.
[rrg]: This seems like a small price to pay to get it right (I'd guess
        that typical systems would use only 3 or 4 digits.)  We still
        have the circuit-switched call propagation delay contribution
        in either case.
> 2) Who is going to implement this mechanism?
[rrg]: Anyone who can't count on the nature of the PSTN and who wants to
        make sure the right call gets associated with the right circuit.
> 3) If we add the cryptographic exchange, who is going to implement this 
[rrg]: Who knows?  I wasn't suggesting that we add the case; I was just
        pointing out that it's possible to generate the identifying
        digits cryptographically to reduce the probability that an
        intruder can capture the destination circuit.  I'd certainly
        suggest that be deferred until someone has a good suggestion
        for doing it.
> the case of a third party call controller.
[rrg]: It doesn't seem like such an upgrade (adding a string of digits
        for identification) would cost much.  The ability to use non-
        digital facilities would widen the applicability, I'd think.
        I'd think it would be easy enough to add later via an attribute
        and related procedures, if someone wants to implement it later
        rather than sooner.
> cost compared to the other mechanisms.
[rrg]: What's the cost of crossed calls?
> 
> My proposal is pragmatical: Let's live with what we have specified 
> today. It is not perfect, but will work in high number of scenarios. The 
> draft already documents the imperfections of the system. Let's make sure 
> that we leave the door open for this mechanism to be standardize when we 
> have a bit more of operational experience and we know whether we want 
> that mechanism or not.
[rrg]: Given that extensions or alternative association mechanisms are
        permitted, that should be OK.
>>> will increase the complexity of implementations. Furthermore, I don't 
>>>> that we need a reliable backup mechanism that we can use in case the