«Ανωνυµία σε SIP δίκτυα»

Transcript

1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥ ΩΝ ΣΤΗΝ ΕΠΙΣΤΗΜΗ ΤΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ιπλωµατική Εργασία Μεταπτυχιακού ιπλώµατος Ειδίκευσης «Ανωνυµία σε SIP δίκτυα» Hρακλής Λ. Λεοντιάδης Επιβλέπων :Μαριάς Ιωάννης ΑΘΗΝΑ, Ιούνιος 2009

2 ... Ηρακλής Λ. Λεοντιάδης Copyright Ηρακλής Λ. Λεοντιάδης, 2009 Με επιφύλαξη παντός δικαιώµατος. All rights reserved. Απαγορεύεται η αντιγραφή, αποθήκευση και διανοµή της παρούσας εργασίας, εξ ολοκλήρου ή τµήµατος αυτής, για εµπορικό σκοπό. Επιτρέπεται η ανατύπωση, αποθήκευση και διανοµή για σκοπό µη κερδοσκοπικό, εκπαιδευτικής ή ερευνητικής φύσης, υπό την προϋπόθεση να αναφέρεται η πηγή προέλευσης και να διατηρείται το παρόν µήνυµα. Ερωτήµατα που αφορούν τη χρήση της εργασίας για κερδοσκοπικό σκοπό πρέπει να απευθύνονται προς τον συγγραφέα. Οι απόψεις και τα συµπεράσµατα που περιέχονται σε αυτό το έγγραφο εκφράζουν τον συγγραφέα και δεν πρέπει να ερµηνευθεί ότι αντιπροσωπεύουν τις επίσηµες θέσεις του Οικονοµικού Πανεπιστηµίου Αθηνών

3 Περίληψη Αντικείµενο της παρούσας µεταπτυχιακής εργασίας είναι η αποτύπωση της ανωνυµίας µιας συγκεκριµένης αρχιτεκτονικής προσαρµοσµένη σε δίκτυα φωνής (VOIP) και συγκεκριµένα στο πρωτόκολλο SIP µε έµφαση την προστασία της ιδιωτικότητας των προσωπικών δεδοµένων του χρήστη. Το πρωτόκολο SIP συµβάλει στην εγκαθίδρυση µιας VOIP σύνδεσης και αποτελεί µέρος του επιπέδου υπηρεσιών στο ΟSI µοντέλο των δικτύων. Παρέχει υπηρεσίες καταχόρυσης ( register ), ανακατεύθυνσης ( redirect ), και πληρεξούσιου ( proxy ). Βασίζεται στο µοντέλο request-response όπως στο http και η επικοινωνία συνίσταται στην ανταλλαγή συγκεκριµένων µυνηµάτων, ώστε ο πάροχος της υπηρεσίας να αντιλαµβάνεται από την αίτηση την απάντηση που πρέπει να στείλει στον πελάτη. Τα δεδόµενα του χρήστη τα οποία δε θέλουµαι να συσχετίσει κάποιος κακόβουλος χρήστης είναι η θέση του και το αναγνωριστικό του χρήστη. Προτείνεται µια συγκεκριµένη αρχιτεκτονική η οποία διαχωρίζει τις 2 αυτες πληροφορίες µέσα στο δίκτυο ώστε να µη µπορεί να γίνει µεταξύ τους συσχέτιση στα διάφορα επίπεδα της ιεραρχίας. Για την αποτύπωση της ανωνυµίας της αρχιτεκτονικής χρησιµοποίουµε διάφορα µοντέλα εντροπίας µε τα οποία ποσοτικοποιείται η ιδιωτικότητα που παρέχει η αρχιτεκτονική δεδοµένων των 2 ευαίσθητων πληροφοριών,της θέσης και του ονόµατος. Λέξεις-Κλειδία ίκτυα φωνής (VOIP), πρωτόκολλο εγκαθίδρυσης σύνδεσης (SIP), ανωνυµία, ιδιωτικότητα πληροφοριών, εντροπία, υποκειµενική πιθανότητα κατά bayes, θεωρητικά µοντέλα επίθεσης σε αρχιτεκτονικές παροχής ανωνυµίας

4 Abstract The subject of this master thesis is the measurement of anonymity in a specific protocol adapted in Voice Over Internet Protocol networks and specially in the Session Initiating Protocol (SIP), with emphasis on the user personal data privacy protection. The SIP protocol is responsible for the initiation of session in order to provide a VOIP call and belongs to the application layer of the OSI network model. It provides user registration services, proxying and redirection requests. It is based in the request-response model as the http protocol and the communication is doing with the exchange of messages in order of the provider to understand the response that he has to send. When a malicious user intrudes the system, we do not want to link a message with a particular name of the user and his current location, which is his ip. An anonymity distributed system is intended in order not to link a specific username with a location in the different layers of the hierarchy. We also use information entropy to measure the anonymity of the system. Keywords Voice over internet protocol (voip),session Initiation protocol(sip),anonymity, privacy, entropy, bayes probabilities, attack models in anonymity

5 - 5 -

6 ΠΕΡΙΕΧΟΜΕΝΑ Λίστα Σχηµάτων...8 Λίστα ιαγραµµάτων...9 Kεφάλαιο 1 Εισαγωγή...10 Kεφάλειο 2 To πρωτόκολλο SIP Εισαγωγή Sip Network Elements SIP User Agents (UAs) SIP Proxy Servers SIP Registrar Servers SIP Redirect Servers Μηνύµατα και Μέθοδοι SIP Unified Resource Identifier (URI) Πεδία επικεφαλίδων ( Ηeader Fields) SIP Requests SIP Responses οµή του Πρωτοκόλλου SIP Στρώµατα του Πρωτοκόλλου SIP SIP Transactions SIP Dialogs...29 Κεφάλειο 3 Αρχιτεκτονικές Ανωνυµίας Crowds Onion Routing Hordes Freedom...45 Kεφάλειο 4 Η αρχιτεκτονική Sipist Εισαγωγή Υλοποίηση Mist Administrator Mist Router Lighthouse Portal Location Service Registration µε το Sipist Ιεραρχία κλάσεων 64 Kεφάλειο 5 Aπόδοση αρχιτεκτονικής και ποσοτικοποίηση ανωνυµίας Ορισµός Ανωνυµίας Μετρικές Ανωνυµίας Ανωνυµία της αρχιτεκτονική Sipist Απόδοση αρχιτεκτονικής.68 Βιβλιογραφία

7 - 7 -

8 Λίστα Σχηµάτων Σχήµα 1: Εναλλαγή ρόλων UAS και UAC 13 Σχήµα 2: Αρχικοποίηση κλήσης µέσω SIP Proxy Servers.15 Σχήµα 3: οµή ενός µηνύµατος SIP...16 Σχήµα 4: Τυπικό παράδειγµα λειτουργίας ενός INVITE Client Transaction..26 Σχήµα 5: Τυπικό παράδειγµα λειτουργίας ενός non-invite Client Transaction..27 Σχήµα 6: Τυπικό παράδειγµα λειτουργίας ενός INVITE Server Transaction.28 Σχήµα 7: Τυπικό παράδειγµα λειτουργίας ενός non-invite Server Transaction..29 Σχήµα 8: SIP Dialogs και SIP Transactions 30 Σχήµα 9: Μονοπάτια σε ένα Crowd: ο αριθµός του Jondo υποδεικνύει το...34 Σχήµα 10: Παράδειγµα δικτύου Onion Routing µε µία ανώνυµη σύνδεση από έναν ιδρυτή σε ένα ανταποκριτή διαµέσου των δροµολογητών W, X, Y και Z...37 Σχήµα 11: Αρχιτεκτονική του Εξυπηρέτη Freedom..48 Σχήµα 12 Ιεραρχία του Mist.51 Σχήµα 13 Ορισµός ιεραρχίας από τον Administrator...52 Σχήµα 14 Ορισµός ip ανά κόµβο από τον Administrator.52 Σχήµα 15 Οπτική αναπαράσταση της ιεραρχίας Μist.53 Σχήµα 16 Usecase Administrator Σχήµα 17 Επικοινωνία Μist routers µε τον administrator 55 Σχήµα 18 Επικοινωνία 2 χρηστών στο Μist 57 Σχήµα 19 Επιλογή Lighthouse µέσω του Portal...58 Σχήµα 20 H γενική µορφή των πακέτων MIST...59 Σχήµα 21 Μist Circuit Establishment...59 Σχήµα 22 Επικύρωση σύνδεσης...59 Σχήµα 23 ηµιουργία Mist κυκλώµατος..60 Σχήµα 24 Location Service...61 Σχήµα 25 Registration µε το Sipist...62 Σχήµα 26 Ροή µηνυµάτων στο Sipist για τη κατοχύρωση soft-phone.63 Σχήµα 27 Ιεραρχία κλάσεων 64 Σχήµα 28 Ανώνυµο σύνολο Μist

9 Λίστα διαγραµµάτων ιάγραµµα 1 Βαθµός ανωνυµίας Mist µε 5 και 10 portals 67 ιάγραµµα 2 Απόδοση κίνησης

10 Κεφάλαιο 1 - Εισαγωγή Η ανάπτυξη και ευρεία αξιοποίηση του Internet οδήγησε στην ανάγκη διασφάλισης της ανωνυµίας και της ιδιωτικότητα σε σειρά εφαρµογών υπεράνω του ιστού. Στο κεφάλαιο 2 παρουσιάζονται τα ευρύτερα αξιοποιούµενα πρωτόκολλα, υπηρεσίες και εργαλεία ενίσχυσης της ιδιωτικότητας (Privacy Enhancing Technologies PET) που είναι τα, Crowds, Onion Routing, Hordes και Freedom, δίνοντας έµφαση στην αρχιτεκτονική τους, τις αρχές λειτουργίας και τα σηµεία ευπάθειάς τους. Ακολούθως στο κεφάλαιο 3 αναλύεται η λειτουργία του πρωτοκόλλου SIP. Επιπλέον, στο κεφάλαιο 4 γίνεται µια τεχνική αναφορά στην αρχιτεκτονική του Mist και πως αυτή ενσωµατώθηκε στα sip servlets για την πραγµατοποίηση κλήσεων.η αρχιτεκτονική που υλοποιήσαµε ονοµάζεται Sipist,ενώ στο 5 ο κεφάλαιο ποσοτικοποιήσαµε µε µια τεχνική την ανωνυµία του συστήµατος και εξάγαµε κάποια συµπεράσµατα για την απόδοσή του

11 Κεφάλαιο 2 To πρωτόκολλο SIP 2.1 Εισαγωγή Το Session Initiation Protocol (SIP) καθορίστηκε αρχικά στο RFC 2543 από την οµάδα εργασίας MMUSIC της IETF και είναι ένα πρωτόκολλο σηµατοδοσίας υπεύθυνο για την αρχικοποίηση, την διαχείριση και τον τερµατισµό συνόδων, µέσω του ιαδικτύου, όπως για παράδειγµα η αρχικοποίηση, ο έλεγχος και ο τερµατισµός VoIP κλήσεων. Η έννοια της συνόδου εισήχθη αρχικά στο RFC 2327 (Session Description Protocol) ως ένα σύνολο από data streams που περιέχουν πολλαπλούς τύπους media δεδοµένων µεταξύ αποστολέων και δεκτών. Μια σύνοδος µπορεί να είναι ένα τηλεφώνηµα, µια τηλεδιάσκεψη, ο διαµοιρασµός data µεταξύ δύο χρηστών, chatting, ή ανταλλαγή instant messaging. Το SIP είναι ένα text-based πρωτόκολλο βασισµένο στο µοντέλο πελατών-εξυπηρετητών (client-server model), που παρέχει τις ακόλουθες βασικές απαιτήσεις των σηµερινών µέσων επικοινωνιών: User Location: Προσδιορισµός παραµέτρων όπως διεύθυνση IP και port number, οι οποίες απαιτούνται για την επαφή µε τον τελικό χρήστη. User Availability: Προσδιορισµός της ικανότητας επίτευξης επικοινωνίας µε έναν τελικό χρήστη. Endpoint Capabilities: Προσδιορισµός των media δυνατοτήτων (π.χ. codecs) των τελικών χρηστών. Session Setup: Εγκατάσταση συνόδων επικοινωνίας (sessions) µεταξύ endpoint users. Session Management: ιαχείριση των συνόδων επικοινωνίας. Ένα σηµαντικό χαρακτηριστικό γνώρισµα του πρωτοκόλλου SIP είναι ότι δεν είναι σε θέση να καθορίζει τον τύπο της επικοινωνίας που εγκαθίσταται, αλλά µόνο να την διαχειρίζεται. Αυτό έχει ως συνέπεια το SIP να µπορεί να χρησιµοποιηθεί σε έναν τεράστιο αριθµό εφαρµογών και υπηρεσιών, όπως interactive games, µουσική, φωνή και βίντεο. Μερικά χαρακτηριστικά του SIP, που το κάνουν να ξεχωρίζει από τα υπόλοιπα πρωτόκολλα σηµατοδοσίας είναι τα εξής: Τα µηνύµατα SIP είναι text-based και ως εκ τούτου είναι εύκολο να διαβαστούν και να διορθωθούν. Εποµένως, η υλοποίηση νέων υπηρεσιών γίνεται πιο εύκολη για τους σχεδιαστέςπρογραµµατιστές. Το SIP επαναχρησιµοποιεί διάφορες υπάρχουσες και ώριµες υπηρεσίες και πρωτόκολλα του ιαδικτύου όπως DNS, RTP, RSVP κ.λπ

12 Μπορούν εύκολα να ορισθούν νέα SIP extensions, επιτρέποντας στους οργανισµούς παροχής VoIP επικοινωνιών να προσθέτουν στα προϊόντα τους νέες υπηρεσίες. Το πρωτόκολλο SIP είναι ανεξάρτητο από το στρώµα µεταφοράς του δικτύου IP. Μάλιστα, χρησιµοποιεί είτε το User Datagram Protocol (UDP) ή το Transmission Control Protocol (TCP). Υποστήριξη πολύ-συσκευών στις συνόδους επικοινωνίας. Για παράδειγµα, εάν µια επικοινωνία παρέχει υπηρεσίες φωνής και βίντεο, οι δύο παραπάνω τύποι δεδοµένων µπορούν να ληφθούν και να αποσταλούν από δύο διαφορετικές συσκευές. 2.2 SIP Network Elements Ένα χαρακτηριστικό VoIP δίκτυο, που χρησιµοποιεί το πρωτόκολλο SIP περιλαµβάνει ένα σύνολο από elements που αλληλεπιδρούν µεταξύ τους. Τα βασικά SIP network elements είναι οι user agents, οι proxy servers, οι registrars και οι redirect servers. Τα παραπάνω elements αποτελούν λογικές οντότητες, συνδυασµός των οποίων συνυπάρχουν σε ένα σύστηµα. Στις επόµενες υποενότητες ακολουθεί περιγραφή των λογικών οντοτήτων του SIP SIP User Agents (UAs) Οι SIP UAs είναι τα Endpoints που χρησιµοποιούν το SIP για την αρχικοποίηση multimedia sessions µέσω του ιαδικτύου. Οι UAs µπορεί να είναι υλικό ή λογισµικό που εκτελείται κατά την εγκατάσταση µιας VoIP κλήσης από τις συσκευές των τελικών χρηστών, όπως τα cell phones, τις µικροσυσκευές πολυµέσων, τα PCs και τα PDAs. Οι SIP UAs χωρίζονται στις λογικές οντότητες User Agent Servers (UAS) και User Agent Clients (UAC), οι οποίες συνυπάρχουν σε έναν SIP UA. Όπως έχει ήδη αναφερθεί το πρωτόκολλο SIP βασίζεται στο µοντέλο Client-Server. Έτσι, ένας UAC είναι το µέρος του UA που αποστέλλει SIP requests και λαµβάνει SIP responses, ενώ αντίθετα ένας UAS είναι το µέρος του UA που λαµβάνει SIP requests και αποστέλλει SIP responses. Επειδή ένας UA περιέχει και έναν UAC και έναν UAS, συχνά λέµε ότι ένας UA συµπεριφέρεται ως UAC ή UAS, ανάλογα µε το αν ο αποστέλλει ένα SIP request ή λαµβάνει ένα SIP response, αντίστοιχα

13 Σχήµα 1: Εναλλαγή ρόλων UAS και UAC. Ένα παράδειγµα εναλλαγής ρόλων παρουσιάζεται στο Σχήµα 1, όπου φαίνονται τρεις UAs και ένας statefull SIP Proxy Server. Κάθε UA περιέχει έναν UAC και έναν UAS. Το µέρος του SIP Proxy Server ή του SIP UA που λαµβάνει ένα request ενεργεί ως UAS, ενώ αντίθετα το µέρος που αποστέλλει ένα SIP request λειτουργεί ως UAC. Αξιοσηµείωτο είναι επίσης το γεγονός ότι ο statefull SIP Proxy Server που αποστέλλει ένα request σε δύο Uas δηµιουργεί δύο UACs, κάθε ένας από τους οποίους είναι αρµόδιος για έναν UA (Callee A ή Callee B). Επίσης, ο Callee B, ενώ αρχικά λειτουργεί ως UAS όταν δέχεται την κλήση, στην συνέχεια συµπεριφέρεται ως UAC όταν αποστέλλει BYE request για τον τερµατισµό της κλήσης SIP Proxy Servers Οι SIP Proxy Servers είναι βασικές οντότητες ενός SIP δικτύου, διότι εκτελούν την δροµολόγηση των SIP µηνυµάτων που ανταλλάσουν δύο SIP UAs, σύµφωνα µε παραµέτρους όπως η τρέχουσα θέση του caller και του callee UA. Ο κύριος ρόλος ενός SIP Proxy Server είναι η προώθηση των SIP µηνυµάτων όσο το δυνατόν «πιο κοντά» στους αρµόδιους UAs. Τα µηνύµατα αυτά θα περάσουν συνήθως από αρκετούς Proxy Servers πριν φθάσουν στον τελικό τους προορισµό. Ένας SIP Proxy Server εάν είναι απαραίτητο τροποποιεί ένα µήνυµα SIP πριν το αποστείλει στον αντίστοιχο SIP UA ή σε άλλον SIP Proxy Server για την περαιτέρω προώθησή του.υπάρχουν δύο κατηγορίες από SIP Proxy Servers: Stateless Proxy Servers: Είναι Proxy Servers που εκτελούν απλή διανοµή των SIP µηνυµάτων, χωρίς να αποθηκεύουν τα µηνύµατα στην τοπική τους µνήµη. Επιπλέον, οι stateless proxy servers δεν κάνουν χρήση των SIP transactions, που είναι βασικό συστατικό στοιχείο του πρωτοκόλλου

14 SIP, κάτι που όπως θα δούµε σε επόµενη ενότητα επηρεάζει την αξιοπιστία της παράδοσης των µηνυµάτων. Το παραπάνω µειονέκτηµα προκύπτει από το γεγονός ότι τα SIP Transactions, χειρίζονται τις αναµεταδόσεις των µηνυµάτων όταν χρησιµοποιείται µη αξιόπιστο µέσο µεταφοράς, όπως το UDP. Επιπλέον, οι stateless proxy servers δεν υποστηρίζουν την λειτουργία forking για την διανοµή ενός µηνύµατος σε πολλαπλούς χρήστες. Παρόλα τα µειονεκτήµατα, το βασικό πλεονέκτηµα των stateless proxy servers είναι η απλότητά τους, που τους δίνει την δυνατότητα να χρησιµοποιηθούν ως load balancers, message translators και routers. Statefull Proxy Servers: Είναι Proxy Servers οι οποίοι είναι πιο σύνθετοι από τους stateless proxies, λόγω του γεγονότος ότι αποθηκεύουν τα εισερχόµενα µηνύµατα και δηµιουργούν ένα εσωτερικό state, το οποίο διατηρείται µέχρι να ολοκληρωθεί το σχετικό SIP Transaction, το οποίο καθορίζει τις απαραίτητες συναλλαγές, ανταλλαγές και αναµεταδόσεις µηνυµάτων για την εγκατάσταση ή τον τερµατισµό µιας κλήσης. Λόγω του ότι τα SIP Transactions που είναι υπεύθυνα για την εγκατάσταση µιας κλήσης έχουν εκτεταµένη διάρκεια, καθιστούν περιορισµένη τη συνολική απόδοση των statefull proxies. Αν εξαιρέσει κανείς το παραπάνω µειονέκτηµα, οι statefull proxies έχουν µια σειρά από σηµαντικά πλεονεκτήµατα. Αυτά είναι: Υποστήριξη της δυνατότητας forking για την µετάδοση SIP µηνυµάτων σε πολλαπλούς αποδέκτες. Εφόσον διατηρείται ένα εσωτερικό state µε την καταγραφή των µηνυµάτων που έχουν παραληφθεί ή έχουν αποσταλεί, υποστηρίζεται η λειτουργία της αναµετάδοσης µηνυµάτων, εξασφαλίζοντας την αξιοπιστία σε ένα δίκτυο που χρησιµοποιεί µη αξιόπιστο πρωτόκολλο µεταφοράς, όπως το UDP. Εκτέλεση πολύπλοκων µεθόδων εντοπισµού τελικών χρηστών για την προώθηση SIP µηνυµάτων, όπως για παράδειγµα redirection ενός µηνύµατος σε εναλλακτική τοποθεσία. Υποστήριξη πολύπλοκων δικτυακών λειτουργιών, όπως NAT traversal. Ένα χαρακτηριστικό configuration ενός SIP δικτύου είναι αυτό που φαίνεται στο Σχήµα 2. Υποθέστε ότι υπάρχουν δύο επιχειρήσεις Α και Β και κάθε µία από αυτές έχει έναν SIP Proxy Server που εξυπηρετεί τους χρήστες της επιχείρησης. Έστω, ότι ο υπάλληλος Joe της επιχείρησης A επιθυµεί να καλέσει τον υπάλληλο Bob της επιχείρησης B. Ο Joe στέλνει ένα INVITE SIP request στον Proxy Server της επιχείρησής του, διότι δεν γνωρίζει το routing που πρέπει να ακολουθηθεί για να φθάσει το µήνυµα στον χρήση Bob. Την απαραίτητη δροµολόγηση αναλαµβάνει ο Proxy Server της επιχείρησης Α, ο οποίος όταν αντιληφθεί πως το INVITE request

15 δεν απευθύνεται σε κάποιον χρήση του domain που ελέγχει, µε χρήση DNS services εντοπίζει και προωθεί το µήνυµα στον proxy server του domain που ανήκει ο χρήστης Bob. Σχήµα 2: Αρχικοποίηση κλήσης µέσω SIP Proxy Servers SIP Registrar Servers Ένας SIP Registrar Server είναι µια ειδική SIP οντότητα που λαµβάνει αιτήσεις εισόδου στο δίκτυο SIP -µέσω SIP REGISTER requests- από τους χρήστες που ανήκουν στο domain που ελέγχει, εξάγει πληροφορίες για την τρέχουσα θέση τους (IP διεύθυνση, port number και όνοµα χρήστη) και δηµιουργεί εγγραφές µε αυτές τις πληροφορίες που τις αποθηκεύει σε µια βάση δεδοµένων. Για παράδειγµα, η λογική διεύθυνση του χρήστη guest, αντιστοιχείται για παράδειγµα στη φυσική διεύθυνση η οποία περιέχει πληροφορία για την τρέχουσα θέση του. Έτσι, ένας SIP Proxy Server µπορεί να επικοινωνήσει µε τον Registrar Server για να ανακτήσει πληροφορίες για την τρέχουσα θέση χρηστών, µε σκοπό να τους προωθήσει SIP µηνύµατα που τους αντιστοιχούν SIP Redirect Servers Ένας SIP Redirect Server είναι µια SIP οντότητα που ενεργοποιείται όταν ένας χρήστης έχει µετακινηθεί προσωρινά ή µόνιµα σε νέα τοποθεσία και ταυτόχρονα έχει αλλάξει η λογική του διεύθυνση. Μια τέτοια περίπτωση µπορεί να συµβεί όταν ένας χρήστης µετακινηθεί για παράδειγµα από το σπίτι του στο γραφείο του. Στην περίπτωση που ένας χρήστης προσπαθεί να επικοινωνήσει µε τον χρήστη που µετακινήθηκε αποστέλλοντάς του ένα INVITE request, ο SIP Redirect Server που λαµβάνει το request απαντά µε µία λίστα πιθανών εναλλακτικών λογικών

16 διευθύνσεων που µπορεί να βρίσκεται ο χρήστης. Η δυνατότητα αυτή επιτυγχάνεται από τον Redirect Server αναζητώντας τον παραλήπτη του αρχικού request στη βάση δεδοµένων που περιέχει εγγραφές τρέχουσας θέσης χρηστών, η οποία έχει δηµιουργηθεί και ενηµερώνεται από τον Registrar Server. 2.3 Μηνύµατα και Μέθοδοι SIP Στην ενότητα αυτή θα ασχοληθούµε µε τα είδη των SIP µηνυµάτων, τη σύνταξή τους, καθώς και τα πεδία (header fields) που τα αποτελούν. Όπως έχει ήδη αναφερθεί, τα SIP µηνύµατα είναι text µηνύµατα, µε σύνταξη που είναι κοντά στην φυσική µας γλώσσα, κάτι που ενισχύει την απλότητα και τη γρήγορη κατανόησή τους. Ένα µήνυµα SIP αποτελείται από τη γραµµή έναρξης (start line), τις επικεφαλίδες (headers) και ένα σώµα (body), όπως φαίνεται στο Σχήµα 3. Στις επόµενες υποενότητες ακολουθεί µια σύντοµη παρουσίαση και επεξήγηση της δοµής ενός SIP µηνύµατος. Σχήµα 3: οµή ενός µηνύµατος SIP Unified Resource Identifier (URI) Η διευθυνσιοδότηση των χρηστών ενός SIP δικτύου πραγµατοποιείται χρησιµοποιώντας το Unified Resource Identifier (URI) syntax notation, που ορίζεται στο RFC Με βάση αυτό το notation µία SIP διεύθυνση µοιάζει ως εξής: Όπως µπορεί να παρατηρήσει κανείς, η παραπάνω διεύθυνση µοιάζει πολύ µε τις http διευθύνσεις, κάτι που είναι αναµενόµενο εφόσον και οι http διευθύνσεις ακολουθούν το URI notation. Σύµφωνα µε την URI σύνταξη, η διεύθυνση ξεκινά µε ένα scheme πριν από την άνω και κάτω τελεία (:). Στην περίπτωση των SIP διευθύνσεων το scheme είναι το sip, όπως φαίνεται και από την παραπάνω SIP διεύθυνση. Η ελάχιστη πληροφορία που πρέπει να ακολουθήσει το scheme και την άνω και κάτω τελεία, ώστε να είναι έγκυρη µια SIP διεύθυνση είναι το host name ή η διεύθυνση IP, της

17 SIP, όπως και στο παραπάνω παράδειγµα. Παρόλα αυτά το URI notation επιτρέπει την ύπαρξη περισσότερων προαιρετικών παραµέτρων. Έτσι, η γενική σύνταξη µιας SIP URI διεύθυνσης είναι η εξής: Το παράδειγµα της SIP διεύθυνσης της προηγούµενης σελίδας, χρησιµοποιεί µόνο τα user και host πεδία από την παραπάνω γενική σύνταξη των SIP URI διευθύνσεων Πεδία Επικεφαλίδων (Header Fields) Σε αυτή την υποενότητα θα παρουσιάσουµε τα βασικότερα πεδία επικεφαλίδων (header fields) που εµφανίζονται πιο συχνά σε ένα µήνυµα SIP. Από αυτά τα πεδία κάποια είναι υποχρεωτικά και άλλα προαιρετικά. Για περισσότερες λεπτοµέρειες και επιπλέον προαιρετικά πεδία επικεφαλίδων µπορεί κάποιος να ανατρέξει στο RFC 3261 στο οποίο παρουσιάζεται αναλυτικά το πρωτόκολλο SIP. Για να διευκολύνουµε την κατανόηση, η επεξήγηση των βασικών πεδίων επικεφαλίδων θα βασιστεί στο SIP request του Σχήµατος 3. Γραµµή Έναρξης (Start Line) Όπως µπορεί εύκολα να καταλάβει κανείς από το Σχήµα 3 η γραµµή έναρξης είναι η πρώτη γραµµή ενός SIP µηνύµατος, η οποία δηλώνει: Tην µέθοδο SIP ενός SIP request ή το status code ενός SIP response. Την έκδοση του πρωτοκόλλου SIP που χρησιµοποιείται, η οποία είναι SIP/2.0 για τα RFC 2543 ή RFC 3261 Compatible SIP endpoints. Το request-uri που απευθύνεται ένα SIP request. Για παράδειγµα, η γραµµή έναρξης του Σχήµατος 3 δηλώνει ένα INVITE request που απευθύνεται στον χρήστη µε URI address alice@alicedomain.com. Από την άλλη, αν το start line ενός SIP µηνύµατος είναι: SIP/ Ringing τότε το µήνυµα είναι ένα SIP response που υποδηλώνει ότι η συσκευή του χρήστη που απέστειλε το response «χτυπά»

18 Via Header Η επικεφαλίδα Via περιέχει πληροφορία για το πρωτόκολλο µεταφοράς ενός SIP request, καθώς και τη διεύθυνση του αποστολέα. Σε αυτό το σηµείο πρέπει να σηµειωθεί ότι σε ένα SIP response οι επικεφαλίδες Via αντιγράφονται από το σχετικό SIP request. Ένα Via Header αποτελείται από τα εξής στοιχεία: Την έκδοση του πρωτοκόλλου SIP (SIP/2.0). Το πρωτόκολλο µεταφοράς των µηνυµάτων SIP (UDP είναι η πιο συνηθισµένη περίπτωση). Την IP διεύθυνση ή το πλήρες Domain Name του αποστολέα του SIP request. Την παράµετρο branch, η οποία χρησιµοποιείται για την αναγνώριση του SIP Transaction που σχετίζεται το SIP request. Η παράµετρος branch πρέπει να είναι µοναδική για κάθε request που στέλνει ένας UAC, εκτός από τα CANCEL και ACK requests, διότι ένα CANCEL request πρέπει να έχει την ίδια branch παράµετρο µε την αντίστοιχη παράµετρο του request που «ακυρώνει», ενώ η παράµετρος branch ενός ACK request για ένα 2XX response είναι ίδια µε την branch παράµετρο του αρχικού INVITE request στο οποίο αντιστοιχεί. Για να υπάρχει συµβατότητα µεταξύ του RFC 3261 και παλαιότερων RFCs, η παράµετρος branch πρέπει να ξεκινά µε τους χαρακτήρες z9hg4bk. Στην πιο συνηθισµένη περίπτωσή, όπου µια SIP κλήση εγκαθίσταται έµµεσα µέσω ενός ή περισσότερων SIP Proxy Servers, κάθε server προσθέτει µία Via επικεφαλίδα στο SIP request που λαµβάνει, πριν το προωθήσει σε επόµενο server ή στον τελικό παραλήπτη. Max-Forwards Header Το Max Forward header είναι ένα υποχρεωτικό header που χρησιµοποιείται για την αποφυγή του φαινοµένου routing loops, όταν η εγκατάσταση µιας σύνδεσης πραγµατοποιείται µέσω SIP Proxy Servers. Έτσι η τιµή 70 στο SIP request του σχήµατος 3 υποδηλώνει ότι το µήνυµα µπορεί να διέλθει το πολύ από 70 SIP Proxy Servers πριν παραδοθεί στον τελικό παραλήπτη. Κάθε SIP Proxy server, που λαµβάνει και προωθεί ένα SIP µήνυµα µειώνει κατά ένα την τιµή του Max Forwards header. From Header Η επικεφαλίδα From είναι υποχρεωτική επικεφαλίδα η οποία προσδιορίζει τη λογική οντότητα, αλλά όχι την τρέχουσα φυσική διεύθυνση, του χρήστη που αποστέλλει ένα SIP request. Για παράδειγµα η λογική οντότητα που αποστέλλει το INVITE request του σχήµατος 3.3, η οποία

19 εµφανίζεται στην επικεφαλίδα From είναι παρόλο που η φυσική θέση του χρήστη είναι η bob-phone.bobdomain.com. Στην περίπτωση ενός SIP response, το From Header προσδιορίζει και πάλι τη λογική οντότητα του χρήστη που απέστειλε το σχετικό request, διότι το From Header ενός SIP response αντιγράφεται από το σχετικό request. Ένα From Header αποτελείται από τα εξής στοιχεία: Το Display Name, το οποίο µπορεί να εµφανίζεται µεταξύ double quotes και είναι προαιρετικό. Το SIP URI το οποίο προσδιορίζει τη λογική οντότητα του αποστολέα του request. Το URI περικλείεται από τους χαρακτήρες < και >, εκτός αν δεν χρησιµοποιείται το προαιρετικό Display Name. Την παράµετρο tag η οποία είναι υποχρεωτική και µοναδική για κάθε SIP µήνυµα που δηµιουργείται στα πλαίσια ενός SIP dialog. Η παράµετρος tag είναι πολύ σηµαντική παράµετρος διότι χρησιµοποιείται για την αντιστοίχηση SIP µηνυµάτων σε existing dialogs, για τα οποία θα αναφερθούµε σε επόµενη ενότητα. To Header Η επικεφαλίδα To είναι υποχρεωτική επικεφαλίδα η οποία προσδιορίζει την λογική οντότητα του αποδέκτη του request. Για παράδειγµα, το INVITE request του σχήµατος 3 προορίζεται για την λογική οντότητα του χρήστη alice@alicedomain.com. Η επικεφαλίδα To χρησιµοποιεί την ίδια σύνταξη όπως και η επικεφαλίδα From, µε την διαφορά ότι µπορεί να εκλείπει η παράµετρος tag στο αρχικό INVITE µιας κλήσης, το οποίο θα προστεθεί από τον αποδέκτη στο αρχικό provisional response που θα αποστείλει. Call-ID Header Η επικεφαλίδα Call-ID είναι υποχρεωτική επικεφαλίδα, η οποία περιέχει ένα µοναδικόπροσδιοριστικό για την κλήση. Το προσδιοριστικό αυτό αποτελείται από ένα µοναδικό αριθµό και την IP διεύθυνση ή το πλήρες DNS host name του UA που δηµιουργεί το request. Οι δύο παραπάνω παράµετροι χωρίζονται από τον Ο συνδυασµός του Call-ID header και των παραµέτρων tag των From και To επικεφαλίδων καθορίζουν πλήρως ένα SIP dialog

20 CSeq Header Η επικεφαλίδα Cseq είναι υποχρεωτική επικεφαλίδα που χρησιµεύει ως προσδιοριστικό για την αντιστοίχηση requests και responses που ανήκουν σε ένα µοναδικό SIP Transaction. Η επικεφαλίδα Cseq αποτελείτε από έναν αριθµό, καθώς και το όνοµα της µεθόδου του SIP request, τα οποία χωρίζονται από έναν κενό χαρακτήρα. Το αριθµητικό µέρος της επικεφαλίδας πρέπει να αυξάνεται κατά ένα, κάθε φορά που αποστέλλεται ένα request που ανήκει σε ένα existing dialog, εκτός από τα ACK και CANCEL requests, όπου το αριθµητικό µέρος είναι ίδιο µε αυτό του σχετικού request. Τέλος, αξίζει να σηµειωθεί ότι τα SIP responses πρέπει να έχουν την ίδια Cseq επικεφαλίδα µε αυτήν που εµφανίζεται στο σχετικό SIP request. Contact Header Η επικεφαλίδα Contact δεν ανήκει στα υποχρεωτικά headers ενός SIP µηνύµατος, αλλά παρέχει σηµαντική πληροφορία για την διεύθυνση που επιθυµεί ο αποστολέας να λάβει επόµενα requests. Η διεύθυνση αυτή εµφανίζεται µε την µορφή URI και πρέπει να είναι valid ακόµη και για εισερχόµενα requests που δεν θα ανήκουν στον τρέχον SIP dialog. Η επικεφαλίδα Contact χρησιµοποιεί την ίδια σύνταξη όπως και η επικεφαλίδα From, µε την διαφορά ότι δεν εµφανίζεται παράµετρος tag, αλλά µπορεί να εµφανίζονται άλλες παράµετροι όπως η παράµετρος expires που δηλώνει το χρονικό διάστηµα (σε seconds) που η Contact διεύθυνση είναι valid: Bob Άλλα Headers Οι επικεφαλίδες που εξετάσθηκαν παραπάνω είναι οι πιο συνηθισµένες και ταυτόχρονα απαραίτητες σε ένα SIP µήνυµα. Εκτός όµως από αυτές υπάρχουν αρκετές επιπλέον επικεφαλίδες, οι οποίες ορίζονται στο RFC Ενδεικτικά µπορούµε να αναφέρουµε τις επικεφαλίδες Content-Type και Content-Length, οι οποίες εµφανίζονται στο INVITE request του σχήµατος 3. Η πρώτη επικεφαλίδα χρησιµοποιείται για να δηλώσει τον media τύπο του Body τµήµατος του SIP µηνύµατος. Έτσι η επικεφαλίδα Content-Type: application/sdp δηλώνει ότι το σώµα του SIP µηνύµατος είναι ένα SDP µήνυµα. Τέλος, η επικεφαλίδα Content-Length χρησιµοποιείται για να δηλώσει το µέγεθος σε bytes του σώµατος του SIP µηνύµατος. Έτσι η επικεφαλίδα Content- Length: 142 δηλώνει ότι το SDP µήνυµα που περιέχει το SIP request είναι 142 bytes

21 2.3.3 SIP Requests Παρακάτω περιγράφονται τα requests που υποστηρίζονται από το πρωτόκολλο SIP: ACK: Ένα ACK request αποστέλλετε από έναν UA client για να επιβεβαιώσει την λήψη final response από έναν SIP server ή UA server, όπως 200 OK σε ένα INVITE request. BYE: Ένα BYE request αποστέλλετε είτε από τον caller agent είτε από τον callee agent µε σκοπό τον τερµατισµό της κλήσης. CANCEL: Ένα CANCEL request µπορεί να αποσταλεί µε σκοπό την ακύρωση της επεξεργασίας ενός request που στάλθηκε προηγουµένως, υπό την προϋπόθεση ότι ο SIP server που έλαβε το request δεν έχει προωθήσει final response στον UAC που το απέστειλε. INFO: Το INFO request ορίζεται στο RFC 2976 και χρησιµοποιείται για την µεταφορά πληροφοριών εν µέσω µιας κλήσης, χωρίς όµως να επηρεάζουν την τρέχουσα κατάστασή της. INVITE: Ένα INVITE request χρησιµοποιείται για την εγκατάσταση µιας κλήσης, καθώς και την αλλαγή των παραµέτρων µιας εν εξελίξει κλήσης. MESSAGE: Το MESSAGE request ορίζεται στο RFC 3428 και χρησιµοποιείται για την αποστολή Instant Messages. NOTIFY: Το NOTIFY request ορίζεται στο RFC 3265 και χρησιµοποιείται για την αποστολή event notifications. OPTIONS: Ένας UA client αποστέλλει ένα OPTION request σε έναν SIP server µε σκοπό να µάθει για τις SIP µεθόδους που υποστηρίζει ο server. Ο SIP server, µέσω ενός SIP response (συνήθως ένα 200 OK) απαντά µε µία λίστα που περιέχει τις µεθόδους που υποστηρίζει. Επιπλέον, ένα OPTIONS request µπορεί να αποσταλεί από ένα UAC προς έναν UAS ζητώντας να µάθει εκτός από τις µεθόδους που υποστηρίζει και τα media capabilities του UAS, καθώς επίσης και τον τρόπο που θα αποκρινόταν στην αποστολή ενός INVITE request. PRACK: Το PRACK request ορίζεται στο RFC 3262 και χρησιµοποιείται για την εφαρµογή αξιοπιστίας στην αποστολή provisional responses (1XX responses). REFER: Το REFER request ορίζεται στο RFC 3515 και χρησιµοποιείται για session redirection. REGISTER: Το REGISTER request αποστέλλεται από έναν UA προς έναν SIP Registrar Server, ώστε να καταχωρηθεί η τρέχουσα θέσης του UA στον υπεύθυνο Location Server. SUBSCRIBE: Το SUBSCRIBE request ορίζεται στο RFC 3265 και χρησιµοποιείται από

22 έναν UA µε σκοπό να αιτηθεί την λήψη συγκεκριµένων event notifications. UPDATE: Το UPDATE request ορίζεται στο RFC 3311 και χρησιµοποιείται µε σκοπό την αλλαγή των media παραµέτρων µιας κλήσης για την οποία δεν έχει αποσταλεί ή ληφθεί final response (early dialogs) SIP Responses Ένας SIP Server ανταποκρίνεται σε ένα SIP request µε ένα ή περισσότερα SIP responses. Υπάρχουν έξη διαφορετικές κατηγορίες responses. Όλες οι κατηγορίες εκτός από την πρώτη (2XX, 3XX, 4XX, 5XX και 6XX) είναι final responses, τα οποία ολοκληρώνουν µια συναλλαγή SIP. Από την άλλη µεριά τα provisional responses (1ΧΧ) αποτελούν προσωρινές απαντήσεις, οι οποίες απλά δηλώνουν την πρόοδο της επεξεργασίας ενός SIP request. Κάθε SIP response αποτελείται από τρία ακέραια ψηφία, από τα οποία το πρώτο καθορίζει το είδος της απάντησης, ενώ τα υπόλοιπα δύο είναι συγκεκριµένα για κάθε response. Θεωρήστε για παράδειγµα το response 486 Busy Here. Το ψηφίο 4 δηλώνει την κατηγορία του response, η οποία σε αυτή την περίπτωση είναι Client Failure, ενώ τα ψηφία 86 είναι µοναδικά για αυτό το response. Επιπλέον, η πρόταση Busy Here ονοµάζεται reason phrase και αποτελεί µία σύντοµη text περιγραφή του SIP response. Τα τρία ψηφία µαζί µε το reason phrase και την έκδοση του πρωτοκόλλου SIP αποτελούν την Start Line ενός SIP response: SIP/ Busy Here Αν εξαιρέσουµε την Start Line, το υπόλοιπο µήνυµα ακολουθεί τη δοµή που ακολουθεί ένα SIP request. Μάλιστα, το µεγαλύτερο µέρος των επικεφαλίδων, καθώς και του σώµατος ενός SIP response αντιγράφεται από το σχετικό SIP request. Αξίζει να σηµειωθεί ότι, όπως και στην περίπτωση των SIP headers, οι εκάστοτε SIP υλοποιήσεις δεν είναι απαραίτητο να υποστηρίζουν όλα τα SIP responses. Ωστόσο, κάθε εφαρµογή πρέπει να είναι σε θέση να αναγνωρίζει τουλάχιστον την κατηγορία που ανήκει το SIP response. Όπως αναφέρθηκε και προηγουµένως, έως τώρα υπάρχουν έξι κατηγορίες SIP responses. Στον Πίνακα 1 φαίνονται τα περισσότερο συνηθισµένα SIP responses, ταξινοµηµένα σύµφωνα µε την κατηγορία που ανήκουν, καθώς και µια σύντοµη περιγραφή της κάθε κατηγορίας

23 SIP Responses 100 e.g. 100 Trying, 180 Ringing 200 e.g. 200 OK, 202 Accepted 300 e.g. 302 Moved Temporarily 400 e.g. 404 Not Found, 482 Loop Detected 500 e.g. 501 Not Implemented 600 e.g. 603 Decline 2.4 οµή του Πρωτοκόλλου SIP Το SIP είναι ένα δοµηµένο σε στρώµατα πρωτόκολλο σηµατοδοσίας, κάτι που σηµαίνει ότι η συµπεριφορά του καθορίζεται από την συµπεριφορά κάθε ανεξάρτητου στρώµατος που το αποτελεί. Όταν λέµε ότι µία οντότητα SIP περιέχει ένα στρώµα του πρωτοκόλλου, εννοούµε ότι η οντότητα «υπακούει» στο σύνολο των κανόνων που καθορίζονται από εκείνο το στρώµα Στρώµατα του Πρωτοκόλλου SIP Τα στρώµατα (layers) του πρωτοκόλλου SIP είναι τα ακόλουθα: Syntax and Encoding Layer: Είναι το κατώτερο στρώµα του πρωτοκόλλου SIP και είναι υπεύθυνο για τη σύνταξη και την κωδικοποίησή των SIP µηνυµάτων, η οποία ακολουθεί τη σύνταξη των HTTP/1.1 µηνυµάτων, ενώ το set των χαρακτήρων που χρησιµοποιούνται είναι ISO µε UTF-8 κωδικοποίηση. Επιπλέον, κάθε γραµµή ενός SIP µηνύµατος τερµατίζεται µε Carriage Return, Line Feed χαρακτήρες (CR-LF). Transport Layer: Είναι το δεύτερο στρώµα, το οποίο είναι υπεύθυνο για την µεταφορά των SIP µηνυµάτων µέσω του IP δικτύου. Όλες οι οντότητες SIP περιέχουν ένα στρώµα µεταφοράς. Transaction Layer: Είναι το τρίτο στρώµα του πρωτοκόλλου SIP και είναι απαραίτητο σε κάθε SIP οντότητα, διότι καθορίζει τις απαραίτητες συναλλαγές µεταξύ τους. Μια συναλλαγή είναι ένα αίτηµα (request) που στέλνεται από ένα client transaction σε ένα server transaction, µαζί µε όλες τις απαντήσεις (responses) που ακολουθούν και αποστέλλονται από το server transaction πίσω προς το client transaction. Οι λειτουργίες που διαχειρίζεται το transaction layer είναι: Η πραγµατοποίηση των απαραίτητων αναµεταδόσεων µηνυµάτων στην περίπτωση που χρησιµοποιείται ένα µη αξιόπιστο πρωτόκολλο µεταφοράς, όπως το UDP. Η διαχείριση των timers οι οποίοι καθορίζουν τα χρονικά πλαίσια των αναµεταδόσεων

24 Η διαδικασία αντιστοίχησης SIP µηνυµάτων που λαµβάνονται από το δίκτυο µε τα αντίστοιχα transactions που βρίσκονται σε εξέλιξη. Όπως αναφέρθηκε και προηγουµένως, ένα SIP transaction αποτελείται από ένα SIP request και όλα τα σχετικά SIP responses που ακολουθούν. Στην περίπτωση που το αρχικό request είναι ένα INVITE request, τότε τo transaction που θα ακολουθήσει είναι ένα INVITE transaction, ενώ σε όλες τις άλλες περιπτώσεις (εκτός από το ACK request) τo transaction που θα ακολουθήσει είναι ένα NON-INVITE transaction. Όπως θα δούµε στις επόµενες υποενότητες το ACK request δεν µπορεί να ξεκινήσει ένα transaction, αλλά χρησιµοποιείται µόνο για να επιβεβαιώσει την λήψη responses σε προηγούµενα requests. Επιπλέον, ανάλογα µε το αν ένα transaction αρχικοποιείται λόγω αποστολής ή λήψης SIP request, τα transactions χωρίζονται σε client και server transactions, αντίστοιχα. Transaction User Layer: Είναι το ανώτερο στρώµα του πρωτοκόλλου SIP το οποίο είναι υπεύθυνο για την διαχείριση των οντοτήτων SIP, εκτός από τους stateless SIP Proxy Servers. Όταν ένα Transaction User (TU) επιθυµεί να στείλει ένα SIP request, δηµιουργεί ένα client transaction µε παραµέτρους το request, καθώς και την IP διεύθυνση και port number του προορισµού. Στη συνέχεια το transaction και transport layer αναλαµβάνουν την αξιόπιστη µετάδοση του SIP request στον προορισµό του. Να σηµειωθεί ότι ένας TU που δηµιουργεί ένα client transaction µπορεί επίσης να το ακυρώσει, ζητώντας στην ουσία την ακύρωση της επεξεργασίας του SIP request από το SIP UAS ή τον ενδιάµεσο Proxy που το έλαβε. Κάτι τέτοιο πρακτικά γίνεται µε την αποστολή ενός CANCEL request SIP Transactions Όπως αναφέρθηκε στην προηγούµενη υποενότητα, τα SIP transactions χωρίζονται σε κατηγορίες ανάλογα µε το αν ένα transaction αρχικοποιείται λόγω αποστολής ή λήψης SIP request (client και server transaction). Εποµένως, είναι φανερό πως τα SIP Transactions σχετίζονται µε SIP µηνύµατα. Έτσι, κάθε transaction αναγνωρίζεται από παραµέτρους που εµφανίζονται σε ένα SIP µήνυµα όπως: η branch παράµετρος του Via Header και το Cseq number και method. Χρησιµοποιώντας αυτές τις παραµέτρους είναι δυνατόν να γίνει αντιστοίχηση ενός SIP µηνύµατος µε ένα SIP Transaction. Κάτι τέτοιο είναι απαραίτητο, όπως θα γίνει κατανοητό στη συνέχεια. Μια επιπλέον κατηγοριοποίηση των SIP transactions έχει να κάνει µε το αν το αρχικό SIP request που προκαλεί την δηµιουργία του SIP transaction είναι ένα INVITE ή non INVITE, αντίστοιχα. Η κατηγοριοποίηση αυτή έχει γίνει για το λόγω ότι ένα INVITE transaction είναι

25 διαφορετικό από τα non-invite transactions, λόγω της εκτεταµένης διάρκειάς του, εφόσον είναι απαραίτητη η αλληλεπίδραση µε το χρήστη για την απόκριση σε ένα INVITE request (π.χ. σήκωµα του ακουστικού). Για το λόγω αυτό τα INVITE transactions ακολουθούν µία three-way handshake διαδικασία για να ολοκληρωθούν, σε αντίθεση µε τα non-invite transactions, τα οποία ολοκληρώνονται άµεσα και αυτόµατα, ακολουθώντας µία two-way handshake διαδικασία. Με βάση τις παραπάνω κατηγοριοποιήσεις υπάρχουν τέσσερα είδη SIP transactions, τα οποία εξετάζονται παρακάτω. INVITE Client Transactions Στην κατηγορία αυτή ανήκουν τα SIP transactions τα οποία δηµιουργούνται από ένα SIP UAC, όταν επιθυµεί την αποστολή ενός INVITE request, για την εγκατάσταση µιας VoIP κλήσης. Ένα INVITE Client Transaction αποτελείται από µία three-way handshake διαδικασία. Το transaction ξεκινά όταν ο χρήστης δηµιουργήσει ένα INVITE request και το µεταβιβάσει στο Transaction Layer του πρωτοκόλλου. Η three-way handshake διαδικασία, που λαµβάνει χώρα στο transaction Layer, περιλαµβάνει την αποστολή του INVITE request, την λήψη ενός τελικού response και την αποστολή ενός ACK request για την επιβεβαίωση της λήψης. Επιπλέον, όταν χρησιµοποιείται µη αξιόπιστο πρωτόκολλο µεταφοράς, όπως UDP, το transaction παραδίδει για αναµετάδοση τo INVITE request στο transport layer του πρωτοκόλλου, ανά διαστήµατα που ξεκινούν από 500 ms (T1) και διπλασιάζονται µετά από κάθε αναµετάδοση. Στην περίπτωση που χρησιµοποιείται αξιόπιστο πρωτόκολλο µεταφοράς, όπως TCP, η παραπάνω διαδικασία δεν ισχύει και εποµένως το request δεν µεταδίδεται παραπάνω από µία φορά

26 Σχήµα 4: Τυπικό παράδειγµα λειτουργίας ενός INVITE Client Transaction. Στη συνέχεια, όταν ληφθεί ένα provisional response (π.χ. 180 Ringing response), οι αναµεταδόσεις του αρχικού INVITE request σταµατούν και ο χρήστης αναµένει την λήψη ενός τελικού response, που θα δείχνει την αποδοχή ή την απόρριψη της κλήσης από τον αποµακρυσµένο user. Στην περίπτωση που έχουν λάβει χώρα επτά αναµεταδόσεις του αρχικού INVITE και δεν έχει ληφθεί provisional response, τότε το transaction τερµατίζει αυτόµατα την λειτουργία του, ενώ πιθανά επιπλέον provisional responses που καταφθάνουν στο transport layer και αντιστοιχούνται στο ίδιο transaction, δεν λαµβάνονται υπόψιν. Τέλος, όταν ο αποµακρυσµένος χρήστης αποφασίσει να στείλει ένα τελικό non-2xx response, το client transaction παραδίδει προς µετάδοση στο transport layer ένα ACK request, το οποίο αναµεταδίδεται κάθε φορά που λαµβάνεται επανάληψη του non-2xx response. Μετά από ένα καθορισµένο χρονικό διάστηµα το transaction τερµατίζεται. Αντίθετα, η λήψη ενός τελικού 2XX response προκαλεί τον άµεσο τερµατισµό του transaction και η αποστολή του ACK request αναλαµβάνεται από το υψηλότερο στρώµα του πρωτοκόλλου SIP, που είναι το Transaction User Layer. Στο Σχήµα 4 φαίνεται ένα τυπικό παράδειγµα λειτουργίας ενός INVITE Client Transaction

27 Non-INVITE Client Transactions Σχήµα 5: Τυπικό παράδειγµα λειτουργίας ενός non-invite Client Transaction. Στην κατηγορία αυτή ανήκουν τα SIP transactions τα οποία δηµιουργούνται από ένα SIP UAC, όταν επιθυµεί την αποστολή ενός request, εκτός από INVITE και ACK. Τέτοια requests µπορεί να είναι για παράδειγµα BYE ή CANCEL request για την ακύρωση εγκατάστασης ή τον τερµατισµό µιας VoIP κλήσης. Η βασική αρχή λειτουργίας των Non- INVITE και Client Transactions είναι η χρήση two-way handshake για την ολοκλήρωσή τους, σε αντίθεση µε τα INVITE Client Transactions, λόγω του ότι δεν χρησιµοποιείται το ACK request για την επιβεβαίωση των τελικών responses. Στην περίπτωση που χρησιµοποιείται µη αξιόπιστο πρωτόκολλο µεταφοράς, όπως UDP, το transaction παραδίδει για αναµετάδοση τo non-invite request στο transport layer του πρωτοκόλλου, ανά διαστήµατα που ξεκινούν από 500 ms (T1) και διπλασιάζονται µετά από κάθε αναµετάδοση, ενώ οι αναµεταδόσεις σταµατούν όταν το διάστηµα αναµετάδοσης φτάσει τα 4 s (T2). Εάν εν τω µεταξύ ληφθεί ένα provisional response, τότε οι αναµεταδόσεις του request συνεχίζονται, αυτή τη φορά όµως ανά διαστήµατα που ξεκινούν από T2 ms και διπλασιάζονται µετά από κάθε αναµετάδοση. Αντίθετα από ένα INVITE Client Transaction, ένα non-invite Client Transaction δεν προβλέπει κανέναν ειδικό χειρισµό για την λήψη τελικών 2XX responses. Στο Σχήµα 5 φαίνεται ένα τυπικό παράδειγµα λειτουργίας ενός INVITE Client Transaction

28 INVITE Server Transactions Στην κατηγορία αυτή ανήκουν τα SIP transactions τα οποία δηµιουργούνται από ένα SIP UAS, όταν λαµβάνει ένα INVITE request από έναν αποµακρυσµένο UAC, µε σκοπό την εγκατάσταση µιας VoIP κλήσης. Ένα INVITE Server Transaction αποτελείται από µία threeway handshake διαδικασία και ξεκινά όταν το INVITE request παραδίδεται από το Transport Layer στο Transaction Layer του πρωτοκόλλου SIP. Σχήµα 6: Τυπικό παράδειγµα λειτουργίας ενός INVITE Server Transaction. Στην περίπτωση που χρησιµοποιείται µη αξιόπιστο πρωτόκολλο µεταφοράς, όπως UDP και έχει αποσταλεί provisional response (π.χ. 180 Ringing response, το οποίο σηµαίνει ότι το τηλέφωνο του τοπικού user χτυπά), το transaction παραδίδει για αναµετάδοση στο transport layer τo τελευταίο provisional response κάθε φορά που λαµβάνεται µία επανάληψη του αρχικού INVITE request. Ο χειρισµός των τελικών responses από ένα INVITE Server Transaction είναι διαφορετικός από το χειρισµό των provisional responses. Συγκεκριµένα, τα τελικά responses εκτός από τα 2ΧΧ, επαναδροµολογούνται κάθε 500 ms, για όσο χρονικό διάστηµα δεν λαµβάνεται ένα ACK request. Και σε αυτή την περίπτωση, το χρονικό διάστηµα µεταξύ δύο αναµεταδόσεων διπλασιάζεται µετά από κάθε αναµετάδοση, ενώ οι αναµεταδόσεις σταµατούν µετά την έβδοµη επανάληψη, ή αν ληφθεί ένα matching BYE request, στην περίπτωση του 200 OK response, ή ένα matching CANCEL request στην περίπτωση των 3XX, 4XX, 5XX, 6XX responses. Να σηµειωθεί ότι η αναµετάδοση των 200 OK responses σε INVITE requests δεν πραγµατοποιείται από το Transaction Layer, αλλά το αναλαµβάνει το Transaction User Layer. Στο Σχήµα 6 φαίνεται ένα τυπικό παράδειγµα λειτουργίας ενός INVITE Server Transaction

29 Non-INVITE Server Transactions Στην κατηγορία αυτή ανήκουν τα SIP transactions τα οποία δηµιουργούνται από ένα SIP UAS, όταν λαµβάνει ένα non-invite request από έναν αποµακρυσµένο UAC, όπως CANCEL ή BYE request. Σχήµα 7: Τυπικό παράδειγµα λειτουργίας ενός non-invite Server Transaction. Όπως και στην περίπτωση των Non-INVITE Client Transactions και σε αυτή την περίπτωση χρησιµοποιείται two-way handshake διαδικασία για την ολοκλήρωσή τους, επειδή δεν λαµβάνεται ACK request για την επιβεβαίωση τελικών responses που στάλθηκαν προηγουµένως. Έτσι, στην περίπτωση που χρησιµοποιείται µη αξιόπιστη σύνδεση για την ανταλλαγή δεδοµένων, κατά την διάρκεια ενός non-invite Server Transaction αναµεταδίδεται το τελευταίο responseανεξάρτητα από το αν είναι τελικό ή provisional- κάθε φορά που λαµβάνεται µια αναµετάδοση του αρχικού request. Στο Σχήµα 7 φαίνεται ένα τυπικό παράδειγµα λειτουργίας ενός non-invite Server Transaction SIP Dialogs Μέχρι στιγµής έχουµε µιλήσει για τα SIP Transactions, τα οποία συσχετίζουν ένα SIP request µε όλα τα σχετικά responses που ακολουθούν. Έτσι, ένα INVITE request συσχετίζεται µέσω ενός INVITE Transaction µε όλα τα responses που ακολουθούν για την εγκατάσταση µιας κλήσης, όπως συµβαίνει επίσης και µε ένα BYE request που αποστέλλεται µε σκοπό τον

30 τερµατισµό της κλήσης και συσχετίζεται µε ένα non-invite request. Όπως είναι φανερό και τα δύο παραπάνω transactions θα εκτελεστούν για την ίδια κλήση. Αυτά τα δύο transactions λοιπόν, πρέπει να σχετίζονται µεταξύ τους, εφόσον αφορούν την επικοινωνία µεταξύ δύο τελικών χρηστών. Ο συσχετισµός αυτός πραγµατοποιείται µέσω των SIP dialogs. Ένα SIP Dialog ορίζει µία peer-to-peer επικοινωνία µεταξύ δύο SIP User Agents, η οποία παραµένει ενεργή για το χρονικό διάστηµα που οι SIP User Agents επικοινωνούν µεταξύ τους. Η βασικότερη λειτουργία των SIP dialogs είναι η διατήρηση της σωστής αλληλουχίας των SIP µηνυµάτων που ανταλλάσσονται. Στο Σχήµα 8 φαίνεται ένα παράδειγµα για τον τρόπο που σχετίζονται τα SIP transactions µε τα SIP µηνύµατα, καθώς τον τρόπο που σχετίζονται τα SIP transactions σε ένα SIP Dialog κατά την διάρκεια µιας επικοινωνίας µεταξύ δύο χρηστών. Σχήµα 8: SIP Dialogs και SIP Transactions. Σύµφωνα µε το RFC 3261, η αρχικοποίηση ενός SIP Dialog µπορεί να πραγµατοποιηθεί µόνο µέσω της µεθόδου INVITE. Επιπλέον, η αποστολή ενός SIP request από ένα UAC µέσα στα πλαίσια ενός εγκατεστηµένου SIP Dialog, πρέπει να γίνεταιακολουθώντας συγκεκριµένους κανόνες οι οποίοι επίσης καθορίζονται στο RFC Ένα SIP Dialog προσδιορίζεται από ένα Dialog ID, το οποίο προκύπτει από το συνδυασµό της τιµής του Call-ID Header του INVITE request που αρχικοποίησε το SIP Dialog, καθώς και των tag παραµέτρων των remote και local User Agents που συµµετέχουν στην peer-to-peer επικοινωνία και οι οποίες εµφανίζονται στα To και From Headers των SIP µηνυµάτων, αντίστοιχα. Με βάση τον παραπάνω συσχετισµό είναι εύκολο να γίνει αντιστοίχηση των εισερχόµενων SIP µηνυµάτων σε open SIP Dialogs, αλλά και να δηµιουργηθούν νέα προς αποστολή µηνύµατα στα πλαίσια του διαλόγου αυτού, δίνοντας έτσι

31 την δυνατότητα για ανταλλαγή δεδοµένων και πληροφοριών εν µέσω µιας κλήσης. Τέτοια µηνύµατα είναι για παράδειγµα το OPTIONS request, το οποίο αποστέλλεται µε σκοπό να διαπιστωθούν media capabilities του συνοµιλητή, ενώ η κλήση είναι σε εξέλιξη. Η αρχικοποίηση ενός SIP Dialog πραγµατοποιείται: Κατά την αποστολή ή λήψη provisional responses που περιέχουν ένα tag parameter στο To Header, ή κατά την αποστολή ή λήψη 2XX responses σε INVITE requests. Έτσι, ένας UAC αρχικοποιεί ένα SIP Dialog όταν λάβει το πρώτο non-failure response για το INVITE που απέστειλε, ενώ ένας UAS αρχικοποιεί ένα SIP Dialog όταν αποστείλει το πρώτο non-failure response για το INVITE που έλαβε. Με λίγα λόγια, ένα SIP Dialog αρχικοποιείται µόνο στην περίπτωση µη άµεσης αποτυχίας (αποστολή ή λήψη τελικού non-2xx response) εγκατάστασης µιας κλήσης µέσω ενός INVITE request. Ένα SIP Dialog που αρχικοποιείται λόγω αποστολής ή λήψης provisional response καλείται early dialog, διαφορετικά καλείται confirmed dialog. Ο τερµατισµός ενός SIP Dialog, πραγµατοποιείται είτε µε την αποστολή ή λήψη BYE request, είτε µε την αποστολή ή λήψη τελικού non-2xx response που αφορά το αρχικό INVITE request. Για παράδειγµα, η λήψη 487 Busy Here response για ένα INVITE request, προκαλεί τον τερµατισµό του early SIP Dialog που δηµιουργήθηκε προηγουµένως, κατά τη λήψη 100 Trying response

32 Κεφάλαιο 3 Αρχιτεκτονικές Ανωνυµίας 3.1 Crowds Το Crowds επιτρέπει την ανάκτηση πληροφοριών από το Internet χωρίς να αποκαλύπτει πληροφορίες ιδιωτικότητας σε τρίτες οντότητες. Στόχος του Crowds είναι η ανώνυµη φυλλοµέτρηση, ώστε είτε η πληροφορία σχετικά µε το χρήστη, είτε η ίδια η πληροφορία που ανακτά από το δίκτυο, να παραµένει κρυφή από άλλους εξυπηρέτες και λοιπές οντότητες. Το πρόγραµµα Crowds αποτρέπει τους εξυπηρέτες να καταγράψουν πληροφορίες, όπως η διεύθυνση IP και το όνοµα του domain, οι οποίες είναι δυνατόν να ταυτοποιήσουν το χρήστη. Επιπλέον, είναι δυνατό να αποκρύψει πληροφορίες όπως τη σελίδα από την οποία προήλθε ο χρήστης και τον τύπο υπολογιστή του χρήστη, καθώς και να αποκρύψει πληροφορίες σε όσους δυνητικά παρακολουθούν απευθείας τα διακινούµενα µηνύµατα από τον υπολογιστή του χρήστη. Το Crowds βασίζεται στην αρχική ιδέα ότι οι άνθρωποι εύκολα διατηρούν την ανωνυµία τους όταν κινούνται µέσα στο πλήθος. Με αυτό τον τρόπο, αντί να πραγµατοποιούν HTTP αιτήσεις διαµέσου µιας συγκεκριµένης τρίτης οντότητας, τις πραγµατοποιούν µέσω ενός πλήθους (crowd): το πλήθος που δηµιουργείται από τους χρήστες του Crowds, ανεξαρτήτως γεωγραφικής διασποράς, πραγµατοποιεί τις συναλλαγές στο Internet εκ µέρους των µελών του. Για να εγγραφεί κάποια οντότητα ως µέλος στο πλήθος, πρέπει να εκτελέσει µία διεργασία στον υπολογιστή της, η οποία ονοµάζεται Jondo (John Doe), υπονοώντας ένα τυχαίο και απρόσωπο άτοµο µέσα στο πλήθος. Συνεπώς, κάθε µέλος στο πλήθος αντιπροσωπεύεται από το Jondo που εκτελείται στον υπολογιστή του. Καθώς ξεκινά η διεργασία Jondo επικοινωνεί µε το πλήθος µέσω ενός πρωτοκόλλου, το οποίο µε τη σειρά του ενηµερώνει τόσο τα υπόλοιπα µέλη του πλήθους για τη νέα συµµετοχή, όσο και το ίδιο το νέο µέλος για τα υπόλοιπα µέλη του πλήθους. Ο χρήστης για να πραγµατοποιήσει αιτήσεις στο Internet πρέπει να ρυθµίσει στο φυλλοµετρητή του τη διεργασία αυτή ως πληρεξούσιο εξυπηρέτη για όλες τις δικτυακές του εφαρµογές. Έτσι, όταν δέχεται κάποια αίτηση από το φυλλοµετρητή, το Jondo επιλέγει τυχαία κάποιο µέλος του πλήθους και του αποστέλλει την αίτηση. Κάθε πακέτο επικοινωνίας αποστέλλεται απευθείας στη Jondo. Όταν ο χρήστης αιτηθεί χρήσης ενός Uniform Resource Locator - URL διαµέσου του φυλλοµετρητή του, η αίτηση ΗΤΤΡ για το συγκεκριµένο URL αποστέλλεται, αντί στον εξυπηρέτη της URL, στη Jondo. Η πιθανότητα για ένα µέλος να προωθήσει την αίτηση αυτή ξανά σε κάποιο µέλος του πλήθους, παρά να την προωθήσει απευθείας στον εξυπηρέτη, είναι µεγαλύτερη από 0.5. Οι χρήστες προωθούν τις αιτήσεις τους σε ένα τυχαία ορισµένο µέλος του πλήθους. Ούτε ο

33 τελικός εξυπηρέτης στον οποίο τελικά καταλήγει η αίτηση, ούτε τα µέλη του πλήθους είναι σε θέση να καθορίσουν από τη γνώση της πηγής της αίτησης, τα στοιχεία του αιτούντος χρήστη. Επιπλέον, παρέχεται συµπληρωµατική προστασία έναντι αυτών που µπορούν άµεσα να παρακολουθήσουν τα µηνύµατα που ανταλλάσσει ο υπολογιστής του χρήστη. Συγκεκριµένα, το σύστηµα Crowds κρύβει τις σελίδες που επισκέπτεται ή αιτείται ο χρήστης από οντότητες µε δικαιώµατα διαχειριστή π.χ. στο τοπικό ανάχωµα ασφάλειας του δικτύου του, αλλά και την ταυτότητά του από τα υπόλοιπα µέλη του πλήθους, τα οποία χρησιµοποιεί για να πετύχει το στόχο του. Η συνολική επικοινωνία µεταξύ των Jondos κρυπτογραφείται µε χρήση συµµετρικού συστήµατος µε µυστικό κλειδί, το οποίο διαµοιράζονται. Αρχές Λειτουργίας Στo πρωτόκολλο Crowds, το µονοπάτι των συνεργαζόµενων πληρεξούσιων υπηρεσιών επιλέγεται τυχαία βήµα προς βήµα καθώς η αρχική αίτηση προωθείται µέσω του πλήθους. Το µονοπάτι επιλέγεται από το πλήθος µία φορά και χρησιµοποιείται για όλες τις ανώνυµες επικοινωνίες από έναν αποστολέα, συχνά αποκαλούµενο ιδρυτή, σε κάθε παραλήπτη εντός µιας περιόδου είκοσι τεσσάρων ωρών (Σχήµα 9). Το Crowds ξεκινά µε την εκτέλεση ενός πρωτοκόλλου αρχικοποίησης. Όταν αυτό ολοκληρωθεί, ο αποστολέας γνωρίζει ένα µυστικό συµµετρικό κλειδί το οποίο γνωρίζουν και όσοι άλλοι Jondo συµπεριλαµβάνονται στο πλήθος. Για την αποστολή δεδοµένων, ο ιδρυτής δηµιουργεί και προωθεί ένα πακέτο, το οποίο περιλαµβάνει: ένα τυχαίο µονοπάτι που αναπαρίσταται µε p, την IP διεύθυνση του παραλήπτη γνωστή ως R, καθώς και τα δεδοµένα τα οποία είναι κρυπτογραφηµένα µε ένα κλειδί K ij, το οποίο διαµοιράζεται µε τον τυχαία επόµενο επιλεγµένο Jondo j: I j: {R, p, data} KIj Κάθε µέλος του πλήθους λαµβάνοντας ένα πακέτο µε ένα νέο id µονοπατιού, αποφασίζει τυχαία µε βάση µία πιθανότητα προώθησης 0.5 <= P f < 1 εάν θα το προωθήσει στον παραλήπτη ή σε κάποιο άλλο επιλεγµένο τυχαίο Jondo. Τελικά ο Jondo θα αποφασίσει αν θα προωθήσει το πακέτο στον παραλήπτη, βασισµένος στο P f. j R : p, data Όταν ο παραλήπτης λάβει το πακέτο, επιστρέφει ένα πακέτο απάντησης διαµέσου του αντίστροφου µονοπατιού της αίτησης. Τα επόµενα πακέτα µεταξύ του αποστολέα και του