Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
Enzo Michelangeli [EMAIL PROTECTED] writes: Anyway, IPSEC (plus Kerberos/PKINIT) is the security mechanism chosen by the PacketCable initiative: http://www.packetcable.com/ http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf Actually, this was chosen only to protect signalling, not the actual VoIP data. If you read the spec carefully you will notice that the RTP stream is NOT using IPsec for data protection. Enzo -derek -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
From: Derek Atkins [EMAIL PROTECTED] Actually, this was chosen only to protect signalling, not the actual VoIP data. If you read the spec carefully you will notice that the RTP stream is NOT using IPsec for data protection. Yup, right. Thanks also to Joseph Tardo, who pointed out that the section 7.6.2.1 of PKT-SP-SEC-I05-020116 specifies standard RTP payload encryption. Enzo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. In certain cases (such as cablemodem networks) this implies that using IPsec effectively halves the number of active VoIP sessions that a carrier can handle. Enzo Michelangeli [EMAIL PROTECTED] writes: If everything is tunnelled inside SSH, its ultimate transport is TCP, which is bad for data types like voice where reliability is less important than low delay. The right thing to do is to build decent security into the RTP layer (the standard transport for voice applications, RFC1889): the SRTP draft (http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-02.txt) goes in this direction. Authentication and key exchange are supposed to be handled in the session initiation phase (e.g., through SIP or H.323). Alternatively, one could rely on IPSEC, but its support on the target machine cannot (yet?) be taken for granted; the RTP stack, on the opposite, is usually built into the application rather than the kernel. Enzo -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
Matt Crawford [EMAIL PROTECTED] writes: There are other problems with using IPsec for VoIP.. In many cases you are sending a large number of rather small packets of data. In this case, the extra overhead of ESP can potentially double the size of your data. HOW small? You'd already be adding IP+UDP+RTP headers (20 [or 40] + 8 + 12 = 40 [or 60] bytes). Using ESP with authentication would add another 22, plus possible explicit IV and padding, if needed -- call it 30? 20ms of uncompressed telephone quality data is 160 bytes ... 8-bit u-law (standard telephone quality) is 56kb/sec. 20ms at that rate is 140 bits (I guess you assumed 64kb/sec to get 160 bits?). However, many audio codecs in common use (e.g. G7.11) output a bit-rate much smaller than 8-bit u-law, to the point were we're really talking about 20-30 bytes of data for that same 20ms of audio. Yes, we're talking 8-12kb/sec codecs. This means that in order to send 20 bytes of data you're already adding 60 bytes (or a factor-of-three increase), not to mention the extra 22 (or more) for ESP. The other thing to keep in mind is that IP+UDP+RTP can be compressed using standard header-compression techniques, which pretty much eliminates most of that extra overhead. So, maybe your factor-of-three increase that we're seeing above is now reduced to a factor-of-one increase. The problem is that if you use ESP then your UDP and RTP headers are now encrypted within the ESP, thereby destroying your chance for any kind of header compression. -derek -- Derek Atkins, Computer and Internet Security Consultant IHTFP Consulting (www.ihtfp.com) [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
anybody used that combo? -- Forwarded message -- Date: Sun, 27 Jan 2002 12:45:21 -0800 From: Don Marti [EMAIL PROTECTED] To: Linux Elitists List [EMAIL PROTECTED] Subject: Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunks failure (fwd) begin Eugene Leitl quotation of Sun, Jan 27, 2002 at 09:22:57PM +0100: Why is there no secure telephony package coming with debian? How about gnome-o-phone over rtptunnel over ssh? I know gphone is packaged; don't know if rtptunnel is. If that's acceptably fast it reduces the key management problem to the previously solved (kind of) problem of ssh key management. If you want someone to be able to call you, just add his or her key to a special authorized_keys for a dial-in account. http://gphone.sourceforge.net/ -- Don Marti http://zgp.org/~dmarti Join the Distributed Unisys Google Experiment. [EMAIL PROTECTED] a href=http://burnallgifs.org/;Unisys/a KG6INA everywhere. ___ linux-elitists http://zgp.org/mailman/listinfo/linux-elitists - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
