Presentation - HAW Hamburg

HAW Hamburg
Anwendungen I
Nico Manske
Peer-to-Peer Internet Telephony using
the Session Initiation Protocol
(SIP)
17.04.2007
Seite - 1 -
Überblick
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ
ƒ
ƒ
ƒ
ƒ
Einleitung
Architektur
Erweiterte Dienste
Sicherheit
Performance
17.04.2007
Seite - 2 -
Einleitung
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ reines P2P System für IP Telefonie
ƒ bei SIP Client – Server üblich (SPoF)
ƒ Vorteile eines P2P Systems nutzen
ƒ Ausfallsicherheit und Skalierbarkeit
ƒ Fehlertoleranz
ƒ kein SPoF
ƒ Nachteil: höhere Schwankungen bei Lokalisierung der
gewünschten Ressourcen
ƒ dieser Ansatz unterstützt:
ƒ user Registration
ƒ call setup
ƒ erweiterte Dienste (offline message delivery, conferencing..)
ƒ Herausforderung:
ƒ sicheres Framework zur Authentifizierung ohne zentralen
Server wie bei meisten SIP-basierten Systemen
17.04.2007
Seite - 3 -
Architektur
Überblick
Einleitung
ƒ existierenden SIP-basierte Systeme keine reinen P2P
ƒ „centralized user location lookup“
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ DHT mit Chord Algorithmus als P2P overlay
ƒ Modell mit verschiedenen Knotentypen:
ƒ Ordinary-Node
ƒ Super-Node als Bestandteil der DHT
ƒ nur die Super-Nodes mit mehr CPU-, Speicherleistung und
Bandbreite sind Teil der DHT
17.04.2007
Seite - 4 -
Architektur
Überblick
Einleitung
ƒ Node key und user key für die DHT werden separat
errechnet
ƒ Node in DHT agiert als SIP Registrar
Architektur
Erweiterte
Dienste
Sicherheit
Performance
17.04.2007
Seite - 5 -
Architektur
Überblick
ƒ P2P-SIP Node Komponenten
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
17.04.2007
Seite - 6 -
Architektur
Überblick
Einleitung
Architektur
Erweiterte
Dienste
ƒ Ordinary Node Startverhalten
ƒ SIP Server über DNS finden
ƒ nach REGISTER
über SIP + P2P
erreichbar
Sicherheit
Performance
17.04.2007
Seite - 7 -
Architektur
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ User Registrierung
ƒ SIP REGISTER zu 2 Super Nodes (Redundanz)
ƒ Ordinary Node ist SIP user agent
ƒ Super Node ist user agent und Registrar
ƒ Super Node sendet SIP REG. für seine zugehörigen
ordinary Nodes
ƒ Ordinary Nodes senden periodisch REG. um
ausgefallene super-nodes zu entdecken
ƒ Node Shutdown & Failure
ƒ Un-REGISTER ebenfalls über Super-Node
ƒ bei Fehler merken die ordinary Nodes das Fehlen, beim
nächsten periodischen Reg.
ƒ suchen sich einen anderen Super-Node
17.04.2007
Seite - 8 -
Erweiterte Dienste
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ NAT und Firewall
ƒ impl. Interactive Connectivity Establishment (ICE)
ƒ per UDP oder TCP Tunnel (port 80)
ƒ Offline Messages
ƒ Speicherung auf Zielgerät wenn Benutzer Ruf nicht
annimmt
ƒ wenn Gerät nicht aktiv dann Speicherung in DHT node
welcher für diesen Teilnehmer verantwortlich ist
ƒ Message kann an mehreren Stellen gespeichert werden
und bleibt somit verfügbar (Oceanstore architecture)
ƒ Konferenz
ƒ Multicast media destribution tree wird genutzt ???
ƒ Geräte unabhängig
ƒ Node speichert verschlüsselte Benutzerprofile in P2P
overlay Netwerk
17.04.2007
Seite - 9 -
Sicherheit
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ einige Punkte die noch offen sind und behandelt werden
müssen
ƒ Authentifizierung
ƒ Verschlüsselung (Ruf- und Userinformationen)
ƒ Lösung wie bei SIP Telefonie durch:
ƒ end-to-end digest auth.
ƒ hop-by-hop transport layer security (TLS)
ƒ end-to-end S/MIME
ƒ Privatsphäre und Vertaulichkeit
ƒ Behandlung von böswilligen Nodes
17.04.2007
Seite - 10 -
Performance
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Sicherheit
Performance
ƒ Skalierbarkeit
ƒ abhängig von Bandbreite, CPU und Speicher der
Super-Nodes
ƒ je mehr Nodes um so höher die Latenz für Rufaufbau
ƒ Ausfallsicherheit
ƒ wird durch folgende Punkte beeinflusst:
ƒ Refresh-Rate (node-Ausfallerkennung)
ƒ User registration Refresh-Rate
ƒ User registration record (user profile) kann an
mehreren Punkten hinterlegt werden
ƒ Latenz bei Rufaufbau
ƒ Vorteile des P2P Netzwerkes fordern Latenz bei
Rufaufbau
ƒ Zeiten bis zu 2 Sekunden für Rufaufbau sollen
tolerierbar sein ???
17.04.2007
Seite - 11 -
ENDE
Überblick
Einleitung
Architektur
Erweiterte
Dienste
Vielen Danke für die
Aufmerksamkeit!!!
Sicherheit
Performance
17.04.2007
Seite - 12 -