[10302] in cryptography@c2.net mail archive
Re: [linux-elitists] Re: Looking back ten years: Another Cypherpunksfailure (fwd)
daemon@ATHENA.MIT.EDU (Derek Atkins)
Mon Jan 28 15:14:50 2002
To: "Enzo Michelangeli" <em@em.no-ip.com>
Cc: <cryptography@wasabisystems.com>,
"Eugene Leitl" <Eugene.Leitl@lrz.uni-muenchen.de>
From: Derek Atkins <derek@ihtfp.com>
Date: 28 Jan 2002 12:41:32 -0500
In-Reply-To: <002601c1a797$2d5db220$0200000a@noip.com>
Message-ID: <sjmvgdm5q5v.fsf@kikki.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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" <em@who.net> 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)
derek@ihtfp.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
