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

["David R. Oran" <oran@cisco.com>]

I'm not a crypto person, and I don't play one on TV. A message from this 
thread got forwarded to me, asking that I provide some background on one 
small item - whether short packets wrapped up in UDP/IP were common and 
important enough to be concerned about packet expansion of about 8 bytes.

The following is snipped from the relevant message (which I believe was 
posted by Steve Kent, although I don't have the whole context so I can't be 
sure):

> I also am surprised that you cite a 20-byte "packet" size for RTP as
> an example. The 20 byte size makes an 8-byte IV seem very large
> indeed. But the 20-byte size is misleading, at best. Do these packets
> have no IP header? How about a UDP header. How about an ESP header &
> authentication trailer? How about the need to pad the ESP payload to
> a 4 byte boundary, which in this case adds 4 bytes to the payload? By
> the time you add all of these parts of the overall packet to the
> original 20-byte payload, the 8-byte IV is not so big an overhead
> anymore. Either your arithmetic is very sloppy, or you are being
> disingenuous.
>
There are a large number of deployed VoIP systems using Codecs like g.729 
or G.723 and 20 ms. packetization period. This produces packets with a 
payload size of 10 bytes. When you add in the overhead of RTP, UDP, and IP 
this gives a total link TU of 60 bytes (20+8+12+10). Relative to 60 bytes, 
and 8 byte expansion is not all that large, but this is not the end of the 
story. People using high compression gain coders ALSO deploy CRTP, which 
does RTP+UDP+IP header compression, reducing the overhead to about 4 bytes 
(assuming PPP), and hence a 8 byte expansion is once again a significant 
amount of overhead.

In the context of the current discussion, a naive IPSEC ESP encapsulation 
would negate nearly all of the compression gain (only the outer IP header 
would get compressed), so people have envisaged things like TCRTP to do the 
inner (IP+UDP+RTP compression first). Even with such tricks, the overhead 
of ESP is large for such applications.

Which is one reason some of us went off and designed SRTP...

Please forgive me if all of this is well known and understood by the IPSEC 
community.

Dave.