RE: [AVT] The Secure Real-time Transport Protocol : Padding/Bandw idth.

[Euchner Martin <[e-mail]>]

Dear all,

I'm very confused by this entire SRTP padding discussion.

My understanding of SRTP is that the document describes a stream-cipher using AES in counter and/or F8 mode. As such, SRTP in this byte-stream mode does not need any padding of the payload, as stream-ciphers do not pad typically. (Note: One can use SRTP with AES with the 40 byte G.711/G.729 payload without any message expansion).

Since the SRTP draft ID provides the possibility of using other crypto mechanisms as an extension, padding might be an issue. Since we have not seen any such extension so far, we can't tell, if padding would be an issue nor how padding should be done for any potential future SRTP encryption mechanism.

My recommendation thus, is that SRTP padding issue be deferred to the future and be solved when there is a need for it. For now it should be sufficient to state, that padding issues should be addressed by the extension documents.



With kind regards


Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: [phone]
| Siemens AG.....................Fax  : [phone]
| ICN M SR 3                     mailto:[e-mail]
|                                mailto:[e-mail]
| Hofmannstr. 51                 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	[e-mail] [mailto:[e-mail]] 
Sent:	Tuesday, June 24, 2003 6:08 PM
To:	[e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject:	[AVT] The Secure Real-time Transport Protocol : Padding/Bandwidth.


Madam and Sirs,

I am responsible for Cipher/VoIP implementation at Mindspeed (ex Conexant).

I would like to draw your attention about padding:
draft-ietf-avt-srtp-05.txt - 4.1.1 :
<<Each of the three terms in the XOR-sum above is padded with as many
leading zeros as needed to make the operation well-defined..>>

By implementing block cipher (as AES), as you experts know already,
we have been facing the padding method consequence (RFC1423, NIST,..)
leading to increase bandwidth.

Example:
G.711 at 5ms generates a payload of 40 bytes.
AES blocks are made of 128 bits = 16 bytes.
40 / 16 = 2.5: AES will require 3 blocks increasing the encrypted payload
up to 16 x 3 =48 bytes.
Hence, AES encryption has impacted the original bandwidth consumption by
+20%.
This drawback applies to others codec G.729,...which have been designed to
save bandwidth.
This bandwidth increase is not acceptable for many Gtw manufacturers.

Mindspeed would like to submit to you a new scheme that allows encrypting
packets which size is not a multiple of AES block size without impacting
bandwidth
complying with existing modes ECB, CBC,...

Please, let me know if this new scheme could contribute to SRTP,
so I will send you related documents.

Dr Norbert Rossello.
Group Leader MindSpeed Cipher Development
[e-mail]

Mindspeed Technologies
BP 161
06903 Sophia Antipolis Cedex - France
www.mindspeed.com




_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt