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

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



I'm not so sure. SRTP and IPsec live in completely different domains,
and voice over IPsec is still necessary, where a tunnel is
necessary. SRTP does not tunnel. For example, you may already have an
IPsec tunnel between a branch office and the home office. Running SRTP
alongside that pre-existing tunnel does not work (because of the
different address space in which the tunnel and the srtp session would
exist.

Yes, you COULD tunnel srtp through an IP-in-IP tunnel or GRE
tunnel. But then you have to administer and configure two virtually
identical tunnels, which I'm sure most administrators won't want to
do. It would be preferable to tunnel voice over the same IPsec tunnel
with minimal hit on packet expansion. In my mind, the trade off is
operational complexity (i.e. 1 IPsec tunnel for regular data and one
ipip tunnel for voice and signalling) versus minimal packet expansion
(voice over the IPsec tunnel).

Once you factor in some internal header-compression schemes
(i.e. header-compress the packets going INTO the IPsec tunnel), voice
over IPsec still sounds reasonable, because it mitigates most of the
packet expansion caused by the ESP header.

The smaller we can make the rest of the packet expansion (IV's
authentication tags, etc), the better.

jan



On Tue, 30 Jul 2002, Housley, Russ wrote:

> 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
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847