Re: [VIPR] Review of draft-jennings-vipr-overview-01

[Cullen Jennings <[e-mail]>]

Thee are excellent points. The first few were easy and fixed in next version but on to some of the harder issues you raised ...

On May 13, 2011, at 1:37 , Michael Procter wrote:

> 
> Section 8.2
>  The TLS-SRP uses the caller ID and called number as a "username"
> 
> This seems to open up an interesting information leak, since the
> username is sent in the clear.  Let's assume EvilCorp registers its
> node-id against the hash of the sales number of its competitor,
> VictimCorp.  Then, whenever a ViPR-enabled caller tries to call
> VictimCorp to buy something, a few hours later their ViPR server will
> attempt to establish a connection to EvilCorp.  Even assuming that
> EvilCorp can't complete the handshake because it has no idea of the call
> details, EvilCorp still ends up with a list of CLIs for people who
> called their competitor's sales line.  I'm not a salesperson, but I
> believe that supplying a list of 'hot leads' like this would make
> EvilCorp's sales team quite happy.

I think we need to protect against the attack you describe. It's been awhile since have looked at SRP. Perhaps hashing the username would solve this?  

> 
> 
> Section 9.2: 3rd attack
>  "the TTL for cached routes is set to match the
>   duration that carriers typically hold numbers."
> 
> I understand the reason for this, but I think it might lead to a poor
> user experience.  If someone becomes accustomed to having a videocall
> / wideband audio with a regular recipient, and then finds that one day
> it falls back to PSTN, I doubt that "ViPR cached route TTL expiry" will
> be the first thing that springs to mind.  If you have a moderate number
> of ViPR-connected regular destinations, and a cache time of 3-6 months,
> then you will find that this happens quite often, which will lead to a
> perception of unreliability for the technology.  Once a fallback call
> is made, it will take up to 12 hours (from my reading of the PVP draft)
> to refresh the SIP route, which essentially means it won't be 'fixed'
> on the same day.  It might help if there were a faster way to revalidate
> routes that have expired recently, or a way to qualify a route for
> continued use whilst still protecting against this attack.

total agree. I'd like to see a better way of doing validation for video calls. 

> 
> 
> Section 9.2: 5th attack
> 
> I think you may be understating the risk here.  An environment that uses
> phones supporting the dialog event package, for example, will allow
> mischievous colleagues to mount this attack.  Even someone sitting in the
> next cubical to the caller, wielding a stop watch, probably stands a good
> chance of mounting this attack.  Rather than recommending that ViPR is not
> deployed in enterprises with moderately clueful staff, is there
> something that can be done to tighten up the defences to this attack?
> 

again I agree. Of course the guy in the next cube could probably just walk over and forward the phone too. One things that can be done is not share the validation you learn for one phone in an enterprise with other phones in the enterprise. 


> Best regards,
> 
> Michael
> _______________________________________________
> VIPR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vipr


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html