Abstract:
One network protocol (RTP) each, having data packets (dp) comprising an expandable header (KE) is provided for a data stream (ds1 . . . n) encoded in a manner individual to said data stream, and the key information (si1 . . . n) formed in a data stream manner individual to said data stream is inserted into an expandable header (RTPH) of a data packet (dp) of the respective data stream (ds1 . . . n) and transmitted. The key information (sp1 . . . n) is selected in a manner individual to said data stream from the expanded headers (KE) of received data packets (dp) of the respective data stream (ds1 . . . n), and the associated encoded data stream (ds1 . . . n) is decoded by means of at least one piece of selected data stream individual key information (si1 . . . n). The forming and inserting of key information (si1 . . . n) into standard expanded headers (KE) can be performed with little additional expense, thus significantly reducing the expenditure for the analysis or diagnosis of the simultaneously transmitted encoded data streams (ds1 . . . n). Advantageously, the insertion of key information (si1 . . . n) can be activated or initiated only if the diagnosis or analysis and/or the recording of the data streams is currently being performed.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is the United States national phase under 35 U.S.C. § 371 of PCT International Application No. PCT/EP2008/058552, filed on Jul. 3, 2008, and claiming priority to German Application No. 10 2007 041 143.1, filed on Aug. 30, 2007. Those applications are incorporated by reference herein. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    1. Field of the Invention 
         [0003]    Embodiments of the invention relate to improvements to analysis or diagnosis of simultaneously transmitted data streams. 
         [0004]    2. Background of the Art 
         [0005]    In communication networks, especially in Voice Over IP communication networks, the RTP (Real Time Protocol) is often used to transmit data streams or multimedia data streams consisting of data packets, i.e., user information or speech information. The RTP is defined in RFC standard 1889, or since 2003 in RFC standard 3550. Due to increased security requirements, data streams have been transmitted encrypted for quite some time, and the secure RTP used for this is described in RFC standard 3711. In this context, the key information required for encryption is assigned and used on a data-stream-specific basis. As an example, for a multimedia session between two endpoints on an IP-based communication network, an audio and a video data stream are each transmitted in one transmission direction. Related to both transmission directions, four data streams are transmitted within a multimedia session, each of which is encrypted separately, i.e., encrypted data-stream-specifically. The key information for that particular session or data stream is assigned or processed during connection signaling—using the SIP (Session Initiation Protocol), for example—with a special key used to encrypt the connection signaling—Preshared Secrets, for example—which cannot be recognized even if the data stream is hacked. 
         [0006]    In communication networks, multiple data streams or multimedia data streams are generally transmitted through a transmission leg or transmission segment. For problem situations arising in communication networks, analysis or diagnosis of the transmitted data streams is necessary in order to locate or delimit errors. For error analysis or diagnosis, reconstruction of the unencrypted data streams is usually necessary. An analysis or diagnosis is often performed on transmission segments with multiple data streams transmitted simultaneously using the RTP, so that the key information in the data streams (RTP data streams, for example), is not available and cannot be determined even during connection signaling, because the signaling information and the key information are re-encrypted, and the key information used is not available. 
       BRIEF SUMMARY OF THE INVENTION 
       [0007]    Embodiments taught herein improve the analysis or diagnosis of individual or simultaneously transmitted data streams containing data packets, with data streams generated and encrypted data-stream-specifically according to a network protocol for data stream transmission. 
         [0008]    Embodiments reported herein may provide a network protocol with data packets having an extendable header, and that data-stream-specifically generated key information is inserted and transferred into an extended header of a data packet of the respective data stream. From the extended headers of the received data packets in the respective data stream, the key information is selected data-stream-specifically and the associated, encrypted data stream is decrypted using at least one piece of selected key information. 
         [0009]    In embodiments reported herein key information can be generated and inserted with minimal administrative effort and that efforts for analysis or diagnostics of simultaneously transferred data streams can be significantly reduced, so that the additional user information can be transmitted in the data packet with extended header. Preferentially the insertion of key information in an extended header of a data packet can be enabled or initiated only while the data stream&#39;s analysis or diagnostics are being performed. 
         [0010]    In a preferred embodiment, the network protocol with extendable header is the standardized network protocol according to the RFC Standard 3550 or 1899, whereby the data streams (ds 1  . . . n) are encrypted according to the Secured Real Time Protocol (SRTP). The standardized SRTP protocol is based on the standardized RTP (Real Time Protocol) according to RFC Standard 3550 or 1899. Through the use of the RTP, key information can be inserted into the standard extendable header with minimal additional effort. 
         [0011]    In another embodiment, it is possible in the network protocol to determine a data packet type for data packages with inserted key information so that the data packets may be discarded, if the data stream is received in accordance with the network protocol, whereby no payload data will be inserted in the data packet. This ensures that the key information is not read if the data packets are transmitted according to network protocol by a network protocol-compliant data receiver. The data packet type for the data packets is defined as a data packet type that is new for the network or preferentially a previously unused data packet type, where the data packets are not read by a network protocol-compliant receiver, if the transfer is according to network protocol. 
         [0012]    In another preferred embodiment, the data-stream-specific key information will be continuously inserted in the respective data stream&#39;s data packets with extended headers. Upon detection of several data packets with inserted key information, this allows continuous examination of the key information or examination of key information after a regular number of received data packets. Since not every data packet must be checked for inserted key information, the dynamic load is reduced. 
         [0013]    Preferentially, the data-stream-specific insertion of key information (si 1  . . . n) for analysis or diagnostics and/or recording of data streams (ds 1  . . . n) can be enabled and subsequently disabled. By enabling the insertion of key information in data packets only during diagnostics of data streams, high security during operations without diagnostics remains intact. 
         [0014]    Additional preferential developments of the invented method and one embodiment of an arrangement according to the invention can be found in other claims. 
         [0015]    The following text further explains the invention and its developments, with reference to two drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0016]      FIG. 1 , a schematic showing one communication arrangement for applying the invented method, and 
           [0017]      FIG. 2 , a data packet suitable for the communication arrangement according to the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0018]      FIG. 1  is a schematic diagram showing an example of a communication arrangement in which the invented method is used, including only components in which the invented method is implemented or which are necessary in order to clarify the invented method. 
         [0019]    The communication arrangement is suitable for Voice Over IP, i.e., for transmitting spoken information in the IP protocol, with signaling by means of the standardized H.323 or SIP protocol. For speech and/or video transmission, use of the RTP (Real Time Protocol) is preferred, with speech and/or video information transmitted directly between the components that are connected by signaling. The RTP is defined in RFC standard 1889 or 3550 and consists of a protocol for continuous transmission of real-time data, e.g., audiovisual or multimedia data over IP-based networks. The data packets to be transferred are coded and then inserted for transmission in IP-compliant data packets via IP-based networks. The data packets are transferred within a session between IP terminals, whereby each session is assigned at least one data stream ds or several data streams. The RTP is suitable for transmission of individual data streams ds as well as for simultaneous transmission of multiple data streams ds 1  . . . n or data packets. For the execution example given here, it is assumed that multiple data streams, ds 1  . . . n, i.e. multimedia streams, are transmitted simultaneously between components of an IP-based network. 
         [0020]    Due to increased security requirements for transmitting data streams ds, it has become increasingly common to encrypt data streams ds, especially data streams ds transmitted according to the RTP. Key information si, which is recognized by the components between which the data streams are transmitted in an IP-based network, is used for this encryption. A protocol for encrypting RTP data streams is defined in the SRTP (Secure Real Time Protocol) according to RFC standard 3711. It uses a symmetrical encryption system that offers a high degree of security. 
         [0021]    The communication arrangement consists of a first component K 1  that is represented in the execution example by a Gateway GW. The Gateway GW can, for example, be connected via a local network LAN—hereafter designated as LAN and represented in  FIG. 1  by a dash-and-dot outlined oval—to a second component K 2 , which in the execution example is represented by an Internet endpoint IP-E such as a multimedia terminal MME. The LAN can consist physically and procedurally of an Ethernet, for example. 
         [0022]    For the execution example, it is further assumed that multiple data streams ds 1 ′. . . n′ or multimedia data streams generated according to the RTP are to be transmitted simultaneously from the Gateway GW to the Internet endpoint IP-E. As an example, the multiple data streams ds 1 ′. . . n′ are generated as audio data streams and video data streams, and both an audio and a video data stream can be assigned to each session. In addition, the data streams ds 1 ′. . . n′ generated according to the RTP are encrypted data-stream-specifically, using an encryption unit VE. This means that, for each data stream ds 1 ′. . . n′, a different piece of key information si 1  . . . n is designated for encryption. RTP data streams ds are encrypted preferably using the SRTP according to RFC standard 3711. 
         [0023]    According to the invention, the encrypted data streams ds 1  . . . n from the data-stream-specifically encrypted data streams ds 1  . . . n should be decrypted for analysis of the data streams by a diagnosis unit DE. Normally a diagnosis unit DE is not involved in the signaling between the connection-generating components of an IP-based network, so as part of the signaling the used key information si is processed for each individual data stream. Of course, signaling could also be analyzed by the diagnosis unit DE, but the key information si 1  . . . n for the data streams ds 1  . . . n could not be determined, because the signaling and the key information si 1  . . . n are re-encrypted and the pieces of key information for these encryptions are not available to the diagnosis unit, nor can they be determined from the signaling information. This means that the diagnosis unit DE has no information about the key information si used in the data streams ds 1  . . . n. 
         [0024]    So that data streams ds 1  . . . n generated according to the SRTP can still be decrypted, the invented method is used, with the invented method applied in the execution example to the simultaneous transmission of multiple data streams sds 1  . . . n generated according to the SRTP from the Gateway GW to the IP endpoint IP-E. The methods and components described below apply to the opposite transmission direction. 
         [0025]    In the gateway GW, the data streams ds 1 ′. . . n′ are encrypted in an encryption unit VE according to the SRTP, whereby the encryption unit VE is arranged together with an insertion unit IE within a transmission unit UE. The required key information si 1  . . . n is stored in a key unit SE and is available from the encryption unit VE and the insertion unit IE, designated in  FIG. 1  by an arrow marked with si 1  . . . n. This means that a piece of key information si 1  . . . n is designated for each data stream ds l′. . . n′, i.e., the data streams ds1′. . . n′ are encrypted data-stream-specifically. 
         [0026]    Within the insertion unit IE, the extension KE—see FIG.  2 —of the header will be inserted in the data packet dp intended for transmitting the key information si 1  . . . n according to the RTP protocol by setting the header extension bits to 1. Furthermore, the number of 16-bit words included in the header extension is indicated in the extension KE of the header RTPH or in the header extension Additionally, a piece of data packet type information or a payload type PT according to the RTP may be indicated in the key information si 1  . . . n provided for transmission, which defines a data packet as a data packet dp with inserted key information. For this, a payload type PT should be selected or specified, which is not used in the standard data packets, and data packets with the selected payload type PT will be discarded during standard transmissions. This means that in this version, no user information or payload may be inserted in the data packet dp. 
         [0027]    In order to increase the security during transmission of data packets dp with key information si 1  . . . n, the data packets dp 1  or the key information si 1  . . . n contained in them may be additionally encrypted. Additional key information is needed for this, and it is generated using a public key spublic and a private key spriv. In this case, the public key spub for the additional encryption is provided in the key unit SE in the Gateway GW and is sent to the transmission unit UE for encryption of the data packets dp or the key information si 1  . . . n contained in them, shown in  FIG. 1  as an arrow marked spub. The private key spriv is provided to the diagnosis unit DE by the decryption unit EE and is used to decrypt the additional encrypted data packets dp or key information si 1  . . . n, shown in  FIG. 1  by the designation spriv in the decryption unit EE. 
         [0028]    Subsequently, the key information si 1  . . . n will be inserted in the extension KE of the header RTPH or the extension header of the data packets of the respective data streams ds 1  . . . n. 
         [0029]    The data streams sds 1  . . . n containing key data packets si 1  . . . n are transmitted over the LAN to the IP endpoint IP-E. A diagnosis unit DE connected to the LAN is provided for the purpose of diagnosing or analyzing the data streams sds 1  . . . n. So that the data streams sds 1  . . . n containing the key information si 1  . . . n can be analyzed, the encrypted data streams sds 1  . . . n must be decrypted. As explained previously, for each encrypted data stream ds 1  . . . n, the key information si 1  . . . n needed for decryption is necessary. Since according to the invention, the data packets dp that contain the key information si 1  . . . n are inserted in the data streams sds 1  . . . n, the diagnostics unit DE uses a monitoring unit UEE to search, read, and store data packets dp in the respective data streams ds 1  . . . n that indicate an extension KE of the header RTPH or a header extension. Additionally, data packets dp with key information si 1  . . . n can also be detected by the payload type PT. 
         [0030]    In the data streams psd 1  . . . n from the respective extensions KE of the header RTPH or header extension of the detected data packet dp, the key information si 1  . . . n will be selected and stored, after which the key information si 1  . . . n can be removed from the extensions KE of the header RTPH or the header extensions. Additionally, the extension of the headers RTPH can be reset by inserting suitable information in the header. Together with the respective key information si 1  . . . n, a piece of information i(ds 1  . . . n) from the extensions KE of the headers RTPH must be found and stored, to determine for which of the data streams ds 1  . . . n the key information si 1  . . . n for decryption is provided. 
         [0031]    Both the encrypted data streams ds 1  . . . n and the selected key information si 1  . . . n are transferred to a decryption unit EE. In it the respective key information si 1  . . . n, i.e., the decryption information and the information i(ds 1  . . . n), is used to decrypt the encrypted data streams sds 1  . . . n. After decryption, the unencrypted data streams ds 1 ′. . . n′ are ready for diagnosis or analysis in the diagnosis unit DE. 
         [0032]    Preferentially or optionally, the diagnosis unit DE is provided with a recording unit REC inserted between the LAN and the diagnosis unit DE, in which the data streams sds 1  . . . n can be recorded. Key information si 1  . . . n can then be selected and recorded data streams sds 1  . . . n analyzed or diagnosed at a later time; they can be recorded at night, for example, and diagnosed later during the day. Alternatively, the recording unit REC can also be inserted after the encrypted data streams sds 1  . . . n are decrypted—not shown—so that the data streams ds 1 ′. . . n′ are unencrypted when readied for diagnosis or analysis. 
         [0033]      FIG. 2  shows the protocol structure of a data packet dp, in which a piece of key information si 1  . . . n is inserted. The data packet dp is generated according to the standard RTP and includes a RTPH heading portion according to RFC 3550—known as a header in the industry—and a RTPP usable portion known as the payload. The RTP is embedded in a UDP, whose header UDPH is added into the RTP header RTPH. Because an IP-based transmission is involved, the UDP is packed into an IP protocol IPP, to which an IP header IPH is added. When there is a transmission over the LAN, especially an Ethernet LAN, the corresponding protocol element is still referenced—shown only partially for clarity. 
         [0034]    In the header RTPH of the RTP, the information on the extension KE of the header RTPH presents an important piece of information for the invented method. For this, an x-bit is provided according to the RTP standard, whereby the setting x-bit=1 shows the header extension, designated as xBit=1 in  FIG. 2 . Additionally, a piece of information on the payload type PT can be inserted, designated with the label PT in  FIG. 2 . The payload type PT used is designated in the RTP, but no payload type PT is assigned to it. A payload type PT of “19” is defined in the standardization phase, but it is later designated as unused and then as “reserved.” Therefore, to designate an RTP data packet with key information si 1  . . . n, the use of payload type 19 is preferred. For the additional use of a payload type PT, no user information 1 may be inserted in the payload RTPP, since data packets dp generated this way will be discarded by the receiving component during standard transmissions. 
         [0035]    The extension KE of the header PTRH or the header extension is positioned in the standardized RTP header RTPH according to table 1 below, wherein the numbering 0 . . . 31 represents one bit. 
         [0036]    According to table 1, the x-bit shows the header extension KE, i.e., an x-bit=1 indicates that the header PTRH of a data packet is extended. The scope of the extension is indicated by the number of 16-bit fields in the header extension field. The key information si 1  . . . n for the respective data stream ds 1  . . . n is inserted in the extension header KE, and the following table 2 shows the key information si used for decryption according to the standardized SRTP, wherein the numbering 0 . . . 9 represents one bit. 
         [0000]    
       
         
               
             
           
               
                 TABLE 1 
               
               
                   
               
             
             
               
                 
                   
                             
                     
                         
                         
                     
                   
                 
               
               
                   
               
             
          
         
       
     
         [0000]    
       
         
               
             
           
               
                 TABLE 2 
               
               
                   
               
             
             
               
                 
                   
                             
                     
                         
                         
                     
                   
                 
               
               
                   
               
             
          
         
       
     
         [0037]    The information in table 1 has the following meaning according to SRTP Standard. 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 Version: 
               
             
          
           
               
                   
                 Version of the tracebeacon. 
               
             
          
           
               
                   
                 BeaconType: 
               
               
                   
                 In 
               
             
          
           
               
                   
                 Content of the tracebeacon. 
               
             
          
           
               
                   
                 F: 
               
             
          
           
               
                   
                 Indicate if the lengths of the variable fields is fixed 
               
               
                   
                 to their maximum values (the lengths are fixed if F == 1). 
               
             
          
           
               
                   
                 Rsv: 
               
             
          
           
               
                   
                 Reserved bits. 
               
             
          
           
               
                   
                 NbCtx: 
               
             
          
           
               
                   
                 Indicates the number of contexts contained in the 
               
               
                   
                 packet. A context is an association between a direction 
               
               
                   
                 (Tx/Rx) and an SSRC. It has been judged that a maximum 
               
               
                   
                 of 15 contexts should suffice for the current purposes. 
               
             
          
           
               
                   
                 NbKeys: 
               
             
          
           
               
                   
                 Indicates the number of keys contained in the packet. 
               
             
          
           
               
                   
                 SCIAuthTagLen: 
               
             
          
           
               
                   
                 The length of the authentication tag appended to the 
               
               
                   
                 tracebeacon. This length will always be zero for now as 
               
               
                   
                 the authentication is not expected to be used in the 
               
               
                   
                 short-term. 
               
             
          
           
               
                   
                 KEK SPI Len: 
               
             
          
           
               
                   
                 Length in bytes of the SPI needed to retrieve the key 
               
               
                   
                 that encrypted the KEK. This length can be zero if the 
               
               
                   
                 Encrypted KEK is not present in the tracebeacon. 
               
             
          
           
               
                   
                 Encrypted KEK length: 
               
             
          
           
               
                   
                 Length of the symmetric key encrypted using RSA, in 
               
               
                   
                 bytes. This length can be zero if the tracebeacon does 
               
               
                   
                 not contain this key. Since the Encrypted KEK can be 
               
               
                   
                 the longest part of the tracebeacon, sending the En- 
               
               
                   
                 crypted KEK in, say, one tracebeacon out of two can re- 
               
               
                   
                 sult in appreciable gains in the average size of the 
               
               
                   
                 tracebeacons sent. 
               
             
          
           
               
                   
                 Contexts: 
               
             
          
           
               
                   
                 Configuration, information for the contexts (see the next 
               
               
                   
                 diagrams). 
               
             
          
           
               
                   
                 Keys: 
               
             
          
           
               
                   
                 Configuration information for the keys (see the next 
               
               
                   
                 diagrams). 
               
             
          
           
               
                   
                 Encrypted KEK: 
               
             
          
           
               
                   
                 Symmetric key encrypted using RSA. This field can take 
               
               
                   
                 up to 256 bytes when the public key has 2048 bits and 
               
               
                   
                 does not need to end on a 32 bits boundary. This field 
               
               
                   
                 is also optional as it can have a length of zero 
               
             
          
           
               
                   
                 KEK SPI: 
               
             
          
           
               
                   
                 Identifier that allows to retrieve the key needed to de- 
               
               
                   
                 crypt the KEK. In your case this field corresponds to a 
               
               
                   
                 Certificate Id. This field does not need to end on a 32 
               
               
                   
                 bits boundary. Like the Encrypted KEK this field is 
               
               
                   
                 optional, as it can have a length of zero. 
               
             
          
           
               
                   
                 SCI Authentication tag: 
               
             
          
           
               
                   
                 The authentication tag of the tracebeacon. The authen- 
               
               
                   
                 ticated portion of the tracebeacon will be the first 
               
               
                   
                 eight bytes, the contexts and keys sections. This field 
               
               
                   
                 is optional, as the authentication tag length can be 
               
               
                   
                 zero. It is indeed not expected to be present for this 
               
               
                   
                 version of the tracebeacon. 
               
               
                   
                   
               
             
          
         
       
     
         [0038]    Using the previously described key information si 1  . . . n according to the standardized SRTP, the encrypted data streams ds 1  . . . n are decrypted, i.e. transformed back into the original data streams ds 1 ′. . . n′. The data streams ds 1 ′. . . n′ can be processed in the diagnosis unit DE using the implemented diagnosis routines—not shown.