At 9:50 PM -0800 3/1/06, Joe Touch wrote: >... > > The reasons that they chose to not use Ipsec are based on per-packet >> overhead, for the very small RTP packets. Nothing we do in BTNS is going >> to address that concern. > >Their per-packet processing overhead can't be all that different; they >use AES and HMAC-SHA1. The key difference is that SRTP allows "good >enough" key lengths that are less than full-sized, which helps keep the >bandwidth overhead down and packet expansion constrained, but which >forces the session keys to have a shorter lifetime. That logic is >equally valid for IPsec. It's communication overhead, not processing overhead, that motivates use of SRTP. the headers for SRTP are very small, even compared to transport mode ESP. > >... > >>> I *fully* agree with the fact that TCP/MD5 doesn't offer the same >>> protection as IPsec, but it does protect the transport layer. That >>> differentiates it from TLS. >> >> it offers some protection, but to say that it "protects" the layer might >> surprise folks who think confidentiality is important :-). > >The same is true for an IPsec SA based on MD5. The point wasn't privacy >vs. authentication; it's transport vs. non-transport. First, there are no SAs that are protected via MD5, per se, although we can have SAs that make use of HMAC-MD5. But, ESP (which is a more efficient way to offer integrity and authentication that AH), also offers confidentiality, if desired. Thus it can "protect" a connection to whatever extent a user wishes, depending on selection of appropriate options, unlike the limited forms of protection offered by the TCP-MD5 checksum option. Steve
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.