1 / 13

Emergency Services and Reliable Service Provisioning in All-IP networks

Emergency Services and Reliable Service Provisioning in All-IP networks. Dorgham Sisalem Fraunhofer Instituit FOKUS. Outline. Who are we? What have we been doing? All-IP infrastructures: What are our emergency related issues here? Every day life: Provide 911 services Catastrophe:

Download Presentation

Emergency Services and Reliable Service Provisioning in All-IP networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Emergency Services and Reliable Service Provisioning in All-IP networks Dorgham Sisalem Fraunhofer Instituit FOKUS

  2. Outline • Who are we? • What have we been doing? • All-IP infrastructures: What are our emergency related issues here? • Every day life: Provide 911 services • Catastrophe: • DoS attacks: Provide secure communication and prevent or at least reduce the effects of DoS attacks • Catastrophe: Make sure that the communication infrastructure is reliable and redundant –allow calls even if your original server has just ceased to exist • Relief services: Provide communication infrastructure for relief workers in ad-hoc networks

  3. FhG-Fokus/Mobis • Fraunhofer: Germany’s national research network • 56 institutes • Tight cooperation with industry • Fokus: research institute for open communication systems in Berlin • 200 People in different competence centers dealing with middle ware, testing, HOT and car technologies and IP communication • IST involvement • Our department ‘mobis’ has been involved in IP telephony since its early beginning

  4. What Have We Done in the Last Years? • Signaling server with open source SIP infrastructure • (thousands of calls per second on an off-shelf PC) • SIP operational experience: We are powering public servers at iptel.org • Long and detailed experience with mobile-IP • Co-authored and standardized firewall-control concept in IETF (MidCom, RFC3303) • Testing suites (TTCN-3) for robust products developed • QoS work: FEC algorithms, packet loss concealment • RTP created in Fokus

  5. All-IP Multimedia Services: Where are we and what are the problems? • “basic package” up and running • Signaling standardized and deployed for few years now • Media quality mostly sufficient • Service integration happens: Instant messaging, web, VoIP • Current problems: • How to provide 911 services? • How to provide reliable services under emergency or attack situations? • How to provide communication services in catastrophe situations?

  6. Requirements for Emergency Services in All-IP Environments • Horizontal and vertical location identification accuracy • Finding user location • Determining the appropriate PSAP • Sending user location data to PSAP • Addressing • How to signal an emergency in a roaming situation? • Reliability and QoS support: • QoS Architecture: How to provide QoS guarantees for emergency calls • Social: How to asses and prove urgency • QoS: How to enforce priorities across a complex systems (IP, signaling, gateways, …) along an uncontrolled end-2-end path • Capacity engineering: How to deal with mass urgency needs?

  7. Reliable and Safe Service Provisioning: Problems • First line of defense against any kind of attack or event is solid and reliable service infrastructure • Multimedia services depend on a large row of components: • End devices: • Software and hardware failures • Network: • Routers, physical links • Supporting services • DNS, proxies, firewall, NAT, AAA servers • Any of these components can fail due to internal problems or DoS attacks.

  8. Why I Do Not Want to Rely on My SIP Phone in Emergency Today • Age • Software still young (~ 5 years, cf. tens of years in PSTN) and buggy • Conceptual Gaps • Availability of open communication systems lower – they are exposed to bogus implementations and attacks • Bogus implementations account for 50% of total resource consumption! • Concepts for network reliability not mature yet • Bandwidth sharing may kill any communication attempt

  9. To-Do List: Reliability • Objective: To keep infrastructure responsive under server, host and network failures • Issues: • Complexity: an IP telephony network depends on many components, all of which may fail: IP routing, DNS, firewalls, call signaling • Latency: in a lossy environment, it is difficult to detect failure in real-time • Failures can have broad impact. Tandem redundancy not good enough in open networks

  10. To-Do-List: Robustness • Objective: To remain responsive under heavy stress caused by exceptional circumstances or security attacks • Issues: • Conflicting requirements: • Good security to preserve resource wasting by unathorized users • We want anyone, even non-authenticated users, to participate in emergency calls • Surviving denial of service attacks not easy • Identifying DoS attacks not easy • Devise solutions and mechanisms for reducing effects of DoS • Operational dependency on systems such as DNS

  11. Reliable and Safe Service Provisioning: Goals • Research large-scale robustness, which follows the IP model with no single point of failure. • Distribute signaling services across a large number of cooperating systems whose aggregated capacity can easily cope with large-scale failures and attacks • It is even thinkable for end-devices to participate in the federations • Reality check: Can end-devices bear the load? • Yes! We’ve architected server which even on IPAQ with 802.11 make 300 calls per second. • Achieve secure access to services such as IP-Telephony and still maintain the open system architecture • Allow only eligible users to use the service but allow also everybody to use the service in case of emergencies

  12. Service Provisioning in Ad-Hoc environments • Support a communication infrastructure in catastrophe locations • Research in ad-hoc networks is mostly dedicated to optimizing routing • However, communication services require • Distributed services such as name translation (SIP address to IP address) • Cooperation between devices with different network technologies (Bluetooth and IEEE 802.1b) • Dynamic establishment of service providers • Example: mobile ad-hoc networks in which each phone is able to serve as PBX and help other systems to establish communication with each other • Issues of trust, service location and mobility to be considered here

  13. Where are we now? • Open source SIP infrastructure released • Proxy, registrar, redirect • AAA, SNMP, Radius support • Application server and configuration utilities • Available from www.iptel.org • Active work in the area of automatic failure detection of SIP servers and removal • First ideas implemented in our SIP platform • Work on DoS attacks on SIP infrastructure • What types are there and how to prevent them? • Work on QoS reservation and policing mechanisms • iptel.org is used demonstrate reliability concepts and mechanisms for DoS prevention

More Related