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

[Dean Willis <[e-mail]>]

On 10/11/11 2:07 PM, Marc Petit-Huguenin wrote:

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

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