[VOIPSEC] The Voice over Cable approach

Geoff Devine gdevine at cedarpointcom.com
Mon Feb 14 17:45:06 CST 2005


I thought I'd share with the group how the Cable operators have
attempted to solve this problem.  The signaling protocol happens to be
an MGCP variant called NCS though their solution would work equally well
with SIP.  The media stream uses RTP and the endpoints exchange
performance statistics via RTCP.  The endpoints are embedded within a
cable modem so NAT traversal issues did not need to be addressed.
 
Signaling key management:
Kerberos with PKINIT (public key initial authentication) extension is
used for key management.  Each device has a manufacturers certificate
assigned by VeriSign.  The endpoints 'log in' to a Kerberos Key Server
to get the information required to set up a security association with a
soft switch.  The key servers can be scaled horizontally to withstand
the authentication storms that happen after a major network outage.
 
Signaling encryption and authentication:
The actual signaling stream uses IPSec ESP in transport mode (as opposed
to tunnel mode).  Encryption is 128-bit 3DES.  Authentication is either
MD-5 or SHA-1.
 
Media stream key management:
Each endpoint picks a key for their transmit side.  The key is exchanged
as part of the SDP in the signaling stream.
 
Media stream encryption and authentication:
The media stream is encrypted with 128-bit AES. The media stream is
authenticated with 2-byte or 4-byte MMH.  There are some strange twists
to this since the initialization vector is calculated from the RTP
header and then modified based on the number of times the RTP timestamp
has wrapped.
 
This is all documented in the PacketCable security spec:
 
http://www.packetcable.com/downloads/specs/PKT-SP-SEC-I11-040730.pdf

Some comments on other threads here:
When you are doing a high capacity VoIP trunking application, I'm not a
big fan of using TCP to deliver SIP.  In a networks with packet loss,
you run the risk of seeing TCP flow control kick in.  The Signaling
System #7 over IP people invented a new transport called SCTP to avoid
this problem.  SCTP supports multiple threads so a dropped packet on one
thread doesn't impact traffic on other threads.  Since nobody is ever
going to put this kind of transport in every SIP endpoint, I think it's
better to use UDP and some security mechanism other than TLS.

Every time I look at NAT traversal issues, I always ask which VPN
technology is most likely to work in my hotel room.  The answer today is
still *shudder* Microsoft VPN though more and more mass market edge
routers are able to deal with IPSec.
 
 
Best regards,
 
Geoff Devine
Chief Architect
Cedar Point Communications





More information about the Voipsec mailing list