Deliverable D2.4: Literature Study and Survey on Applicable Technologies

Transcription

1 VIVALDI PROJECT DOCUMENT WORKPACKAGE 2 Deliverable D2.4: Literature Study and Survey on Applicable Technologies Final Version Project full title: Advancing interactive Broadband satellite access by optimal convergence of session based services over DVB-RCS Proposal/Contract no.: FP IST SIXTH FRAMEWORK PROGRAMME PRIORITY 2 IST-Information Society Technologies

2 Introduction Table of Contents 1 Introduction Focus of the Study Protocols Signaling and Media Session Initiation Protocol (SIP)...6 Typical Topologies...6 Registration for Endpoints...6 General Interaction between Servers...6 Call Signaling...6 Security Mechanisms H Typical Topologies...7 Registration for Endpoints...8 General Interaction between Servers...8 Call Signaling...8 Security Mechanisms Inter-Asterisk exchange protocol (IAX or IAX2)...9 Typical Topologies...9 Registration for Endpoints...9 General Interaction between Servers Skype Typical Topologies NAT and Firewall Traversal Implications of Underlying Transport General Interaction between Servers Call setup RTP and RTCP Security Mechanisms Issues for Satellite Communications Conclusions Security Threats Components and Interactions Existing Security Solutions IPsec VIVALDI WP 2 27-Nov-06 Page 2/50

3 Introduction Transport Layer Security (TLS) NATs and Firewalls Problems Created by NATs and Firewalls Existing Solutions STUN / TURN / ICE Universal Plug-and-Play (UPnP) Application Layer Gateways (ALGs) Tunneling IPv Transitional Solutions Security Link Layer Issues Implications Voice Codecs Header Compression QoS Architectures End System Solutions Network Based Solutions Cross-Layer Solutions Admission Control QoS for VoIP IntServ DiffServ Hybrid Models Usage Scenarios Rural Home User SOHO / SME Large Enterprise Conclusions Architecturally Significant Decisions Probabilistic vs. Deterministic Approach to QoS Detect Sessions vs. Detect Media Flows Sound Quality vs. Bandwidth Efficiency Recommendations and Observations Protocols Probabilistic Approach to QoS Detection of Media Flows VIVALDI WP 2 27-Nov-06 Page 3/50

4 Introduction Security Voice Compression Header Compression VIVALDI WP 2 27-Nov-06 Page 4/50

5 Introduction 1 INTRODUCTION 1.1 Focus of the Study The literature study aims to survey and describe existing technologies and mechanisms that are applicable to the VIVALDI project. The areas surveyed are protocols, quality of service models in general and quality of service architectures and solutions that are applicable to voice over IP. The study also considers a number of usage scenarios based on the user requirements work and finally concludes with recommendations and observations about the applicable technologies and architectural decisions. The survey of protocols includes signaling and media protocols (SIP, H.323, RTP etc.), security solutions and NAT and firewall solutions. The aim is not to describe the different protocols in detail, but instead summarize the most important existing solutions and their relevant characteristics. The section on general QoS models aims to provide a higher level architectural view on the issues of QoS and describe the fundamental approaches and tradeoffs involved. The most important existing QoS technologies are described in their own section. The study is concluded with a set of possible usage scenarios and their respective reference architectures. Architecturally significant decisions are identified along with recommendations and observations that relate to the architecture. Where possible, the study aims to highlight important aspects and problems that are relevant to the architecture work. The overall goal is to make sure that future architectural work is based on a clear knowledge of the problems, existing technologies and solutions and their advantages, weaknesses and applicability. VIVALDI WP 2 27-Nov-06 Page 5/50

6 Protocols 2 PROTOCOLS 2.1 Signaling and Media Session Initiation Protocol (SIP) SIP is an IETF proposed standard for initiation, terminating and modifying interactive multimedia sessions. The base specification is defined in RFC 3261 with other core components defined in RFC 3261, RFC 3264 and RFC Typical Topologies There are two basic approaches to SIP-based telephony deployments in multi-site enterprises. One is to have one central SIP server in a datacenter to which all the sites are connected to and the other one is to deploy SIP servers on each site and interconnect them. The advantages of centralized topologies are easier configuration and maintenance. The disadvantages are having a single point of failure and having intra-site traffic looping through the datacenter. The problem of a single point of failure can be solved by duplicating the SIP server on-site or off-site. However, the need for the signaling traffic to go through a central datacenter can prove problematic due to increased delays in an environment where one of the sites is behind a satellite segment. A distributed solution where each site has a dedicated SIP server requires more effort to configure and maintain, but eliminates the above problems inherent with a centralized solutions. Topology decision through correct proxy placement will be a major factor in the success of any SIP based architecture. Registration for Endpoints Registration in SIP is handled by the SIP servers (Registrars). Each endpoint registers with a dedicated SIP server whose location depends on the topology as described above. The registration might take place directly between a user agent (UA) and a Registrar, or it might traverse one or more SIP proxy servers in the case that the UA has moved to a different location. The SIP UA sends a REGISTER message once in the beginning of the session and then resends it periodically. The UA may request a desirable refresh frequency for the REGISTER messages. The server can be configured with a minimum refresh period in order to protect against excessive load from frequent updates. Typically the refresh frequency is in the order of once per hour, but higher frequency is possible for users that change their UA frequently. The client is likely to keep an open TCP connection to the Registrar so that new connection does not have to be established every time the registration needs to be refreshed. General Interaction between Servers SIP servers as long as they operate as a proxy simply forward messages received from a UA (or another proxy) and modify a few header fields. There are no other interactions defined between servers in the context of SIP besides such message forwarding. This particularly means that no inter-server communication takes place unless initiated by a UA. (The case may be slightly different for B2BUAs but even then, inter-server interaction is usually restricted to happen in the context of SIP calls between two UAs.) Call Signaling A call setup between two parties involves a three-way handshake initiated by an INVITE message from the caller (UAC) to the called party (UAS). The called party responds with any number of provisional responses (such as to indicate that the UAS is ringing) that might be originating from VIVALDI WP 2 27-Nov-06 Page 6/50

7 Protocols multiple devices and a final response from a single UAS. The UAC completes the sequence with an ACK message. There might be a number of these transactions during a single connection due to establishing temporary media streams for in-band announcements or ring-back tones, waiting for security, connectivity, or quality-of-service preconditions to complete, etc. However, these are not commonly used by vendors in enterprise products today. As a result, only a small number of these (if any) are used in a given connection. There are also two-way handshake transactions, without the final ACK message or provisional responses, that are meant for updating media state, invoking supplementary services and terminating calls. Most of the messages exchanged are of this type. Call signaling incurs numerous round-trips but many of these can be avoided by means of caching of DNS replies (which is done anyway), by caching authorization nonces for some time, and by keeping transport connections open. Security Mechanisms SIP messages carry a variety of information whose privacy and authenticity has to be guaranteed. Examples are the TO and FROM fields of the header that would allow tracking of calling patterns and the SDP messages that contain information about media types, open ports and so on. Therefore security mechanisms are needed to guard the privacy of the users as well as to protect against identity spoofing that would allow users to set up SIP sessions while pretending to be someone else (possibly leading to the charging of a third party). SIP provides authentication and data encryption mechanisms. The mechanisms are: HTTP 1.1 Digest Authentication, S/MIME, the use of TLS (sips: -URI) and IP Security. The HTTP Digest Authentication method requires a shared secret between the two parties. The authentication is done using MD5 or SHA-1 in a challenge-response exchange. The mechanism is susceptible to offline dictionary attacks if weak passwords are used. The mechanism cannot be used to ensure confidentiality or integrity. Since the SIP message bodies are MIME encoded the standard S/MIME security mechanism can be used. This is especially useful for encrypting the SDP payload. However, the use of S/MIME requires the knowledge of the recipient s public key. This leads to the well known key distribution problem that has not been solved in a practical manner. TLS and IPsec are standard mechanisms described in section H.323 H.323 is a protocol for multimedia communication in packet based networks that has been developed by the International Telecommunication Union (ITU-T). H.323 itself is an umbrella standard that defines the usage of technologies and protocols described in other documents. The core protocols H and H.245 provide call signaling between two communication partners as well as conference setup. Security mechanisms from user authentication to media encryption are introduced in H.235. The H.450.x series defines supplementary services similar to those definitions in ISDN/QSIG. Several annexes to H.323 and H describe mechanisms and protocols for specific problems like Inter-Domain communication, Interworking, Remote Camera Control or Robustness. The usage of H.323 has been declining in favor of SIP for VoIP call setup and control. H.323 is seen as the more complex, inflexible and difficult to implement of the two. However, H.323 is still used in many cases for video conferencing. Typical Topologies The typical topologies and related issues are similar to those with SIP, see VIVALDI WP 2 27-Nov-06 Page 7/50

8 Protocols Registration for Endpoints Similar to SIP, all endpoints must register with a Gatekeeper. The registration includes the transport addresses of the endpoint as well as any number of aliases (user s name, telephone number, etc.) that are assigned to the user. The registrations are soft-state and must therefore be refreshed periodically (the period is determined dynamically). Unlike SIP, H.323 endpoints can only register a given address to one endpoint at a time. General Interaction between Servers Server interaction in H.323 usually happens within a call context. Messages from an endpoint are (possibly modified and) forwarded to the other server, so generally two servers in a call exchange the same messages two endpoints would exchange directly. There are only two exceptions to this rule: When locating a user (see below) an endpoint may contact another gatekeeper via RAS unicast or RAS multicast and asks it to resolve a given address or list of addresses (Location Request, LRQ). When sent via unicast, the contacted gatekeeper sends a (negative) reply even if it does not know the address. The other exception is due to the fact that H Annex G defines an inter-gatekeeper routing protocol that periodically exchanges information about available gatekeeper zones. Call Signaling H.323 models large part of its call signaling mechanisms on ISDN signaling. Similarly to ISDN, first a SETUP message is sent from the caller to the callee, then CALL PROCEEDING and ALERTING messages are returned finally the call is accepted with a CONNECT message or rejected with RELEASE COMPLETE message. The inheritance from ISDN means that interworking of H.323 systems and ISDN-like systems is relatively straightforward. The call signaling also uses a media control channel. The channel is used to signal what kind of media streams and the corresponding addresses the parties are expecting. Overall H.323 call signaling is seen as somewhat verbose requiring unnecessarily many round trips, which causes problems in high delay systems such as satellite links. However, there are extensions to the H.323 protocol that combine the multiple messages required in the setup and reduce the number of interactions required. Security Mechanisms H.323 offers a range of security mechanisms described in the H.235 for authentication, message integrity and encryption of the signaling, media control and media channels. The mechanisms also provide protection against man-in-the-middle attacks and replay attacks. The authentication mechanism can use either a shared secret or public key models. Same problems that were encountered with SIP apply to H.323 mechanisms as well. The encryption mechanisms use either triple-des or RC2. All mechanisms and their variations are grouped in profiles defined in H.235. The profile adopted by most vendors is the Baseline Security Profile, which provides message integrity and authentication on the RAS, H and H.245 channels. Suitable for a global range is the Signature profile which enables end-to-end (as well as hop-by-hop) authentication and nonrepudiation and hop-by-hop message integrity. In addition to this profile, a Voice encryption profile is defined that allows RTP payload encryption. Both profiles use a shared secret exchanged a priori by means outside H.323 and only work on a hop-by-hop basis. H.323 can also use TLS and IPsec, see section VIVALDI WP 2 27-Nov-06 Page 8/50

9 Protocols Inter-Asterisk exchange protocol (IAX or IAX2) IAX is a peer-to-peer, VoIP oriented, protocol that includes both control and media functions [1]. The protocol was originally designed by Mark Spencer for use with the Asterisk open source PBX. There are two versions of the protocol: IAX and IAX2. However, the latter has almost universally replaced the former and today the acronym IAX is taken to refer to the second version of the protocol. IAX is not a standardized protocol and there do not seem to be any efforts at the IETF to standardize it. The designers have created an Internet-Draft describing the protocol. However, the main source of information on the protocol is still the Asterisk source code, which is subject to change at any time. Originally IAX was designed for efficient trunking of calls among Asterisk PBXes. However, it can also be used between servers and clients that support the IAX protocol. A small number of softphones and hard-phones exist that directly support the IAX protocol. IAX could be described as a monolithic protocol since it includes both call control signaling and media transport functionality. IAX can register locations, create, modify and terminate multimedia sessions as well as carry the actual media streams. The authors claim that it is general enough that it can handle most common types of media streams. However, the main focus of the protocol is in point-to-point VoIP calls with some focus on video calls. The design focus of IAX has been in improving efficiency of VoIP calls by prioritizing low overhead and low bandwidth consumption. To this end the protocol is binary encoded and has been kept simple by limiting its scope. Other stated design goals are to ensure NAT transparency, the ability to exchange dial plans and the efficient implementation of intercom and paging features. There has been a preliminary study indicating that IAX might perform better in these areas in comparison to SIP based solutions.[2] An important aspect of IAX is the fact that it transmits all the control signals as well as media over the same UDP port (4569). Multiple calls can be multiplexed over a single connection. This is designed make NAT traversal easier. Typical Topologies Typically a small scale IAX system is built around a single IAX-enabled server (Asterisk) acting as a PBX to which a number of clients connect using IAX, SIP or H.323 protocols. The server typically also acts as a gateway to PSTN or even other VoIP networks. On a larger scale, in multi-site settings it is typical to deploy a single IAX-enabled server on every site and a central server in a data center. The central server in the data center is then connected to PRI lines for PSTN access and possibly to other VoIP networks. Registration for Endpoints IAX provides a facility for clients to register their address and credentials so that others can reach them. The registration process allows for user authentication via multiple methods ranging from plaintext to the use of public/private keys (RSA). The registration process is initiated by the client sending a REGREQ message containing its username. The server responds with a REGAUTH message containing information about the supported authentication types (if authentication is used). The client then resends the REGREQ with the correct authentication. The server then accepts with a REGACK or rejects with a REGREJ message. The registrations are soft-state with a default expiration time of 60 seconds, although this can be specified to be something different in the REQACK message. By default, the client refreshes the credentials every 50 seconds. The client can terminate the registration by simply letting it time out, or explicitly by sending a REGREL request. VIVALDI WP 2 27-Nov-06 Page 9/50

10 Protocols General Interaction between Servers There does not appear to be much interaction between AIX-enabled servers outside of a call context. The only exceptions are the POKE/PONG packets that can be exchanged between servers even when there is no active call Skype Skype is a popular proprietary protocol mainly aimed at VoIP but also supporting video in the latest versions. The heavy encryption of signaling and media traffic along with anti reverseengineering techniques used in Skype make analyzing the protocol difficult. As a result relatively little is known about the detailed functioning of Skype. Typical Topologies Skype is an overlay peer-to-peer network similar to many file sharing applications. Three are three different elements in the network: nodes (clients), super-nodes (servers) and login server. The first two elements are client hosts running the Skype application software. Every ordinary node is connected to a super-node and the super-nodes are interconnected. The login server is maintained by Skype and is used to authenticate users during login. The Skype application software decides whether to run as a normal node or a super-node. There is no way to configure this behavior directly. The difference between the two modes of operation is that in a super-node mode the client stores information for other nodes in the network and is involved in the routing of the calls. A client will not become a super-node if it does not have a public IP address or if it is unable to accept incoming connections. NAT and Firewall Traversal Skype is well known for its ability work behind NATs and firewalls. Although the exact methods used are unknown, it has been conjectured that Skype uses its own proprietary versions of TURN and STUN. According to the Skype Network Administrator s Guide [3] two clients will always try to establish a direct connection between them during the call setup. If the caller is unable to connect to the receiver due to a firewall or NAT at the receiver s end, the caller s super node will signal the receiver to try and establish the connection in the other direction. Should this too fail (due to both parties being behind a firewall or NAT), a third network node with direct Internet connection can be used to relay the traffic. The mechanism for a Skype client behind a NAT to learn its public IP address was described in a presentation given by Biondi and Desclaux [4]. The described procedure is the following: 1. In the beginning of a connection the Skype client sends an initial UDP packet to a super peer. This packet is obfuscated using RC4 and a key calculated from various datagram fields including the source IP address. Initially an IP address of is used. 2. The receiver fails to decrypt the packet because the source IP address it sees differs from the one used by the client to compose the key. 3. The receiver sends back a negative acknowledgement (NAck) which contains the public IP address of the client that the receiver observed. 4. The client takes a note of the address. Implications of Underlying Transport Skype uses both UDP and TCP connections, but there are no predefined ports. Ports can be configured by the user and are randomized during the installation. The range mentioned in the Skype Network Administrator s Guide is >=1024 for both UDP and TCP. Skype is capable of functioning without any UDP connectivity, but this will have a detrimental effect on the quality. TCP connectivity is required, but Skype is capable of tunneling through the ports 80 (HTTP) and 443 (HTTPS). VIVALDI WP 2 27-Nov-06 Page 10/50

11 Protocols General Interaction between Servers Skype is purely peer-to-peer oriented protocol with no explicit servers. However, any client running the Skype software might start to act as a super-peer in essence a server. When a client acts as a super-peer it can provide a number of different services to third parties such as looking up users and relaying signaling and voice traffic. When acting as a super-node, a Skype node is likely to exchange frequent messages with other super-nodes as well as ordinary nodes connected to it. All the communications are heavily end-to-end encrypted (AES-256) making it impractical to build network elements for supporting the protocol. Call setup A call setup with a receiver on the buddy-list takes roughly 5.5 RTT and 2070 bytes when both have a direct Internet connection. When the caller is behind a NAT, the call setup takes roughly 13 RTT and 7163 bytes [5]. The exact mechanisms used for call setup are currently not publicly known RTP and RTCP Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) are IETF standardized protocols for carrying real-time media streams across IP networks. RTP and RTCP were developed by the IETF Audio-Video Transport Working Group in 1996 and are currently published as RFC RTP provides the minimal necessary support for real-time communications: it provides for intrastream timing (i.e. ensures proper timing of pieces of a single media stream) as well as for interstream timing (i.e. proper synchronization between different media streams) and maintains packet ordering. It further allows distinguishing between different payloads (e.g. two codecs or speech and DTMF), supports simple peer identification, and calculates reception statistics to monitor quality of service. Packetization formats define how output data of a particular codec is to be formatted into one or multiple RTP packets. The objective of packetization formats is to provide as much robustness as possible against packet losses and allow independent decoding of individual packets. Dedicated packetization formats have been defined to cope with packet loss: general considerations for error repair are discussed in RFC 2354, a generic forward error correction (FEC) format is defined in RFC 2733, and audio redundancy coding (RFC 2198) provides an audio-specific solution to efficiently convey redundant information. All such approaches add further delay (which may not be a major issue with satellite communications). However, today s IP telephony equipment usually does not support such mechanisms. Both SIP and H.323 rely on RTP for transporting the media streams between end points, while Skype and IAX have their own solutions. Security Mechanisms There exists a Secure RTP (SRTP) extension that provides confidentiality, message authentication and replay protection to the RTP and RTCP traffic. The encryption mechanism uses the AES stream cipher and the authentication mechanism extends the headers by adding a 4 or 10 byte field for data integrity check. The use of SRTP raises the need for determining the keys to be used for encryption. These keys can be exchanged through any mechanism, for example by using the signaling protocol (SIP, H.323). However, there is a proposed extension to RTP called ZRTP [6]. ZRTP extends the RTP headers to support Diffe-Hellman key exchange and session parameter negotiation. The use or ZRTP essentially means that the authentication and encryption is done in-band with the media, completely separate from any call signaling protocols. The use of IPsec is also possible for securing RTP and RTCP in the IP layer, see VIVALDI WP 2 27-Nov-06 Page 11/50

12 Protocols Issues for Satellite Communications RTP and RTCP are designed to work over UDP or TCP. However, the ports used for communications are not standardized but instead are dynamically determined. Typically even ports used for RTP and the next higher odd port used for the corresponding RTCP connection although this can differ. This dynamic usage of port numbers creates problems for NATs, Firewalls and other mid-boxes. These problems are further discussed in section 2.3. Due to their nature, RTP and RTCP generate steady packet flows. A typical uncompressed G.711 data stream, for example, uses 80 or 160 bytes (10 or 20 ms) of audio payload per RTP packet, resulting in 100 or 50 packets per second. Per default, RTCP packets are sent at most every five seconds and usually consist of some 100 bytes per packet. A significant issue raised is the amount of header overhead when RTP is used over UDP/IP. The header overhead per packet using IP/UDP/RTP is 40 bytes, while the packet might only contain a 20ms sample of 8 KHz speech (80 or 160 bytes). For terrestrial wireless links, IP/UDP/RTP header compression techniques have been developed to deal with precisely the issue of high perpacket overhead. Header compression is able to reduce the 40 bytes per-packet overhead to about one byte per packet (optimistic mode) or two/three bytes per packet (reliable mode) the two modes essentially differ in the number of consecutive packet losses they can survive without requiring interactive resynchronization (which would incur another RTT). For these reasons implementing a header compression scheme over a satellite link is crucial for ensuring effective usage of the expensive transmission bandwidth Conclusions RTP and RTCP are the standard way of transporting media streams over IP networks. Due to the dynamic use of port ranges, these protocols present problems with middle-boxes that have to be addressed. Although depending on the application, it is possible that the ports can be configured to a limited extent by an administrator. Furthermore, a significant header overhead incurred by the use of IP/UDP/RTP has to be addressed through header compression in order to achieve high efficiency in bandwidth utilization. Providing QoS for RTP streams should be one of the main goals of the architecture work. H.323 is being replaced by SIP as the predominant protocol for multimedia session setup and management. SIP adoption is expected to grow rapidly due to its flexibility and complexity considerations. It is able to meet the needs for enhanced services that were identified as an important need of the business users in D2.1. SIP is also the only protocol with significant standardization efforts by the IETF. The VIVALDI Deliverable D2.2 (Service Provider Requirements Specification) also identifies SIP as the mandatory signaling protocol to be supported. Therefore the architecture work should be mainly aimed at accommodating SIP based traffic. Proprietary but widely used protocols such as Skype present problems due to the fact that they are not openly documented and are subject to change at any time. For these reasons the architecture should aim to accommodate these protocols where possible, but should not put special effort into ensuring their functionality when such efforts would lead to significant costs, significant increase in complexity or tradeoffs with respect to SIP. Open but non-standardized protocols with growing user base, such as AIX, should be treated in a similar manner as Skype. 2.2 Security Threats VoIP and other multimedia communications are susceptible to four main types of attacks [7]: 1. Snooping. This means the act of listening in on the communication sessions in order to gather a variety of information about the communicating parties as well as the network. Snooping attacks generally require a network element on the traffic path in order to be VIVALDI WP 2 27-Nov-06 Page 12/50

13 Protocols effective. However, in a wireless environment such as a satellite segment where the medium is shared, an attacker only needs to be close to the path (i.e. be able to receive the satellite broadcast). 2. Modification. In this case attacker captures messages and modifies their contents. The goal might be to route the traffic through another network element operated by the attacker or for bid down attacks for reducing the level of security. Like snooping attacks, these types of attacks generally require a hostile network element on the traffic path. However unlike snooping attacks, it is not sufficient to merely be close to the path. 3. Impersonation. This involves the attacker pretending to be a server or user in order to gain some information from the victim. 4. Denial of Service. One of the most popular types of attacks today, DoS attacks might be distributed in nature or originate from one source. The aim is to render either a server or a user agent unusable through the use of a variety of different techniques. 5. Spam. Spam can create two different threats to communication systems: 1) Network resources can be used without authorization to distribute large quantities of spam traffic and 2) clients connected to the network might receive large amount of spam traffic (especially undesirable when the bandwidth costs are high) Components and Interactions A typical VoIP system is composed of user terminals (soft-phones, hard-phones) and a variety of different types of servers (SIP servers, H.323 Gatekeepers). The system further includes numerous different interactions between these components. The main types of interactions between the network components are: Registration of a user to the network. Involves authenticating the user and granting access privileges. Forwarding of messages by the servers. The servers need to know the destination of the message in order to determine the next hop. Also involves hop-by-hop authentication of servers. Inspection and modification of the messages by the servers. Servers that actively take part in providing the service by inspecting and modifying various fields in the messages. This requires the server to be able to decipher the relevant fields if the messages are encrypted (problem for end-to-end solutions, see below). The traffic in a typical system can be divided into signaling traffic and media traffic. These differ in many ways, the most important of which is that media streams tend to be established directly between two endpoints while signaling traffic can traverse multiple servers (e.g. SIP proxies) along the route. The two fundamental modes of security are end-to-end security and hop-by-hop security. End-toend security refers to mechanisms that involve the caller and the callee. End-to-end security mechanisms are usually implemented by the signaling protocols themselves. On the other hand, hop-by-hop security refers to the security (authentication, encryption) between two consecutive components on the traffic path. Hop-by-hop security is generally not implemented by the signaling protocols themselves, but rather by lower layer security solutions (IPsec on the IP layer and TLS on the transport layer). End-to-end security for a VoIP signaling or data streams creates a number of problems for components along the traffic path. Solutions such as IPsec that guard against header modifications will not work with components such as NATs whose functionality relies on changing various header field values. IPsec for instance encrypts the TCP and UDP checksum fields, which stops a NAT from recalculating the checksum after changing the address and port fields in the header. For this reason, it is not possible to create an end-to-end security solution between a VIVALDI WP 2 27-Nov-06 Page 13/50

14 Protocols host in a private network and one outside of it. Any security solution will need co-operations from multiple network elements. Furthermore, any security solution that encrypts packet contents (such as S/MIME) will make sniffing of traffic impossible. For example, it is not possible to provide QoS for VoIP traffic traveling inside a VPN tunnel simply by observing the traffic flows. Hop-by-hop security on the other hand raises issues with authentication. The components on the traffic path have to be able to authenticate each other and to form trust relationships. In a private network authentication mechanisms can be configured and used with relatively low administrative overhead since one entity is responsible for all the network elements. However, if not all the network components are owned and controlled by one party the configuration of authentication mechanisms can cause significant overhead. In such cases the trust relationship can be formed using a shared secret or through certificate system. Authentication is especially important in order to prevent unauthorized third parties from routing their own traffic through the service provider s network (see United States of America vs. Robert Moore [8]). Unfortunately both systems add a great deal of complexity and are hard to maintain Existing Security Solutions IPsec IPsec is an IP layer security mechanism that can be used for authentication, encryption, integrity checks and replay protection for IP packets. IPsec is a mandatory part of IPv6 and optional part of IPv4. IPsec is currently defined in RFCs The most common use for IPsec is for constructing VPN tunnels over the public Internet. Connectionless authentication and integrity checks for IP packets are provided by the Authentication Header (AH). The AH protects all the fields in an IP packet. The Encapsulated Security Payload (ESP) extension header can be used provide authentication, integrity checking and encryption for IP packet contents. This mechanism does not protect the header fields. Since IPsec works below transport layer (UDP and TCP) it can be used to protect both signaling and media streams. However, this also means the implementation of IPsec cannot be done in the applications but must instead be done in the kernel. Transport Layer Security (TLS) TLS is a security mechanism designed to be used on top of a connection-oriented transport protocol (typically TCP) to provide authentication and encryption of data. TLS is the successor of a earlier Secure Socket Layer (SSL) protocol. TLS 1.0 is substantially the same as SSL 3.0 (current TLS version is 1.1). After a connection is set up (e.g. after TCP SYN-ACK exchange) there are a number of TLS phases. These include: determination of a basic set of protocol parameters, key exchange and certificate based authentication and encryption of traffic using a symmetric cipher. The determination of protocol parameters includes the determination of the cryptographic ciphers to use. Currently RSA, Diffie-Hellman, DSA and Fortezza are supported for public key cryptography, RC2, RC4, IDEA, DES, triple-des and AES for symmetric cryptography and MD5 and SHA for hash algorithms. The authentication can be done either for both parties or only for one party. In a typical client/server case only the server is authenticated. The authentication is done through X.509 certificates while an OpenPGP certificate based authentication is also suggested by a draft. The encryption of traffic is done using a symmetric cipher with a key exchanged through Diffie- Hellman exchange or through using the public key algorithms. VIVALDI WP 2 27-Nov-06 Page 14/50

15 Protocols 2.3 NATs and Firewalls Problems Created by NATs and Firewalls DVB-RCS service providers typically use Network Address Translators (NATs) to assign non global IP addresses to the terminals. It is common that the customer s side of the network has one global address at the satellite terminal and private address space for the customer s internal LAN. NATs create problems for VoIP and other media signaling protocols because the end points only know their private addresses and port numbers that are not valid in the global address space. Therefore the signaling protocols need to explicitly deal with situations where one or more of the parties are behind a NAT. The main problems with NATs and firewalls are the following: Connections originating from outside a private network generally have no way of knowing the IP address of the receiver inside the private network. Many protocols use dynamic port ranges that are signaled between the parties inside the application part of IP packets. This leads to following problems: o o o Static firewall rules cannot be set up to allow this traffic. There is no existing mapping in the NAT if the connection is not originated from inside the private network. The party inside a private address space behind a NAT does not generally know a global address that can be used to reach it and might therefore incorrectly signal its private address instead. These problems can be illustrated with SIP: When a connection is set up using SIP, the parties enter their IP addresses and ports for receiving media streams into the SDP portion of a SIP message. If there is a firewall between the two parties it has no way of knowing which ports to open for the flows unless it is able to interpret the SDP message. Furthermore, if one of the parties is behind a NAT, it does not know its global IP address and therefore cannot create a valid SDP message [9] Existing Solutions Unfortunately there is no single solution that would solve all the problems associated with NATs and firewalls in all possible cases. However, there are multiple different methods that work in different situations. These range from IETF standardized methods to proprietary methods developed for specific protocols. STUN / TURN / ICE These are a set of technologies developed by the IETF for enabling protocols to work behind different types of NATs. STUN is a protocol and a set of methods that a client can use to discover the type of NAT it is behind as well as the corresponding address bindings. The process involves a STUN client connecting a STUN server outside of the private address space. The server will report the global addresses that it sees and instruct the client to perform specific actions required to determine the type of NAT used. In practice many SIP solutions implement STUN type mechanisms with good results. However, STUN will not be enough for traversing all types of NATs. For example, if the parties are behind symmetric NATs (the type most commonly found in corporate networks) STUN will not be effective. Furthermore, the STUN protocol does not address the use of TCP which is now a mandatory requirement for SIP (although the same mechanisms can still be applied). However, this is often not a big problem because clients establish communications with their VoIP servers, typically located outside the NAT. VIVALDI WP 2 27-Nov-06 Page 15/50

16 Protocols TURN is another IETF proposal for solving the media traversal problem with symmetric NATs. The basic idea is to have a TURN server on the media and signaling path but outside the private address space. The client then opens a connection with the TURN server that will forward any messages that the client whishes to send. This way all the communication can travel across the same symmetric mapping in the NAT. The major problem with TURN protocol is that it does not reveal the details of the SIP session to the TURN server and therefore creates problems for QoS or security architectures. ICE is an IETF attempt at creating a unified framework that brings together the different NAT traversal techniques such as STUN and TURN. However, implementing ICE (or STUN / TURN) adds a large amount of complexity to the application. This coupled with the fact that the ICE specification has only recently become stable has meant that the industry has been slow to adopt these techniques. Universal Plug-and-Play (UPnP) UPnP is actually a collection of different protocols and solutions with an aim to provide simple and seamless networking between a large number of different applications and devices. The protocols are developed by the UPnP Forum. UPnP includes a solution for NAT traversal called Internet Gateway Device (IGD) protocol. The idea is to let applications to configure NAT routers by explicitly adding and removing mappings as well as inspecting existing mappings. The main problem with IGD is the lack of practical security mechanisms. While UPnP does define security mechanisms, they are overly complex and often not implemented. The adoption of UPnP by the industry has been slow and it is expected to be limited to small installations. Application Layer Gateways (ALGs) ALG is a combination of a NAT or a firewall and a protocol specific server (e.g. SIP proxy). The ALG understands the protocol and modifies specific fields such as IP addresses and ports in a way that allows the connection to be established (i.e. changing private addresses to global addresses). The protocol specific part of an ALG is also able to work with the NAT or firewall in order to keep up bindings or open correct ports. The main disadvantage of ALGs is the fact that they need to be updated every time the protocol is changed. Also, ALGs only support the protocols that they understand and support has to be added separately for new protocols. Furthermore, any end-to-end security solution (such as TLS for SIP) or any hop-by-hop solution that does not include the ALG will stop ALGs from working correctly. For these reasons ALGs do not appear as an attractive solution in the long term. Although it would be possible to define an architecture that includes ALGs, it has many disadvantages. The main problems with this approach would be the added complexity due to having another component with the issues of trust, interoperability and maintenance. For these reasons including ALGs in the architecture is not desirable. Tunneling Involved sites may use a virtual private network to create a coherent address space across all involved sites. In this case, NAT devices are invisible to the communicating entities. After the initial establishment of the VPN tunnels, peers communicate as if no NATs were present. The only performance implication is the overhead for IPsec encapsulation, i.e. the per-packet overhead on the satellite link. However, beyond performance implications the use of tunneling solutions requires a trust relationship between the end-points or their sites, which raises the issues described in section IPv6 IPv6 is the new network layer standard intended to be the successor for IPv4. The number of IPv6 nodes is currently small and move to IPv6 is expected to be a long process. The adoption of VIVALDI WP 2 27-Nov-06 Page 16/50

17 Protocols IPv6 has been quickest in regions with IPv4 address shortage, Asia in particular. The transition process might also be accelerated by the US Government decision to have all the agencies transition to IPv6 by June Transitional Solutions The move to IPv6 will involve a number of different transitional solutions. The three main types of transition mechanisms are: Tunneling: The encapsulation of IPv6 packets inside other protocol packets. Most popular solutions are likely to be IPv6 over IPv4 tunneling and Ethernet bridging. Dual-stack operation: The support of both IPv4 and IPv6 by the IP nodes. Translation: The translation of IPv6 into other protocol versions by the IP nodes. The support for IPv6 in current generation of DVB-S/RCS equipment is very limited (or nonexistent). Therefore tunneling solutions are likely to be deployed where IPv6 is required. The evaluation of the different transition mechanisms is beyond the scope of this document, but the issue has been studied in detail in the ESA project: Preparation for IPv6 in Satellite Communications Security IPv6 includes mandatory support for IPsec. This coupled with the reduced need for NATs means that the use of IPsec is likely to grow in popularity, which in turn leads to the problems with middle-boxes described in section However, even though IPv6 technically removes the need for NATs, they (and their associated problems) are not likely to disappear completely. Another addition is the Cryptographically Generated Addresses (CGA). The basic idea is to form a part of the IPv6 address (usually the 64-bit interface identifier) from a cryptographic hash of the owner s public key. The address owner can then assert ownership of the address by using the corresponding private key to sign the messages. The mechanism can be used for authentication between two network elements with CGA addresses, for example in an IPsec key exchange Link Layer Issues The Multiprotocol Encapsulation (MPE) mechanism that is used for encapsulating IP packets in MPEG-2 frames does not specify the usage of IPv6 and therefore cannot be implemented on the DVB-S or DVB-RCS links. To support IPv6 on the DVB-S links, a new encapsulations protocol called Ultra Lightweight Encapsulation (ULE) has been defined by the IETF IPDVB working group. For DVB-RCS links AAL5/ATM can be used Implications The IPv6 header is 40 octets long which is twice the length of IPv4 header. This further increases the need for optimizing bandwidth usage through framing solutions and header compression mechanisms. The applicable header compression methods are the IP Header Compression specified in RFC 2507 and Robust Header Compression (ROHC) specified in RFC As the popularity of IPv6 increases it becomes more likely that the private networks behind satellite segments use IPv6. How to accommodate this depends on the transitional solution employed by the network operator. However, in practice all the network elements in the signaling or media paths need to be able to process IPv6. Furthermore, any architecture has to be able to support of mixed setting with both IPv4 and IPv6 segments. The use of IPsec is likely to increase with the adoption of IPv6. The issues arising from this need to be addressed (see section 2.2.2). 2.5 Voice Codecs Up until recently, voice communications had been coupled with two capacity measures: 4 khz for the engineers in the analogue field and 64 kbps for those in the digital domain. The former figure VIVALDI WP 2 27-Nov-06 Page 17/50

18 Protocols is based on the fact that out of the audible spectrum, 4 khz are adequate for transferring intelligibly what the speaker says, as well as some meta-information, such as the speaker s identity, his/her mood etc. The latter figure is a direct product of Nyquist s theorem and some small scale data compression based on a simple psycho-acoustic model. Since the voice content is of 4 khz value, a sampling frequency of 8 khz is needed; furthermore, a word of 13 bits leads to good quality, which in turn can easily be compressed to 8 bits based on the fact that the human sensitivity to sound shows logarithmic characteristics. This compression scheme comes in two equivalent flavors (A-law and µ-law) and has been the first step in the design of better, more efficient voice codecs. Voice codecs move into two axis. The first one takes advantage of how humans perceive sound and suppresses all parts that will not make a significant impact when they reach the human ear. These psycho-acoustic models can lead to significant savings in bandwidth, as has been shown by the success of the MPEG-2 layer 3 (mp3) audio codec. Contrary to the above, the latter axis is content agnostic and employs well known techniques from information theory, such as symbol coding. The Huffman coding scheme is a well known technique for data compression that falls within this category. Voice codec designers unfortunately face a self-conflicting goal: bandwidth requirements must be minimized, while the perceived quality must be held to high levels. Furthermore, there are secondary goals that must be honored, such as low complexity, robustness to errors/lost frames etc. Voice compression has been a field that started slowly, yet today is a very active domain. New algorithms are being produced, while older ones are being refined and optimized. The main driving force behind this intense activity is considered the success of cellular telephony, where each kbps that can be spared leads to significant boosts in the system efficiency. In the following table, the most well known voice codecs employed in practice are presented, together with their corresponding performance characteristics. Alg. Delay (ms) Bitrate (kbps) Complexity (MIPS) MOS G (lr) G (hr) G G.729A G.729D G.729E ilbc (lr) ilbc (hr) BV Speex GSM-FR GSM-HR GSM-EFR AMR For further information, see Appendix A. 2.6 Header Compression In an all-ip communications network, multimedia traffic is served by the same framework as data traffic. The transport protocol of choice in the case of VoIP is obviously RTP, which is based upon UDP and of course IP. Consequently, to the output of the voice coder a number of headers will be prepended, which are (from innermost to outermost) the RTP (12 octets), UDP (8 octets) and IP (20 octets) headers, summing up to 40 octets. VIVALDI WP 2 27-Nov-06 Page 18/50