Network Working Group                                Rolf Blom, Ericsson
INTERNET-DRAFT                              Elisabetta Carrara, Ericsson
Expires: April 2001                               Mats Naslund, Ericsson
                                                       November 15, 2000

           Conversational Multimedia Security in 3G Networks

Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   As emerging real-time services on the Internet, such as Voice over IP
   (VoIP), increase their visibility, a security framework has to be
   provided. In particular, confidentiality is a main concern in the
   multimedia scenario.

   To support full flexibility of the services, a solution with IP all
   the way (to the terminal) is believed to offer advantages, if
   technically and economically feasible. Therefore, new requirements
   have to be met on cellular access networks, and this has an impact on
   the security solutions.

Blom, Carrara, Naslund                                          [Page 1]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   This document investigates requirements that a security scheme for
   such applications should fulfill when used in a cellular environment.
   The focus is mainly on the confidentiality of the media session, in
   particular within the conversational multimedia scenario, which
   proves to be the most demanding one.

   The highlighted keypoints are the necessity of a trade-off between
   security and cost to end up with an attractive service, and the
   support of profiles.


   1. Introduction..................................................2
   1.1. The right security for each type of traffic.................4
   2. Requirements for the encryption scheme........................4
   2.1. Encryption and bit error rate...............................4
   2.2. Encryption and efficiency...................................5
   2.3. Encryption and heterogeneous environments...................5
   2.4. Selective (payload) encryption..............................5
   2.5. Security and bandwidth......................................6
   2.5.1. Encryption and header compression.........................6
   2.6. Encryption and unequal error protection.....................6
   3. A suitable encryption scheme..................................7
   3.1. IPsec applicability.........................................7
   3.2. Conversational multimedia...................................8
   4. Encryption methods overview...................................9
   4.1. Stream ciphers..............................................9
   4.2. Block ciphers...............................................9
   4.3. Block ciphers used as stream ciphers.......................10
   4.4. Applicability of the encryption scheme to conversational
        multimedia ................................................11
   5. Integrity protection.........................................12
   6. Video and streaming..........................................12
   7. Security considerations......................................13
   8. Conclusions..................................................13
   9. Acknowledgments..............................................14
   10. Authors addresses...........................................14
   11. References..................................................14

1. Introduction

   Emerging real-time services in the Internet, such as VoIP [WMGL],
   pose new requirements on cellular access networks, as described in
   [WL00]. The main concern is to take into consideration the
   characteristics of the radio link to end up with a service, which

Blom, Carrara, Naslund                                          [Page 2]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   could be as attractive as today's circuit switched service in terms
   of cost and speech quality.

   Moreover, there is a strong need to add a security framework to
   multimedia scenarios. In particular, increasing interest in the end-
   to-end (e2e) confidentiality of the session flow has been showed by
   several parties. While IPsec [KA98] is generally envisaged as
   becoming a widely used security solution, there are indeed cases
   where its usage as e2e functionality has implications, as lately
   pointed out in the document.

   An aspect that should be taken into consideration mainly in the
   emerging real-time service scenario is the attractiveness of the
   service [WMGL]. A high security level will of course in many cases be
   a very strong argument (perhaps the strongest one) in favor of a
   certain solution. However, the cost of the cellular spectrum is a
   strong argument against some features, which are inherent to full
   security (e.g., added fields, and high reliability of the
   transmission). Therefore, we foresee the security/cost trade-off as a
   keypoint of the service. Profiles have to be offered to fulfill the
   user's expectation in the experience of the service, and any kind of
   compromise that shall be needed in term of security has to be
   explained in terms of cost for the user and/or for the operator.

   The above is clearly motivated by the fact that, as the wired
   Internet and the wireless world merge (heterogeneous environment),
   new requirements have to be met, which also have an impact on the
   design of a security solution.

   There are in general several ways to provide support for real-time
   services in cellular access networks. One straightforward way may be
   to use proxies and gateways; but such solutions pose problems for e2e
   security, because they often require that some entities on the
   transmission path between the endpoints have the ability to inspect
   and possibly manipulate the packets. The preferred solution is
   instead to transfer the IP packet e2e ('IP-all-the-way approach',
   [WL00] and [ROHC], sometimes also called 'All-IP scenario'), and also
   to support e2e security. Moreover, bypassing the air link and
   entering with encryption at the wired edge (where constraints are not
   demanding) opens trust model issues, as it requires network-assisted
   security. Instead, an e2e solution is the desired possibility, if
   feasible. This necessitates a compromise between e2e security and
   spectrum cost, as motivated in the following discussion.

   This document does not propose a general security solution for RTP
   [RTP] traffic (RTP being the most likely transport protocol for the
   applications in question). The document instead investigates some
   requirements that a security scheme for RTP should fulfill, in
   particular when used as the transport protocol for conversational

Blom, Carrara, Naslund                                          [Page 3]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   multimedia applications over a heterogeneous environment, such as the
   one described in [WL00].

   Among the different security services, we investigate in particular
   the confidentiality of the session flow, which has to be guaranteed
   by use of encryption. In case of speech, confidentiality is seen as
   the major objective, even if authentication/integrity protection may
   be requested in other situations. Therefore, we concentrate mainly on
   confidentiality of conversational multimedia sessions over RTP in the
   rest of this paper.

1.1. The right security for each type of traffic

   Security can be entered at many layers of the stack, providing
   different protection levels. Going towards an All-IP scenario, IPsec
   turns out to be a natural choice, ranging from a very general
   framework to a fine-granular security. However, for certain types of
   traffic the employment of IPsec does not appear to be the most
   suitable one. This statement is motivated by the requirement of
   offering an attractive service with a reasonable level of security,
   and is further discussed in Section 3.

   We describe in the following the requirements of the RTP session in a
   conversational multimedia scenario, which proves to be one of the
   most demanding types of traffic. The description highlights the
   reasons why application security seems to be the feasible choice.
   Some other real-time (video) and streaming types of traffic show more
   relaxed requirements (see Section 6).

2. Requirements for the encryption scheme

   As underlined in [WL00], there is the need of an appropriate design
   of the link layer protocol based on radio requirements, and of some
   link layer enhancements to support real-time traffic. This poses
   specific requirements on the encryption scheme to be used, which we
   briefly outline in the following, in relation to conversational audio

2.1. Encryption and Bit Error Rate

   A first aspect is the interaction between the bit error rate (BER)
   and the chosen encryption algorithm. Some modes of encryption result
   in error propagation, that is, a single bit error in the transmitted
   ciphertext causes multiple bit errors in the deciphered message (in
   block ciphers, at least one entire block, e.g. 64 bits, is turned
   into "random noise"). This error propagation is a very undesired
   feature that should be minimized/eliminated in a VoIP scenario, not
   to degrade quality. Therefore, the encryption algorithm is requested

Blom, Carrara, Naslund                                          [Page 4]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   to be error-robust. [FC] provides a good overview about the relation
   between encryption and BER.

   - The encryption algorithm must be error-robust (error propagation
   should be avoided).

2.2. Encryption and Efficiency

   Efficiency plays an important role in real-time services. The overall
   delay budget has to be reduced to achieve acceptable performance in
   terms of service quality and spectrum efficiency, therefore a
   particular concern is the processing time required by the
   encryption/decryption engine that contributes to the overall delay.

   Another aspect affecting the efficiency requirements is that the
   security solution has also to take into account that the encryption
   endpoints may be small, lightweight mobile (wireless) terminals often
   with limited computational resources.

   - The encryption algorithm must be fast, and has to be implemented in
   thin clients.

2.3. Encryption and Heterogeneous Environments

   In an e2e solution for a heterogeneous environment, different types
   of networks pose different constraints to be taken into account in
   the overall solution. As an example, the unreliable nature of IP per-
   se means packet-loss and non-ordered delivery, while the air-link
   shows other characteristics (discussed throughout the paper). These
   are features of the media, which the encryption scheme has to deal

   - The encryption scheme needs to show a "fast-forward/rewind"

2.4. Selective (Payload) Encryption

   Furthermore, [WL00] stresses the need for protocol enhancements to
   solve the issues posed on the radio network by real-time traffic.

   The flows should be identified and demultiplexed over appropriate
   radio channels for efficient transmission. There may be different
   ways to implement this kind of identification, one being e.g.
   snooping on the traffic in the attempt of classifying it. This
   implies in general the necessity of accessing some parts of the
   packet (i.e., the IP/UDP/RTP headers may be enough for a good guess)
   by intermediate nodes. This scenario breaks the e2e confidentiality,
   unless a compromise is accepted, and specific parts of the packet are
   left accessible. If e2e confidentiality is the objective, it is
   likely that e2e encryption can cover only a part of the IP datagram,
   in case optimization/manipulation need access to some parts of the

Blom, Carrara, Naslund                                          [Page 5]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   datagram. The disclosure of more fields in the packet may open higher
   chance of attacks, but should be justified by the need of said trade-

   In the previous scenario (an intermediate node requires access to the
   packet, e.g., transcoder or any kind of payload-manipulating proxy),
   it is up to the trust model to define the way security has to be
   handled between entities. As said, we do not investigate the proxy

   - The encryption scheme should be possible to apply selectively to
   different portions of the payload.

2.5. Security and Bandwidth

   The cost of cellular access links poses the need of careful bandwidth

   In general, the number of bytes added by encryption should be
   minimized: a right compromise between encryption and bandwidth usage
   has to be reached. Schemes limiting message-size expansion and added
   fields (e.g., dedicated headers and padding) should be preferred.
   Authentication and/or integrity protection, if used, add several
   bytes; therefore, an analysis of their impact should be performed.

   - Message-size expansion and added fields should be limited

2.5.1. Encryption and Header Compression

   Optimization of the protocol headers is needed for real-time
   transmission [VOIPOW, SH00], that is, header compression is to be
   performed when cost is a concern. [ROHC] has developed a robust
   header compression scheme particularly suitable for lossy links. It
   develops a link-layer header compression scheme working (with maximum
   compression rate) over the IP-UDP-RTP headers to be performed on the
   air link for spectrum usage optimization. [VOIPOW] reports that the
   capacity drops only 10% with respect to the circuit-switched
   reference case, once the IP(v4)/UDP/RTP header is compressed. This
   should be compared with a capacity drop to less than 50%, if the
   complete header is sent over the air interface.

   - If both e2e encryption and header compression are to be applied,
   the former has to be done in a way not to obstruct the latter.

2.6. Encryption and Unequal Error Protection

   Unequal Error Protection (UEP) might be added to reduce the frame
   error rate (FER) for the audio stream, by taking into consideration
   the fact that different bits in a frame of encoded speech show a
   varying sensitivity to errors. UEP results in the division of the
   application payload into different classes, which are protected in

Blom, Carrara, Naslund                                          [Page 6]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   different ways according to their importance. When encryption is
   applied, attention has to be paid in keeping the independence of the
   classes. The influence that an error in a certain bit has to a class
   it does not belong to may be against the definition of UEP itself.

   - The encryption scheme should not interfere with the use of UEP.

3. A suitable encryption scheme

3.1. IPsec Applicability

   IPsec is a protocol suite used to secure communication at the network
   layer, and is one of the most promising security schemes for the All-
   IP scenario. Its two protocols are the Authentication Header [AH] and
   the Encapsulating Security Payload [ESP]. Below, we analyse the
   applicability of IPsec according to the requirements described

   Applicability of ESP within the real-time scenario raises some
   considerations. ESP in transport mode is the one used for e2e
   encryption and preferred for reduced header overhead. However, ESP in
   transport mode has the major disadvantage to hide the UDP and RTP
   headers, giving them the cryptographic randomness that obstructs a
   proper header compression (which normally works at the link layer,
   i.e. [ROHC]). [ROHC] has developed profiles to compress ESP, treating
   the two cases in which ESP is implementing the NULL algorithm (only
   authentication, therefore header compression can work on all
   headers), and encrypting algorithms other than NULL (where
   compression only works up to the ESP header). The objective here is
   confidentiality, therefore the interest is in the latter case. The
   fact that full header compression (IP/UDP/RTP headers) cannot be
   performed implies that the service's cost for the session increases.
   A profile may require ESP in the case the user is willing to pay for
   it, and in that case the ROHC profiles may be applied, providing a
   limited increase in the efficiency. Otherwise, we envisage the
   encryption of only the RTP payload to be the right compromise to make
   the service attractive for larger user groups (it allows the most
   efficient header compression profile), still providing
   confidentiality of the media traffic.

   [MF00] has recently specified the use of an additive stream cipher
   within the context of ESP, whose features satisfy several of the
   requirements previously outlined. In particular, advantages showed
   are speed, reduced packet expansion, and random-access property (the
   keystream can be entered at any point, to solve out-of-order
   delivery). These features could make the Stream Cipher ESP suitable
   for real-time traffic requirements, except for header compression
   whose absence would actually have an impact in terms of cost. In case
   ESP is required by the user profile, we recommend the use of said
   Stream Cipher ESP.

Blom, Carrara, Naslund                                          [Page 7]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   In ESP transport mode, the header compression could work only on the
   IP header and similarly on the ESP header. Since compression has to
   be performed before encryption, it is possible to apply tunneling to
   accommodate them. Full header compression can be performed, followed
   by IPsec insertion, coupled with an appropriate tunneling protocol
   (e.g., GRE or L2TP over PPP). However, this would end up having to
   support e2e header compression, and it would also result in header
   overhead. As a general rule, tunneling should be avoided in wireless
   environments.  Thus, we conclude not to examine this alternative any

   We note that the IPsec non-suitability for several applications has
   been raised before, most prominently by the Transport Friendly IPsec
   BOF, that promoted selective encryption of the packet. Some similar
   proposals for multi-layer payload protection have been presented
   elsewhere. This kind of proposals could provide some of the necessary
   modifications to promote the applicability of IPsec to our scenario,
   but none of them has lead to work in the standard.

   AH also opens some considerations, which extend to other kinds of
   cryptographic authentication as well (e.g., ESP with NULL encryption
   algorithm, or simply a MAC at the application layer). Typically, the
   authentication data (Integrity Check Value, or ICV, in the AH
   glossary) consists of an uncompressible field, i.e. 160/128-bit field
   when SHA1 [SHA] or MD5 [MD5] are used (typically truncated to 96 bits
   [HMAC]). It results in obvious bandwidth consumption, which turns out
   in cost. Moreover, the necessity of delivering all frames to the
   application, e.g. a speech decoder, regardless of bit errors,
   motivated by the lossy and expensive nature of a cellular access
   link, encounters a problem once authentication/integrity protection
   is requested. In fact, a single bit error, either in the data portion
   of the packet or in the MAC portion, would cause the integrity check
   to fail, and the packet to be dropped. This is wasteful, as most
   audio/video encoding schemes will produce acceptable quality from the
   user point of view, even in the presence of a few bit errors. Hence,
   to what extent integrity should be pursued is not always obvious.
   Again, security/cost/usability must be weighed against one another.
   We discuss this further in a later section (Section 5).

3.2. Conversational Multimedia

   The above indicates that the conversational multimedia scenario over
   a wireless link poses specific (sometimes delicate) issues for the
   encryption scheme (and other security primitives, see Section 5), due
   mainly to the properties of the air link. We argue that these issues
   are not fully taken into consideration by existing solutions,
   tailored for a fixed, reliable transport medium, and the use of more
   powerful platforms.

Blom, Carrara, Naslund                                          [Page 8]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

4. Encryption Methods Overview

   There are two main flavors of ciphers: block ciphers and stream
   ciphers. In the following, we analyze some of the main aspects of
   these two flavors to determine their applicability to the
   conversational multimedia scenario. For more information, we refer to

4.1. Stream Ciphers

   An additive stream cipher is a cipher that generates a pseudo-random
   string of bits (the keystream), and encrypts by adding it modulo 2 to
   the plaintext. Decryption is obtained adding the keystream to the
   ciphertext, modulo 2. The operation has to be performed bitwise, that
   is, synchronization has to be guaranteed to correctly decrypt. In the
   remainder of the document, stream ciphers refer to additive stream

   Stream ciphers offer valuable advantages over block ciphers. They
   generally provide faster ciphers and do not expand the protected
   message as instead some other methods do by e.g. requiring padding.
   This makes stream ciphers particularly suitable in scenarios where
   time and bandwidth are two valuable aspects.

   Regarding the specific conversational multimedia data features, error
   propagation is not an issue, since one-bit error in the transmitted
   ciphertext results exactly in one-bit error in the recovered message.
   UEP can be used without problems, since the effect of encryption is
   local to every single bit and does not influence bits belonging to
   other classes.

   The main issue that stream ciphers pose is the synchronization of the
   keystream. Moreover, in an e2e solution, the unreliability of IP as
   transport gives the necessity for encryption to deal with out-of-
   order delivery and loss of packets. State-caching mechanisms are
   possible to overcome the out-of-order problem, but they are complex,
   expensive in terms of time, and may be vulnerable to denial of
   service attacks [MF00]. Many stream ciphers, e.g. the alleged RC4
   [SC96], cannot overcome the problem, while SEAL [SEAL] can. We say
   that a cipher that efficiently (in constant time) enables forward
   advance/backward rewind to any position in the keystream has the
   random-access property.

4.2. Block Ciphers

   Block ciphers operate on larger blocks of plaintext and ciphertext.
   There are mainly two modes. Electronic Codebook (ECB) mode operates

Blom, Carrara, Naslund                                          [Page 9]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   on each block independently, which eliminates problems of
   synchronization. Cipher Block Chaining (CBC) mode instead, feeds the
   previous ciphered block into the current block. Generally speaking,
   ECB is not secure in the strongest sense of the word (regardless of
   what block cipher is used), while CBC can be (if the block cipher is
   idealized) [BDJR].

   Block ciphers have some features which deprecate their use with the
   RTP-type traffic.

   Error propagation is not desired, as stated above. [WL00] underlines
   that cellular telephony systems require delivery of all frames to the
   speech decoder to guarantee an acceptable speech quality. With block
   ciphers, a single bit error in transmisssion affects an entire block
   in ECB mode, and even propagates to the following block with CBC
   mode. Given the current requirement for the BER target over the air
   link, this may negatively influence the resulting speech quality.

   Managing out-of-order delivering and loss of packets then is not
   simple in CBC mode. The former may require state-caching mechanisms
   with the problem already underlined, and the latter may give error
   propagation in feedback mode.

   The applicability of UEP is not straightforward. A bit ends up
   influencing other classes it does not belong to, when CBC mode is
   used. Even worse, the cipher chaining propagates occurring errors,
   which may end up in high importance classes of bits if the
   encryption/decryption of packets is not kept independent from each

   ECB can keep the independence of the classes, needed to perform UEP.
   However, to achieve this, padding may be required for each class to
   "fill out" a multiple of the block size. The resulting waste in bits,
   which depends on the class sizes, is in many cases unacceptable.

4.3. Block Ciphers used as Stream Ciphers

   It is possible to use block ciphers to realize stream ciphers; they
   can offer the same advantages as pure stream ciphers, except
   generally the same high speed. Examples are block ciphers in Output-
   Feedback (OFB) mode, and Counter mode. We do not consider Cipher
   Feedback (CFB) mode (that can be implemented to give a self-
   synchronizing stream cipher), since it gives error propagation and,
   perhaps even worse, since its self-synchronization may be lost due to
   recurring bit errors.

   Counter mode has the advantage that the keystream can be directly
   entered at any point independent of the previous states (random-
   access property). This is not a feature of pure OFB mode.

Blom, Carrara, Naslund                                         [Page 10]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

                        Stream   Block      Block as Stream (OFB)

   Error-robustness      yes      no            yes
   Speed *            very high   high          high
   Out-of-order and
   loss resistance       yes**    some          yes***
   Absence of message
   size expansion        yes      no            yes
   UEP friendliness      yes      no            yes

   * it is a general observation, there might be block ciphers with a
   speed comparable to certain (slow) stream ciphers
   ** it is true for some stream ciphers, for ex. SEAL. It is not true
   for example for RC4
   *** it is not a feature of pure OFB, but it may be for revised OFB

   Table 1: Convenience of encryption schemes for conversational

4.4. Applicability of the encryption scheme to conversational multimedia

   We conclude from the previous discussion that from the encryption
   point of view a fast stream cipher with the random-access property
   appears to be suitable for conversational multimedia traffic. This
   stream cipher, in turn, can be derived from a block cipher in a
   suitable mode. Table 1 summarizes some relevant parameters, which are
   meaningful to the comparison. In particular, we refer to [BC00],
   which suggests the use of a variant of OFB.

   Moreover, for the motivations presented in Section 2, we also believe
   that a straighforward way to provide media confidentiality and to
   allow needed optimization like full header compression, is to apply
   encryption only on the RTP payload. [RTP] itself foresees encryption
   methods leaving the headers in clear. We refer to [BC00] for a
   proposal specifying such a method, and fulfilling the requirements
   highlightened in the current document.

   For many applications, there will be an extra level of security
   added, for instance by the air interface for a mobile phone. Though
   not an e2e solution, this may sometimes, at least partly, compensate
   for a different level of security at the application layer.

Blom, Carrara, Naslund                                         [Page 11]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

5. Integrity Protection

   Integrity and message authentication may be chosen independently of
   confidentiality. There are several aspects that question their
   applicability to conversational multimedia traffic.

   First of all, they are typically performed using a keyed hash as a
   MAC (whatever layer in the stack they are applied on) that translates
   into additional (uncompressible) bytes to be bound to the single
   packet. Popular functions like SHA1 and MD5 produce an output of
   160/128 bits, often truncated to 96 bits, which increases the
   overhead for packets, especially for short packets like those for
   voice transmission (6-32 bytes of speech payload, [SW00]). Such an
   impact on capacity should be strongly motivated.

   The biggest problem is related to the impact given by errors. [WL00]
   states that the BER over the radio link may be on the order of 10e-3,
   when retransmission is not used. Furthermore, [WL00] identifies as a
   necessary improvement for the radio link the requirement 'no dropped
   packets due to bit errors in the payload'. The reason for this is
   that the codec itself can manage errors in the payload, often
   maintaining reasonable speech quality. A single bit error in the
   authentication verification process causes the packet to be dropped.
   This single error can be present either in the data portion or in the
   MAC field of the packet. Therefore, authentication of the payload may
   lead highly degraded speech quality.

   Replay attacks seem hard to perform, for the nature of conversational
   multimedia traffic. If then an attacker knows the codec (with a
   stream cipher, the information may be gained by observing the packet
   length), he could for example perform bit inversion. However, in
   general it seems hard to perform modifications which could lead to
   something harmful and meaningful, while it may cause mainly
   degradation of the quality and Denial-of-Service (DoS), which anyway
   authentication cannot prevent, only detect. [BC00] reports further

   We conclude therefore that, even if (strong) authentication is
   required from the security point of view, whether or not to actually
   use it, and at what level of security (number of bits for the MAC)
   depends on the security need vs. the channel characteristics. It is
   again up to the user profile to require its correct usage.

6. Video and Streaming

   Conversational video shows characteristics and requirements similar
   to conversational voice, for the channel described in [WL00].

Blom, Carrara, Naslund                                         [Page 12]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   Streaming traffic shows more relaxed requirements. Packets have
   bigger sizes, and retransmission is performed. Therefore, the choice
   of the encryption algorithm and the security scheme seem less
   critical, as does authentication (assuming the overhead is
   acceptable). Header compression should be performed anyway, but the
   gain is not so remarkable as it is in the case of short packets.

7. Security considerations

   Most of the discussion has been focused on security issues, with a
   main concern on confidentiality.

   We underline the open challenge with respect to DoS attacks, which
   appear the most feasible and harmful attacks in this scenario.

   Moreover, we foresee the need for a careful key management design
   behind this security framework. Bandwidth usage and time restrictions
   (e.g. round-trip time has impact on service behavior) impose strict
   requirements on the key management as well.

   Real-time Transport Control Protocol (RTCP) security is not
   investigated in this version of the document.

8. Conclusions

   Real-time services in the Internet need to be coupled with security.
   The ambition is to employ a solution with IP all the way, and to
   offer a service as attractive as the circuit switched one is already
   today. This leads to new issues, mainly posed by the cellular access

   The document has highlighted the need for a trade-off between
   security and cost as a paradigm for 3G networks, and promotes the use
   of security profiles.

   Requirements for encryption in the conversational multimedia scenario
   have mainly been addressed. The high spectrum cost induced by the use
   of IPsec and the need of full header compression motivate the choice
   of placing encryption at the RTP layer. Message authentication and
   integrity may have impact on the bandwidth usage and on the quality
   of the service, thus their proper usage is an issue.

   A stream cipher (possibly based on a block cipher) with certain
   features (listed in the document) seems to properly fulfill the
   requirements needed by the encryption algorithm for conversational
   multimedia traffic.

Blom, Carrara, Naslund                                         [Page 13]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

9. Acknowledgments

   We would like to thank Lars Westberg, Morgan Lindqvist, and Luigi
   D'Antonio for their work and assistance. Krister Svanbro, Johan
   Sjoberg, and Magnus Westerlund provided significant help. Thanks to
   Jari Arkko, Luis Barriga, and Andras Mahes for their valuable

10. Author's Addresses

   Rolf Blom                Tel:    +46 8 58531707
   Ericsson Research
   Stockholm, Sweden        EMail:

   Elisabetta Carrara       Tel:    +46 8 50877040
   Ericsson Research
   Stockholm, Sweden        EMail:

   Mats Naslund             Tel:    +46 8 58533739
   Ericsson Research
   Stockholm, Sweden        EMail:

11. References

   [AH]    Kent, S., and Atkinson, R., "IP Authentication Header",
           RFC 2402, November 1998.

   [BC00]  Blom, R., Carrara, E., Naslund, M., Norrman, K., "RTP
           Encryption in 3G Networks", IETF draft, November 2000

   [BDJR]  M. Bellare, A. Desai, E. Jokipii, and P. Rogaway: "A Concrete
           Security Treatment of Symmetric Encryption: Analysis of the
           DES Modes of Operation", in proceedings of the 38th IEEE
           FOCS, 1997.

   [ESP]   Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
           (ESP)", RFC 2406, November 1998.

   [FC]    Ferland, G., Chouinard, J., "Error Rate Performance Analysis
           of Stream and Block Ciphers in a Digital Mobile Communication
           Channel," Int. Conf. Vehicle Navigation and Information
           Systems, Oslo, Norway, 1992.

   [HMAC]  Madson, C., and Glenn, R., "The Use of HMAC-MD5-96 within ESP

Blom, Carrara, Naslund                                         [Page 14]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

           and AH", RFC 2403, and "The Use of HMAC-SHA-1-96 within ESP
           and AH", RFC 2404

   [KA98]  Kent, S., and R. Atkinson, "Security Architecture for the
           Internet Protocol", RFC 2401, November 1998.

   [MD5]   Rivest, R.,"MD5 Digest Algorithm", RFC 1321, April 1992.

   [MvOV]  Menezes, A., van Oorschot, P., and Vanstone, S, "Handbook of
           Applied Cryptography", CRC Press 1997.

   [MF00]  McGrew, D., Fluhrer, S.R., Peyravian, M., "The Stream Cipher
           Encapsulating Security Payload", Internet Draft, draft-
           mcgrew-ipsec-scesp-01.txt, July 2000

   [ROHC]  Burmeister, C., Clanton, C., Degermark, M., Fukushima, H.,
           Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
           Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke,
           T., Zheng, H., "RObust Header Compression (ROHC)", Internet
           Draft, October 2000

   [RTP]   Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.,
           "RTP: A Transport Protocol for Real-time Applications", RFC
           1889, January 1996.

   [SC96]  Schneier, B., "Applied Cryptography. Protocols, Algorithms,
           and Source Code in C", John Wiley and Sons, 2nd edition, 1996

   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.

   [SH00]  Svanbro, K., Hannu, H., Jonsson, L-E, and Degermark, M.,
           "Wireless Real-time IP Services Enabled by Header
           Compression", Proceedings of IEEE VTC Spring 2000, Tokyo,
           June 2000

   [VOIPOW] Svanbro, K., Wiorek, J., and Olin, B., "Voice-over-IP-
            over-wireless", Proc. PIMRC 2000, London, Sept. 2000

   [SEAL]  Rogaway, P., and Coppersmith, D., "A Software-Optimized
           Encryption Algorithm", Journal of Cryptology, vol. 11(4),
           1998, 273-287

   [SW00]  Sjoberg, J., Westerlund, M., Lakaniemi, A., Koskelainen, P.,
           Wimmer, B., and Fingscheidt, T., "RTP payload format for
           AMR", IETF, August 2000

   [WL00]  Westberg, L., Lindqvist, M., "Real-time Traffic over Cellular
           Access Networks", Internet Draft, draft-westberg-real-time-
           cellular-02.txt, May 2000

Blom, Carrara, Naslund                                         [Page 15]

INTERNET-DRAFT                  cmsec-3G               November 15, 2000

   [WMGL]  Wang, J., McCann, P., Gorrepati, P.B., and Liu, C-Z.,
           "Wireless Voice-over-IP and Implications for Third-Generation
           Network Design", Bell Labs Technical Journal, Vol.3, No.3,
           July-September 1998.

This Internet-Draft expires in April 2001.

Blom, Carrara, Naslund                                         [Page 16]