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

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 6 Aug 2002, Michael Richardson wrote:

>
>
> >>>>> "Jan" == Jan Vilhuber <vilhuber@cisco.com> writes:
>     Jan> I'm not so sure. SRTP and IPsec live in completely different domains,
>     Jan> and voice over IPsec is still necessary, where a tunnel is
>     Jan> necessary. SRTP does not tunnel. For example, you may already have an
>
>   We are regularly doing 6 party VoIP (h.323, alas) conference calls over
> IPsec. There is an H.323 bridge (openmcu) on a box that does both the VoIP
> and IPsec. There is 3Mb/s in, 800kb/s out at the concentrator, and a range of
> 1M modem, T1, cable and ADSL at the other ends. Starting a download at the
> same time, can hurt.
>
>   It isn't perfect, but most of this is due to the fact that we are not yet
> able to negotiate proper SLAs for the data with our ISPs.
>
>   We have not yet enabled any IPcomp, mostly because of laziness, and also
> because we are doing this over Opportunistic Encryption, which does not
> negotiate IPcomp by default.
>

>From what I've seen, IPcomp wouldn't help voip much. Most codecs are
already compressed. On an internal alpha-test network we run (to our
cisco telecommuters ;) we (the administrators for said alpha network)
tried IPcomp once and it seemed to make voice quality worse. I suppose
that's anecdotal evidence, not hard evidence, but there it is.

jan



>   So, I want to agree strongly with Jan:
>
>   Many voice applications will occur over IPsec. Particularly ones where
> there is already IPsec infrastructure (tunnels). Branch office/HQ connections
> are logical situations where this makes a lot of sense - buy more bandwidth
> for the Internet connection, save on LD calls.
>
>   But, this is too rich for many application spaces.  Anything without
> wires. SRTP will continue to exist there. Desk VoIP boxes will likely have to
> support SRTP as well IPsec.
>
>   What does this mean for AES-CTR mode to me:
>
>   Anyone who *needs* AES-CTR mode, likely needs it because they have >1Gb/s
> links they want to secure. As such, I think that they have the bandwidth not
> to care.
>
>   If AES-CTR mode is *the* AES mode that we suggest, then there may be some
> place for some other system that is more compact. That system likely doesn't
> even want to pay for the 8 byte IV that current 3DES-CBC has.
>
>   The previous email went on to give numbers for how many channels one gets
> on a T1 with various encodings. This is relevant to telcos that are trying to
> replace TDM with packets. While they may have big pipes to fill, it isn't
> clear to me that they will be terminating all of these packets on the same
> piece of equipment - an OC-12-rate full of packets that terminate eventually on
> customer connected T1-rate equipment may not require AES-CTR mode.
>
> ]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
>

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

http://www.eff.org/cafe