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

[Michael Procter <[e-mail]>]

General

Three occurrences of the header field 'X-Cisco-ViPR-Ticket'.
Hopefully this will be renamed at some stage?


Section 2.1 para 2:

"email-style SIP URI" replace with "email-style SIP URIs"


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.


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.


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?

Best regards,

Michael