Subject: Re: [VIPR] Agenda for 2011/09/23

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 03 Oct 2011 09:26:29 -0700

Hi Muthu,

On 09/28/2011 11:10 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:
> A fundamental question: Why would a provider want to advertise routes for a
> number for which neither of the enterprises is willing to pay for?

I am not sure why you are saying that.  When an enterprise uses a provider, it
is paying for the service of routing the calls to the PSTN, so why advertizing
the number in the VIPR overlay could not be part of this cost?

> Isn't ViPR based on the fact the provider is trusted for the first (PSTN)
> call? If the provider is fooling with the enterprise, won't the enterprise
> switch to a different provider? Or are we concerned about the security
> implications around routing subsequent calls through the provider? Aren't
> they applicable to the first call as well?
>
> If the enterprise doesn't trust the provider then ViPR in its current form
> doesn't seem to make sense.
>
> Muthu

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 7 Oct 2011 17:19:42 +0530

Hi Mark,

|When an enterprise uses a provider, it is paying for 
|the service of routing the calls to the PSTN, so why
|advertizing the number in the VIPR overlay could not 
|be part of this cost?

Sure, if it adds value to the enterprise and the provider can monetize it, I see no issue (it could be a provider hosted ViPR service, for e.g). At the first level, the enterprise might want to require that the provider published route be easily distinguishable from the enterprise published route, so that if both routes are available for someone calling into the enterprise they can chose one among them. I think in the majority of cases one would prefer a direct route, unless the provider offers differentiated services like audio/video transcoding, rate adaption, echo cancellation etc that a direct route doesn't have.

Muthu

|-----Original Message-----
|From: Marc Petit-Huguenin [mailto:[email-masked]]
|Sent: Monday, October 03, 2011 9:56 PM
|To: Muthu Arul Mozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: Agenda for 2011/09/23
|
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|Hi Muthu,
|
|On 09/28/2011 11:10 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:
|> A fundamental question: Why would a provider want to advertise routes for a
|> number for which neither of the enterprises is willing to pay for?
|
|I am not sure why you are saying that.  When an enterprise uses a provider, it
|is paying for the service of routing the calls to the PSTN, so why advertizing
|the number in the VIPR overlay could not be part of this cost?
|
|> Isn't ViPR based on the fact the provider is trusted for the first (PSTN)
|> call? If the provider is fooling with the enterprise, won't the enterprise
|> switch to a different provider? Or are we concerned about the security
|> implications around routing subsequent calls through the provider? Aren't
|> they applicable to the first call as well?
|>
|> If the enterprise doesn't trust the provider then ViPR in its current form
|> doesn't seem to make sense.
|>
|> Muthu
|
|- --
|Marc Petit-Huguenin
|Personal email: [email-masked]
|Professional email: [email-masked]
|Blog: http://blog.marc.petit-huguenin.org
|-----BEGIN PGP SIGNATURE-----
|Version: GnuPG v1.4.11 (GNU/Linux)
|
|iEYEARECAAYFAk6J4jQACgkQ9RoMZyVa61cL+QCfTYblcS5CYAfWyJtEgwEUpdQX
|pfoAniHnwohEklPZMndKsOcA6wo+3IXr
|=AS6j
|-----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 07 Oct 2011 06:51:10 -0700

On 10/07/2011 04:49 AM, Muthu Arul Mozhi Perumal (mperumal) wrote:
> Hi Mark,
> 
> |When an enterprise uses a provider, it is paying for |the service of routing
> the calls to the PSTN, so why |advertizing the number in the VIPR overlay
> could not |be part of this cost?
> 
> Sure, if it adds value to the enterprise and the provider can monetize it, I
> see no issue (it could be a provider hosted ViPR service, for e.g). At the
> first level, the enterprise might want to require that the provider published
> route be easily distinguishable from the enterprise published route, so that
> if both routes are available for someone calling into the enterprise they can
> chose one among them. I think in the majority of cases one would prefer a
> direct route, unless the provider offers differentiated services like
> audio/video transcoding, rate adaption, echo cancellation etc that a direct
> route doesn't have.

Yes, but the difficulty here is how to choose this route.  The proposal sent by
Hakim, i.e. sending the capabilities of the endpoint together with the SIP route
and ticket, would permit this, as only the VIPR domain the closest to the end
user would be able to send the real capabilities of the endpoint (extracted for
example from the SIP registrar).  The transcoding is interesting, as an
intermediary using it could eventually claim to better route than the direct
route.  Perhaps what we need is a new media feature tag that would indicate that
a capability set is "native" (i.e. built directly from the SIP registrar or
information coming from the endpoint), instead of been from a intermediate media
point, like transcoding.

> 
> Muthu
> 
> |-----Original Message----- |From: Marc Petit-Huguenin
> [mailto:[email-masked]] |Sent: Monday, October 03, 2011 9:56 PM |To: Muthu
> Arul Mozhi Perumal (mperumal) |Cc: [email-masked] |Subject: Re: Agenda for
> 2011/09/23 | |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA1 | |Hi Muthu, | 
> |On 09/28/2011 11:10 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: |> A
> fundamental question: Why would a provider want to advertise routes for a |>
> number for which neither of the enterprises is willing to pay for? | |I am
> not sure why you are saying that.  When an enterprise uses a provider, it |is
> paying for the service of routing the calls to the PSTN, so why advertizing 
> |the number in the VIPR overlay could not be part of this cost? | |> Isn't
> ViPR based on the fact the provider is trusted for the first (PSTN) |> call?
> If the provider is fooling with the enterprise, won't the enterprise |>
> switch to a different provider? Or are we concerned about the security |>
> implications around routing subsequent calls through the provider? Aren't |>
> they applicable to the first call as well? |> |> If the enterprise doesn't
> trust the provider then ViPR in its current form |> doesn't seem to make
> sense. |> |> Muthu |

- -- 
Marc Petit-Huguenin

---

From: Dean Willis <[email-masked]>
Date: Fri, 07 Oct 2011 11:23:07 -0500

On 10/7/11 8:51 AM, Marc P
> information coming from the endpoint), instead of been from a intermediate media

If we create a situation where there is an incentive for an intermediary 
to mis-state a capability set in order to "capture" more 
revenue-generating traffic, then the intermediaries are going to lie 
like politicians seeking re-election.

I think this is a MUCH harder problem than we currently realize.

Even Hakim's proposal requires that route-validation also validate the 
offered capabilities, not just evaluate them and choose the richest set. 
This is hard; a motivated intermediary could probably convince a 
test-bot that it is the target instead of an intermediary.

--
Dean

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 11 Oct 2011 12:07:18 -0700

On 10/07/2011 09:23 AM, Dean Willis wrote:
> If we create a situation where there is an incentive for an intermediary to
> mis-state a capability set in order to "capture" more revenue-generating
> traffic, then the intermediaries are going to lie like politicians seeking
> re-election.
> 
> Even Hakim's proposal requires that route-validation also validate the offered
> capabilities, not just evaluate them and choose the richest set. This is hard; a
> motivated intermediary could probably convince a test-bot that it is the target
> instead of an intermediary.

Perhaps one way to solve this would be to lower the priority of a route if a
subsequent SIP call made using it does not match the capabilities advertized.
It could also be done with an OPTIONS, but the response can also be faked.  It's
a little bit more difficult to fake the actual video (I suppose that wideband
audio can be faked by resampling the narrowband signal).

- -- 
Marc Petit-Huguenin

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Oct 2011 12:40:27 -0500

> audio can be faked by resampling the narrowband signal).

My local broadcaster sends a lot of fake HDTV by just upsampling the SD 
signal.

The problem is that a transit provider might get "greedy" and advertise 
capabilities they can't deliver in order to get more traffic. But the 
ability of a route to support a capability says nothing about what 
capability the called party might allow on a given call, so a caller 
can't just deprioritize a route when a completed call receives less 
capability than the route advertised. Nor can the called party withdraw 
validation support for a route just because it receives low-capability 
calls over that route, because the callers themselves might have low 
capabilities (or desires).

Essentially, we're trying to detect a MITM "capability bid-down" attack. 
This might be a generic SIP problem, not just a ViPR problem, although 
we could perhaps use ViPR to help cure it.

If we had a way for the caller to securely express the capabilities that 
the route is offering, then the callee could compare those capabilities 
to what it thinks the route should be offering, and thereby filter out 
"bad" routes.

However, every attempt I make to solve this falls into "but the greedy 
intermediary could fake it" because they have access to the only actual 
authentication data in the system. It's a catch-22; by giving a transit 
provider access to your call verification data, you give them the keys 
to the city.

The only answer I have so far is that one could audit the routes 
pointing at oneself and get upset about bogus/misleading entries.

--
Dean