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

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "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. 
  
  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"); [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPVAsz4qHRg3pndX9AQF0pgQAngiWQXSlenGntvBaOmWzQROHUhpG4DrT
8uPsJ9rxT5qPmNR3iSoXosKWRDoh91UwPBiQlyRf1Wgc7K76/HYhcftTt1R1UDFa
O/blFqtqYOReFpmDkPQjyRpjHSPK0FXfJlze4owuEZWGwfhGNpAU1nFmhAEeK6Vi
FVC/GVBM618=
=ZlU2
-----END PGP SIGNATURE-----