[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt



Based on this message thread, I conclude that ESP (regardless of the 
encryption algorithm, mode, or IV size) is considered too heavyweight for 
VoIP.  As a result, they have invented a security protocol that meets their 
unique header compression requirements.  If this is the case, then we seem 
to have reached consensus for the people that actually plan on using 
AES-CTR with ESP.  Right?

Russ


At 11:28 AM 7/30/2002 -0400, Dilkie, Lee wrote:
> > Which is one reason some of us went off and designed SRTP...
>
>Thank goodness someone said it. I've been biting my tongue since this 
>thread started. Yes, the 8 bytes of IV *are* significient. SRTPs solution 
>to use existing information in the packet to generate an implicit IV (and 
>you avoid IV reuse too) and avoid *any* packet expansion is key to not 
>wasting bandwidth and is absolutely necessary if you want to 
>encourage(push) encryption of media streams (VoIP especially).
>
>Is it important that IPsec use implicit IVs? It would help but IPsec has 
>other overheads that expands the packet already and you could well argue 
>that it wouldn't make much of a difference (and therby justify SRTPs 
>original reason for existance... that IPsec is just too big to use for VoIP).
>
>Do some math.
>
>One T1 (24 voice channels if configured for PSTN, 32 for european T1), 
>1536000 bps (more for our european friends). I'm ignoring media transport 
>overhead, these numbers are better than they would be in real life.
>
>(assuming 20ms (50 fps) RTP packets, no header compression)
>
>G.729, 60 byte TU , 64 voice "channels"
>G.729, 68 byte TU (explicit IV), 56 voice "channels" (dunno 'bout you, but 
>that 13 percent overhead seems significient to me)
>
>G.711(uncompressed), 210 byte TU, 18 "channels" (unhappy customer, gets 
>less than PSTN T1)
>
>Things get better with header compression.
>
>Now try the same math with IPsec encrypted packets...
>
>
>-lee