Skip to Content.
Sympa Menu

wg-voip - Re: SecurityFocus: FBI seeks Internet telephony surveillance

List archive

Re: SecurityFocus: FBI seeks Internet telephony surveillance


Chronological Thread 
  • From: Tyler Miller Johnson <>
  • To: VoIP Working Group <>
  • Subject: Re: SecurityFocus: FBI seeks Internet telephony surveillance
  • Date: Mon, 31 Mar 2003 22:13:29 -0500

The standard for encryption for h.323 is h.235. We use Tandberg endpoints for video *because* they support this and this group is capturing the market because of HIPAA requirements. In my opinion, all media streams should be encrypted. Under h.235, one can encrypt both the media streams *and* the call signalling, so that it is not possible to (easily) decode what is said, nor whom it was said to. The latTer is also an important component of privacy. What if it were discovered that you regulary called the AIDS clinic / Iraqi embassy / gay bar. Could this have an impact on your life?

I would like to see Internet2 take a really strong stand on supporting (requiring/preferring?) encryption on all video/voice communications and trying to drive the market in that regard. I do not believe it is reasonable to implement a voice over IP system over Internet1/Internet2 without encryption today, given the simplicity with which media can be sniffed and decoded and the potential for loss of privacy resulting from that.



Andrew Rutherford wrote:
At 8:41 PM -0500 31/3/03,

wrote:

It sounds like both FEC and encryption are far too uncommon in the voip
world.


I've seen one physical SIP phone vendor (using a modified linphone for software) work around "encryption being too expensive for my cut-down hardware" as follows:

- Send some random data in the SIP Invite.
- Construct and MD5 hash of the random data and a shared password.
- Use a compressed codec and XOR the voice payload only with the MD5 hash.

Very little computation, and with a compressed codec it's a little bit harder to figure out what the key is. Not recommended for anything serious, though.

The real problem is a lack of agreement as to exactly how VoIP should be encrypted. The obvious answer is IPsec - which works well, but doubles the bandwidth required. Lots of little voice packets which already have their size doubled or more from IP, UDP, and RTP headers then having IPsec and another IP header thrown on the front can get an 8k codec up to around 50k, depending on the number of packets per second.

There are a number of suggestions relating to encrypting only the payload, and so not increasing the size of the packet much beyond what it is now, but the combination of real-time requirements and packet loss issues don't make this as trivial as it might appear at first.




---------------------------------------------------------------wg-voip-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/

---------------------------------------------------------------wg-voip--




Archive powered by MHonArc 2.6.16.

Top of Page