Mohamed Nassar

Radu State

Olivier Festor

VoIP Malware: Attack Tool & Attack Scenarios

With the appearance of new Internet services like Voice over IP and IP television, malwares are in the way to update and extend their targets. In this paper, we discuss the emergence of a new generation of malwares attacking VoIP infrastructures and services. Such malwares constitute a real threat to the currently deployed VoIP architectures without strong security measures in place. We present one implemented environment that can be used to evaluate such attacks. Our "VoIP bots" support a wide set of attacks ranging from SPIT to DDoS and are tested against several VoIP platforms.

I. INTRODUCTION

Malware is the general term grouping softwares designed to infiltrate or damage a computer system without the owner's informed consent. A worm is a special type of malware that can run on its own and propagate itself to other machines. An attacker using worms and other infection mechanisms to install bots on vulnerable machines is called bot herder or bot master. Upon their bootstrap, the compromised machines or Zombies connect themselves to their master to receive command input and execute attack operations. In many scenarios, the bot master rents time on the botnet (network of bots under a common control infrastructure) to a third party which orientates them to launch Distributed Denial of Service Attacks (DDoS) and massive SPAM. Botnets pose a severe threat to today's Internet. Over the recent years, botnets have become a popular and profitable market. Since April 2007 when the government and private web servers in Estonia were the target of a large DDoS, "cyberwar" is no more science fiction.

With the growing of new Internet technologies like VoIP, it is expected that botnets will play the same malicious role. VoIP services are well exposed to such threats since they are open and have to be reachable. Values of interest within a VoIP enterprise domain include signaling and media infrastructure, accounting directories, PBX services (voice mailboxes, gateways), individual user accounts, the internal networks running other services. Attacks can be transmitted across gateways to integrated networks like mobile and traditional telephony ones. Conversely, compromising VoIP applications constitutes a bridge to bypass security mechanisms and attack internal networks. Currently, some researchers argue that SKYPEwhich is the most deployed peer to peer VoIP applicationcould be a backdoor [START_REF] Leung | Network forensic on encrypted peer-topeer voip traffics and the detection, blocking, and prioritization of Skype traffics[END_REF]. SIP (Session Initiation Protocol -RFC 3261) -which is the de-facto standard signaling protocolis a strong candidate to become the UFBP (Universal Firewall Bypass Protocol) or the universal payload injector. This is as-Fig. 1. VoIP Botnet Framework sessed after the discovery of many cross-site scripting (XSS) 1and SQL injection attacks2 due to SIP vulnerabilities. To be effective however, these vulnerabilities have to be exploited over a large distributed framework. A botnet seems perfectly adequate for this task.

In this paper, we present such a framework of VoIP bot and botnet in the context of SIP. Our bots are not equipped with propagation mechanisms so they don't represent a real threat value; rather than being used for research purposes. The overlay network of our framework is depicted in Figure 1.

The rest of the paper is organized as follow: In Section II we introduce the SIP protocol. We illustrate our bot architecture in Section III and we enumerate many attack scenarios in Section IV. We discuss implementation issues in Section V. In Section VI we debate the related work and we conclude the paper in Section VII.

II. SIP BACKGROUND

SIP is emerging as the future standard for Internet telephony signaling because of the following strength points [START_REF] Johnston | SIP: Understanding the Session Initiation Protocol, Second Edition[END_REF]:

• SIP is professionally developed by the IETF (Internet Engineering Task Force) to be scalable over Internet and utilizing Internet standards and capabilities (e.g. DNS, URL support, Wireless);

• SIP is text based with heritage from HTTP and SMTP, so it can be easily scripted, logged and inspected; • SIP has presence and instance messaging capabilities presenting a high potential to invent new applications in the future;

• SIP is well supported by the industry: it has been adopted by mobile operators in their third generation networks and services;

• SIP takes advantage of Internet security mechanisms as encryption, authentication, integrity and certificates, even if it inherits a large set of vulnerabilities from the underlying data networks from another side. Basically, SIP allows two communicating parties to set up, modify and terminate a phone call. SIP is a requestresponse transaction-based protocol. A SIP Dialog is composed of one or more transactions. The SIP addressing scheme is based on URIs (Uniform Resource Identifier) e.g. sip:user@host:port;parameters. Proxy servers help routing SIP messages. A basic call initiation scenario is depicted in Figure 2.

III. VOIP BOT ARCHITECTURE

Our bot architecture is shown in Figure 3. The stack of different protocols provides the bot with an application interface to use these protocols. The SIP stack is responsible for sending and receiving, manufacturing and parsing SIP messages. The RTP stack is responsible for coding and decoding, compressing and expanding, encapsulation and demultiplexing of media flows. Other stacks can be supported as well. For example, the STUN [START_REF] Rosenberg | STUN -Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs)[END_REF] protocol is useful to bypass NAT.

The communication agent allows the bot to exchange information and commands with the attacker. Most of the known botnets use IRC (Internet Relay Chat -RFC 1459) or peer-to-peer (P2P) networks for their control and command architecture. IRC is mainly designed for group communication and allows one-to-one communication (private discussion) as well. A channel (or a room) is supported by multiple servers building an application level spanning tree among them and relaying IRC messages between room visitors. P2P refers to a class of systems and applications that employ distributed resources to perform a function in a decentralized manner [START_REF] Milojicic | Peer-to-Peer computing[END_REF]. Bot masters moved towards P2P networks because of their high degree of anonymity and privacy. For example in Freenet [START_REF] Clarke | Freenet: a distributed anonymous information storage and retrieval system[END_REF], when a peer sends a message, the peer identity is rewritten as the message is relayed among a chain of peers. Another example is the Lucent Personalized Web Assistant (LPWA) [START_REF] Gabber | Consistent, yet anonymous, web access with LPWA[END_REF] which acts as a proxy server and allows consistent untraceable aliases for clients from servers. A LPWA client opens an account and is recognized upon returning to this account while his true identity is hidden from the server. The Slapper worm [START_REF] Arce | An analysis of the slapper worm[END_REF] which builds a P2P overlay network has advanced features like reliable end to end message delivery, coping with network partitions and reshaping, and anonymous message delivery.

The data retrieval component allows the bot to retrieve different kinds of data (e.g. list of VoIP extensions (URIs), advertising audio files, list of default passwords to try, SIP messages to shoot, etc ... ) using a data communication protocol (e.g. FTP or HTTP Client). Web servers using a dynamic DNS server (i.e. the DNS changes the IP corresponding to the web server over time) are preferred to avoid being tracked.

The exploit retrieval component allows the bot to retrieve specific exploits against vulnerabilities and software flaws in VoIP products. The damage of such exploits ranges from remote DoS on the target (similar to a ping of death) to remote eavesdropping 3 . Cross script attacks and data base injection vectors can be carried by malformed SIP messages to attack embedded web servers in the targeted products and databases querying theses messages for accounting and statistics. Some exploits are stateless (consisting on shooting one SIP message) but others are stateful (based on the state machine of the target). Stateful attacks are formed by a series of messages where the content and the sending time of each message depends from the previous sent message and the corresponding reaction or response of the target to that message. For example, a stateful remote DoS on a Cisco 7940 SIP Phone4 has been discovered using the KIF stateful fuzzer [START_REF] Abdelnur | KiF: a stateful SIP fuzzer[END_REF]. The bot master uses some format to describe stateful exploits and upload them to a server where they can be found by the bot. The bot parses the exploit description and builds a local state machine to perform the attack.

The encryption engine enables the bot to create digest authentication from credentials when authentication is required in the process of an attack or an attempt of registration. Typical use of this engine is password cracking and CPUbased flooding against the target's authentication procedure.

The SIP state machine manages the operations of the bot with respect to the commands issued by the attacker. The mission of the bot as set by the attacker drives its behavior upon occurrence of SIP events (i.e. receiving a SIP request RequestEvent or a SIP response ResponseEvent) and TimeOut events. The transition from a state to another is constrained by predicates on a set of global and local variables. For example, when receiving a 200 OK message that belongs to some existing dialog, the bot's next step is based on the Cseq method (which determines the method the 200 OK is in response for) and on the global attack parameters (mission, target IP, target SIP port ...).

Based on this architecture, different attack scenarios are possible as detailed in the next section.

IV. ATTACK SCENARIOS

SPIT

SPIT or SPAM over Internet Telephony refers to unsolicited calls intended for advertising or social engineering. Automated calls have already been used a couple of times like for example in the 2008 American presidential election. 5 In a SPIT scenario, the attacker asks the bot to deliver an audio record to one or more destination URI. Similarly to e-mails being used in SPAM, URIs can be collected by web crawlers or in result to a VoIP domain enumeration. The bot manufactures an INVITE request carrying an SDP body, giving arguments like the destination URI, its IP address, its RTP port, the codec to be used and other media attributes. When the call is answered, the bot retrieves the audio record from the location as supplied by the attacker (e.g. from a URL or a local file in the compromised machine) and stream it to the callee.

Flooding

Flooding attacks target the signaling plane elements (e.g. proxy, gateway, etc.) with the objective to take them down or to limit their quality, reliability and availability. Flooding attacks can be categorized regarding their destination and their strategy. Whether the attack is destined to a valid URI in the target domain, a non existent URI in the target domain, a URI with an invalid domain or IP address, an invalid URI in another domain, or a valid URI in another domain, different damages are produced. The strategy is related to the nature of messages used during the attack: legitimate, malformed (carrying some exploits), invalid (non compliant to the SIP standard), and spoofed SIP messages (spoofed From and Contact header). Other attacks are targeted against the authentication process by using messages carrying valid nonces and requiring the target to compute digests which overwhelm its CPU capacity 5 http://edition.cnn.com/2008/POLITICS/10/23/robo. calls/index.html [START_REF] Luo | CPU-based DoS attacks against SIP servers[END_REF]. In a flooding scenario, the bot starts a thread which sends continuously request messages (INVITE or REGISTER) given the destination, the duration, the timing and the strategy as supplied by the attacker. Distributed flooding attacks can be easily organized by involving and synchronizing a number of bots.

Enumeration

Enumeration is the process of discovering valid SIP extensions (or URIs) in a SIP domain. Enumeration is usually preceded by a port scan to identify existent SIP proxies and user agents. The standard port used by SIP is 5060. The first step of enumeration is to identify if the SIP service is running on that port and what type and version of server is there. This is done by sending a simple OPTIONS message and interpreting its response. The searched information is usually found in the Server or the User-Agent header.

In an enumeration scenario, the bot retrieves a list of extensions/URIs from a specified location, then it probes them using INVITE, REGISTER or OPTIONS messages. OPTIONS enumeration is preferable since it is stealthier (it does not ring the phones, nor raise suspicions about the registration process). The bot has to match each request with the response it triggered based on the call-ID and/or transaction identifier. It analyzes the response to determine 1) if the dialed extension exists and is registered to the target, 2) exists and is temporarily unavailable, or 3) doesn't exist at all. The interpretation of responses depends on the target's type and version. For example, if the target carries an OpenSER sip proxy (version 1.1.1-notls) fingerprint, the response to an OPTIONS message destined to an extension is interpreted as follows: a "200 OK" means that the extension exists and it is registered, a "404 NOT FOUND" means that the extension is invalid, but a received "100 TRYING" before a final error response means that the extension is valid but not available for the moment.

Cracking

Remote brute force password cracking consists in repeatedly trying guesses for an account's password using INVITE or REGISTER requests. Unchanged default passwords of deployed VoIP platforms make them strongly vulnerable to such attacks. In a cracking scenario, the bot has to discover the registration or the voicemail password for a user name. Note that the user name used in the authentication process is not always the same as the one in the user's URI (which can be obtained by enumeration). The attacker has to know the user name or the voice mail extension before going to a brute force attack. The bot retrieves a list of default passwords corresponding to the target platform. For each guess, it sends a first REGISTER (or INVITE) asking for a challenge. An error response from the target gives him back a nonce. The bot calls its encryption engine to build a new request containing credentials based on the challenge and the temporal nonce. The target's final response decides if the guess was right or not.

Fingerprinting

Remote fingerprinting allows the attacker to identify the type and the version of the SIP target platform. The simplest method consists on sending an OPTIONS message and extraction of the manufacturer string from its response. This process can be fooled if the manufacturer string was intentionally falsified. Smarter fingerprinting schemes as described in [START_REF] Yan | Incorporating active fingerprinting into SPIT prevention systems[END_REF] or in [START_REF] Abdelnur | Advanced network fingerprinting[END_REF] can be supported as well. In a fingerprinting scenario, the bot is asked to fingerprint one or range of SIP extensions. The bot has to send back its results to the attacker or -in order to not disclose him-to put them in a specified location where he can access them later.

Exploiting Specific Vulnerabilities

In an exploit attack scenario, the bot is either given the platform of the target or has to discover it by itself (by fingerprinting). The bot connects to an exploit server and retrieves a set of possible exploits corresponding to the target fingerprint. Each exploit should be tagged with some meta-data so the bot can choose the exploit which meets the attacker's aim. In case of stateful attacks, the bot builds a local attack state machine to execute the attack given local and remote parameters as reported by the attacker.

Interception and Modification

These attacks require an access to the internal network in the VoIP domain. If the attacker succeeds to compromise a machine inside the VoIP domain, many interception, eavesdropping, modification and man in the middle attacks are possible using ARP poisoning techniques. It is not just media and signaling traffic which is targeted, but also supporting protocols like DNS, DHCP, ICMP, and TFTP. In one scenario, if the bot knows the IP address of a phone and the IP address of the outbound SIP proxy, it can fool the phone into thinking that it is the proxy (by sending an RTP packet with the IP address of the proxy and the MAC address of the bot) and vice versa. Like that, the bot plays an MITM role by watching and forwarding messages between the two entities. Because typically no data integrity is deployed in current SIP implementations, the MITM can change an INVITE request before forwarding it. For example, it can redirect the call towards an IVR (Interaction Voice Response) to do Vishing (VoIP Phishing) scam.

Fraudulent Calls

The increasing financial and informational value of VoIP will attract more Internet hackers into attacking VoIP middlewares, take control over them and execute remote code. Future scenarios are to ask the compromised phone to dial an overtaxed number (similarly to the modem-based dialers in the near past) or to record all calls. Terms like "VoIP dialer" or "VoIP logger" are going to appear in the near future. A one million dollar idea arises immediately: let a large number of victims (one million) dial an overtaxed number resulting on only one additional dollar on the monthly bill of each caller. Most of the victims will not complain about.

Propagation

Propagation models of worms exploiting VoIP and mobile vulnerabilities and using directories in the compromised platforms to spread up are discussed in [START_REF] Fleizach | Can you infect me now?: malware propagation in mobile phone networks[END_REF]. By its fingerprinting, exploit retrieving and executing capabilities, our bot constitutes a basis for such a worm using an algorithm like the following one:

Forall uri in PhoneBook fingerprint = Bot.Fingerprint(uri); exploit = Bot. retrieve_exploit(fingerprint); Bot.send_exploit (exploit, uri); Bot.upload_version(uri); End_Forall

V. IMPLEMENTATION AND EXPERIMENTS

We implemented a proof-of-concept worm-free IRC bot based on SIP and RTP using the JAVA language. For SIP we used the Jain SIP library [START_REF] O'doherty | JAIN SIP Tutorial: Serving the developer community[END_REF]; for RTP we used the JMF library [START_REF]Java Media Framework API Guide[END_REF] and for IRC we used the PircBot library 6 . Our code is available under an open source license [START_REF]The VoIP Bot project[END_REF]. The bot is currently able to perform DoS, SPIT, SCAN, CRAK, FINGEPRINT, SHOOT, EXPLOIT and REGISTER functionalities. Moreover, the bot master is able to perform a collective suicide of all the bots. The screenshot of Figure 4 shows the IRC client (Xchat7 ) of the bot master upon the connection of one bot.

Deployed on an Intel Pentium 4 CPU 3.40GHz and 2G RAM memory machine running a Linux kernel 2.6.18-1, the bot is able to send around 10,000 messages per second with different call-Ids. The call-ID seed is the number of the bot as set by the attacker. Messages from different bots have different Call-Ids. We used a similar machine with 3G RAM memory to be the target (hosting Asterisk and OpenSER 8 ). Using legitimate messages and non existent URI destination, one bot is able to raise the target CPU to 100% in case of both Asterisk and OpenSER, and 2 bots are able to saturate the bandwidth of a LAN connection (about 12 MBytes/s). Asterisk consumes 25% of the host system memory (i.e. 750 MB) after 100 seconds of attack (i.e. 0.25% raise in memory/s), while OpenSER memory consumption depends on the number of child processes as configured by the administrator (Each child reserves a 33 MB memory space). OpenSER integrates a defense module against flooding attacks called PIKE. PIKE blocks an IP address for a period p after receiving a number T h coming from that address during a prefixed sampling period s.

In order to perform a flooding against a PIKE-protected OpenSER, a number of bots should be synchronized. The first step is to discover the PIKE parameters. We propose the scheme of Figures 5 and6.

We need only 1 + p/s bots to continuously deny the service at the proxy. A first bot starts the attack and is blocked after the first sampling period, the other p/s bots, each by turn, assure the attack until the first bot is unblocked again. For sake of simplicity, a scheme using only three bots is depicted in Figure 7.

Several flooding mitigation mechanisms are currently proposed ( [START_REF] Reynolds | Secure IP Telephony using Multi-layered Protection[END_REF], [START_REF] Chen | Detecting DoS attacks on SIP systems[END_REF], [START_REF] Ehlert | Specification-based denial-of-service detection for sip voice-over-ip networks[END_REF], [START_REF] Sengar | Detecting VoIP Floods using the Hellinger Distance[END_REF]). However, our bots are able to bypass such mechanisms at least from a theoretical point of 8 The project has evolved in two parallel projects OpenSIPS and Kamailio view. Threshold-based systems can be deceived by fine-tuned the flooding rates. Learning-based systems can be "poisoned" by inserting specially crafted data points so that the model of "normality" drifts into the direction of an attack vector [START_REF] Nelson | Bounding an attack's complexity for a simple learning model[END_REF].

VI. RELATED WORKS

Computer viruses and malwares [START_REF] Aycock | Computer Viruses and Malware (Advances in Information Security)[END_REF] pose a serious threat to the computer network infrastructures of our society. Logic bombs, Trojan horses, backdoors, spywares and worms should be studied for their different aspects to enhance our protection, intrusion detection and prevention. With the emergence of VoIP, many vulnerabilities have been discovered through security testing of SIP implementations [START_REF] Wieser | Security testing of sip implementations[END_REF] that can be exploited by such malwares.

Appropriate security approaches have been well investigated to increase the immunity of this new technology. An early warning system has been published in [START_REF] Nassar | Voip honeypot architecture[END_REF]. A holistic intrusion detection solution based on event and alert correlation is described in [START_REF] Nassar | Holistic voip intrusion detection and prevention system[END_REF]. This paper uses a different approach since it adopts the attacker's perspective and therefore provides an assessment tool to feedback currently deployed security architectures.

A number of similar tools are already available 9 . SIPp 10 is a SIP traffic generator providing basic call flow scenarios while allowing more complex scenarios to be described using XML. Sipsak 11 is a command line tool that can be used for simple SIP tests. C07-SIP 12 is a byproduct of the PROTOS project providing a group of tests against SIP parsers. SIPSendFun 13 is a set of php scripts to send spoofed SIP messages. Skora 14 wrote several Perl scripts demonstrating different attacks such as BYE and CANCEL attacks. Our VoIP bot is novel with respect to these tools because of its numerous functionalities and the ability it gives to manage distributed attacks.

VII. CONCLUSION

In this paper, we presented a framework of VoIP-specific malware using bots installed on compromised machines and we showed how different attack scenarios can be supported by such a framework. We presented a prototype implementation that we experimented against VoIP servers and showed how cooperating bots can be synchronized to bypass flooding defense mechanisms. Future works include the investigation of efficient and scalable defense mechanisms against VoIP malwares and distributed denial of service attacks.

Fig. 2 .Fig. 3 .

 23 Fig. 2. SIP Call Establishment

Fig. 4 .

 4 Fig. 4. Screen view of the bot master

Fig. 5 .Fig. 7 .

 57 Fig. 5. Discovering the s Parameter

http://seclists.org/fulldisclosure/2007/Oct/0174. html

http://voipsa.org/pipermail/voipsec_voipsa.org/ 2007-October/002466.html

http://www.voipsa.org/pipermail/voipsec_voipsa. org/2007-August/002424.html

http://www.voipsa.org/pipermail/voipsec_voipsa. org/2007-August/002422.html

http://www.jibble.org/javadocs/pircbot/index.html

http://www.xchat.org/

http://www.voipsa.org/Resources/tools.php

http://sipp.sourceforge.net/


Abdelkader Lahmadi
email: abdelkader.lahmadi@loria.fr

Olivier Festor
email: olivier.festor@loria.fr

SecSip: A Stateful Firewall for SIP-based Networks

Keywords: SIP, VoIP, Security, Firewall

SIP-based networks are becoming the de-facto standard for voice, video and instant messaging services. Being exposed to many threats while playing an major role in the operation of essential services, the need for dedicated security management approaches is rapidly increasing. In this paper we present an original security management approach based on a specific vulnerability aware SIP stateful firewall. Through known attack descriptions, we illustrate the power of the configuration language of the firewall which uses the capability to specify stateful objects that track data from multiple SIP elements within their lifetime. We demonstrate through measurements on a real implementation of the firewall its efficiency and performance.

I. INTRODUCTION

The Session Initiation Protocol (SIP) [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF] has established itself among the most important Internet protocols. It is designed to establish, modify, and terminate a session of application services. SIP is currently used in many popular services such as Voice over IP (VoIP), Instant Message (IM), Presence Service and even File Transfer. In the near future, it is expected that SIP will play an essential role in the nextgeneration telephony networks. Traditional telephony based on PSTN networks was well secured, since it is based on close environments, where calls are carried by dedicated lines and managed by operator-owned devices. To carry calls, SIP-based service architectures use the Internet and expose themselves to all kinds of attacks ranging from Distributed Denial of Service to toll-fraud, vishing or eavesdropping [START_REF] Voipsa | VOIPSEC mailing list on VoIP security issues[END_REF].

Offering an efficient security management framework for SIP infrastructures is becoming a challenge to the success and the wide deployment of VoIP services. We believe that one essential building block of such a security management framework is a dedicated SIP firewall. It must be dedicated because the use of generic IP-based firewalls are inefficient to address and mitigate most attacks against SIP services. IPlevel firewalls actually have two major drawbacks :

• they do not address the SIP protocol semantics. The SIP protocol messages are text based, and the various fields of a message are exploited to carry out different kinds of attacks. For example, an attacker can easily employ the SIP BYE request to tear down a session, without any violation of an IP level firewall rule.

• they do not allow to consider per device specific vulnerabilities. Different devices have different vulnerabilities.

Being able to protect them in an efficient way requires both the knowledge of the devices and a precise specification of the specific vulnerabilities. This is not provided by IP level firewalls.

To remedy these shortcomings, we have designed and implemented a SIP defense system that does support an indepth message analysis together with a SIP protocol state tracking function. It is also required that the designed SIP defense system satisfies the following properties: it must be fast, accurate, induce low overhead and be safe. Our approach to this problem is an application level firewall implemented as a "bump in the wire" device: it intercepts SIP messages, evaluates their safety before forwarding them to their destinations. If the message or the transaction to which a message belongs is unsafe, our system SecSip blocks it, thus protecting the device from the threat.

Our approach to protect SIP networks from diverse vulnerabilities is depicted in Figure I. The fuzzing module allows the discovering of per device SIP vulnerabilities in the network. It then updates the vulnerability knowledge base that shares with the firewall named SecSip. In a second stage, SecSip translates this vulnerability into defense rules to protect devices from the threat.

The SecSip environment combines two key techniques. First, it uses a rule-based engine to execute rules that model SIP vulnerabilities. These rules are executed against SIP protocol messages, transactions and dialogs. Second, it monitors the SIP protocol to enable stateful semantic tracking through stateful objects claimed by vulnerabilities defense rules. Hence, rules that model SIP vulnerabilities are based on both protocol behaviour and attack signatures.

The system can operate either as a service deployed in the network infrastructure or as a client-side protection tool. While each has its merits as we will explain later, we focus in this paper on the network service deployment model on which performance is a key issue.

The remainder of the paper is organised as follows. Section II gives an overview on SIP vulnerabilities as well as on achievements in the area of firewalls and the associated specification languages. Then, we discuss the design space of a SIP defense system in section III. The SecSip runtime and language are described in section IV. Their evaluation is performed in section V. Finally, we conclude on the contribution and outline some future work in section VI.

II. RELATED WORK

A. SIP exploits and vulnerabilities

VoIP networks are subject to many types of attacks. A rich set of existing work [START_REF] Zhang | Billing attacks on SIPbased VoIP systems[END_REF], [START_REF] Abdelnur | Assessing the security of VoIP Services[END_REF], [START_REF] Chen | Detecting dos attacks on sip systems[END_REF], [START_REF] Geneiatakis | Survey of security vulnerabilities in session initiation protocol[END_REF] has addressed SIP vulnerabilities and exploits to examine how they can be efficiently used to compromise the reliability and trustworthiness of SIP-based VoIP systems. In [START_REF] Zhang | Billing attacks on SIPbased VoIP systems[END_REF], authors focus on billing attacks The SIP protocol is also exposed to traditional DoS attacks [START_REF] Habib | Detecting service violations and dos attacks[END_REF] like network bandwidth and OS/firmware attacks to exhaust available resources. Furthermore, SIP comes with its own specific DoS attacks. These attacks are illustrated in [START_REF] Chen | Detecting dos attacks on sip systems[END_REF] where the author presents stateful solutions based on finite-state machines for SIP transactions to detect them. These two contributions, have mainly illustrated SIP exploits rather than the specification of the vulnerability that allows such attacks. In [START_REF] Geneiatakis | Survey of security vulnerabilities in session initiation protocol[END_REF], authors enumerate SIP attacks and identify the vulnerabilities that causes them. The lack of authentication is for example, the major cause of signalling attacks like BYE, CANCEL and Re-INVITE.

B. Application Level Firewalls and their language

There is a lot of literature on application level firewalls and intrusion detection systems [START_REF] Rustic | ModSecurity Reference Manual v2.5.5[END_REF], [START_REF] Snort | The Open Source Network Intrusion Detection System[END_REF], [START_REF] Paxson | Bro: a system for detecting network intruders in real-time[END_REF] devoted to common protocols like HTTP, SMTP, etc. The SecSip language is inspired by the ModSecurity [START_REF] Rustic | ModSecurity Reference Manual v2.5.5[END_REF] approach which allows HTTP traffic monitoring and filtering, with real-time intrusion detection. Snort and Hogwash [START_REF] Snort | The Open Source Network Intrusion Detection System[END_REF] are other intrusion detection systems that target mainly the network level. They recently started to support some SIP exploits such as INVITE flooding attacks in a very limited way.

VoIP firewalls and more specifically those addressing the defense of the SIP protocol, are still in early stages and there is only limited work published [START_REF] Fielder | VoIP Defender: Highly scalable sip-based security architecture[END_REF], [START_REF] Wu | Scidive: A stateful and cross protocol intrusion detection architecture for voice-over-ip environments[END_REF], [START_REF] Sengar | Voip intrusion detection through interacting protocol state machines[END_REF], [START_REF] Chen | Detecting dos attacks on sip systems[END_REF]. The authors of [START_REF] Wu | Scidive: A stateful and cross protocol intrusion detection architecture for voice-over-ip environments[END_REF] propose a solution for stateful intrusion detection called SCIDIVE. The system relies on a stateful engine that determines the current state from multiple packets involved in the same session. The system also uses cross-protocol detection to verify the consistency between two protocols involved in the same VoIP session, mainly SIP and RTP. The goal of their work are similar to SecSip and shares the stateful feature.

VoIP defender [START_REF] Fielder | VoIP Defender: Highly scalable sip-based security architecture[END_REF] is a SIP-based security architecture designed to monitor, detect, analyse and counter attack. The nature of the employed detection scheme (stateful or stateless) is not clearly defined in the publication. In addition, no details are provided in about the language used to build defense rules and how it can be used for SIP.

Our work is complementary to existing SIP vulnerability and exploit discovery tools. SecSIP uses the output from vulnerability discovery systems like KIF [START_REF] Abdelnur | Kif: A stateful sip fuzzer[END_REF] to close the defense loop by enforcing security policies against attacks exploiting these vulnerabilities. We also take profit from existing intensive literature dedicated to application level firewalls, to instantiate the system.

III. SIP DEFENSE DESIGN SPACE

The SIP protocol is transaction-based. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF]. Attackers usually use malformed SIP messages within a transaction to compromise a SIP entity. They also employ legitimate messages to attack a SIP infrastructure (e.g. redirect calls, end a session, cancel invitation and update session parameters). Therefore, a SIP defense system must be able to defend a SIP infrastructure against both malicious (but legitimate) transactions and malformed messages.

The underlying approaches we do consider fall into two categories: proactive and reactive. Proactive defense prevents malicious transactions and malformed packets from reaching the intended victim. A common proactive approach to identify malicious behaviour is to record interacting SIP states, objects and messages. In this case, the approach is stateful. A proactive approach may operate anywhere in the network perimeter. However, if located at the victim side such an approach becomes useless, since a denial of service attack damage still occurrs while the defense system tries to prevent it. A reactive defense approach generates an inoculation in response to an attack. This response will protect SIP devices. An example of such inoculation is to deploy patches to eliminate a bug exploited by the attacker. There are many additional examples of reactive defense approaches including intrusion prevention systems, statistical analysis, attack signatures, reactive address blacklisting, etc. These solutions attempt to recognise postattacks and take a counter-measure later.

The effectiveness of each approach depends on the type of attack. A proactive approach is suitable to cover compromise attacks like toll fraud, unwanted calls and messages, . . . [START_REF] Geneiatakis | Survey of security vulnerabilities in session initiation protocol[END_REF]. This type of attack needs very few SIP messages to cause damage. The proactive approach needs to identify malicious SIP objects and prevent them from reaching the victim. The defense strategy can be exercised either in the network perimeter or at the victims' location. Denial of service attacks keep the victim unaffected if applied at the network level rather than on end-systems.

The design space of SIP defense solutions is summarised in Table I. We observe that a proactive SIP defense in network is more efficient than others, but also more challenging to build. It needs high assumptions about safety and complexity. However it is more efficient to protect SIP-based networks.

IV. ARCHITECTURE AND COMPONENTS

Our approach to defend SIP-based networks relies on the insertion of a proactive point of defense between a SIP-based network of devices (servers, proxies, user agents) and the open Internet. Therefore, all SIP traffic is inspected and analysed before it is forwarded to these devices. Figure 2 Each component is described in details in the following sections.

a) Input/Output Layer: The input and output features provide the service able to capture, inject, send and receive SIP packets from and to the network. They are configured according to the deployment mode of the firewall. In an in-line mode, the capture feature is active on the incoming interface (from the Internet). If the packet is safe, the firewall, will inject it, using raw sockets, on the SIP network while keeping the same source and destination addresses. Features to accept TCP connections and UDP traffic for further deployment modes is also supported. b) SIP Packet Handler: Intercepted packets are moved to the SIP Packet parser module. The main function of this module is to extract different fields within a SIP message. Each field within a SIP message is the composition of a key that represents the field name as defined by the SIP BNF [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF] and its respective value. While parsing a sip message, the parser builds a data tree that represents the SIP packet. Each node of the parse tree represents a SIP field defined by a numerical identifier. The parse tree node also contains useful information about the field such as type, length, starting and ending offsets within the SIP packet, . . . This information is used later by the stateful inspection layer to check the various SIP fields.

c) Rules Compiler and Optimizer: The core of the Sec-Sip firewall is its rule engine. It has the critical task to process defense rules against SIP messages and transactions. When initializing, the rule engine starts loading and parsing rules to identify different targets, operations and actions within each rule. Each rule is transformed into a specification. A specification is a data structure that holds the names and values of each object of the rule. Then, rule specifications are compiled to identify the targeted fields from the parse tree, the pre-registered operations and actions.

During rule parsing, the engine creates stateful objects to store SIP dialogs related data. Each defined rule set is attached to a SIP transaction state machine type as specified in [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF]. The rules engine is thus able to store defense rules according to their transaction state machine types. It uses a hash table to store rules where each entry is defined by the rule's transaction type. After being stored, an optimization component traverses the rules hash table and starts scheduling their execution. This component specifies how rules will be executed when a SIP message arrives to the firewall. Rules are ordered in a scheduling list according to their referenced objects. At the top of the list are the rules that declare objects and acts on their values. At the bottom of the list are rules that have many matches and have disruptive actions on a SIP message. In the example depicted in Figure 3, we have two SecSip rules. The first rule declares and updates a counter that counts the number of received INVITE messages. The values 10 and 60 denote that we need to decrease the counter value by 10 each 60 seconds. The second rule will drop SIP messages when the counter is greater than 80.

Even, if the rules are reversed in the configuration files and the administrator writes R2 before R1. The SecSip optimization component will schedule R1 followed by R2 in its scheduling list since R2 references the variable rate that is declared and updated by R1.

d) Stateful Inspection Layer:

The inspection layer executes the appropriate rules on each received SIP packet without any buffering, even if the SIP message is incomplete.

Figure 4 shows how a SIP message traverses the SecSip runtime and gets analyzed. First a SIP message is captured from the network interface by the IO layer and delivered to the parsing module. Then, the packet is parsed according the pre-registered fields of the SIP parse tree that follows the SIP format specification. These parsed fields will fill the parse tree Where each container has a key that is a SIP dialog identifier defined by the triple (Call ID, To Tag, From Tag). Based on the current state of the SIP session and the direction of the packet, the corresponding matching set of rules is invoked to be processed. Rule processing will take considered actions that may lead to a decision of forwarding the packet to its destination or to drop it.

A. The SecSip language

The main feature of the stateful firewall is its language designed to model SIP vulnerabilities. We here define a SIP vulnerability as a flaw in one of its objects where execution may go wrong and violate the intended semantics of the SIP protocol (i.e., the protocol state machine and message formats).

This leads to the following definitions :

Definition 1: S is the set of all possible object states in a SIP interaction.

Definition 2: A SIP vulnerability is a tuple v = (f, P ), where f is a state transition function that defines postconditions, and P ⊆ S is a set of SIP objects states satisfying pre-conditions.

A vulnerability contains a set P ⊆ S, where P defines the required SIP object state for the vulnerability to exist, also known as pre-condition. The post-condition function f expresses a transition from one SIP object state to another. Definition 3: A SecSip rule is modeled as a tuple i = (v, S ′ , A), where v is a vulnerability, S ′ is a SIP state defined by S ′ = f v (P v ) and f v is the vulnerability function associated to v.

In this setting if S ′ is detected by the post-condition function f v , the SecSip runtime triggers the set of actions A, before enabling f v to occur on the real network.

A SIP object contains properties that describe network entities and logical relationships. Logical relationship describes communication and trust patterns between SIP network entities. We identify three types of entities for which SIP objects are necessary : messages and their fields, transactions and dialogs. In the SecSip defense language, a user-defined SIP object follows the dot notation. It's syntax form is as follows:

Object::= ObjectIdentifier [*('.' ObjectIdentifier)]

A user-define SIP object describes the SIP protocol properties over its lifetime. In the SecSip language, we define several kinds of SIP objects with different lifetimes and scopes. Table II summarizes the SIP objects defined by the SecSip language. These objects are employed by the user-defined rules to detect SIP vulnerabilities.

Stateful objects are defined using the hold instruction. A stateful object has predefined properties when it is created.

The objects related to a SIP message track the values of its fields. These objects are stateless since they are re-initialized with each message. By default the SecSip runtime provides a set of stateless objects mapped to the parsed fields of a SIP message. These objects are defined by the FIELDS or BODY identifiers mapped to the header or the body parts of a SIP message. The identifier is followed by the name of the object that follows a dot notation. For example, to access the From specific field of a SIP message, we use: F IELDS : sip.f rom.

Transaction related objects are used to record data across the lifetime of a transaction, spanning a request and multiple responses. Within the SecSip runtime, a transaction is identified by the combination of the BranchID and the CSeq command value.

A dialog is defined by the Call-ID together with the From IP and To IP. It spans multiple transactions. Objects related to a dialog are stateful and provide data across the lifetime of the dialog. For example, to initialize a stateful object that tracks the values of the From field in all messages within a dialog, we use the following:

hold:FROM_LIST=set[MESSAGE_HEADERS:sip.from]
In the above example, the statement defines a stateful object F ROM LIST that holds the values of the stateless object sip.form from the message-object FIELDS over all messages within a dialog. We note, that F ROM LIST is a user defined object that will hold stateful data. However, the FIELDS:sip.form is a predefined object in the SecSip language.

To illustrate the ease of use of the SecSip language, we present two real attacks against SIP protocol on which we will illustrate the defense specification.

e) DoS attacks detection: A well known example of DoS attack against the SIP protocol is the BYE-attack [START_REF] Geneiatakis | Survey of security vulnerabilities in session initiation protocol[END_REF]. In this scenario, the aim of the attacker is to teardown a VoIP session between two UAs. To this end, it sends a faked BYE message to one UA on behalf of the other UA. When the targeted UA receives the fake BYE message, it prematurely tears down the established call assuming that is requested by the partner UA. This attack is illustrated in Figure 5.

The detection of this attack, needs to track stateful objects within a SIP session 1 . In this scenario, we start with recording the values of the From field used by SIP messages within a session in the user defined stateful object f rom list. We also track the IP addresses in the messages and record them under the main stateful object from list with a child object ip addr . The two stateful objects have a list as container since we need to track all values. In the SecSip language, the different objects are expressed by the rules depicted in the Figure 6.

When a request of type BYE is seen by SecSip, its From field is checked against the data store object f rom list. If 1 i.e. a sequence of multiple SIP messages exchanged between two or more SIP entities. its value is not in the list then the message is dropped by the SecSip runtime. The set of rules that detects this attack is depicted in Figure 7.

f) INVITE request flooding attack detection: Another type of DoS attack, used to illustrate the SecSip language, is the flooding attack that targets either SIP phones or proxies and servers. The objective of the attack is to exhaust resources (CPU, memory, bandwidth) of the targeted device by generating multiple calls within a short duration of time.

In [START_REF] Chen | Detecting dos attacks on sip systems[END_REF], the author proposes a method based on thresholds to detect this kind of attacks. He considers that an upper bound on the number of allowed transactions per node should be defined and enforced to defend SIP devices from flooding attacks. This defense strategy can be easily specified in and enforced by our framework as depicted in Figure 8.

The illustrated rule set tracks INVITE attempts within each monitored transaction expressed by the TR object and its count sub-object. In the first rule, we declare the stateful object that will hold transactions identified by the branch parameter from the Via field. The second rule declares a counter and updates it every time an Invite message is seen. If the screened traffic crosses the threshold of more than 15 attempts in 1 minute, SecSip will drop subsequent transactions.

V. FRAMEWORK EVALUATION

When we designed and built the SecSip runtime, we had several goals, the most important one being efficiency in terms of both safety and performance.

A. SecSip safety

Since SecSip is designed to ensure SIP devices security in an adversarial environment, it is imperative that it does not introduces new source of failure and vulnerabilities. Given the fact that we implemented the environment in C, we employed several techniques to make it safe. They are listed below.

1) Buffering optimization: The stateful nature of SecSip, exposes it to state-holding attacks [START_REF] Handley | Network intrusion detection: evasion, traffic normalization, and end-to-end protocol semantics[END_REF]. Such attacks may occur when buffering data from parsed SIP message. To prevent the environment from such attacks, each stateful object used SecSip "FIELDS:sip.method" "!ˆBYE$" hold:from_list=set[FIELDS:sip.from] SecSipRule "FIELDS:sip.method" "ˆBYE$" && "FIELDS:sip.from" "!@in from_list" drop Fig. 7. SecSip rules to detect the BYE attack and drop the malicious message.

SecSipaction hold:tr=set[FIELDS:sip.via.branch] SecSip FIELDS:sip.method "ˆINVITE$" declare:tr.count=counter [10;60] SecSip tr.count "@gt 15" drop by SecSip rules is hold within a timed container that when expired, removes the object and blocks further traffic on the object. The lifetime of the container is adjusted according the scope of the object (message, transaction or session). Furthermore, each buffered data is normalized to a maximum size specified by the user from SecSip rules. For example, the following SecSip rule normalizes a buffered SIP URI object to a maximum size of 1024 bytes. Parsers do strictly limit the length of data at runtime to avoid buffer overflows.

SecSip FIELDS:sip.uri "@normalize 1024"

2) SIP parser optimization: In the SecSip runtime, we employed a lazy parser to optimize the time consumed by the parsing of a SIP message. After loading the rules, the SecSip runtime computes which objects of a SIP message are referenced by the user defined rules. Therefore, only those objects will be defined in the parse tree generated by the SIP parser module.

B. SecSip performance

SIP dialogs and transactions are delay sensitive. Therefore a SIP firewall needs low overhead when inspecting packets before forwarding them to the target devices. To assess the performance of our system, we start by looking at how SecSip performs with a stressing SIP traffic and what latency it adds while inspecting this traffic.

The testing environment is composed of three hosts with a core 2 CPU cadenced at 2.93GHZ with 2 GB of RAM. The first host plays the role of the SIP packet injector where we have used the SIPp tool [START_REF] Gayraud | SIPp Reference Manual[END_REF]. This tool is dedicated to sip performance testing and provides a flooding feature capable to generate INVITE SIP messages at higher rates. The second host, where SecSip is running, is deployed as as a bump in the wire device between the attacking host where the INVITE messages injector is deployed and the targeted host. The three hosts are connected through a 100 Mbits switched Ethernet. SecSip performs all necessary functions including (1) capturing the incoming SIP traffic on the specified interface (2) extracting SIP fields, (3) Comparing extracted fields with the available rules of the current transaction phase, and forwarding the SIP messages to the outgoing interface towards SIP devices. Our metrics are the delay introduced by the SecSip runtime while processing a SIP message and its throughput in terms of messages/second. To measure the delay introduced by SecSip, a Tcpdump instance did continuously run on the incoming-traffic interface to capture incoming SIP INVITE messages from the attacker and another Tcpdump instance was operational on the egress interface to capture the same messages after having been processed by the SecSip runtime. We analysed captured data using a developed Perl scripts to compute the throughput and processing delays of SecSip.

In this work, we evaluated the performance of SecSip with two scenarios:

• In the first one, we only vary the rate of INVITE messages from 10 to 1000 messages/second by a step of 10. Each value is maintained by the SIPp tool one minute and then it is incremented by 10. SecSip is deployed without any rule, only messages parsing overhead is measured.

• In the second one, we maintained the INVITE message rate at a level of 60 messages per second. We then vary for each test the number of rules from 1 to 650 by a step of 10. Herein, our goad is to measure the overhead of the rules processing module. load towards SecSip. In figure 9, we show the mean delay introduced by the SecSip runtime while processing a varying number of injected INVITE messages towards the SIP device. We observe that the delay stays below 1 ms, even with an injection rate close to 500 messages/second.

The SecSip throughput is depicted in Figure 10 with respect to an injection rate from the source host. We observe that the throughput stays close to the injection rate. The results of the second scenario, where we only varied the number of rules, are depicted in Figures 11 and12. We observe from the Figure 12 that SecSip maintains its throughput close to the injection rate of 60 SIP messages/second. However, as depicted in Figure 11, the delays introduced by SecSip become more important when we increase the number of loaded rules.

It seems that the rules processing module is the largest component contributing to the SecSip overhead. Therefore, we need to better optimize this component, to obtain a better performance of the firewall.

VI. CONCLUSIONS AND FUTURE WORK

With the increasing importance of SIP-based systems in the Internet, the availability of defense solutions able to protect all these systems against malicious exploitation of vulnerabilities is essential. In this paper, we have shown that SecSip is one solution able to deal with known, and to some extend unknown, vulnerabilities by efficiently building a per device tuned protection scheme. Our key contribution include the design of a runtime and a rule-based language to protect SIP-based networks from discovered vulnerabilities. The specification language is easy to use for authoring SIP vulnerabilities based on the protocol states prior any potential exploitation, along with message parsing for exploit detection. To achieve this, the SecSip language allows the use of stateful objects that track protocol states. The evaluation of a SecSip implementation, indicates that the introduced delays are acceptable for an online analysis engine. The SecSIP implementation is distributed in Open Source (GPL 2 license) and can be downloaded from the INRIA Gforge2 .

We are currently working on the improvement of the Sec-Sip implementation and its language to stabilize the release and provide improved performances. Interfaces with several management services are also under development (e.g. Syslog, SNMP). The idea behind it is to allow secsip to interact directly with SIP devices management interfaces to collect some useful data. For example, SecSip may need to know if the SIP device is up or down. Finally, we also plan to couple SecSip with attack and vulnerability tools [START_REF] Abdelnur | Kif: A stateful sip fuzzer[END_REF] to automatically generate defense rules.

Fig. 1 .

 1 Fig. 1. Overall approach combining the SecSip firewall and fuzzing tools.

  depicts the proposed SecSip architecture that integrates four major components: Input/Output Layer, Stateful Inspection Layer, SIP Packet Handler and Rule Compiler and Optimizer.

Fig. 2 .

 2 Fig. 2. Overview of SecSip architecture.

Fig. 4 .

 4 Fig. 4. SIP message traversal through SecSip runtime.

Fig. 5 .

 5 Fig. 5. Illustration of the BYE attack.

  SecSip hold:from_list=list[FIELDS:sip.from] SecSip hold:from_list.ip_addr=list[FIELDS:sip.from.addr]

Fig. 6 .

 6 Fig. 6. Declaration of stateful objects to track the From field values and their respective source IP addresses.

Fig. 8 .

 8 Fig. 8. SecSip rules to detect a flooding attack INVITE transactions and drop the malicious messages.

Fig. 9 .Fig. 10 .

 910 Fig. 9. Delays introduced by SecSip deployed as a bump in the wire device. No rules are loaded by SecSipThe results of the first scenario are depicted in Figures9 and 10. In this scenario, we measure the effect of a stressing

Fig. 11 .

 11 Fig. 11. Delays introduced by SecSip deployed as a bump in the wire device.We varied the number of rules loaded by SecSip. The y-axis is in log scale.

Fig. 12 .

 12 Fig.[START_REF] Wu | Scidive: A stateful and cross protocol intrusion detection architecture for voice-over-ip environments[END_REF]. Throughput of SecSip in terms of number of SIP messages per second. We varied the number of rules loaded by SecSip.

TABLE I DESIGN

 I SPACE OF SIP DEFENSE SOLUTIONS. . 3. A sample of SecSip rules and synchronize the stateful objects defined by the SecSip defense rules. SecSip stateful objects are stored to a certain type of container specified in a specific rule. The SecSip language provides three types of containers: set, list and bag. A set is an unordered collection of objects without repeated values. A list is an ordered collection of objects. A variation of a set is the bag. It allows repeated values and multiple objects. The different containers referenced by stateful objects are stored within a hash table.

	Attack type		Defense approach		Criteria
		Proactive at SIP device	Proactive in SIP network	Reactive in SIP network
		High	High	Not useful	Assumptions
	Compromise attacks	High	High		Effectiveness
		Low	High		Complexity
		Not useful	High	Medium	Assumptions
	Deny of service attacks		High	Medium	Effectiveness
			High	Medium	Complexity
	Examples	Firewalls	Firewall, NAT	IDS
	R1: secsip "FIELDS:sip.method" "ˆINVITE" declare:rate=counter[10;60]
	R2: secsip rate "@eq 80" drop

Fig

http://secsip.gforge.inria.fr


Doctor, Aurélie Talon
email: atalon@cust.univ-bpclermont.fr

Professor, Daniel Boissier
email: daniel.boissier@cust.univ-bpclermont.fr

Decision in the face of risks: optimization of decision schedule

The reasoning schedule leading to the decision making is the same whatever the addressed risks: a set of data to be collected, one or several models to be developed and a decision to be made. This schedule must integrate: (1) data that are uncertain, incomplete, censured, (2) models and decision processes that are imprecise or based on strong hypothesis of models and, (3) economical, political and sociological aspects. Considering the triplet {risks; context of decision making; variety of data, models and decision making}, the following problem directly emerges: what is the best triplet {data; models; decision making} that will allow taking the best decision when faced to risks in a fixed context? Our proposition is a methodology to collect and use at best data in order to obtain a coherent chain of risk analysis. As an illustration, we propose the case study of the service life assessment of building components.

Introduction

The evolution of new technologies, climate change and, at the same time, increasing knowledge stimulate mankind to assess the risks that are confronted, that is to say, in our context, technological and natural risks.

The reasoning schedule leading to decision making is the same whatever the addressed risks: data → models → decision making, in an economical, political and sociological context that contributes more or less thought and study time.

Different types of data are available, such as sightings, results from experimentations, instrumentations and numerical or theoretical models. Several models of data treatment may be useful: statistical model [START_REF] Siemes | modeling of building materials performance in durability[END_REF], probability [START_REF] Brandt | EPIQR -A new surveying tool for maintenance and refurbishment[END_REF] and possibility [START_REF] Shafer | A mathematical Theory of evidence[END_REF]Lair, 2000) approaches, expert judgements (as an example [START_REF] Iso | Building and constructed assets -Service life planning -Part 8: Reference service life and service-life estimation[END_REF])), etc. Decision making is usually aided by optimization methods [START_REF] Fletcher | Practical methods of optimization[END_REF] or multicriteria decision making methods [START_REF] Roy | Méthodologie multicritère d'aide à la decision[END_REF]. A succinct critical review of these available data, models and decision making methods is done in the second section of this paper.

The problem that is directly emerging from this context is to find the best triplet {data; models; decision making} that will allow taking the best decision when faced with risks in a given context.

Our proposition is a methodology to collect and use at best data in order to obtain a coherent chain of risk analysis. In concrete terms our proposition compounds: (1) a model to formalise the objectives of the decision making and the available data to responds to these objectives, (2) a model to assess the data quality that appears essential to best choose the models of data treatment and, (3) a generic and iterative process of the decision schedule. This proposition is detailed in the third section of this paper.

The fourth section of this paper is dedicated to an illustration of the above proposition with regard to a case study of the assessment of service life of building components. The considered risks for this illustration are associated with the failures of these building components likely to be caused by a random environment. The context of this assessment is characterized by the heterogeneity of available data (sources, scales, imperfections in terms of uncertainty, imprecision and incompleteness) and the will of improvement of building components in the phase of design as well as in the phase of service life (inspection, maintenance and repair). The different types of data, models and decision makings as previously cited are integrated in the decision schedule.

Problem of the optimization of decision schedule

In the construction domain, problems to be solved are numerous, as the diversity of the subdomains of application (characterisation of materials behaviour, of building components behaviour, of structures behaviour, stability of buildings, of civil engineering constructions considering current conditions, accidental conditions or exceptional conditions, etc.), as the diversity of materials, building components and structures, as the diversity of actors, as the diversity of the technical and usage functions ensured by these constructive entities and as the diversity of the requirements and the political, economical and social stakes. Among all the possible problems some examples can be shown: (1) the modeling of the alkali-reaction phenomenon for NPKA concrete tests, (2) the assessment of the fire resistance of firebreak doors, (3) the failure probabilities of a dam for a project flood of 10 000 years, (4) the assessment of the service life of a double glass unit considering real exposure conditions, (5) etc.

The optimization problem of the decision schedule is based on two observations. To solve the different problem of the construction domain, several data, several models of data treatment and several methods of decision making have been developed. These methods present similarities, divergences and they are more or less accurate to the available data; in consequence it seems to be evident that a unique triplet {data, model of data treatment, method of decision making} cannot solve the entire set of the problem. Then, we propose in this section a critical review of the main types of data, of the main models of data treatment and of the main methods of decision making before detailing in section 3 the proposed tools that allow to aid the solving of the problem of decision making that is, in our opinion, to find the triplet {data, model of data treatment, method of decision making} that best corresponds to the given objective and the given study context.

Critical review of available type of data

The main type of available data are: (1) sightings, (2) experimentations, (3) instrumentations,(4) simulations, (5) statistics, (6) expert opinions and, (7) probabilities.

a. Sightings

The sightings correspond to the data provided by the feedback; data may be providing from visual examination or instrumentation measures on available constructive entities (as an example, the crack spacing measured with a crack meter or the piezometric height measured with a piezometer). The main advantage of sightings is that they are obtained for real constructive entities and real environment conditions. The major disadvantage are: (1) the eventual imprecision of the observed values, (2) the unawareness of the climatic and usage conditions and, (3) the censorship (i.e., selective sampling) of data if the sightings are not made in a continuous way that is the current case.

b. Experimentations

The experimentations correspond to data provided by an experimental assembly that is done in order to characterise the behaviour of constructive entities when considering controlled climatic and usage conditions. As an example, for the ageing tests of constructive entities, three type of exposure conditions can be distinguished: long term exposure, short term exposure and accelerated short term exposure [START_REF] Jernberg | Guide and Bibliography to Service Life and Durability Research for Building Materials and Components[END_REF]. The main advantage of experimentations is that they are obtained for controlled exposure conditions. The main disadvantage of this type of data is inherent to the difficulty to transpose these results to other case studies in real environment conditions.

c. Instrumentations

The instrumentations correspond to data provided by measurement tools. The main advantage of this type of data is to have access to results that are not visually measurable and that are reproducible. The main disadvantages of this type of data are: (1) the implementation cost, (2) the censorship if the measurements are not obtained in a continuous way and, (3) the transposition to other case study.

d. Simulations

The simulations correspond to the results of numerical models. The main advantage of such type of data is the possibility to realise a consequent number of simulations that correspond to different case studies. The main disadvantages of this kind of data are: (1) the number of simplifying hypothesis for a generic numerical model, (2) the difficulty of transposition to other case studies for an accurate numerical model and, (3) the difficulty of feedback analysis.

e. Statistics

The statistics correspond to a value or a set of values for a fixed sample. The advantage of this type of data is to have a global vision of a phenomenon that is difficulty explicable by the variation of the set of parameters that characterise this phenomenon. The main disadvantage is to obtain a representative sample.

f. Expert opinions

The expert opinions correspond to the expert conclusions as regards observed facts. The advantages of expert opinions are that results can be provided quickly, however the major disadvantages are that such data is subjective and quite difficult to be extracted.

g. Probabilities

The probability data corresponds to probability laws and parameters of these probability laws that characterise phenomena. The advantage of such type of data is the numerous available probability laws to best model the studied phenomena. The main disadvantage of such data is the number of simplifying hypothesis that must be fixed.

Critical review of available models of data treatment

Five models of data treatment are generally distinguished: (1) statistical approach, (2) probability approach, (3) approach based on the possibility theory, (4) behaviour models and, (5) expert models.

Statistical approach

The statistical approach is relevant when several data of one same type, that is to say data associated to a same problem, is available in order to provide a coherent sample.

Probability approach

The probability approach is relevant when well known phenomena are studied, that is to say when sufficient information is available in order to define the best appropriate probability law and its characteristic parameters.

The statistical and the probability approaches allow taking into account together several random parameters; however these approaches use only one type of data for one study and the obtained results are difficult to transpose to other case studies.

Approach based on the possibility theory

The possibility approach allows taking into account all the available data whatever its type; however such approach needs a good knowledge of the obtaining conditions of the used data in order to define the belief mass (i.e., degree of confidence) attached to each data. It is possible to use the entire set of possible types of data as all types of data can be modeled with a possibility format [START_REF] Boissier | Approche probabiliste et possibiliste pour la prise en compte de l'incertain[END_REF].

Behaviour models

They allow providing a theoretical modeling of the behaviour of constructive entities; however the more accurate the obtained model is, the more difficult the transposition of this model to other case studies is.

Expert models

The expert models correspond to the modeling of the reasoning of experts that allows obtaining conclusions on the basis of observed facts. The expert models allow quickly obtaining a result, but it is a subjective result.

     Probabilistic approach        Approach based on possibility theory        Behaviour model    Expert model    

Critical review of available methods of decision making

Two types of methods of decision making may be generally distinguished: (1) optimisation methods that search the parameters values that maximise or minimise the most relevant criterion of the considered problem and, (2) methods of multi-criteria decision making that consist in choosing, sorting, ordering or describing a set of solutions as regards the different criteria that characterise the problem. The main available methods of multi-criteria analysis are: multiplicative and additive models, MAUT, Goal Programming, Condorcet, ELECTRE, PROMETHEE, EXPROM, etc. [START_REF] Lemaire | Aide au choix des produits de construction sur la base de leurs performances environnementales et saniataires[END_REF][START_REF] Roy | Méthodologie multicritère d'aide à la decision[END_REF].

Tools for aiding the decision schedule

Three tools are proposed in this section that allow aiding the definition of the best triplet {type of data, model of data treatment, method of decision making} to solve some problems of the construction domain.

Model of data formalisation

This first tool is dedicated to the data formalisation and aims to build cartography of the endorsed objective and of the available data to reach this objective. The goal of this cartography is twofold:

(1) to appropriately define the endorsed objective, that is to say the wanted level of accuracy and the study limits and, (2) to locate the correspondence (accuracy and scales) between available data and endorsed objective in order to best select the most relevant model of data treatment when several types of data are available.

We consider that all objectives and all data may be formalised in accordance with four parameters: (1) a geometrical granularity, (2) a phenomenological granularity, (3) a functional granularity and, (4) a temporal granularity.

A referential of formalisation is proposed in which four graduated axes are associated to these four factors. The first axis is the geometrical axis that compounds four levels: (1) the material (such as concrete), (2) the element (such as a concrete beam), (3) the building component (such as a concrete wall covered by an insulating complex) and, (4) the construction (such as a building with a reinforced concrete structure). The second axis is the phenomenological axis that regroups three levels: (1) the phenomenon (such as the shock of an avalanche against an anti-avalanche wall), (2) the scenario (such as the chain of events that leads to the destruction of a firebreak door) and, (3) the scenarios (as an example, the entire set of chains of events that leads to the failure of a building). The third axis is the functional axis; it characterises the requirements as regards the objective; two levels are defined: (1) the mono-function level, the main requirement is considered and, (2) the multi-function level, all the requirements are taken into account. The fourth axis is the temporal axis; it is possible to consider a study during the duration of the research project, during the duration of a test or during the service life of a constructive entity, etc.

This formalisation model of data is detailed in [START_REF] Talon | Service life assessment of building components: Application of evidence theory[END_REF][START_REF] Talon | Evaluation des scenarii de degradation des produits de construction[END_REF].

Model of data quality assessment

This model is dedicated to the quality assessment of collected data and aims to affect a belief mass (confidence degree) to each data in order to allow: (1) to judge if the collected data has a sufficient quality in order to pursue the study, that is to say in order to apply the model of data treatment and, (2) to provide a priority of the different types of data that has the highest belief mass when several types of data are collected.

The data quality is inversely proportional to the imperfections associated to this data; three types of imperfections may be distinguished: -Inherent imperfection: this one integrates the obtaining process of this data, the reliability of the information source, the censorship (due to the duration and the means of the sightings) and the incompleteness; -Imperfection due to the modeling of data: this imperfection corresponds to the efficiency of the modeling of all types of data in a possibility format; -Imperfection due to the usage: on the one hand, this imperfection regroups the fit between collected data and studied case and, on the other hand, this imperfection includes the rate of information of the data. As an example, the combustion duration of a wood beam in an air oven and the combustion duration of a wood frame in service will not have: (1) the same geometrical granularity (element level for the first and building component level for the second) and, (2) the same exposure conditions correspondence (different exposure environments). The rate of information of a data, measured with the Shannon's Entropy, represents the idea that an assessment provided by a particular value integrate more uncertainty (there is a higher chance that the result is realistic) than an assessment provided by an interval that includes this particular value.

An assessment grid of data quality is proposed in Table 2 and detailed in [START_REF] Talon | Evaluation des scenarii de degradation des produits de construction[END_REF] in order to facilitate the assessment of the data quality process and to make the assessment homogeneous for all collected data. This grid is based on the NUSAP method, for Numerical Unit Spread Assessment Pedigree, [START_REF] Funtowicz | Uncertainty and Quality in Science for Policy[END_REF]) and of the PhD thesis of J. Lair (2000). The result of the assessment of belief mass is equal to the average of the values taken by the entire set of the quality criteria.

           / ln x f ln x f X x mc mc 1
where X represents the interval of values of the data (such as [5; 10] years for an duration assessment), x is a value of the discrete data (a date for the duration assessment), Θ is the frame of discernment (observation period   max min t ; t for the duration assessment), and   x f mc is the belief mass function associated to the x value, as detailed in [START_REF] Talon | Evaluation des scenarii de degradation des produits de construction[END_REF].

Generic and iterative process of the decision schedule

The proposed generic and iterative process of the decision schedule is schematised in the following Figure 1. The general principle of this decision schedule process is to assess the quality of the available collected data, to choose the method of data treatment that is best adapted to the type of data that had the highest belief mass as well to the accuracy of the required objective. As an example, if one wants to assess with a high accuracy a material behaviour as regards specific environmental actions, the obtaining of a behaviour model will be more appropriate (if data is sufficient and has a satisfactory quality) than an expert opinion. The general principle is then led by the assessment of the result obtained by the chosen model of data treatment; if the result is satisfactory, then the application of the decision method that best corresponds to the weighted objective is done. When the obtained result is satisfactory, the process is stopped. This process is iterative as, if the results are not satisfactory, new data may be searched or a new method of data making may be applied.

An added aim of this decision schedule process is the definition of missing data in the construction domain that can lead to underline the new experimentations, simulations, examinations … that may be proceed.

Application to the case study of the service life assessment of building components

The problem of the case study presented in this section is to assess the service life of all building components in a given climatic and usage in-service environment while considering: (1) all the degradation scenarios that can affect the performance of this building component over its service life, (2) all the technical and usage functions ensured by this building component.

As regards the referential proposed in the section 3.1, this problem may be modeled by the four following levels: (1) geometrical axis = building component, (2) phenomenological axis = all degradation scenarios, (3) functional axis = all the functions ensured by these building components and, (4) temporal axis = service life.

The service life assessment is a major research field in the construction domain, as it is proved by the international work group ISO/TC59/SC14 and the national French work group P01E for the standardization of the service life, as well as the CIB work groups, notably the CIB W080. As a consequence, many sources of data are available: the seven types of data defined in the section 2.1 are available for this problem. Some data concerns the durability of the materials, the elements and the building components. This data is relevant to the phenomena or the degradation scenarios of these constructive entities. This data characterises one or several functions ensured the building components and is associated to different phases of the life cycle of the building components (design, implementation, service life, rehabilitation and deconstruction). Then, the available data is multi-sources and multi-scales.

The main models of data treatment used in the domain of the service life assessment of the constructive entities are: methods based on a probabilistic approach, statistical approaches, comparisons between long-term and short-term exposure tests, feedback from practice and factorial method for service life estimation. The major disadvantages of these models are: (1) use of a unique type of data and, (2) difficulty to the transpose to other constructive entities considered in other climatic and usage conditions. Those are the reasons why we prefer using the approach based on the possibility theory as it allows: (1) to model all data types with a possibility format and then to use all available data, (2) to integrate the belief mass attached to each collected data (obtained by the model of data quality assessment -cf. § 3.2), into the model of data treatment; this model is a compound of: -a data unification that is applied when several data relevant to a same problem is available that is to say when the levels in the referential of the problem objective (as proposed in § 3.1) are the same as the levels of the collected data; -a data aggregation that is applied when data relevant to different sub-problems that allow obtaining the problem result is available that is to say when the levels in the referential of the problem objective are different from the level of the collected data associated to the different sub-problems.

The method of decision making of the problem of the service life assessment of building components aims to obtain a consensual data that regroups the maximum of consensus and an estimation of the quality of the obtained consensual data.

Illustration:

Considering the following problem: "to assess the cracking time of a reinforced concrete structure in contact with external environment". We also consider that this problem may compound three sub-problems: -sub-problem 1: "to assess the duration of the carbonation front to reach the reinforcement", -sub-problem 2: "to assess the duration of the reinforcement corrosion", -sub-problem 3: "to assess the duration of the cracking to reach the structure surface due to the reinforcement corrosion". Considering that the nine available data are grouped in the Table 3. The approach for the resolution problem associated to the available data of the Table 3 is schematised in the Figure 2.

Conclusions

Many problems solving in the construction domain may be schematized by the following decision schedule: data  model of data treatment  method of decision making. The second part of this paper has proposed a critical review of the different types of data, of the different models of data treatment and of the different available methods of decision making. From this critical review, we deduced that all problem solving in the construction domain is done by the choice of the triplet {data type, model of data treatment, method of decision making} that best responds to the given problem. Three tools have been proposed in order to facilitate this choice; they are: (1) a formalisation model of the fixed objective and the available data, (2) an assessment model of the quality of the available data (3) a generic and iterative process of the decision schedule. Their applications to the case study of the assessment of service life of building components has proved the applicability and the efficiency of these three tools.

Figure 1 :

 1 Figure 1: Schematisation of the generic and iterative process of the decision schedule

Table 3 :

 3 Duration data associated to the assessment problem of the

Figure 2 :

 2 Figure 2: Approach of data treatment for the problem of the cracking time of an reinforced concrete structure

Table 1

 1 regroups the different types of data, defined in the section 2.1, usable by the five models of data treatment previously presented.

Table 1 :

 1 Correspondence between data type and model of data treatment

	Data treatment model	Data type	a b c d e f g
	Statistic approach

Table 2 :

 2 Assessment grid of data quality

	Values