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

[Black_David@xxxxxxx]

A few comments on this from a co-chair of the IP Storage (ips) WG,
which is *very* interested in AES Counter Mode - it will be a
"SHOULD implement" requirement for the IP Storage protocols.

- The primary motivation for IP Storage's interest in AES Counter
mode is the perceived "need for speed".  3DES CBC is the "MUST
implement" algorithm/mode, and we wanted the second choice of algorithm
to scale to significantly higher speeds.  Yes, there's a problem with
getting a faster authentication transform, but that leaves one problem
to solve as opposed to two, which sounds like progress - also see
Howard Herbert's related email on this topic.

- Packet expansion is not an issue for IP Storage because typical
data transfer sizes are kilobytes and up.  8 bytes overhead on even
a 1kB MTU is in the noise.  IP Storage doesn't share voice over RTP's
need to squeeze out every last possible byte of overhead.

- IP Storage bans manual/static keying (MUST NOT use); pre-shared
keying is ok.  With IP Storage's potential/likelihood of
transferring large amounts of data, an automatic rekeying mechanism
is necessary (MUST implement) independent of whether AES Counter Mode
is used or not.

- Words fail me in reacting to Paul Hoffman's naming non-issue,
but I like Michael Richardson's suggestion of renaming the AES
mode to "Ted" and "Barbara" for marketing purposes :-).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@xxxxxxx       Mobile: +1 (978) 394-7754
---------------------------------------------------