DenkReiz

FDP trollt sich selbst

FB — Wed, 13 Apr 2011 12:45:36 +0000

Herrlich

Hartz IV – Die Büchse der Pandora

FB — Fri, 14 Jan 2011 01:41:51 +0000

Auf den Punkt gebracht

FB — Sun, 09 Jan 2011 01:24:12 +0000

Ans deutsche Volk, von Ulm bis Kiel:
Ihr esst zu oft! Ihr esst zu viel!
Ans deutsche Volk, von Thorn bis Trier:
Ihr seid zu faul! Zu faul seid ihr!

Und wenn sie auch den Lohn entzögen!
Und wenn der Schlaf verboten wär!
Und wenn sie euch so sehr belögen,
dass sich des Reiches Balken bögen!
Seid höflich und sagt Dankesehr.

Die Hände an die Hosennaht!
Stellt Kinder her! Die Nacht dem Staat!
Euch liegt der Rohrstock tief im Blut.
Die Augen rechts! Euch geht’s zu gut.

Ihr sollt nicht denken, wenn ihr sprecht!
Gehirn ist nichts für kleine Leute.
Den Millionären geht es schlecht.
Ein neuer Krieg käm ihnen recht,
So macht den Ärmsten doch die Freude!

Ihr seid zu frech und zu begabt!
Seid taktvoll, wenn ihr Hunger habt!
Rasiert euch besser! Werdet zart!
Ihr seid kein Volk von Lebensart.

Und wenn sie euch noch tiefer stießen
und würfen Steine hinterher!
Und wenn Sie euch verhaften ließen
und würden nach euch Scheiben schießen!
Sterbt höflich und sagt Dankesehr.

Erich Kästner, 1928

Zurück zur Steinzeit

FB — Sat, 23 Oct 2010 03:14:18 +0000

In ihrem Raubzug gegen die Kunden und Kreativen macht die Musikbranche auch vor den Kindern nicht mehr halt. So treibt seit einiger Zeit die GEMA für die VG Musikedition Gebühren ein und kassiert dabei auch Kindergärten ab. Hierzu ein eigener Erfahrungsbericht aus dem Leben einer Musikschule.

Die GEMA, ihres Zeichens eine der widerlichsten Institutionen auf deutschem Boden, macht mal wieder von sich reden. Sie agiert für die VG Musikedition als Inkassobüro und schickt ihre Steuervogte nun auch in Kindergärten.

Bisher ist mir die VG Musikedition nicht negativ aufgefallen, was sich aber seit einigen Monaten rapide geändert hat. Möglicherweise steckt dahinter der Wechsel in der Führungsspitze, wie Telepolis mutmaßt. Denn Ende letzten Jahres startete die VG Musikedition ihre Kampagne gegen die privaten Musikschulen und versucht seitdem, mittels verkappter Drohungen die klammen Kassen der Schulen weiter zu melken.

Da ich selbst an einer Musikschule aktiv bin, möchte ich euch den Erpresserbrief der VG Musikedition nicht vorenthalten. Vergrößern könnt ihr sie durch Draufklicken. Entschuldigt die Qualität (Handy-Cam).

Gehen wir das Ganze mal durch:

Das Schreiben der VG Musikedition (VGM) beginnt mit einem Verweis aufs Urheberrechtsgesetz, namentlich §53 Abs. 4a UrhG. Darauf basierend wird behauptet, dass das “Fotokopieren von Noten stets nur mit Einwilligung des Berechtigten (hier die VG Musikedition) zulässig” ist. Ohne jede Bescheidenheit beansprucht die VGM also mal kurz alle schriftlich niedergelegten musikalischen Werke für sich.

Kurz sacken lassen… weiter. Es werden Ausnahmen genannt, die da wären:

(Manuelles) Abschreiben der Noten
§53 Abs. 2 Satz 1 UrhG
Eigengebrauch bei einem seit mindestens zwei Jahren vergriffenen Werk

Wer nun dachte, das wäre ja einzusehen (und es steht ja auch im §53), wird eines besseren belehrt, denn “Ausnahmen spielen allerdings hier keine Rolle”. Die VGM beweist dies durch Behauptung (also gar nicht) und meint wohl jede Musikschule zu kennen. Dann der ganz dicke Hammer:

Danach ist das Fotokopieren von Noten praktisch verboten.

Auch das kurz mal sacken lassen: Die VGM sagt, sie habe Rechte an allen musikalischen Werken und das Fotokopieren eines Werks sei praktisch verboten.

Die (imho frei interpretierte) Gesetzeslage hält die VGM nicht überraschend für “sinnvoll”. Nach kurzem Heucheln von Verständnis für die Lage der Musikschulen wird die passende Lösung serviert:

Seit kurzem gibt es nun die Möglichkeit für Musikschulen, einen einfachen und konstengünstigen Lizenzvertrag mit der VG Musikedition als Inhaberin der entsprechenden Rechte abzuschließen, der das legale Kopieren von Noten ohne vorheriges aufwändiges Kontaktieren der Musikverlage in nachfolgend beschriebenem Umfang ermöglicht:

Kopien von so genannten “kleineren” Werken mit einer Spieldauer von max. 5 Minuten

Kopien von Teilen/Ausschnitten von Werken oder Ausgaben (max. 20% des gesamten Werkes bzw. der gesamten Ausgabe)

Kopien zum besseren Umblättern (Wendestellen)

Kopien für Juroren bei musikschulinternen Wettbewerben

Der vorgeschlagene Lizenzvertrag mit diesen Bedingungen kostet pro SchülerIn 15 Euro pro Jahr, unabhängig von der Nutzung. Ein freundliches Fazit findet sich noch am Ende:

Entweder eine Musikschule verwendet ausschließlich Originale, dann ist nichts Weiteres zu tun. Sollen aber zu bestimmten Zwecken Fotokopien von Noten (oder Liedtexten) – gleich welchen Umfangs – hergestellt werden, muss zwingend ein Lizenzvertrag mit der VG Musikedition geschlossen werden.

Selbstverständlich ist ein solcher Vertrag nicht akzeptabel. Bei meiner Musikschule liegt der Fall so, dass nur etwa ein Viertel aller Schüler Fotokopien in nennenswertem Umfang benötigt. Eine pauschale Zahlung für jeden Schüler ist ergo nicht nur unfair, sondern macht keinen Sinn. Im Endeffekt müssen dann also alle auf Fotokopien verzichten.

Damit aber nicht genug: Um bei Kontrollen nicht belangt zu werden, werden Schüler dazu angehalten, keine Fotokopien in den Unterricht mitzunehmen. Lehrer haben die Aufgabe, jede ausgehändigte Fotokopie wieder zurückzuverlangen und vom Schüler mitgebrachte Fotokopien einzuziehen. Im Ernstfall drohen empfindliche Strafen, weswegen die eh nicht hoch bezahlten Lehrer mit Argusaugen über das Unterrichtsmaterial wachen müssen. De facto läuft die Erpressung durch die VGM also auf eine Selbstzensur und eine beispiellose Paranoia hinaus.

Die Neuregelung führt den Musikunterricht zurück in die Steinzeit. Wenn man das Schutzgeld nicht zahlen kann oder will, sind laut vorliegenden Dokumenten nur noch handgeschriebene Kopien erlaubt oder autorisierte Materialien (sprich Originale, mit Erlaubnis desjenigen Verlags).

Aus dem Schreiben der Musikschule geht außerdem hervor, dass auch Tabs nicht mehr erlaubt sind. Dabei handelt es sich um Noten, die von vielen verschiedenen engagierten Leuten in stundenlangen Sessions (und in oft erstaunlicher Qualität) niedergeschrieben und dann kostenlos der Community zur Verfügung gestellt werden. Oft ist es so, dass Originale gar nicht existieren, da entsprechende Songbooks von keinem Verlag herausgegeben werden (würde sich nicht lohnen). Hin und wieder kam es sogar vor, dass solche Tabs sich plötzlich in kommerziellen Produkten wiederfanden (natürlich ohne Nennung des Autors).

Die Rechtslage gibt der VGM meines Erachtens dort recht, wo sie sich auf Fotokopien von verfügbaren Originalen bezieht. Das kommt sicherlich oft in Musikschulen vor. Ich wage allerdings zu behaupten, dass andere Formen noch weitaus häufiger sind. Im Fall der Kindergärten ist die Lage schließlich so, dass Kinderlieder allgemeines Kulturgut sind. Fotokopien von Liedbüchern sind freilich nicht ohne weiteres erlaubt, aber Kopien von im Internet frei verfügbaren Kinderliedern (z.B. in Tabs) können doch nicht illegal sein? Gleiches gilt für die eben beschriebenen modernen Werke aus Nischen der Musikkultur, die überhaupt nicht in offiziellen Werken vertreten sind und nur durch den Schweiß der Internetcommunity der Allgemeinheit zur Verfügung stehen. Wenn die VGM sich einfach dieses freie öffentliche geistige Eigentum aneignet, ist das nichts anderes als Enteignung.

Es geht allerdings auch anders. Ich war lange Jahre in der Powertab-Gemeinde aktiv (ein einfaches kostenloses Notensatzprogramm), die wegen der frei verfügbaren Tabs einen längeren Streit mit der Musikindustrie ausfocht. Nach einer hochdotierten Klage und der darauf folgenden erzwungenen mehrmonatigen Downtime konnte schließlich ein Kompromiss erzielt werden, der die Plattform unter den Schutz eines Musikverlags stellte.

Eine solche einvernehmliche Lösung, die für beide Seiten einen Gewinn bedeutet, ist mit der VGM noch in weiter Ferne. Nach einer langen Ära des Laissez-Faire setzt sie nun auf Konfrontation, Erpressung, (Selbst)Zensur und Angst, um ihre Forderungen durchzusetzen. Im Moment führt es den Unterricht medientechnisch zurück in die Steinzeit. Mal sehen, wohin es noch weiter führt.

Merkel mit klassischem Eigentor

FB — Sun, 17 Oct 2010 10:49:59 +0000

Merkel bestätigt mal wieder aufs neue Volker Pispers (”Angela Merkel zitiere ich am liebsten wörtlich, ich habe noch keine bessere Möglichkeit gefunden, diese Frau zu beleidigen.”). Bei einem Kongress der Jungen Union in Potsdam schaffte sie es, sowohl “Multikulti” als “absolut gescheitert” zu erklären als auch unsere Kultur “christlich-jüdisch” zu nennen. Leider löste sie sich nicht in einem Unlogikwölkchen auf

Wenn sie mal ihre Indoktrination ablegen würde, müsste ihr schnell auffallen, dass “christlich-jüdisch” die Mischung von zwei Religionen bzw. zwei Kulturen beschreibt und dadurch “Multikulti” ist (Zum Unsinn, der mit dem Wort seit Jahren getrieben wird, hat Feynsinn schöne Worte gefunden). Wenn Multikulti also absolut gescheitert sein soll, dann auch unsere Kultur, so wie sie die Union versteht. Da kann man nicht mal widersprechen.

Stuttgart 21 – Widerstand am Ende

FB — Sat, 16 Oct 2010 01:50:37 +0000

Seit Wochen verfolge ich Stuttgart 21 und die Berichterstattung. Der “Schwarze Donnerstag” (siehe unten) hat beispielhaft gezeigt, wieviel die Demokratie und der Rechtsstaat in Deutschland noch wert sind. Nun wurde Heiner Geißler als Schlichter eingeschaltet und auch die Gegner des Projektes stiegen auf seine Vermittlung ein.

Man muss Geißler Respekt zollen, dass es ihm geglückt ist, den Vertrauensvorschuss in eine Gesprächsgrundlage zu verwandeln und beide Parteien am Verhandlungstisch zu halten. Heute sind die Parkschützer aus den Verhandlungen ausgestiegen. Der Rest sitzt wohl weiter am Tisch. Die Spaltung der Protestbewegung ist damit perfekt. Dem CDU-Mann Geißler ist damit der Todesstoß gelungen, denn die aussteigenden Gruppen lassen sich leicht als Sturköpfe marginalisieren, während den am Tisch sitzenden “Verhandlungspartnern” der Allerwerteste gepudert wird, bis der Schwung und der Dampf aus den Protesten raus ist und unumkehrbare Fakten im Hintergrund geschaffen sind.

Geißler ist für mich ein Phänomen. Seit Jahrzehnten schafft er für seine Partei durch geschickte Schachzüge nützliche Freiräume. Er führte als Generalsekretär die CDU durch geschickte PR in die Erfolgsspur zurück und drängte die SPD bzw. die politische Linke in die Manövrierunfähigkeit. Durch seine Schlichtertätigkeit, seine Kapitalismuskritik und seinen Eintritt bei Attac erwarb er sich auch Zuspruch im neu”linken” Spektrum. Möglicherweise liegt es an diesen Begebenheiten, dass grade die Grünen um Geißler als Schlichter warben. Ich halte es allerdings für wahrscheinlicher, dass die oberen Grünen eher an Geißlers eben beschriebener U-Boot-Funktion interessiert waren, die den Widerstand spalten soll. Mehr zur fragwürdigen Haltung der Grünen im Rahmen S21 bei Spiegelfechter und FixMBR.

Für die CDU in Baden-Württemberg gibt es noch kostenlos zwei Wahlplakate zur Feier des Tages. Jungs, bedient euch ruhig, ihr habt es euch verdient!

Auch Angie soll gewürdigt sein

Parteisoldaten beim Aufmarsch (man beachte die Handschuhe)

Man bedenke dabei, was los wäre, wenn die Bundeswehr im Inneren auch bei solchen Lagen möglich wäre. Schon durch die Polizei gab es 368 Verletzte, davon knapp 100 klinisch betreut, ein Mensch verlor ein Auge (siehe oben), ein anderer kämpft angeblich noch um sein Augenlicht. Eine Frau brach bei der Räumung zusammen und verstarb auf dem Weg zum Krankenhaus. Die Umstände sind allerdings auch zwei Wochen später nicht klar.

Geißlers Erfolg schafft somit, falls bei den Verhandlungen nichts mehr vorfällt (wovon auszugehen ist), freie Bahn für eine schwarz-grüne Allianz im März, die beide Seiten unter “Bauchschmerzen” eingehen werden “aus Liebe zu ihrer Heimat”, weil sie aufgrund des Wählerwillens “alternativlos” ist. Wie auch im Saarland wird in BW gelten: Wer grün wählt, wird sich schwarz ärgern.

Rechnernetze (Schicht 2)

FB — Thu, 23 Sep 2010 19:20:03 +0000

Noch ein kleiner Nachtrag zur Schicht 2 in Rechnernetzen.

1 – Aufgaben der Schichten
2 – Verfahren in Schicht 2a
3 – Verfahren in Schicht 2b
4 – Verbindungsprotokolle

1 – Aufgaben der Schichten

Schicht 1 ist für die transparente Übertragung von Bits zuständig. Dabei sind die Mediencharakteristiken zu berücksichtigen (z.B. Pin-Belegung oder Signalkodierung). Sie legt die Übertragungsart fest (Analog oder digital, synchron oder asynchron, seriell oder parallel, Modulation, Coding…). Beispiele für Protokolle auf dieser Schicht sind V.24 und X.21.

Schicht 2 fasst Bits zu Blöcken bzw. Frames zusammen. Sie ist für die Frame-Synchronisation zuständig und für Fehlererkennung und ggf. -korrektur. Aus den Data Circuits (Ebene 1) wird ein gesicherter Data Link / Logical Link (Ebene 2), der medien- und übertragungstechnik-unabhängig ist. Beispiele für solche Protokolle sind BSC, HDLC und LLC.

Schicht 3 regelt das Zusammenschalten von Links zu einem Ende-zu-Ende-Pfad über Transitsysteme. Sie ist für Wegewahl (Routing) und Vermittlung zuständig. Bekannte Protokolle sind X.25 PLP und IP.

Schicht 4 sorgt für den netzunabhängigen Transport von Nachrichten zwischen zwei Endsystemen. Dabei kommt es zu einer Anpassung der Übertragungsqualitäten (QoS) und zur Netzauswahl. Unterstützt wird das ganze von Splitting und Multiplexing. Eine Ende-zu-Ende-Fehlerbehandlung ist auch gewährleistet. Bekannte Beispiele sind TCP und UDP.

Schicht 5 managt die Dialogführung und Synchronisation innerhalb einer Session (temporäre logische Komm.beziehung) mittels Berechtigungstokens. Sie definiert außerdem Wiederaufsatzpunkte für die Sitzungen.

Schicht 6 handelt eine konkrete Transfersyntax aus und bildet sie auf die lokale konkrete Syntax ab.

Schicht 7 beherbergt Protokolle, die eine Standardisierung allgemein verwendbarer Dienste darstellen.

2 – Verfahren auf Schicht 2a

Schicht 2 wird in zwei Teilschichten unterteilt. Bei einem shared medium gibt es dann Schicht 2a, genannt MAC (Media Access Control), und Schicht 2b, genannt LLC (Logical Link Control).

Aufgabe der Schicht 2a (MAC) ist die Organisation des Vielfachmedienzugriffs. Dabei gilt es Kollisionen zu verhindern. Ein solches Vielfachzugriffsverfahren ist ein verteiltes Verfahren zur Vergabe des Kanals/Mediums. Zu beachten ist, dass Kommunikation bzgl. des Kanals den Kanal selbst nutzt.

Kriterien für ein Zugriffsverfahren sind:

Reservierung (oder auf gut Glück)
Zeitscheiben (Slots)
Priorität / Fairness
Lastabhängigkeit
Durchsatz

Es gibt drei Kategorien von Zugriffsverfahren:

Wettbewerbsverfahren / Random Access: Bekannt sind hier ALOHA (pure, slotted, reservation) und Carrier Sensing (p-persistent, non-persistent).
Zuteilungsverfahren: zentral (Polling) oder dezentral (Token Passing, Register Insertion, DQDB).
Reservierungsverfahren: fest (TMDA, FDMA, WDMA, CDMA, SDMA) oder dynamisch.

Bei Wettbewerbsverfahren bzw. Random Access besteht immer eine Konfliktgefahr durch Kollisionen. Bei stochastischen Verfahren ergeben sich drei Problemkreise: der Kanalzugang, die Konflikterkennung und die Konfliktbereinigung. Wichtig ist der Konfliktparameter K = Signallaufzeit / Nachrichtenübertragungszeit = (Kanallänge / Signalgeschwindigkeit) / (Nachrichtenlänge / Übertragungsrate).

Ein kurzer Blick darauf, wie bekannte Verfahren an der Luftschnittstelle damit umgehen. WLAN nutzt CSMA/CA, MACA(W) und DFWMAC. GSM verlässt sicha uf eine Mischung von FDMA und TDMA. UMTS beruht auf Wide Band CDMA und Satelliten und Funk auf FDMA. Bluetooth nutzt Frequency Hopping mit Zeitmultiplex.

Reservation ALOHA

Pure und Slotted ALOHA wurde ja schon im Rahmen der Selbstorganisierenden Netze angesprochen. Deswegen nun noch eine Erläuterung zu Reservation ALOHA. Dabei wird die Zeitachse unterteilt in Gruppen von M Data-Slots der Länge P und ein Reservierungssegment der Länge P, das aus V Mini-Slots besteht. Der Zugriff aufs Reservierungssegment läuft gemäß Slotted ALOHA ab und enthält die Reservierung auf ein Datensegment, die eine Reservierung in der fiktiven Warteschlange der fortlaufend nummerierten Data-Slots ist. Jede Station hält den Reservierungszähler r.

Problematisch dabei ist die exakte Zeitsynchronisation. Sie soll über die Erkennung von Paketanfängen oder über ein Sync-Paket durch eine bestimmte Station hergestellt werden. Schwierig ist auch, den Wiederanlauf zu erkennen. Entweder man wartet, bis keine Reservierung mehr vorhanden ist oder hört die Reservierungen und die zugehörigen Sendungen mit und berechnet daraus r oder lässt sich durch die Leitstation mit einem gültigen r synchronisieren. Die Leistung ist dabei abhängig von M, der Anzahl der Station und der Begrenzung der Reservierungen.

Carrier Sense

Auch schon kurz angeklungen ist Carrier Sense, also das vorherige Lauschen, ob das shared medium frei ist. Dadurch wird die Kollisionswahrscheinlichkeit gesenkt. Das Verfahren ist allerdings nur sinnvoll bei einem Konfliktparameter K << 1. Die einzelnen Carrier-Sense-Verfahren unterscheiden sich durch den Sendebeginn bei freiem Kanal:

unslotted p-persistent: Mit Wahrscheinlichkeit p wird bei freiem Kanal sofort gesendet, mit 1-p um Round-Trip-Delay RTD/2 verschoben.
slotted p-persistent: Die Slotgrenze gilt als Sendebeginn oder die Übertragung wird um 1 Slot verzögert.
unslotted non-persistent: Es wird sofort gesendet, falls der Kanal frei ist, sonst versucht man es erneut nach einer zufälligen Zeit t.
slotted non-persistent: Die Slotgrenze gilt als Sendebeginn oder man wartet zufällig viele Slots.

Carrier Sense wird z.B. im Ethernet (IEEE 802.3) verwendet und zwar in der Form CSMA/CD mit 1-persistent CSMA. CD heißt Collision Detect und bedeutet, dass während des Sendens der Kanal abgehört wird und bei Kollision ein Jam-Signal (4-6 Byet beliebiger Inhalt = ungültige Paketlänge) gesendet wird. Ein Binary Exponential Backoff wird als Wartezeit bei Kollisionen eingesetzt. Der Konfliktparameter K < 0,2325 bei einem 10-Mbit-LAN.

Ein Frame setzt sich wie folgt zusammen:

Präambel: 7 Bytes mit 10101010.
Start of Frame: 1 Byte mit 10101011.
Ziel-, Quell-MAC-Adresse: 48 Bits
Datenfeldlänge: mindestens 64 Bytes.
Nutzdaten: 0-1500 Bytes.
Pad: 0-46 Bytes.
CRC-Prüfsumme: 4 Bytes.

Als Topologie kommt entweder ein Bus, ein Stern mit Hub oder ein Stern mit Switch zum Einsatz. Als Medium wird entweder Koax, Twisted Pair, Lichtwellenleiter oder Breitband verwendet. Koppelelemente sind Hub, Repeater (Schicht 1), Bridge (2) und Router (3).

3 – Verfahren auf Schicht 2b

Schicht 2b, die Logical Link Control (LLC), hat als Aufagbe die Bereitstellung und Steuerung der Schicht-2-Verbindung (Data Link und Logical Link). Sie steuert und sichert den Datenaustausch von Zeichenfolgen (Blöcke) oder Bitfolgen (Frames). Als Dienst nach unten bietet sie die Übernahme/-gabe von Bitfolgen an, nach oben die Verdeckung der Charakteristika physischer Medien. Die Dienstgüte wird durch Establishment Delay, Establishment Failure Probability, Durchsatz, Transit Delay, Resilience, Residual Error, Transfer Failure Probability, Protection und Prioritäten bestimmt. Happy Googling ^^

Aspekte der Leitungsprotokolle auf Schicht 2b sind die Leitungsart (Stand- oder Wählleitung), die Verbindungsart (Point-to-Point oder Mehrpunkt), die Betriebsart (simplex, halbduplex, duplex), die Übertragungsrate, die Synchronität, die Datensicherheit (Sequenznummern, Fenster, Prüfsummen), die Formatdarstellung (zeichenorientiert, bitorientiert, Trennung von Daten und Steuerinformationen), Steuerverfahren (Konkurrenzbetrieb, Aufrufbetrieb (Polling)), der PDU-Aufbau und der Diensttyp, der Protokollablauf und der Protokollautomat.

4 – Verbindungsprotokolle

Ein früher oft verwendetes, mittlerweile aber veraltetes Protokoll ist BSC (Binary Synchronous Communication). Es wird nur noch bei Terminals und Geldautomaten eingesetzt. Es arbeitet zeichenorientiert und codeabhängig (ASCII oder EBCDIC). Die Prüfsummenbildung erfolgt mit BCC. Bit- und Byte-Synchronisation wird mit speziellen Steuerzeichen sichergestellt (sehr viele, Transparenz über Fluchtsymbol). Eine PDU besteht aus:

SOH – Start of Header
Kopf
STX – Start of Text
Text
ETX – End of Text
BCC

Der Ablauf des Protokolls gestaltet sich folgendermaßen:

Binary Synchronous Communication (BSC) - Ablauf im Normalfall und im Fehlerfall

HDLC

Eine etwas neuere Variante ist HDLC. Es arbeitet bitorientiert und synchron und wird z.B. bei LAPB (X.25), LLC1 (Ethernet) und LLC2 (Token Ring) verwendet. Es unterstützt Punkt-zu-Punkt, Mehrpunkt und alle Betriebsarten. Die Absicherung erfolgt via CRC, Sequenznummern und Fenstertechnik.

Die Endgeräte werden in Leitstationen, Folgestationen und kombinierte Stationen unterteilt. Leitstationen (primary stations, P) steuern die Kommunikation mittels Commands. Folgestationen (secondary stations, S) antworten auf diese Commands mit Responses. Zu jeder S gibt es eine eigene logische Verbindung. Kombinierte Stationen können P und S sein. Links zwischen den Stationen sind entweder unsymmetrisch, d.h. 1 P und mindestens 1 S sind mit halbduplex oder duplex verbunden, oder symmetrisch, d.h. zwei kombinierte Stationen sind mit halbduplex oder duplex verbunden.

Es gibt drei Betriebsmodi:

Normal Response Mode (NRM): geht nur bei unsymmetrischen Links, S darf nur auf Commands antworten.
Asynchronous Response Mode (ARM): S darf auch ohne Erlaubnis von P senden.
Asynchronous Balanced Mode (ABM): geht nur bei symmetrischen Links.

PPP

Auch das Point-to-Point-Protocol haben wir schon letztens angesprochen. Darum nur kurz noch ein paar Worte dazu. Es ist einfach zu konfigurieren und zeichenorientiert. Der Rahmenaufbau sieht ähnlich aus wie bei HDLC. PPP wird über HDLC, SDH/SONET, Ethernet oder ATM genutzt. Zum Einsatz kommen dabei zwei unterstützende Protokolle:

LCP (Link Control Protocol): Es wird in PPP-Rahmen transportiert. LCP managt den Auf- und Abbau des Links und handelt dafür die Optionen aus.
NCP (Network Control Protocol): hält den Bezug zum transportierten Protokoll der Vermittlungsschicht (3). Es beherbergt eine ganze Familie von Protokollen (je nach Ausprägung der Schicht 3). Frames haben den folgenden Aufbau: Flag | Address | Control | Protocol | Payload | CRC | Flag. Das Flag zeigt mit der Bitfolge 0111 1110 Beginn und Ende an. Control spezifiziert die Fenstergroße (default 0000 0011).

Der Zustandsautomat bzw. Ablauf des PPP sieht so aus:

Ablauf des Point-to-Point-Protokolls

So, das war’s aber nun (einstweilen) endgültig mit der Informatik hier im Blog

IT-Sicherheit

FB — Tue, 21 Sep 2010 19:41:38 +0000

Ein großes Kapitel der Netzwerke ist deren Sicherheit. Gleichzeitig ist mit diesem Artikel die Reihe zur Informatik und meine Lernzusammenfassung abgeschlossen. Mal hoffen, dass innerhalb des nächsten halben Jahres während der Diplomarbeit mehr Zeit für Kommentare zur Politik bleibt, für die ich dieses Blog eigentlich ins Leben gerufen habe. Nun aber zur IT-Sicherheit, in folgender Weise:

1 – Grundlagen
2 – Kryptologie
3 – Zugriffskontrolle
4 – Sicherheit auf OSI-Schicht 2
5 – Sicherheit auf Schicht 3, 4 und 7
6 – Firewalls und Intrusion Detection
7 – Maßnahmen gegen Spam

1 – Grundlagen

Als Grundlage für Kommunikationsprotokolle in Rechnernetzen gibt es das OSI-Referenzmodell. Es unterteilt in sieben Schichten:

Bitübertragungsschicht / Physical Layer
Sicherungsschicht / Data Link Layer
Vermittlungsschicht / Network Layer
Transportschicht / Transport Layer
Kommunikationssteuerungsschicht / Session Layer
Darstellungsschicht / Presentation Layer
Anwendungsschicht / Application Layer

Die Grenze zwischen Systemen wird als Systemschnitt bezeichnet. Zwischen ihnen gibt es ein Medium zur Übertragung von Daten (physischer Datenfluss). Die Grenze zwischen den Diensten der verschiedenen Schichten heißt Dienstschnitt und die zwischen Protokollen beim logischen Datenfluss Protokollschnitt. Das Protokoll überträgt sogenannte Schicht-N-PDUs (Protocol Data Units).

Die OSI Security Architecture definiert einige Dienste für die Sicherheit in Verteilten Systemen (nicht Host- oder Betriebssystemsicherheit!). Diese sind:

Authentisierung: Zweifelsfreie Identifikation jeder Entität. Zu unterscheiden sind Peer Entity Auth. (gegenseitige Auth. von Komm.partnern) und Data Origin Auth. (Identifikation des Senders/Autors einer Nachricht).
Zugriffskontrolle: Schutz vor unberechtigter Ressourcennutzung.
Vertraulichkeit: Schutz der Daten vor unberechtigter Offenlegung.
Datenintegrität: Erkennung von Modifikationen, Einfügen, Löschen, Umordnen, Duplikaten oder Wiedereinspielen von Daten.
Verbindlichkeit: Niemand kann das Senden oder Empfangen einer Nachricht leugnen. Zu unterscheiden sind Proof of Origin (Empfänger kann Empfang beweisen) und Proof of Delivery (Sender kann die Auslieferung beweisen).
Identifikation: Zweifelsfreie Verbindung zwischen digitaler ID und Real-World-Entity.
Autorisierung: Erteilung von Rechten an Entitäten.
Zurechenbarkeit (im Sinne von Accountability)
Anonymität
Verfügbarkeit/Verlässlichkeit
Ressourcenbeschränkung.

Die Sicherung einzelner Eigenschaften lässt sich folgendermaßen erzielen:

Vertraulichkeit: Verschlüsselung.
Integrität: Kryptographischer Hashwert, gesicherte Sequenznummern, Zeitstempel (gegen Duplikate und Replays) und Verschlüsselung des Hashwertes.
Autorisierung von Benutzern: Wissen (PW, PIN), Besitz (Smartcard, Token, Schlüssel) oder Eigenschaft (Biometrie).
Autorisierung des Datenursprungs: Verschlüsselung, Digitale Signatur oder Message Authentication Code (MAC), d.h. ein Hashverfahren mit gemeinsamem Schlüssel, z.B. DES im CBC-Mode. Eine weitere Möglichkeit sind Hashed MACs (HMAC). Aus vorherigen Artikeln ist schon das “Rundum-Sorglos-Paket” bekannt, das hier nochmal genannt sein soll: K[m||K_A^-{H(m)}].

Attacken

Es gibt eine Vielzahl von Attacken. Die bekanntesten sollen nun vorgestellt werden.

Eine davon ist Denial of Service (DoS). Dabei wird versucht, dass berechtigte Nutzer ihre Dienste nicht mehr nutzen können durch Überlastung, Fehlersituationen oder Bugs. DoS kann entweder durch Anforderung bzw. Nutzung beschränkter Ressourcen erfolgen, durch Zerstörung bzw. Änderung der Konfiguration oder durch physikalische Beschädigung oder Zerstörung.

Distributed DoS (DDoS) ist die verteilte Variante von DoS. Dabei versucht der Intruder/Attacker im ersten Schritt eine oder mehrere kompromittierbare Maschinen zu finden und dort seine Tools (Master/Handler) zu installieren. Dieser Master versucht dann, weitere Maschinen zu kompromittieren und dort einen sogenannten DDoS-Daemon/Client zu installieren. Der so verseuchte Rechner wird Bot oder Zombie genannt. Für die DDoS-Attacke startet der Intruder dann ein Programm auf dem Master, das allen Daemonen mitteilt, wann und gegen wen sie mit einer DoS-Attacke losschlagen sollen.

Gegen DoS gibt es einige Gegenmaßnahmen. Es ist wichtig, Monitoring und Intrusion Detection zu betreiben und entsprechende Konfigurationen zu überprüfen. Ein Paketfilter auf Gateways und Routern leistet auch gute Dienste. Pro Quelle im Rechnernetz sollte eine Überwachung von Verbindungsvolumen und -anzahl stattfinden und die offenen Ports im Auge behalten werden. Broadcasts sollten blockiert werden. Außerdem sollte man Bug-Warnungen verfolgen, Patches installieren und die Kooperation mit anderen Unternehmen bzw. Personen in ähnlicher Lage suchen.

Andere Attacken basieren auf Malicious Code. Eine davon ist der Virus, eine Befehlsfolge, die zur Ausführung ein Wirtsprogramm benötigt. Er repliziert sich selbst und infiziert weitere Wirte. Ein Virus ändert im Speicher die Einsprungadresse von einer unschädlichen Stelle auf den Virus-Teil und springt von dort nach dem Schadensteil wieder zurück zur alten Adresse. Ein anderer ist der Wurm, ein eigenständig ablauffähiges Programm, das kein Wirtsprogramm benötigt. Auch er repliziert sich selbst. Beispiele sind ILOVEYOU, SQL Slammer oder Conficker. Auch Trojaner bzw. Trojanische Pferde zählen zum Malicious Code. Hierbei handelt es sich um ein Programm, dessen Ist- und Soll-Funktionalität sich unterscheidet und das zum Datenklau, Keylogging o.ä. verwendet wird. Hinter einer attraktiven Nutzfunktionalität verbirgt sich eine versteckte Schadfunktionalität. Trojaner vervielfältigen sich nicht selbständig. Mobile Code gehört auch zu diesem Gebiet. Dabei wird Code auf einem entfernten Rechner generiert, in Webseiten etc. eingebettet und auf einem lokalen Client ausgeführt, i.d.R. mit Ausführungsplattform (Virtual Machine) oder Interpreter. Beispiele dafür sind ActiveX oder JavaScript.

Gegenmaßnahmen bei Malicious Code beinhalten, keine Software aus unsicheren Quellen zu installieren und Antiviren-Software aktuell zu halten. Firewalls sollten um Viren- und Mail-Scanner erweitert werden. Es hilft auch, ausführbare Dateien und Dateisysteme zu verschlüsseln und sie mit kryptographischen Prüfsummen zu versehen, einen Integrity-Checker zu installieren und damit regelmäßig zu testen. Schreibrechte sollten sehr restriktiv nach dem “need-to-know”-Prinzip vergeben werden. Automatische Makro-Ausführung sollte deaktiviert werden. Testweise kann man das System auch impfen, d.h. bewusst den Erkennungscode eines Virus in Programme einzutragen, um zu sehen, ob die Maßnahmen wirken. Letzlich kann man auch ein weniger anfälliges Betriebssystem wählen, um dem meisten Malicious Code zu entkommen.

Auch Hoax (Betrugsmail) und Spam (unerwünschte Werbemail) gelten als Attacke. Zu Spamfiltern komme ich im letzten Kapitel.

Eine andere Gruppe von Attacken sind Exploits. Ein Exploit ist das Account- bzw. Passwort-Cracken: Dabei wird versucht, den Benutzernamen und das Passwort zu erraten, entweder durch Brute Force (alles durchprobieren) oder eine Dictionary Attack (häufigere Wörter probieren). Auch möglich ist, den Verschlüsselungsalgorithmus des Passworts zu brechen und es dadurch zu erlangen. Eine andere Möglichkeit ist Social Engineering, also entweder das Vortäuschen oder Ausnutzen von Freundschaft, Shoulder Surfing oder Dumpster Diving. Weitere Exploits sind Backdoor und Trapdoor. Dabei will der Angreifer Zugang zur bereits kompromittierten Maschine erhalten, und zwar vorbei an der OS-Auth. und mit speziellen Rechten. Auch Rootkits gelten als Exploit. Sie sind Werkzeugsammlungen zum Verbergen und Erhalten einer Kompromittierung und dem Zugang.

Eine in den letzten Jahren beliebtere und mittlerweile häufigste (80%) Attacke ist das Cross Site Scripting (XSS). Dabei schleust der Angreifer Code in Webseiten oer Links ein. Der Betrachter der Seite führt dann unfreiwillig den Schadcode aus. Es gibt drei Arten von XSS:

DOM-based / local (Type 0): Schadcode wird direkt an das Client-Skript übergeben ohne den Server zu involvieren.
Non-persistent / reflected (Type 1): Die Eingabe wird vom Server direkt an den Nutzer zurückgeliefert und der Schadcode vom Browser interpretiert.
Persistent / stored / second-order (Type 2): Der Schadcode wird per Webanwendung auf dem Server gespeichert und später bei allen Abrufen ausgeführt.

Ein weiteres Angriffswerkzeug ist der Sniffer, der ein Abhören des Netzverkehrs erlaubt. Im LAN wird i.d.R. ein shared medium (Ethernet, Token Ring) verwendet, d.h. der ganze Verkehr kann von der Netzwerkkarte mitgelesen werden (in der Einstellung “Promiscious Mode”). Im WAN können bspw. die Vermittlungsrechner mitlesen.

Portscanner seien als letztes Tool aufgeführt. Damit kann man offene Ports durch versuchsweisen Verbindungsaufbau testen. Die offenen Ports ermöglichen die Identifikation von möglicherweise laufenden Diensten. Im folgenden kann man dann die bekannten Schwachstellen der Dienste gezielt ausnutzen.

Der grundlegende Ansatz, mit all den Bedrohungen fertig zu werden, nennt sich Security Engineering. Dabei wird ein mehrstufiger, iterativer und kontinuierlicher Prozess durchlaufen, der mit einer Bedrohungsanalyse beginnt, zu einer Risikopriorisierung übergeht und daraus dann Sicherheitsanforderungen ableitet.

2 – Kryptologie

Kryptologie besteht aus drei Teilbereichen, nämlich der Kryptographie (Lehre von den Methoden zur Ver- und Entschlüsselung von Nachrichten), der Kryptoanalyse (Wissenschaft von den Methoden zur Entschlüsselung ohne den Schlüssel zu besitzen) und der Steganographie (Methoden, die bereits die Existenz der geheimen Nachricht verbergen durch linguistische oder technische Mittel).

Ein Kryptosystem verwendet entweder Substitution oder Permutation oder beides, um Nachrichten zu verschlüsseln. Substitution ist der Austausch von Zeichen eines Alphabets gegen Zeichen eines anderen Alphabets nach einer bestimmten Abbildungsregel. Permutation funktioniert mittels Durchmischen im selben Alphabet (NEWYORK_ABC…).

Bei symmetrischen Verfahren sind Encrypt-Key und Decrypt-Key gleich oder leicht voneinander ableitbar. Die Kommunikationspartner teilen einen gemeinsamen geheimen Schlüssel. Voraussetzung dafür ist ein vorheriger Schlüsselaustausch.
Bei asymmetrischen Verfahren hat jeder einen öffentlichen und geheimen Schlüssel. Sie sind weniger performant, d.h. viel langsamer, als symmetrische Verfahren.

Kryptographische Angriffe sind…

Brute Force / Exhaustive Search: Vollständiges Durchsuchen des Schlüsselraums.
Klartextangriff / ciphertext-only: Der Analytiker hat mehrere Chiffren und berechnet daraus den Schlüssel und/oder den Klartext.
Bekannter Klartext / known-plaintext: Der Analytiker kennt Klartext-Chiffren-Kombinationen und kann dadurch entweder den Schlüssel brechen oder jede mit dem Schlüssel verschlüsselte Botschaft per Algorithmus entschlüsseln.
Gewählter Klartext / chosen-plaintext: Der Analytiker kann selber den Klartext wählen und verschlüsseln lassen.
Gewählte Chiffre / known-ciphertext: Der Angreifer kann sich zu ausgewählten Chiffren den Klartext berechnen lassen.

DES (Data Encryption Standard)

DES galt früher als Standard der Verschlüsselungsalgorithmen, ist aber mittlerweile von AES abgelöst worden. Der grobe Ablauf von DES beinhaltet drei Schritte:

Initialpermutation (IP) des Inputblocks
16 schlüsselabhängige Iterationen. Dabei werden 48 Bit lange Teilschlüssel aus 64-bit-Schlüsseln generiert.
Inverse Initialpermutation (IIP) als Ausgangspermutation

Die Entschlüsselung verläuft analog mit den Schlüsseln in umgekehrter Reihenfolge in Schritt 2.

Nun genauer zur Verschlüsselung. Dabei wird der Block in einen linken (L) und einen rechten (R) Block á 32 bit aufgeteilt. Die 16 Iterationen laufen so ab, dass in jedem Schleifendurchgang i (0-15) folgende Operationen ausgeführt werden:

L(0) = L   Λ   R(0) = R
L(i+1) = R(i)
R(i+1) = L(i) xor f(R(i),K(i+1))

K ist hierbei der DES-Schlüssel. Die Funktion f ist der Kern des Verfahrens und läuft wie folgt ab:

Rechter Inputblock R wird mithilfe der Funktion E auf 48 bit expandiert.
XOR-Verknüpfung mit dem Rundenschlüssel, führt zum 48-bit-Block A.
Aufteilung von A in 8 Blöcke mit je 6 Bits.
Abbildung der Blöcke mit einer S-Box auf je 4 Bit.
Konkatenation zu 8×4=32-bit-Block B.
(Ausgangspermutation IIP)

Eine S-Box bezeichnet eine Tabelle, die den aus Spalte und Zeile kombinierten Wert durch einen Wert aus einem neuen Alphabet substituiert.

Die Schlüsselauswahl bei DES läuft in vier Schritten ab:

Permuted Choice 1 (PC1) auf den 64-bit-Schlüssel, d.h. Kürzen auf 56 relevante Bits und 8 Bits Parity, dann Permutation des Schlüssels.
Aufteilen des Schlüssels in 2 Teile á 28 bit.
Zyklischer Links-Shift, in Runde 1, 2, 9, 16 um 1 bit und sonst um 2 bit.
Zusammenfassen der Teilblöcke und PC2. Dabei werden die Bits 9,18, 22, 25, 35, 38, 43 und 56 entfernt und die verbleibenden 48 bit permutiert.

Vorteile von DES sind der starke Avalanche-Effekt (1 Bit ändern => 50% der Ausgabe ändert sich) und der starke Schutz gegen analytische Angriffe (2⁴⁷ chosen-plaintexts nötig). Nachteilig ist das teils geheime Design, da dadurch Stärken und v.a. Schwächen nur unzureichend bekannt sind. Außerdem ist die Schlüssellänge zu gering. Die Größe des Schlüsselraums beträgt nur 2⁵⁶. Mittels differentieller Kryptanalyse lässt sich die Komplexität auf 2³⁷reduzieren. Es gibt desweiteren 4 schwache Schlüssel mit DES(DES(x,K),K) = x und 6 semi-schwache Schlüsselpaare mit DES(DES(x,K),K’) = x. DES ist für Hardware-Implementierung optimiert. IP und IIP erhöhen die Sicherheit überhaupt nicht. Eine doppelte Anwendung von DES erhöht die Sicherheit nicht merklich.

Eine Variante von DES ist immer noch im Einsatz, nämlich Triple-DES bzw. 3DES. Dabei wird mit E1→D2→E1 verschlüsselt und mit D1→E2→D1 entschlüsselt. Gängig ist auch, im jeweils ersten Schritt einen dritten Schlüssel zu verwenden. 3DES hat einen Schlüsselraum von 2¹⁶⁸. Die Komplexität kann aber auf 2¹¹² reduziert werden (siehe WP). Es ist ähnlich sicher wie übliche 128-bit-Verschlüsselungen, ist aber aufwendiger und kostet mehr Zeit.

AES (American Encryption Standard)

Einer der derzeit schnellsten und meistverbreitetsten Algorithmen ist AES. Es gibt ihn in Ausführungen mit variabler Blocklänge und Schlüssellänge (128, 192, 256 Bit). Auch die Rundenanzahl variiert je nach Schlüssellänge (10, 12, 14). Die einzelnen Runden arbeiten auf sogenannten States, die im Grunde quadratische Matrizen sind. Die Verschlüsselung läuft wie folgt ab:

Add Round Key (ARK): Addition des Schlüssels
1. SubBytes (SB): Byte-Substitution mit S-Boxen
2. ShiftRows (SR): Zeilen-Shift nach links – erste Zeile kein Shift, je Zeile ein Shift mehr.
3. MixColumns (MC): Durchmischen der Spalten.
4. Add Round Key (ARK): Addition des jeweiligen Rundenschlüssels.
SubBytes
ShiftRows
Add Round Key

Die Schleife (2) wird bis zur N-1. Runde durchlaufen.

Die Entschlüsselung ähnelt der Verschlüsselung. In den Runden läuft sie leicht anders ab:

Add Round Key (ARK)
Inverse MC
Inverse SR
Inverse SB

RSA (Rivest, Shamir, Adleman)

RSA ist der Standard in der Public-Key-Kryptographie, also ein asymmetrisches Verfahren. Die Generierung der Schlüssel läuft wie folgt ab:

Wähle große Primzahlen p und q und berechne das RSA-Modul n = p*q.
Wähle d ε [0, n-1] und d relativ prim zum Eulerschen φ(n) = (p-1)(q-1), d.h. ggT(φ(n), d) = 1. Ratsam ist angeblich, die untere Intervallgrenze von d oberhalb von √n zu wählen.
Wähle e ε [0, n-1] mit e x d ≡ 1 mod φ(n), d.h. e ist das multiplikative Inverse mod φ(n) zu d. Die Mathematik dahinter ist eigentlich nicht allzu schwer, allerdings ein Graus, sie mit Wordpress zu tippen. Deswegen verweise ich auf Wikipedia.
Öffentlicher Schlüssel ist dann (e, n).
Privater Schlüssel ist (d, n).
Die Verschlüsselung eines Klartexts m ε [0, n-1] funktioniert dann so:
E(m) = m^e mod n = c
Die Entschlüsselung analog:
D(m) = c^d mod n = m

Mögliche Angriffe auf RSA sind bspw. Brute Force und chosen-plaintext. Es gibt auch mathematische Angriffe, z.B. die Faktorisierung von n zu versuchen (mit einem General Number Field Sieve, GNFS), die direkte Bestimmung von φ(n) ohne Faktorisierung oder die direkte Bestimmung von d ohne Bestimmung von φ(n). Ausgefuchst ist die Timing Attack. Dabei überwacht man die Laufzeit von Entschlüsselungsoperationen und schließt aus Laufzeitunterschieden auf den privaten Schlüssel. Bei Signaturen, für die RSA verwendet wird, gibt es auch noch die Möglichkeit der existentiellen Fälschung und das Ausnutzen der Multiplikativität von RSA. Dazu gleich mehr.

Hybride Kryptosysteme

Hybride Kryptosysteme nutzen die Vorteile beider Welten. Zum Schlüsselaustausch wird ein asymmetrisches Verfahren verwendet (K_A^-{Verfahren, K_B⁺(K)}), zur Kommunikationsverschlüsselung ein symmetrisches (A←K(m)→B). Beispiele hierfür sind PGP oder SSH.

Signaturen

Signaturen verwenden asymmetrische Verschlüsselung. Mit dem privaten Schlüssel wird die Signatur erstellt, dadurch kann sie jeder mit dem öffentlichen Schlüssel verifizieren. Asymmetrische Verfahren sind i.d.R. langsam und aufwendig, deswegen wird lediglich ein kryptographischer Hashwert (Message Digest) signiert (= digitaler Fingerabdruck).

Mögliche Angriffe auf Signaturen (mit RSA) sind die existentielle Fälschung und die Multiplikativität von RSA. Die existentielle Fälschung läuft so ab:

Wählen einer beliebigen Zahl r mit 0 ≤ r < n.
Behaupten, dass r ein von A signiertes Dokument ist.
Der Empfänger verifiziert es. Falls K_A⁺(r) sinnvollen Text ergibt, war der Angriff erfolgreich.

Die Multiplikativität von RSA lässt sich wie folgt nutzen:

Alice zwei Nachrichten m₁und m₂ signieren lassen.
Berechnung von K_A^-(m₁) * K_A^-(m₂) mod n = X.
Es gilt X = (m₁*m₂)^{K_A^-} mod n, d.h. man kann aus zwei signierten Dokumenten ein drittes gültig signiertes erzeugen, ohne den Schlüssel zu besitzen.

Gegenmaßnahme zur Multiplikativität ist das alleinige Signieren vom Hashwert (und nicht ganzen Nachrichten).

Kryptographische Hashfunktionen

Dazu verwendete Hashfunktionen zeichnen sich durch einige Eigenschaften aus. Zunächst einmal nehmen Hashfunktionen ein beliebig langes Wort m als Eingabe. Die Ausgabe des Hashwerts h = H(m) hat eine feste Länge. Obwohl die Abbildung eines Universums auf einen beschränkten Wertebereich nicht ohne Kollisionen ablaufen kann, gilt die Anforderung, dass die Funktion möglichst kollisionsresistent ist.

Sie werden angewandt zur Integritätssicherung und für Digitale Signaturen. Integritätssicherung funktioniert folgendermaßen:

A schickt (m, H(m)) an B bzw. verschlüsselt den Hashwert noch: (m,K[h]).
B empfängt (m’, h) und berechnet h’ = H(m’).
Falls h = h’, dann m = m’, ergo m unverändert.

Hashfunktionen können mit einer Birthday Attack angegriffen werden. Bekannt ist diese Methode aus dem Phänomen, dass sich schon bei wenigen Leuten zwei finden lassen, die am gleichen Tag Geburtstag haben. Bei einer solchen Attacke sichert A die Nachricht M mit einem m Bit langen Hash. C erzeugt von der Nachricht s2^m Variationen durch Einfügen von Spaces oder mit Synonymen. Dann ist die Wahrscheinlichkeit für eine Kollision größer als 50%.

Beispiele für Hashfunktionen dieser Art sind MD4, MD5, SHA-1, SHA-512 oder Whirlpool. Nur die letzten beiden gelten noch als sicher.

Needham-Schroeder

Das Protokoll wurde ja schon bei den Verteilten Systemen besprochen. Es wurde auch gesagt, dass eine Protokollschwäche besteht, und zwar, dass alte Sitzungsschlüssel gültig bleiben. Gegenmaßnahmen sind Sequenznummern oder Zeitstempel. Wichtig ist auch, eine Gültigkeitsdauer für Sitzungsschlüssel einzuführen.

Kerberos

Kerberos baut auf Needham-Schroeder auf. Auch hier basiert die Authentisierung auf einem gemeinsamen Sitzungsschlüssel. Jeder Teilnehmer hat zwei Credentials: (1) Das Ticket T, ein Ausweis für die Dienstnutzung, der nur für einen Server gültig ist. Es wird vom Ticket Granting Server (TGS) erstellt. Ein Ticket enthält Client- und Server-ID, Adresse, Zeitstempel, Gültigkeitsdauer und den Schlüssel. (2) Der Authenticator A, ein Ausweis zur Authentisierung und zur Verifizierung des Tickets. Er wird vom Client selbst erzeugt und zusammen mit dem Ticket verschickt. Ein Authenticator enthält Client-ID, Adresse und Zeitstempel.

Der Vorgang sieht dann folgendermaßen aus:

Der Client stellt an den Kerberos-Server eine Anfrage bzgl. eines Ticket Granting Ticket (TGT). Der Server schaut, ob er den Client in der Datenbank finden kann.
Der Server schickt das TGT zurück. Es besteht aus K_c[K_c,tgs] und K_tgs[T_c,tgs], also dem entschlüsselbaren Schlüssel zur Kommunikation mit dem TGS und einem nicht entschlüsselbaren Paket mit dem Ticket für die Kommunikation.
Der Client stellt an den TGS eine Anfrage nach einem Server Ticket (ST). Er schickt dafür dem TGS die Server-Adresse, den verschlüsselten Authenticator K_c,tgs[A_tgs] und das verschlüsselte Ticket K_tgs[T_tgs].
Das zurückgeschickte ST besteht aus K_c,tgs[K_c,s] und K_s[T_c,s], also dem entschlüsselbaren Paket mit dem Schlüssel zur Kommunikation mit dem Server und das nicht auslesbare Paket mit dem Ticket für diese Kommunikation.
Der Client stellt an den Server eine Dienstanfrage mit seinen beiden Credentials K_c,s[A_s] und K_s[T_s].
Optional authentifiziert sich der Server gegenüber dem Client.

Bei mehreren Domänen/Realms wird der TGS des fremden Realms zum “normalen” Server. Der Client geht also bis zum 4. Schritt seinen üblichen Weg und wiederholt dann nochmal Schritt 3 und 4 beim zweiten TGS. Danach geht er erst über zum letzten Schritt beim Server in der fremden Domäne, den er wirklich erreichen will. Dafür ist natürlich ein Schlüsselaustausch zwischen TGS1 und TGS2 nötig. Die Domänen müssen sich vertrauen und gegenseitig ihre Authenticators und TGS anerkennen. Bei mehreren Realms kommt es außerdem zu einem Skalierungsproblem: n Realms erfordern n(n-1)/2 Schlüssel, die Komplexität liegt also bei O(n²).

Gut an Kerberos ist die sichere netzwerkweite Authentisierung. Allerdings beruht sie auf der IP-Adresse, die durch Spoofing gefälscht werden kann. Kerberos verlässt sich außerdem auf vertrauenswürdige Software, was einer Trojanisierung Vorschub leistet. Darüberhinaus ist für den Betrieb eine lose gekoppelte Zeit erforderlich, also eine Uhrensynchronisation.

3 – Zugriffskontrolle

Autorisierung ist die Vergabe und Spezifikation von Rechten. Die Zugriffskontrolle ist die Durchsetzung dieser Rechte. Drei Begriffe sind in dem Zusammenhang wichtig, die so ähnlich auch schon aufgetaucht sind:

Subjekt: die handelnde Person.
Objekt: die schützenswerte Einheit im System.
Recht: wird an Subjekte erteilt, gilt für Objekte.

Zugriffskontrollstrategien umfassen:

DAC (Discretionary Access Control): basiert auf dem Eigentümer-Prinzip. Der Eigentümer spezifiziert die Rechte an seinen Objekten. Zugriffsrechte werden auf der Basis von Objekten erteilt.
MAC (Mandatory Access Control): regelbasierte Festlegung der Rechte, z.B. eine Ordnung in unclassified – confidential – secret – top-scret. Die Rechte gelten systemglobal.
RBAC (Role-Based Access Control): Trennung von Subjekt und Aufgabe. Rechte werden an Aufgaben statt Subjekte geknüpft. Subjekte erhalten Rechte über Rollenmitgliedschaften.

Bekannt aus den Verteilten Systemen ist auch die Zugriffsmatrix, in der Subjekte die Zeilen und Objekte die Spalten bilden. Sie ist zeitabhängig und nur jeweils für einen bestimmten Zeitpunkt gültig: Ein Eintrag beschreibt Rechte von S an O zum Zeitpunkt t. Spaltenweises Auslesen ergibt Zugriffskontrollisten wie bei Unix; beim zeilenweisen Lesen erhält man die Capabilities.

Ein Referenzmonitor bzw. Access-Control-Monitor ist eine gesicherte Systemkomponente zur Realisierung der Zugriffskontrolle. Der Zugriff auf Objekte ist nur über den Monitor möglich. Er kann Aufrufer zweifelsfrei identifizieren (Auth.) und ihren Objektzugriff unterbrechen und verhindern.

Identifikation

Ohne sichere Identifikation kann es keine sinnvolle Authentisierung geben. Identifikation beinhaltet mindestens zwei Stufen. Zum einen die Personalisierung, also die zweifelsfreie Ermittlung der Real-World-Identität und Vergabe einer digitalen ID, und andererseits die Identifikation, als Verbindung von digitaler ID mit Informationen, die nur die Entität nutzen und wissen kann. Problematisch ist immer, dass ein Masquerade-Angriff möglich ist, wenn der Angreifer seine Informationen mit einer fremden ID verbinden kann.

Identifikation kann durch eine digitale Signatur / Zertifikat erreicht werden. Dabei ist eine Trusted Third Party (TTP), in dem Fall eine Certification Authority (CA), nötig. Sie unterschreibt für die Identität einer Entität. Ein Zertifikat ist eine Datenstruktur zur Verbindung von Identitätsinformationen und öffentlichem Schlüssel der Entität und ist digital signiert. Die CA versieht Zertifikate mit einer Digitalen signatur, wie ich gleich erläutern werden. Als Realm wird der Benutzerkreis der CA bezeichnet. Eine Local Registration AUthority (LRA) nimmt Anträge auf ein Zertifikat (CertReq) entgegen und führt die Personalisierung durch.

Das Aufgabenspektrum einer CA beinhaltet die Generierung von Zertifikaten, ihre allgemein zugängliche Speicherung, ihren Widerruf und Sperrung, die Aktualisierung, Schlüsselerzeugung und Historienverwaltung, wo nicht mehr gültige Cert gespeichert werden, einen Notardienst zum Signieren von Nutzervorgängen, einen Zeitstempeldienst, eine realmübergreifende Zertifizierung (Zertifizierung fremder CAs) und eine Reihe von Attribut-Zertifikaten, die Attribute und Identität verknüpfen, z.B. Rechte oder Vollmachten.

Die Benutzerzertifizierung läuft folgendermaßen ab:

Schlüsselgenerierung: erfolgt zentral durch die CA oder dezentral durch die Nutzer. Nur der Zertifizierte darf den geheimen Schlüssel kennen.
Personalisierung, CertReq: Der Benutzer beantragt ein Zertifikat (CertReq). Daraufhin wird seine Identität festgestellt. Der Benutzer muss belegen, dass er den passenden privaten Schlüssel besitzt (z.B. via Challenge-Response-Protokoll, s.u.).
Generierung der Datenstruktur durch das Zertifikat. Entsprechende Attribute werden aus dem CertReq entnommen.
Digitale Signatur durch die CA.

Wie bei Schlüsseln ist es nötig, Zertifikate nach einiger Zeit auszutauschen bzw. zu erneuern. Um Konsistenz zu bewahren, gibt es Certificate Revocation Lists (CRL). Dabei handelt es sich um eine Liste aller Cert-IDs mit Datum der Ungültigkeit, die von der CA digital signiert ist. Es stellt sich dann natürlich das Problem, wie man die Information verteilen soll und das auch noch zeitnah, effizient und vollständig. Ansätze dafür sind ein Push-Modell (regelmäßige Übersendung der CRL), Pull-Modell (Verifikator fragt bei der Überprüfung aktuell nach, ob Cert noch gültig ist oder holt die CRL) und vollständige CRL oder sogenannte Delta-Listen. Eine Alternative z.B. bei HTTPS ist das Online Certificate Status Protocol (OCSP).

4 – Sicherheit auf OSI-Schicht 2

Ausgehend von Virtuellen Netzwerken werden nun einige Sicherheitstechnologien in verschiedenen Schichten besprochen. Virtuelle Netzwerke sind auf Schicht 1 z.B. der Virtual Private Wire Service (VPWS) bzw. Line Service (VPLS), z.B. in Optical Private Networks. Auf Schicht 2 in einem Virtual LAN laufen mehrere LAN-Broadcast-Domains über den selben physischen Link (siehe auch VLAN-Tagging). Eine andere Möglichkeit sind Punkt-zu-Punkt-Verbindungen und das Layer 2 Tunneling Protocol. In Schicht 3 und darüber sind IPSec, SSL/TLS und OpenVPN bekannte Verfahren.

Bleiben wir zunächst bei Schicht 2. Ihre Aufgaben sind fehlerfreie Übertragung von Frames (Rahmen), Flusskontrolle und Medienzugriffsverfahren bei einem shared medium (z.B. CSMA/CD bei Ethernet, CSMA/CA bei WLAN). Dazu wird der Bitstrom in Frames aufgeteilt. Fehlerkontrolle wird durch Prüfsummen (z.B. CRC) gemanagt. Außerdem gibt es Quittungs- und Wiederholmechanismen.

PPP (Point-to-Point Protocol)

In dieser Schicht gibt es das Point-to-Point Protocol (PPP). Es ist für den Verbindungsaufbau über Wählleitungen (z.B. DSL, ISDN, …) zuständig und besitzt ein Frame-Format mit Begrenzungssymbolen und Prüfsumme. PPP nutzt das Link Control Protocol (LCP) für Verbindungsaufbau und -abbau, zum Test und dem Aushandeln der Konfiguration (z.B. Nutzdatenlänge). Bei der Aushandlung kann jeder Partner eine Authentisierung fordern. Außerdem nutzt es das Network Control Protocol (NCP) zum Aushandeln der Konfiguration der unterstützten Schicht-3-Protokolle (IP, IPX, etc.). Es sind auch verschiedene Protokolle über einen PPP-Link möglich. Ein Beispiel ist das bekannte PPPoE-Protokoll.

Es gibt drei auf PPP beruhende Authentisierungsprotokolle: PAP, CHAP und EAP.

PAP (Password Auth. Protocol): Der Authentisierer kennt ID und PW aller Clients. Der Client schickt seine ID und sein Passwort im Klartext (!). Der Server antwortet darauf im Erfolgsfall mit ACK. Es gibt keine Verschlüsselung. Das Protokoll ist offensichtlich hochgradig unsicher.
CHAP (Challenge-Handshake Auth. Protocol): Dabei gibt es eine periodische Authentisierung durch einen 3-Wege-Handshake. CHAP basiert auf einem gemeinsamen Geheimnis (Passwort) K und läuft so ab:
A→B: 1, id, R_A, A
B→A: 2, id, H(id,R_A,K), B
A→B: 3|4, id
Dabei ist die id ein 1 Byte Identifier gegen Replay-Angriffe, R_Aeine Zufallszahl (Nonce), H ein Hashverfahren (MD5) und 3 bedeutet success, 4 heißt failure.
Das große Sicherheitsrisiko bei CHAP ist der PAP-Fallback, d.h. zur Abwärtskompatibilität kann man vom Server verlangen, dass er PAP statt CHAP verwendet. Dadurch wird ein Man-In-The-Middle-Angriff möglich: Erst klaut man das Passwort und startet dann eine Masquerade.
EAP (Extensible Auth. Protocol): ist ein Authentisierungsframework mit gemeinsamen Funktionen und Aushandlungsmechanismen für konkrete Verfahren. Es gibt 40 unterstützte Methoden, z.B. EAP-MD5 (entspricht in etwa CHAP) oder EAP-GTC (Generic Token Card).

Verwandt mit PPP ist das Point-to-Point Tunneling Protocol (PPTP). PPP wird für direkt verbundene Systeme genutzt, PPTP realisiert Tunnel durch/über das Internet. Dabei werden PPP-PDUs mithilfe von GRE (Generic Route Encapsulation Protocol) in IP-Pakete gekapselt. Es ist eines der ersten VPN-Protokolle. PPTP wird entweder aktiv verwendet, wenn ein Client mit einem Remote Access Server(RAS) verbindet (voluntary tunneling), oder passiv, d.h. der Client weiß nichts von PPP, wenn ein ISP Point of Presence (POP) mit einem PPTP RAS verbindet (compulsory tunneling). Die Sicherheit ist sehr mager, grade bei Protokollen wie MS-CHAP.

MS-CHAP

Microsoft hat zwei Versionen von CHAP entwickelt. In der ersten Version (MS-CHAPv1) lief das Protokoll folgendermaßen ab:

C→S: Login Request
S→C: Challenge C (8 Byte Zufallszahl)
C→S: DES(K_L,C), DES(K_N,C) mit K_L = LAN-Manager-kompatibler Hash und K_N = NT-kompatibler Hash
S: Verifikation
S→C: success | failure

Unsicher daran ist nicht nur (mittlerweile) die DES-Verschlüsselung, sondern auch der LAN-Manager-Hash, der schon in den 90ern geknackt wurde und zum Angriff auf den härteren NT-Hash eingesetzt werden konnte. Das und einiges mehr versuchte Microsoft in MS-CHAPv2 zu bereinigen:

C→S: Login Request
S→C: Challenge C (Zufallszahl mit 16 Byte)
C→S: PC, DES(K_N,R) mit PC = Peer Authenticator Challenge (16 Byte Zufallszahl) und R = die ersten 8 Byte von SHA1(C,PC,username)
S: Verifikation
S→C: SHA(O,R,”Pad to make it do more than one iteration”) mit O = SHA(MD4(K_N), DES(K_N,R),”Magic server to client constant”)
C: Verifikation

Nun kann der Client den Server verifizieren. Die festcodierten Strings sind allerdings reichlich abstrus und fügen keine Sicherheit hinzu. Die verwendeten Algorithmen (SHA-1, MD4, DES) gelten heute alle als unsicher. Das Protokoll ist unnötig kompliziert und bietet keinen integrierten Schutz. Es gab auch zur Zeit seiner Erfindung bereits bessere Verfahren. Außerdem ist eine Version Rollback Attack möglich, d.h. ein Forcieren auf MS-CHAPv1. Weitere haarsträubende Sicherheitsmängel beschreiben Schneier et al. in einer Kryptanalyse.

WLAN

WLAN kann im Infrastrukturmodus und im Adhocmodus betrieben werden. Im ersten Fall wird ein Access Point (AP) als Zugangsknoten zum WLAN verwendet. Eine Station ist als Gerät mit WLAN-Ausstattung (Client) definiert, ein Basic Service Set (BSS) als Gruppe von Stationen, die die selbe Frequenz nutzen. Ein Extendded Service Set (ESS) ist ein logisches Netz aus mehreren BSS, gebildet durch ein Verbindungsnetz (Distribution System (DSS)) und wird durch eine SSID identifiziert. Eine Verbindung zu anderen Netzen wird Portal genannt. Im Adhocmodus ist kein AP erforderlich. Alle Stationen sind gleichberechtigt. Dabei ist keine Kommunikation zwischen verschiedenen BSS möglich.

WLAN-Sicherheit hat immer damit zu kämpfen, dass die Funkschnittstelle einfacher abzuhören ist als geschützte Leitungen. Anforderungen an die Sicherheit sind Authentisierung, Zugangskontrolle, Vertraulichkeit und Integrität. Mechanismen sind WEP, WPA(2) und IEEE 802.11i (äquivalent zu WPA2).

WEP (Wireless Equivalent Privacy)

Bei WEP wird der Klartext mit einem Bitstrom XOR-verknüpft, der wiederum mit RC4 als Pseudozufallszahlengenerator (PRNG) erzeugt wird, dessen Seed aus 24-bit Initialisierungsvektor (IV) und 40-bit WEP-Schlüssel (K_BSS) besteht. Die Nachricht und ihr CRC-Wert werden konkateniert. Schematisch sieht das so aus:

WEP-Verschlüsselung und -Entschlüsselung in schematischer Skizze

CRC (Cyclic Redundancy Check) ist ein Prüfsummenalgorithmus zur Integritätsprüfung. Dabei wird der Bitstring als Polynom aufgefasst (Nachricht M als M(x)) und mit einem Generatorpolynom G(x) verrechnet, das i.d.R. standardisiert ist: CRC = M(x) mod G(x). Getestet wird der CRC so: (M(x)||CRC) mod G(x) =?= 0. Er ist einfach und billig in Hardware umzusetzen und eignet sich gut für die Erkennung von zufälligen Fehlern, aber nicht zu deren Korrektur. Es ist keine kryptographische Hashfunktion – andere sinnvolle Nachrichten mit dem selben CRC sind leicht zu erzeugen!

WEP bietet Open System Authentication. Dabei verschlüsselt der AP entweder nicht, d.h. es gibt keine Authentisierung und jeder kann den AP nutzen. Oder bei aktiver WEP-Verschlüsselung kann jeder Daten übertragen, der den Schlüssel kennt.

Die Shared Key Authentication nutzt ein Challenge-Response-Protokoll auf der Basis von WEP. Zuerst sendet die Station einen AuthReq an den AP. Dieser antwortet mit der Challenge r im Klartext. Die Station verschlüsselt dann r und schickt WEP(r) zurück, was der AP dann verifiziert.

Als optionalen Zusatz kann man bei WEP MAC-basierte Access-Control-Listen (ACL) benutzen. Dann dürfen nur bekannte MAC-Adressen senden. Die Sicherheit ist allerdings trügerisch, denn MAC-Adressen können ienfach mitgelesen werden und einfach gefälscht werden.

In punkto Sicherheit erfüllt WEP keine der obigen Anforderungen. Vertraulichkeit ist wegen des problematischen Schlüsselmanagements nicht gegeben. Der Schlüssel ist auch einfach zu brechen mittels known-plaintext oder mit einem Angriff auf RC4 über passive ciphertext-only, der nur wenige Minuten dauert. Über ARP Replay/Injection ist WEP sogar innerhalb weniger Sekunden zu knacken. Deswegen wird von einer Verwendung dringendst abgeraten. Auch die Integrität ist nicht gesichert, da CRC ungeeignet ist bei absichtlicher Manipulation (z.B. Änderung der IP-Adressen). Die Authentisierung basiert auf WEP und ist zudem fehlerhaft umgesetzt. Zugriffskontrolle kann auch nicht wirklich durchgesetzt werden, da es keine individuelle Authentisierung gibt. Sie ist also nur rudimentär möglich.

WPA (Wi-Fi Protected Access)

WPA macht es möglich, WEP-Hardware weiter zu verwenden, nutzt aber sicherere Algorithmen als WEP. Die Vertraulichkeit wird durch TKIP (Temporal Key Integrity Protocol) gewährleistet. Es gibt einen Rekeying-Mechanismus zum automatischen Schlüsselwechsel. Die Integrität wird über TKIP Message Integrity (MIC) gesichert, einer mit Schlüssel parametrisierten kryptographischen Hashfunktion. Die Authentisierung wird über einen Pre-Shared Key (PSK) geregelt oder EAP über 802.1x. Bei PSK ist die Sicherheit sehr von der Stärke des Passworts abhängig.

Angriffe auf WPA sind einigermaßen kompliziert und ausgefuchst. Einer läuft über sogenannte Rainbow-Tables. Eine andere Möglichkeit ist es, die Pseudozufallszahlenfunktion bei der Schlüsselverteilung mit einer CUDA-Architektur anzugreifen, was innerhalb von 2-3 Tagen zum Erfolg führt. Eine recht bekannte Attacke ist der Chop-Chop-Angriff. Dabei wird der Umgang mit ARP-Paketen missbraucht, um durch deren “Kleinhacken” Bytefolgen zu entschlüsseln. Genauer sieht der Angriff so aus:

Verkehr mitschneiden, bis man ein verschlüsseltes ARP-Paket findet.
Letztes Byte entfernen (Annahme, dass es 0 ist).
Mit bestimmtem Wert XOR-verknüpfen, daraufhin versuchen, eine gültige Prüfsumme zu erzeugen.
Paket an AP senden. Wenn es inkorrekt ist, wird es verworfen. Wenn es korrekt ist, erzeugt der Client ein MIC Failure Report Frame.
Wenn Schritt 4 korrekt war, dann 60 Sekunden warten vorm nächsten Versuch, sonst wird ein Verbindungsaufbau erzwungen.

Der Worst Case bei der Attacke ist 256 Tests für 1 Byte. Praktisch läuft es darauf hinaus, dass in 12 Minuten 12 Bytes entschlüsselt werden können. Die Entschlüsselung des ARP-Pakets ermöglicht die Ermittlung des Schlüsselstroms vom AP zur Station und des MIC-Codes. Dann können eigenes verschlüsselte Pakete an die Station gesendet werden, z.B. zum Manipulieren von ARPs.

Grenzen der Attacke liegen im Rekeying-Intervall, das ausreichend groß sein muss. Außerdem muss QoS aktiviert sein (sonst keine 8 Kanäle) und es funktioniert nur in Richtung AP zu Station. Eine einfache Sicherheitsmaßnahme gegen Chop-Chop-Angriffe ist der Verbindungsabbau bei 2 falschen MICs in einer Minute. Deswegen wird oben 60 Sekunden gewartet.

Bei der Weiterentwicklung WPA2 wird der RC4-Algorithmus durch AES ersetzt und TKIP durch CCMP.

5 – Sicherheit auf Schicht 3, 4 und 7

Auf Schicht 3 ist IP-Sec das Mittel der Wahl. IP selbst hat deutliche Sicherheitsschwächen. Vertraulichkeit ist nicht gegeben, da man einfach mithören, Man-In-The-Middle spielen oder den Verkehrsfluss analysieren kann. Auch die Integrität fehlt, denn Daten können verändert, Session Hijacking durchgezogen oder Replay-Attacken gefahren werden. Authentisierung ist wegen IP-Spoofing auch nicht sicher.

IP-Sec ist integraler Bestandteil von IPv6, dem Nachfolger des heute noch gebräuchlichen IPv4. Es nutzt zwei Technologien, Authentication Header (AH) und Encapsulating Security Payload (ESP). AH berechnet eine Prüfsumme über IP-Header, Authentication Header und Daten (z.B. mit HMAC-MD5) und sicher mit diesem Integrity Check Value (ICV) die Integrität des verbindungslosen Verkehrs. Auch die Authentisierung des Datenursprungs (bzw. IP-Headers) wird gesichert. Optional kann man auch noch einen Anti-Replay-Dienst einschalten. Bei ESP wird Vertraulichkeit durch die Verschlüsselung der Daten gewährleistet. Integrität wird durch MAC (z.B. HMAC-SHA1 über ESP-Header, Daten und ESP-Trailer) gesichert, Authentisierung (der Security Association) durch HMAC. Dabei ist auch ein Anti-Replay-Dienst durch Sicherung der Sequenznummern.

Eingesetzt werden diese beiden Verfahren in 2 Betriebsmodi: Transport Mode und Tunnel Mode.Die Einsatzszenarien reichen dabei von End-to-End über Telearbeitsplätze (Remote-Access Endsystem zu Security Gateway (SGW)) bis zur Kopplung von Unternehmensstandorten (SGW zu SGW). Bei letzterem verwendet man am besten AH im Transport Mode am Endsystem und ESP im Tunnel Mode am SGW. Dann ist Integrität, Ende-zu-Ende-Authentisierung und Vertraulichkeit ab dem SGW gewährleistet und auch private Adressen möglich.

Eine Security Association (SA) ist eine Liste mit sicherheitsrelevanten Daten. Sie beinhaltet den verwendeten Modus (Transport/Tunnel), Parameter (Algorithmen, Schlüssel, Zertifikate, Initialisierungsvektoren), Gültigkeitsdauer, Sequenznummernzähler, Anti-Replay-Window und einiges mehr. Die Identifikation erfolgt durch Security Parameter Index (SPI), Zieladresse und verwendetes Protokoll. In jeder Kommunikationsrichtung wird eine eigene SA verwendet. Jeder Teilnehmer hat eine Security Policy Database (SPD) mit allen SAs.

Zum Schlüsselaustausch und -generierung und zur Authentisierung wird IKEv2 verwendet. Dabei kommt der Diffie-Hellman-Algorithmus zum Einsatz:

Die Kommunikationspartner Alice und Bob einigen sich auf eine Primzahl p und eine diesbezügliche Primitivwurzel g.
Beide erzeugen je eine geheime Zahl a bzw. b aus dem Intervall [1;p-2].
Alice berechnet A = g^a mod p, Bob berechnet B = g^b mod p. Dann schicken sie sich gegenseitig ihre Zahl.
Der Schlüssel ist dann K = B^a mod p oder im anderen Fall K = A^b mod p. Beide Berechnungen liefern das selbe Ergebnis, ergo haben beide den selben Schlüssel generiert bzw. ausgetauscht.

Selbst bei einem Abhören der Nachrichten ist der Algorithmus nicht zu knacken, da die Berechnung des Schlüssels daraus zu aufwendig ist. Erst wenn die Möglichkeit der Datenänderung durch einen Man-In-The-Middle-Angriff besteht, kann die Sicherheit untergraben werden. Einen solchen Angriff unterbindet man am besten mit digitalen Signaturen und MACs.

SSL/TLS

TLS begreift sich als Zwischenschicht zwischen Schicht 4 und 5 (als Anwendungsschicht). Es wird angewendet beispielsweise bei HTTPS oder SSL-VPNs (browserbasiert oder als schlanker Client, z.B. AnyConnect). Die Authentisierung ist vor der eigentlichen Kommunikation möglich und geschieht entweder einseitig oder zweiseitig: Client prüft Server (wie bei HTTPS), Server prüft Clien oder beide sich gegenseitig. Vertraulichkeit ist gewährleistet durch Verschlüsselung, die während des Sitzungsaufbaus vereinbart wird. Zur Verfügung stehen DES, 3DES, RC4, AES und andere. Die Integrität wird per HMAC gesichert (MD5 oder SHA).

Die Protokollarchitektur von TLS sieht verschiedene Protokolle für spezielle Aufgaben vor: So gibt es das Application Data Protocol für die Datenübermittlung zwischen Anwendung und TLS; es hat Zugriff aufs Record Protocol. Das Alert-Protocol gibt Warn- und Fehlermeldungen aus. Das Change Cipher Spec Protocol ermöglicht die Änderung der Kryptoverfahren, die Initialisierung die Einigung auf neue Verfahren. Das Handshake-Protocol ist für Authentisierung, Schlüsselaustausch und Vereinbarung der Parameter zuständig. Und schließlich das Record Protocol fragmentiert und komprimiert optional die Klartextdaten und ist außerdem für Verschlüsselung und Integritätssicherung zuständig.

Problematisch bei SSL/TLS ist die Performance. Der Verbindungsaufbau ist rechenintensiv und geschieht deswegen langsamer. Es gibt außerdem keine Ende-zu-Ende-Verschlüsselung. Jede Zwischenstation erhält den Klartext. Die Usability ist in der Praxis suboptimal, da z.B. die Zertifikatprüfung bei HTTPS eher lästig als hilfreich ist. Außerdem werden immer wieder Implementierungsfehler in den SSL-APIs entdeckt. Angriffe auf TLS sind als Brute-Force oder known-plaintext möglich, aber wenig erfolgversprechend. Implementierungsspezifische Angriffe, die dezidiert die jeweiligen Schwachstellen nutzen, sind besser geeignet. Es gibt auch eine Renegotiation Vulnerability. Dadurch wird ein Man-In-The-Middle-Angriff möglich, mit dem man am Verbindungsanfang eigene Anfragen einschleusen kann.

SSH (Application Layer Secure SHell)

Bei SSH verbindet sich ein Client (ssh) mit einem Host, der auch Daemon genannt wird (sshd). Jeder Host hat ein Schlüsselpaar zur Authentisierung gegenüber den Clients. Zwei Trust-Modelle kommen zum Einsatz: Eine lokale Datenbank mit Hostname-PublicKey-Paaren. Der Hostname und der Public-Key werden von einer CA zertifiziert. Clients benötigen nur den öffentlichen Schlüssel der CA. Der Client kann den öffentlichen Schlüssel bei der ersten Verbindung zum Host in die lokale Datenbank übernehmen. Dabei ist ein MITM-Angriff möglich; die Option sollte also nicht verwendet werden.

Das Designprinzip bei SSH ist die Erweiterbarkeit. Das Basisprotokoll ist sehr einfach gestaltet. SSH setzt auf einem verlässlichen Schicht-4-Protokoll auf, in der Regel TCP. Es gibt Algorithmen für jede Kommunikationsrichtung (Verschlüsselung, Integritätssicherung, Schlüsselaustausch, Datenkompression), die frei wählbar sind. Der Server darf keine eigene Verbindung zum Client aufbauen (außer beim Forward) und keine Kommandos auf dem Client ausführen. Es gilt das Prinzip der Perfect Forward Secrecy: Die Kompromittierung eines Sitzungsschlüssels oder privaten Schlüssels darf nicht zur Kompromittierung früherer Sessions führen.

Das SSH Connection Protocol bietet eine interaktive Login Session, entfernte Ausführung von Kommandos, X11-Forwarding, Statisches Forwarding von einzelnen TCP/IP-Ports, dynamisches Forwarding auf SOCKSv5-Basis, ein oder mehrere Channels pro Dienst, Multiplexing aller Channels über einen SSH Transport Protocol – Kanal (bietet Vertraulichkeit und Integritätssicherung) und Port Forwarding, d.h. ein Port auf der lokalen Maschine wird zu einem Port auf dem entfernten System getunnelt.

6 – Firewalls und Intrusion Detection

Firewalls bestehen aus einer oder mehreren Hardware-Komponenten und Software-Komponenten. Sie koppeln mindestens zwei Netze als kontrollierter Netzübergang. Der gesamte Verkehr zwischen den Netzen läuft dabei über die Firewall. Sie realisiert Sicherheitspolicies bzgl. Zugriff, Authentisierung, Protokollierung und Audting. Nur Pakete, die den spezifizierten Policies genügen, werden durchgelassen.

Paketfilter-Firewall

Es gibt drei Klassen von Firewalls, eine davon ist der Paketfilter. Dabei handelt es sich um einen Filter auf Schicht 3 oder 4, der nach Informationen aus den Protokollpaketen (sprich Flags, Protokoll, Quell-IP-Ziel-IP, IP-Optionen, Quell-Port, Ziel-Port, etc.) filtert. Es sind nur Regeln bzgl. der Felder in den Paket-Headern möglich. Durch einen solchen Filter ist IP-Spoofing erkennbar. Es liegt vor, wenn ein Paket mit interner Quelladresse am externen Firewall-Interface ankommt.

Beim Paketfilter gibt es zwei Ansätze. Einerseits die Blacklist, bei der generell alles erlaubt ist, was nicht explizit verboten ist. Und andererseits die Whitelist, bei der generell alles verboten ist, was nicht explizit erlaubt ist. Wählen kann man auch zwischen einer statische Paketfilterung, die zustandslos Pakete unabhängig voneinander filtert, und einer dynamischen Paketfilterung, die zustandsabhängig filtert, also abhängig vom Zustand des Protokollautomaten.

Paketfilter sind einfach und preiswert und recht effizient. Sie sind außerdem gut mit einer Routerfunktionalität kombinierbar. Allerdings kann die Integrität der Header-Infos nicht garantiert werden; Fälschungen sind recht einfach. Paketfilter lassen auch nur eine grobgranulare Filterung zu. Es findet keine Analyse bei freigegebenen Diensten an. Statische Filterung ist außerdem problematisch bei Diensten, die Ports dynamisch aushandeln. Es besteht auch eine generelle Abbildungsproblematik zwischen Policy und Firewall-Regeln. Die Einstellung einer Filtertabelle ist nicht trivial – Korrektheit, Vollständigkeit und Konsistenz sind schwer festzustellen.

Applikationsfilter

Der Application Level Gateway, kurz ALG, ist ein Filter auf Schicht 7. Er analysiert Anwendungsschichtprotokolle und die Nutzdaten. Für jeden Dienst und jedes Protokoll ist ein eigener Filterprozess erforderlich (sogenannter “Proxy”). Solche Proxys sind für viele Standardprotokolle verfügbar, aber problematisch bei proprietären Protokollen. Interne Clients müssen sich i.d.R. am Proxy authentisieren. Der Proxy trennt die Verbindung zwischen Client und Server. Nach außen erscheint immer nur die Adresse des ALG: Es besteht also eine völlige Entkopplung von internem und externem Netz. Der ALG kann Zustandsinformationen halten und Nutzen.

ALGs bieten eine schlechtere Performance als Paketfilter wegen dem Overhead. Schlecht ist auch, dass sich Clients explizit an den Proxy wenden müssen. Positiv zu vermerken ist die feingranulare, dienstspezifische, zustandsbehaftete Filterung und die umfangreichen Logging-Möglichkeiten, die ein Accounting erlauben. Schön ist auch, dass eine Inhaltsanalyse möglich wird, also die Filterung aktiver Inhalte möglich ist. Man kann Benutzer authentifizieren und benutzerabhängig filtern. Die Entkopplung der Netze ist auch zu begrüßen. Zwiespältig ist die mögliche Erstellung von Nutzungsprofilen zu sehen. Lästig ist, dass jeder Dienst einen eigenen Proxy benötigt und die Sicherheit der Proxy-Implementierung und -konfiguration immer fragwürdig ist. Das Problem von Protokollschwächen bleibt bestehen.

Verbindungsgateway (Circuit Level Gateway)

Der Verbindungsgateway (CLG) ist ein Filter auf Schicht 3 und 4. Es handelt sich dabei um einen generischen Proxy bzw. “Multiprotokollproxy”. Er ist nicht auf einzelne Dienste zugeschnitten, sondern allgemeiner Vermittler von IP-Verbindungen. Auch er trennt die Verbindung zwischen Client und Server. Eine Benutzerauthentisierung am Gateway ist möglich. SOCKS kann verwendet werden. SOCKSv4 ist nur für TCP/IP gedacht, die Auth. geht nur über Identifikationsprotokolle und der Client muss DNS selbst auflösen. Bei SOCKSv5 gibt es vollwertige Client-Auth., DNS Auflösung über Server, auch für UDP und Einschränkungen bezüglich Zielrechner und -ports sind konfigurierbar.

Erfreulich beim Verbindungsgateway ist die anwendungsunabhängige Filterung und der einzelne Proxy für alle Dienste. Fürs Accounting geeignet sind die umfangreichen Logging-Möglichkeiten. CLGs sind zustandsbehaftet. Die Benutzerauthentisierung und benutzerabhängige Filterung ist ein weiterer Vorteil, genauso die Entkopplung der Netze. Nutzungsprofile sind wieder eine zwiespältige Sache. Als nachteilhaft werten muss man, dass i.d.R. keine Filterung nach Dienstprimitiven möglich ist. Wiederum ist auch die Sicherheit der Proxy-Implementierung und -konfiguration fraglich. Außerdem ist Support durch Clients oder Modifikationen der Clients erforderlich.

Firewall-Architekturen

Bei der Architektur von Firewalls geht es um die Kombination von Firewall-Komponenten und deren Anordnung. Der unterschiedliche Schutzbedarf von Komponenten führt zur Bildung von Schutzzonen (z.B. öffentlich zugänglich, Mitarbeiternetz, etc.). Bei Firewalls gibt es 4 Architekturen:

Single-Box: Die Firewall ist der einzige Übergang ins interne Netz. Ein Router übernimmt Firewall-Funktionalität (”Screening Router” mit Paketfilter i.d.R.). Normale Rechner haben 2 Netzwerkinterfaces (Dual Homed Host). Single-Box ist billig und einfach und leicht zu verwalten als Single Point of Administration. Allerdings ist sie natürlich dann auch ein Single Point of Failure und wenig flexibel. Positiv ist die meist gute Performance (bei Paketfiltern).
Screened Host: Die Firewall (=Bastion Host) liegt im internen Netz, ergo gibt es nur ein Interface. Verkehr von außen wird über einen Screening Router vorgefiltert und zum Bastion Host geleitet. Der kann entweder einen ALG oder einen CLG realisieren. Gut ist bei einem Screened Host die Trennung von Paket- und Applikationsfilter und die Vorfilterung des externen Verkehrs. Außerdem ist das Design sehr flexibel. Allerdings kann ein Paket immer noch direkt ins interne Netz gelangen.
Screened Subnet: Hier liegen die Firewall-Komponenten in einem eigenen Subnetz, das Perimeter Subnet oder DMZ (Demilitarized Zone) genannt wird. Der Schutz der DMZ nach innen und außen wird von einem Paketfilter gewährleistet. Der Vorteil an dieser Konstruktion ist, dass keine direkte Verbindung von außen nach innen möglich ist, was einen zusätzlichen Grad an Sicherheit bietet. Der interne Router bzw. Firewall schützt vor dem Internet und ggf. vor der DMZ.
Multiple Screened Subnet: Hierbei werden zwei Perimeter Subnets verwendet, die durch einen Dual Homed Host getrennt sind. Außerdem können mehrere Bastion Hosts aus Redundanzgründen verwendet werden.

Generelles zu Firewalls

Durch Firewalls werden abgestufte Sicherheitskontrollen (von einfach nach komplex) möglich. Außerdem kann man effizient protokollieren und Profile bilden. Allerdings besteht leider immer das Problem der Fehlkonfiguration. Es sind umfangreiche Kenntnisse für den gewinnbringenden Betrieb einer Firewall nötig. Meist bieten sie nur trügerische Sicherheit und verursachen erheblichen Administrationsaufwand. Generell besteht eine Tunnel-Problematik: Die Firewall kann nicht erkennen, wenn Anwendungsprotokolle über bspw. HTTP getunnelt werden. Filterregeln lassen sich außerdem per Anonymisierungstools umgehen. Die starre Portzuordnung muss auch nicht unbedingt der Realität entsprechen. Schön ist, dass man Firewalls automatisch über PAC konfigurieren kann.

Weitere Firewalltechniken gibt es auf Schicht 3 und 4. Da wäre zum einen die Network Address Translation (NAT). Dabei werden intern andere Adressen und Ports als extern verwendet. die Firewall erledigt die Umsetzung statisch oder dynamisch. Eine weitere Möglichkeit ist das Masquerading, d.h. alle ausgehenden Pakete erhalten die Adresse der FW, wodurch das gesamte interne Netz verborgen wird. Zum anderen gibt es noch Anti-Spoofing. Darunter versteht man das Binden von Firewall-Regeln an bestimmte Interfaces (egress, ingress). Wenn dann eine interne Quelladresse am externen Interface auftaucht, kann man sich sicher sein, dass es eine Fälschung ist.

Intrusion Detection Systeme

Bei Intrusion Detection Systemen (IDS) steht im Vordergrund, Angriffe automatisch zu erkennen. Intrusion Prevention Systeme verlegen sich dagegen darauf, auf Angriffe gut zu reagieren. IDS verwenden als Methode die passive und aktive Überwachung von Netzen und Netzsegmenten.

Hostbasierte IDS werden auf dem zu überwachenden System ausgeführt. Dabei kommt es zur Überwachung des Systems, der Applikationen und der Integrität (krypt. Prüfsummen, Hashing). Sie sind individuell anpassbar und erlauben sehr spezifische Aussagen über erkannte Angriffe. Allerdings benötigen sie die Ressourcen des Systems. HIDS können auch selbst das Angriffsziel darstellen. Außerdem ist eine Anpassung ans System erforderlich. Ein weiterer Nachteil: Bei einem erfolgreichen Angriff fällt mit dem System auch das IDS aus.

Als Alternative gibt es netzbasierte IDS. Es ruht auf einem eigenen Server und überwacht den Netzverkehr eines Rechners, eines Subnetzes oder einer ganzen Domäne. Es gibt also einen Server fürs gesamte Netz. Ein NIDS kann außerdem unsichtbar und ausfallsicher installiert werden und kann verteilte Angriffe erkennen. Es wird am Mirror Port eines Netzgeräts betrieben, wodurch Packet-Drop ein Problem wird. Auch eine Überlastung des NIDS ist möglich. Verschlüsselte Daten und Kanäle kann es natürlich auch nicht auslesen. Außerdem sind nur Netzauffälligkeiten erkennbar.

Wie werden nun Angriffe oder Missbrauch erkannt? Dazu gibt es drei Möglichkeiten:

Signaturbasiert: Es werden Pattern Matching und Expertensysteme verwendet, um typische Angriffsmuster zu erkennen. Das funktioniert auch relativ zuverlässig, aber es sind nur bekannte Angriffe zu erkennen. Zero-Days können überhaupt nicht erkannt oder erahnt werden.
Anomalie-Erkennung: Das IDS lernt das Normalverhalten des Systems und deutet dann Abweichungen als Angriffe. Ein solches System ist flexibel bei neuen Angriffen. Es ist aber nicht trivial, das System so zu eichen, dass es wenig False-Positives und -Negatives gibt und es adaptiv auf Netzänderungen reagieren kann.
Integritätsprüfung: Dabei werden kryptographische Hashes berechnet, gespeichert und verglichen. Das funktioniert schnell und zuverlässig, verursacht allerdings einigen Aufwand bei gewollter Änderung der Daten.

7 – Maßnahmen gegen Spam

Zum Schluss möchte ich noch kurz schildern, wie gegen Spam vorgegangen wird. Die Quellen von Spam sind meistens Botnetze oder virenverseuchte Rechner, Wegwerf-Accounts (die mit Captchas eingedämmt werden können), Backscatter (Spam entsteht durch Antwort-Automatismen) oder weitergeleiteter Spam.

Eine grundlegende Gegenmaßnahme ist die Verkehrsanalyse. Dabei wird der TCP/IP-Verkehr statistisch analysiert. Falls Schwellwerte übertreten werden, führt dies für denjenigen zu einer Strafe. Hierbei ist Whitelisting empfehlenswert, um bestimmten Teilnehmern speziellen Zugang zu gewähren. Eine andere Maßnahme ist die Authentisierung beim Mailversand. Von zahlreichen Mailprogrammen bekannt ist auch die Möglichkeit, eigene Blacklists zu führen. Man kann teilweise auch fremde Listen einbeziehen. Ein Sender Policy Framework hilft bei diesen Aufgaben. Es bietet sich – ähnlich einer Firewall – auch an, phasenweise von einfachen hin zu komplexen Kriterien zu filtern.

Ein bekannter Ansatz ist das Greylisting. Es nutzt das Fire&Forget-Prinzip der Spammer aus. Das Prinzip besagt, dass Spammer eine Spam-Mail nicht mehr als einmal versenden, da jedes weitere Versenden im Normalfall nur Zeit verschwendet. Ergo wird die Mail beim ersten Mal automatisch abgelehnt. Nach einer bestimmten Zeit (Blocking Time) wird sie dann angenommen. Weitere werden sofort akzeptiert. Dadurch lässt sich viel Spam auf einfache Weise beseitigen.

Weitere Möglichkeiten sind die inhaltliche Analyse nach bestimmten Heuristiken (Spam-Assassin ist hier das Tool der Wahl). Viren-Filterung wird meist mittels einer Quarantäne realisiert, die bei jedem dubiosen Neuankömmling den Empfänger benachrichtigt.

Eine kleine Anmerkung noch: Es tut mir leid um das viele Geschwurbel samt Abkürzungsorgien in diesem Artikel. Es ist leider nicht möglich, das Gebiet umfassend darzustellen, ohne ein Buch zu schreiben. Eine vereinfachende Darstellung würde wiederum der Materie (und dem Lernziel) nicht gerecht. Ich habe generell versucht, einen Mittelweg zu gehen, weiß aber, dass der hier bei diesem Artikel doch eine sehr steile Kurve hat. Ich bitte das zu entschuldigen

Morgen folgt dann noch ein kleiner Artikel zur Schicht 2 bei Rechnernetzen und dann ist die Chose komplett. Daumen drücken für die Prüfung in einer Woche!

Selbstorganisierende Netze

FB — Tue, 21 Sep 2010 15:29:58 +0000

Zweiter Teil der Reihe über Netzwerke. Heute zum Thema “Selbstorganisierende Netze” wie zum Beispiel Sensornetze oder die von Tauschbörsen bekannten P2P-Netze.

1 – Grundlagen
2 – Zugriffsverfahren
3 – Routingprotokolle
4 – TCP und Varianten
5 – P2P-Systeme

1 – Grundlagen

Selbstorganisierende Adhoc-Netze zeichnen sich dadurch aus, dass sie ohne die Unterstützung durch feste Infrastruktur auskommen. Die Kommunikation zwischen den Geräten erfolgt direkt (ohne z.B. Umwege über einen Router). Ressourcen, Komponenten und Dienste müssen kollaborativ verwaltet werden statt zentral. Selbstorganisation steht im Mittelpunkt der Herausforderungen selbstorganisierender Netze. P2P-Netze sind nicht unbedingt Adhoc-Netzwerke; P2P kann auch als Overlay über infrastrukturbasierte Netze realisiert werden (bspw. Tauschbörsen im Internet).

In selbstorganisierenden Netzen sind mobile Knoten in einem temporären Netzwerk vereint. Die Topologie kann sich oft und unvorhergesehen ändern. Es gibt keine zentrale Administration oder verfügbare Standarddienste. Jeder Host ist ein unabhängiger Router. Üblicherweise ist die Netzwerkschnittstelle ein Funk-Transceiver. Die Bandbreite und die Übertragungsrate sind daher limitiert. Außerdem ist Strom meist ein knappes Gut, z.B. in Sensornetzen. In solchen Fällen sollte in die Komponenten ein Sleep-Mode eingebaut sein, der hilft, Strom zu sparen. Es entsteht dann allerdings ein Overhead durch die Synchronisation beim Aufwachen bzw. Aufwecken. Ein selbstorganisierendes Netz hat normalerweise 10 bis 100 Knoten, in seltenen Fällen maximal 1000. Als Kommunikationstechnologie werden z.B. Bluetooth, WLAN im Adhoc-Modus, WiMaX im Mesh-Mode oder ZigBee in Mesh Networks (hybride Netze) verwendet. Anwendungen von selbstorganisierenden Netzen reichen von Telemetrie (Automobil-Verständigung) über Schlachtfelderkundung und -kommunikation bis hin zu Brand- oder Tierüberwachung, intelligenten Gebäuden, Medizintechnik und Logistik.

Selbstorganisierende Netze (SoNet) haben eine Reihe von charakteristischen Eigenschaften:

Autonomie: Es gibt keine externe Kontrolle.
Dynamische Operation: Hinzufügen, Löschen und Ändern von Knoten und deren Verbindungen und Daten ist jederzeit möglich. Auch das Verhalten der Teilnehmer und die Struktur des Netzes kann sich ändern.
Adaptivität und Selbstwartung: Das SoNet ist fähig, auf Störungen zu reagieren und Komponenten zu reparieren, erneuern und zu ersetzen.
Feedback: Es treten positives (Verstärkung des Effekts) und negatives (Verringerung) Feedback auf. Dazu später mehr anhand von Beispielen.
Emergenz: “Das Ganze ist mehr als die Summe seiner Teile” (Aristoteles). Das Zusammenwirken der Subsysteme führt zu unerwarteten Effekten auf Makroebene.
Kritizität: … bezeichnet einen kritischen Zustand des Systems, der zu einer Kettenreaktion führt. Schon kleine Änderungen können große Wirkung haben.
Stigmergie: Methode indirekter Kommunikation durch Modifikation der Umgebung, wie z.B. bei Ameisen.

Eine Unterart der selbstorganisierenden Netze sind Adhoc-Funknetze, die Wireless Adhoc Networks (WAHN). Die Komponenten in einem solchen Netz teilen sich einen gemeinsamen Broadcast-Kanal (shared medium). Um den Zugriff der einzelnen Teilnehmer sinnvoll zu gestalten, sind Zugriffsverfahren notwendig.

2 – Zugriffsverfahren

Ein Zugriffsverfahren sollte drei Bedingungen erfüllen: Es sollte…

fair sein (gleichmäßige Aufteilung der Bandbreite)
effizient
Kollisionen minimieren, die dadurch entstehen, dass verschiedene Knoten gleichzeitig übertragen und sich dabei gegenseitig stören.

Um das zu gewährleisten, ist Medium Access Control (MAC), also Zugriffskontrolle, nötig.

ALOHA

Ein sehr naives Verfahren dafür ist ALOHA. Dabei senden Knoten sofort ihre Nachricht, wenn sie bereit sind. Die Empfänger senden bei einer erfolgreichen Übertragung ein ACK zurück. Bei Kollisionen muss der Knoten eine zufällige Zeitspanne abwarten, dann darf er mit dem Retransmit beginnen.

ALOHA ist ein Beispiel für positives Feedback, da bei mehreren Teilnehmern die Wahrscheinlichkeit für Kollisionen sehr schnell ansteigt. Es hat deswegen eine extrem schlechte Performance. Der Durchsatz pro Rahmenzeit S = G * e ^{− 2G} (G = Versuche pro Paketzeit) beträgt nur 18% der maximalen Datenrate.

Eine Variante von ALOHA ist Slotted ALOHA. Dabei werden Zeitscheiben verwendet, an die sich die Teilnehmer beim Senden halten müssen. Bei Kollisionen kommt es also zur vollständigen Überlagerung. Eine Kollision durch teilweise Überlagerung wie bei Pure ALOHA kann so nicht auftreten. Der Durchsatz steigert sich dadurch um das doppelte auf knapp 37%.

CSMA

Intelligenter ist es, vor dem Senden den Kanal abzutasten, ob nicht schon jemand anderes sendet. Dies ist der Fall bei CSMA (Carrier Sense Multiple Access). Vor einer Übertragung wird zuerst getestet, ob der Kanal frei ist. Eine Übertragung findet nur bei freiem Kanal statt. Wenn er belegt ist, wird nach einer bestimmten Strategie die Übertragung verlegt. Eine Verzögerung der Übertragungsankündigung kann natürlich zu Kollisionen führen. Im Falle dessen erfolgt ein neuer Versuch nach zufälliger Wartezeit.

Es gibt verschiedene Arten von CSMA:

1-persistent: Wenn der Kanal frei ist, wird sofort gesendet. Wenn nicht, dann wird kontinuierlich getestet.
non-persistent: Wenn der Kanal frei ist, wird sofort gesendet. Wenn nicht, dann erfolgt eine Unterbrechung des Abtastens. Weitergemacht wird nach einer zufälligen Wartezeit.
p-persistent: Der Kanal wird in Zeitslots unterteilt. Wenn der Kanal belegt ist, wird getestet, bis ein freier Timeslot gefunden wird. Im freien Slot wird dann mit der Wahrscheinlichkeit p gesendet bzw. die Übertragung mit Wahrscheinlichkeit 1-p verlegt.

Sehr gute Ergebnisse lassen sich mit 0,01-persistentem CSMA erzielen.

Eine Variante von CSMA, die z.B. beim Ethernet verwendet wird, ist CSMA/CD (Collision Detection). Sie ist nur möglich in kabelgebundenen Netzen. Dabei wird zwischen dem gesendeten und empfangenen Signal verglichen. Falls dabei ein großer Unterschied auffällt, muss es zu einer Kollision gekommen sein. Die Komponente sendet daraufhin ein Jam-Signal aus und wartet eine kurze zufällige Zeit, die sich exponentiell zu den bisherigen Konflikten verhält (Binary Exponential Backoff).

MACA

Ein anderes Zugriffsverfahren, das ohne Carrier Sense arbeitet, ist MACA (Multiple Access with Collision Avoidance). Es nutzt zur Koordination einen RTS/CTS-Handshake. RTS bedeutet dabei “Ready To Send” und wird vom Sender geschickt. Es enthält die Adresse des Senders und des Empfängers und die Länge der Übertragung. CTS bedeutet “Clear To Send” und ist die Antwort des Empfängers an den Sender. Der Inhalt ist gleich.

In Funknetzen kommt es zu Problemen durch ausgelieferte und versteckte Terminals bzw. Knoten. Ausgeliefert ist ein Knoten dann, wenn er senden will, aber ein Knoten in seiner Nachbarschaft an einen weiter entfernten Knoten sendet und dadurch seine Übertragung verhindert. Versteckt ist ein Knoten, wenn er vom sendenden Knoten nicht sichtbar ist, den Empfang des empfangenden Knotens aber durch eine Übertragung in dessen Nachbarschaft stören kann.

MACA vermeidet ausgelieferte Terminals dadurch, dass jemand, der RTS hört, mit seiner Übertragung wartet, bis das korrespondierende CTS und die Übertragung vorbei sind. Falls kein CTS ankommt, dann ist man wohl außer Reichweite vom Empfänger. Versteckte Terminals werden vermieden, indem jeder, der CTS hört, mit eventuellen Übertragungen warten muss.

MACA ist trotzdem nicht kollisionsfrei. Beispielsweise können gleichzeitige RTS von verschiedenen Sendern kollidieren. Es kann außerdem zu einer RTS-Kollision beim Empfänger kommen, wenn der Sender dessen laufende Übertragung nicht hört. Einen Hinweis darauf erhält er aber durch ein fehlendes vorheriges CTS (siehe oben). Wenn ein CTS ausbleibt, sollte er daher eine zufällige Wartezeit (Backoff) bis zum Retransmit einlegen.

MACAW

MACAW erweitert MACA um einige Nachrichten aufgrund mehrerer Beobachtungen:

Der relevante Wettbewerb findet beim Empfänger statt.
Stau ist ortsabhängig.
Stau-Erkennung muss kollektiv geschehen.
Synchronisationsinformation über Wettbewerbsabschnitte ist für gute Effizienz nötig.

Bei MACA kommt es diesbezüglich zu zahlreichen Problemen, deren Lösung bei MACAW versucht wurde:

Unfairness: Stationen mit niedrigem Binary Exponential Backoff (BEB) können dauernd senden, während andere mit hohem BEB ewig warten müssen.
Lösung hierfür ist BEB-Copy, d.h. alle übernehmen das BEB vom Sender.
Die Backoff-Anpassung geschieht zu schnell: Bei BEB-Copy haben nach erfolgreicher Übertragung alle Teilnehmer einen minimalen BEB. Es kommt also erstmal zu einer ineffizienten Wettbewerbsperiode ohne Datenübertragung.
Lösung: MILD = Multiplicative Increase, Linear Decrease. Der BEB wird beim Erhöhen mit 1,5 multipliziert, beim Erniedrigen aber nur 1 subtrahiert.
Streams werden unfair behandelt.
Lösung: Es werden mehrere Queues (1 pro Ziel) mit eigenem Backoff eingerichtet. Die Queue mit niedrigster Übertragungszeit sendet als nächstes.
Übertragungsfehler: Retransmits werden nötig. Eine Rettung ist durch TCP oder höhere Protokolle möglich, diese haben aber einen Timeout > 0,5 Sekunden, was viel zu lange ist und folglich den Durchsatz vermindert.
Lösung: Bestätigung nach Datenübertragung (RTS – CTS – DATA – ACK).
Ausgelieferte Stationen können CTS nicht hören: Hierbei erhöht sich das Backoff unnötigerweise. Es kommt auch vor, dass das RTS das ACK stört.
Lösung: keine!
Ausgelieferte Stationen wissen nicht, ob RTS-CTS erfolgreich war. Sie verschieben also ihre eigene Übertragung unnötigerweise.
Lösung: Entweder Carrier Sense (nicht in MACAW integriert) oder ankündigendes Paket (”Data Send”, DS), das die Länge der Übertragung enthält: RTS – CTS – DS – DATA – ACK. Eine ausgelieferte Station wartet dann mit ihrer nächsten Aktion bis zum Ende der Übertragung plus einer zufälligen Wartezeit.
Empfänger kann wegen einer Übertragung in der Umgebung nicht mit CTS antworten. In diesem Fall erhöht der Sender sinnlos sein Backoff.
Lösung: Nach dem Erhalt des ACK der laufenden Übertragung publiziert der Empfänger ein RRTS (”Request for RTS”) im nächsten freien Abschnitt. Der Sender kann dann sein RTS schicken und wie oben fortfahren.

Weitere Verfahren

Besprochen wurden auch noch IEEE 802.11, (D)BTMA und MARCH. Die beiden letzten werde ich hier nicht näher ausführen, ersteres ist auf Wikipedia angenehm zu lesen.

3 – Routingprotokolle

Es gibt zwei Arten von Routingprotokollen für selbstorganisierende Netze: Die einen sind tabellenbasiert, die anderen arbeiten on-demand. Zu den tabellenbasierten Protokollen gehören DVR, DSDV und WRP, zu den on-demand Protokollen DSR, AODV, LAR, ABR und ZRP.

DVR (Distance Vector Routing)

Beim Distance Vector Routing hat jeder Knoten eine Tabelle mit der kürzesten Distanz zu jedem Knoten im Netz und den dafür nötigen Nachbarsknoten. Tabellenupdates erfolgen über Broadcast. Die Distanzmetrik wird bestimmt von der Anzahl der Hops, der Verzögerung und den Paketen auf dem Pfad. Bei DVR kann es zu einem Count-to-Infinity-Problem kommen, wenn eine Verbindung reißt und verschiedene Knoten sich gegenseitig ihre neuen Einträge zu-broadcasten und dabei in eine Endlosschleife geraten.

DSDV (Destination-Sequenced Distance Vector Protocol)

Bei DSDV führt jeder Knoten eine Destination Sequence Number (DSN), die zur Bestimmung der Aktualität genutzt wird. Der Knoten mit der höheren DSN für ein bestimmtes Ziel hat ergo die aktuelleren Daten. Die Knoten verschicken Tabellenupdates mit DSN an ihre Nachbarn. Die DSN ist dabei immer höher als beim letzten Update und eine gerade Zahl). Wenn eine getrennte Verbindung erkannt wird, wird deren DSN um 1 erhöht (ergo ungerade Zahl). DSDV bevorzugt geringe Distanzen bei gleichen DSNs. Falls die Distanz gleich ist, wird die höhere DSN eingetragen.

WRP (Wireless Routing Protocol)

Bei WRP führt jeder Knoten eine Distance Table und eine Routing Table. In der Distance Table sind in jeder Zeile Ziel, Nachbar, Distanz und Vorgänger des Ziels verzeichnet. In der Routing Table finden sich Knoten, nächster nachfolgende Knoten, Vorgänger und Distanz. Wenn ein Knoten eine getrennte Verbindung zu einem Nachbarn bemerkt oder eine Änderung der Kosten zum Erreichen eines Ziels oder ein Vorgängerknoten sich ändert, berechnet er die Distanzen und die Vorgänger zu allen betroffenen Zielen neu anhand seiner Distance Table und schickt Updatenachrichten bzgl. der Änderungen an seine Umgebung. Daraufhin löschen bei einem Ausfall eines Knotens alle Knoten die Routingeinträge, wo selbiger Knoten der Vorgängerknoten ist.

WRP konvergiert bzgl. aktueller Routinginformationen viel schneller als DSDV.

DSR (Dynamic Source Routing)

Weiter geht’s mit on-demand Routingprotokollen. Sie verursachen keinen Overhead durch den Austausch von Routingtabellen. Generell arbeiten sie mit dem Flooding von RouteRequest-Paketen (RReq). Das Ziel antwortet darauf mit RouteReply an die Quelle.

DSR funktioniert ohne Beacons, d.h. es werden keine periodischen “Hallo”-Pakete versandt. Die RReq-Pakete haben Sequenznummern zur Vermeidung von mehrfachem Versenden. Es basiert auf Source Routing, d.h. die Quelle initiiert und bestimmt das Routing. Entlang der Route können Wege zu bestimmten Zielen gespeichert werden (Route Caching), um den RReq/RRep-Handshake zu verkürzen. Bei DSR kann man auch Daten ans RReq-Paket anhängen (”Piggybacking”). Das lohnt sich allerdings nur bei kleinen Daten. Caching wird dann umständlich. Eine weitere Verbesserung erfährt DSR durch Reflecting Shorter Routes: Wenn ein Knoten eine kürzere Route zum Ziel entdeckt, dann schickt er ein RRep an die Quelle.

AODV (Adhoc On-demand DVR Protocol)

AODV funktioniert ähnlich wie DSR mit dem Fluten von RReq-Paketen. Es verwendet allerdings kein Source Routing, sondern jeder Knoten hat eigene Routingtabellen. Ein RRep wird versandt, wenn Zwischenknoten eine frische Route haben. Ähnlich wie bei DSDV gibt es DSNs, die für die Frische einer Route stehen. AODV hat bessere Performance als DSR bzgl. Overhead und Verzögerung, hat allerdings das Problem, dass eine unnötige Flut von RReq-Paketen durchs Netzwerk geistert. Die Lösung dafür lautet Expanding Ring Search, d.h. die Einführung einer TTL (Time To Live) für RReq-Pakete, die bei jedem Hop verringert wird und bei deren Ablauf das Paket verworfen wird. Getrennte Verbindungen werden durch ausbleibende Beacons erkannt. Der Vorgänger des kaputten Links schickt dann an seine Vorgänger die diesbezügliche Information.

LAR (Location-Aided Routing)

LAR nutzt Ortsinformationen, um RReq-Flooding zu vermeiden. Zur Ortsbestimmung wird beispielsweise GPS verwendet. Die Knoten verpacken ihre Ortsinformationen (sprich Koordinaten und Geschwindigkeit) in RRep-Pakete und in die Daten. Es gibt zwei Versionen von LAR:

Bei LAR1 wird der Aufenthaltsort des Ziels auf eine bestimmte Fläche geschätzt (die Expected Zone). Sie wird aus dessen letzter bekannter Position und Geschwindigkeit geschätzt. Dann wird eine Request Zone errichtet. Sie umfasst das kleinstmögliche Rechteck um Quelle und Expected Zone, wobei sich diese in den Ecken diametral gegenüberliegen. Nur Knoten innerhalb der Request Zone leiten bzw. fluten RReq-Pakete weiter. Wie man sich leicht ausmalen kann, ist es durchaus möglich, dass sie wegen einer ungünstigen Topologie gar nicht bis zum Ziel kommen.

Deswegen gibt es das etwas klügere LAR2. Es basiert auf der Distanz zwischen Quelle und Ziel, die in RReq-Paketen mitgeführt wird. RReq werden nur weitergeleitet, wenn die Distanz zwischen neuem Knoten und Ziel kleiner ist als die alte Distanz. Auch in diesem Fall kann es dazu kommen, dass der Weg zum Ziel “verbaut” ist, weil zwischendurch Hops zu weiter entfernten Knoten nötig wären. Abhilfe für dieses Problem schafft das Greedy Perimeter Stateless Routing.

ABR (Associativity-Based Routing)

ABR legt die Betonung auf langlebige, stabile Routen (statt kurze). Die Stabilität der Links wird anhand der Anzahl von Beacons bestimmt, die “Associativity Ticks” genannt werden. Der Pfad zum Ziel wird durch RReq-Flooding aufgebaut (wie bei DSR). Das RReq-Paket enthält dabei den durchlaufenen Pfad und die zugehörigen Ticks. Das Ziel wählt dann aus den angekommenen RReq-Paketen den Pfad mit den meisten stabilen Links aus. Getrennte Verbindungen werden durch Local Query (LQ) repariert, die der Vorgängerknoten des kaputten Links an seinen Vorgänger schickt. Wenn dieser auch keine Route kennt, broadcastet er das LQ mit TTL-1 (TTL ist üblicherweise die halbe Distanz Quelle-Ziel). Falls auch damit kein neuer Weg gefunden wird, muss die Quelle eine ganz neue Route finden.

ZRP (Zone Routing Protocol)

Ein weiterer Ansatz ist das Zone Routing Protocol. Grob gesagt wird das Netz in Zonen unterteilt, die sich aus der k-Nachbarschaft des Quellknotens ergeben (z.B. alles rundrum, was maximal 3 Hops entfernt liegt). Innerhalb dieser Zone wird mit einem der obigen Routingprotokolle gearbeitet. Wenn ein Ziel außerhalb der Zone erreicht werden soll, wird es gesucht, indem an alle am Rand liegenden Knoten ein Request-Paket gesendet wird, die dann wiederum den Algorithmus wiederholen.

4 – TCP und Varianten

Das TCP-Protokoll bietet Flusskontrolle und Staukontrolle. Flusskontrolle garantiert, dass der Puffer des Empfängers nicht durch zu viel und zu schnelles Senden überflutet wird. Dazu schickt der Empfänger an den Sender ACK-Nachrichten, die die max. Datenmenge als Angabe enthalten (AdvertisedWindow, AW). Durch die Staukontrolle wird verhindert, dass zu viele Quellen zu viele Daten zu schnell herumschicken und dadurch das Netz überlastet wird, was sich durch Pufferüberlauf in den Zwischenknoten ausdrückt. Dazu werden die Sender gedrosselt. Die bei TCP verwendete Ende-zu-Ende-Staukontrolle läuft so ab, dass aus beobachtetem Paketverlust und der Verzögerung die Stausituation abgeschätzt wird. Möglich wäre auch eine network-assisted congestion control (Staukontrolle), bei der Zwischenknoten Feedback zur Situation über eine sogenannte Congestion Flag weitergeben.

Damit zusammen hängt das Congestion Window (W), das die Menge von Daten angibt, die der Sender ohne ein ACK vom Empfänger an ihn übertragen darf. Bei Empfang eines ACK rutscht das Fenster weiter und neue Daten können übertragen werden. Die Größe des W ist abhängig von der Stausituation und Kollisionen; die Maximalgröße beträgt min(W,AW).

Bei TCP-Übertragungen gibt es folgende Phasen:

Slow Start: W=1, nach erfolgreichem Roundtrip W=W*2. Die Phase endet bei Nichterhalten eines ACK, was als Stau interpretiert wird, oder wenn der Slow-Start-Threshold (ss-thresh) erreicht ist.
Congestion Avoidance: startet bei ss-thresh. Das Congestion Window wächst nur noch linear (nach Roundtrip W=W+1).
Congestion Control: Bei Timeout oder Duplicate ACKs wird der ss-thresh auf W/2 gesetzt, W auf 1 und wieder mit Slow Start begonnen.
Fast Retransmit: Statt Congestion Control wird nach dem dritten Dup-ACK ss-thresh=W/2 und W=ss-tresh gesetzt. Dann wird in die Congestion Avoidance übergegangen.

Beim Entdecken von Paketverlust kann ein Timeout vorliegen. Er wird auf RTT (Roundtrip Time) plus eine gewisse Zeitspanne geschätzt. Bei Ablauf des Timeouts wird, wie oben erwähnt, Congestion Control aktiviert. Die Timeoutzeit verdoppelt sich (BEB). Segmente ohne ACK werden nochmals übertragen. Wenn die Übertragung erfolgreich war, wird der Timeout wieder auf RTT+Δt gesetzt.

TCP ist absolut ungeeignet für Adhoc-Netze, da es Paketverlust als Netzüberlast fehlinterpretiert (und ergo auch das Congestion Window). Bei Adhoc-Netzen liegt dagegen häufiger ein Pfadbruch vor; die Sicherungsschicht ist also schuld am Dilemma. Die Wiederherstellung der Verbindung auf Schicht 3 ist aufwendig. Außerdem ist der Effekt der Pfadlänge zu bedenken: Je länger der Pfad ist, desto höher steigt die Wahrscheinlichkeit eines Pfadbruchs, und der Durchsatz sinkt. Weitere Probleme sind das asymmetrische Linkverhalten, der unidirektionale Pfad und die Sliding-Window-basierte Übertragung. Aus diesen Gründen wurden einige Modifikationen für TCP vorgeschlagen.

TCP-Feedback

Bei TCP-Feedback sendet ein Knoten, der einen Pfadbruch bemerkt (Failure Point, FP), eine Route Failure Notification (RFN) in richtung Quelle. Die auf dem Weg liegenden Zwischenknoten aktualisieren damit ihre Routingtabellen und schicken die RFN weiter, außer einer von ihnen hat eine alternative Route zum Ziel. In diesem Fall verwirft er die RFN. Falls die RFN bis zur Quelle kommt, geht diese in den Snooze State: Sie leitet einen Sendestop ein, freezt alle Timer und ihr Congestion Window und beginnt mit einem Route Failure Timer (RFT). Falls vor Ablauf dieses Timers der FP einen neuen Pfad entdeckt, sendet er eine Route Reestablishment Notification (RRN) an die Quelle. Bei Empfang der RRN geht die Quelle zurück in den Connected State und fährt mit der Übertragung fort, ohne Timer oder Fenster zu resetten. Wenn der RFT ausläuft, ohne dass eine RRN die Quelle erreicht hat, dann reaktiviert diese ihre Timer und Windows und leitet eine Congestion Control ein.

TCP-Bus

TCP-Bus nutzt ähnlich wie TCP-Feedback die Informationen in den Zwischenknoten. Es puffert außerdem Segmente der Nachrichten in den Zwischenknoten, um Neuübertragungen zu vermeiden. Es basiert auf ABR. Falls eine Verbindung abbricht, sendet der Pivotknoten (Vorgänger des kaputten Links) eine Explicit Route Disconnection Notification (ERDN) zur Quelle, die die Nummer des Segments (ERDN_GEN_SEG) enthält, das sich am Anfang der Queue des Pivotknotens befindet. Die Quelle stoppt bei Empfang der ERDN ihre Übertragung und friert alle Timer und Fenster ein. Sie merkt sich außerdem die Nummer des letzten übertragenen Segments (ERDN_RCVD_SEG). Der Knoten hinter dem Pfadbruch schickt eine Route Notification (RN) ans Ziel. Die Segmente, die sich in den Zwischenknoten befinden, können verworfen werden. Der Pivotknoten verschickt bei einem Pfadbruch eine Local Query (LQ, enthält ERDN_GEN_SEG), um einen neuen Pfad zum Ziel zu finden. Das Ziel antwortet nach Erhalt der LQs mit einer ABR-Kontrollnachricht, die die Nummer des letzten erhaltenen Segments beinhaltet (LAST_ACK). Wenn ein neuer Pfad besteht, schickt der Pivotknoten eine Explicit Route Successful Notification (ERSN) an die Quelle und macht dann normal bei GEN_SEG weiter. Die Quelle führt ihre Arbeit bei LAST_ACK fort und lässt die Segmente zwischen GEN_SEG und RCVD_SEG aus, die noch in den Zwischenknoten lagern.

TCP-Split

TCP-Split, auch Split-TCP genannt, trennt sinnvollerweise die Verantwortlichkeiten: Staukontrolle ist ein lokales Phänomen und wird auch so behandelt, Verlässlichkeit hingegen Ende-zu-Ende. Auf dem Pfad von der Quelle zum Ziel werden Proxys errichtet. Dadurch entstehen viele kurze Verbindungen. Die Proxys puffern Pakete vom vorherigen Proxy und sind für die Auslieferung zum nächsten verantwortlich. Bei Paketverlust wird das Paket vom letzten Proxy neu geholt (NICHT von der Quelle). Bei Erhalt eines Pakets schickt ein Proxy ein Local ACK (LACK) an den vorherigen Proxy. Das Ziel schickt je ein ACK an die Quelle bzw. ein kumuliertes ACK für bspw. 100 erhaltene Segmente. Vorteilhaft an TCP-Split ist, dass der Sender sein Congestion Window bei einem Pfadbruch nicht anpassen muss. Außerdem wird die nötige Bandbreite durch die Lokalität von Fehlern, Lasten und Neuübertragungen (localized capture effect) reduziert. Die Proxys müssen allerdings on-demand ausgewählt werden.

5 – P2P-Systeme

Ein P2P-System ist definiert als selbstorganisierendes System von gleichen autonomen Entitäten, das in einer Netzwerkumgebung unter Vermeidung zentraler Dienste auf gemeinsame Nutzung von verteilten Ressourcen abzielt.

P2P wird als Layer über dem IP-Layer realisiert. Es ist das Gegenteil des Client-Server-Prinzips, das fürs WWW charakteristisch ist. Es gibt strukturierte (auf DHT basierend wie z.B. Chord oder CAN) und unstrukturierte P2P-Netze. Letztere sind entweder zentralisiert (z.B. Napster), pur (z.B. Freenet) oder hybrid (z.B. Gnutella 0.6, JXTA).

P2P-Netze werden angewendet, um beim Ubiquitous Computing oder bspw. bei Instant Messengern (z.B. ICQ) aktuelle Präsenzinformationen auszutauschen. Man kann sie auch für Kollaborationszwecke verwenden, z.B. für Shared Spaces oder Groupware. Die größte Verbreitung haben sie aber beim Filesharing erlangt. Dort gibt es drei Modelle:

Centralized Directory Model: Ein Koordinator bietet einen Indexdienst an. Jede Suchanfrage geht an den Koordinator, der als Antwort eine Liste mit Peers schickt. Die Datenübertragung findet dann direkt zwischen den Peers statt. Der Indexdienst stellt einen SPoF dar. Beispiel für dieses Modell ist Napster.
Flooded Request Model: Jede Suchanfrage geht an eine bestimmte Anzahl von Peers. Wenn diese nicht antworten können, dann wird sie weitergeschickt mit TTL-1. Die Übertragung der Daten findet dann wieder direkt statt. Das Modell skaliert offensichtlich nicht und kann außerdem nicht garantieren, dass existierende Dokumente gefunden werden.
Document Routing Model: Bei diesem Modell werden Dateien nicht bei den sie anbietenden Peers gespeichert, sondern an anderen Stellen im P2P-Netz. Jeder Peer verwaltet eine gewisse Menge von Dateien. Dateianfragen werden nach einer bestimmten Funktion auf zuständige Peers gemappt/abgebildet (Hashfunktion/DHT). Es findet eine selbstorganisierende Adaption für beitretende und verlassende Peers statt.

Um in ein P2P-Netz reinzukommen, muss man mindestens einen Teilnehmer des Netzes kennen (der einen dann mit den anderen bekannt macht). Das Prinzip nennt sich Bootstrapping. Nur wie finden? Dafür gibt es zwei Möglichkeiten: Entweder nutzt man einen Bootstrap Cache, d.h. man klappert altbekannte ehemalige Teilnehmer ab, ob sie gerade aktiv sind. Dafür muss man natürlich vorher schon mal dabei gewesen sein. Oder man nutzt einen Bootstrap Server, also einen bekannten aktiven Server und bezieht von ihm die aktiven Knoten. Eine weitere Möglichkeit wäre ein Broadcast auf dem IP-Layer (limitiert aufs lokale Netz).

DHT

Um die Grundlagen von modernen P2P-Systemen zu erfassen, muss man auch kurz auf Distributed Hash Tables (DHT) eingehen. Bei DHTs befinden sich Daten und Knoten im selben Adressraum. Die Verfügbarkeit von Daten ist deterministisch bestimmbar. Die Abbildung von Knoten und Daten in den Adressraum geschieht mittels einer Hashfunktion. Dabei korrelieren reale und logische Topologie in der Regel nicht. Man benötigt bei der Suche O(log N) Hops zum speichernden Knoten. Jeder Knoten hält O(log N) Routingeinträge pro Knoten. N ist hier die Anzahl der Knoten. DHTs arbeiten also sehr performant. Problematisch ist allerdings die Pflege der Routinginformationen. Außerdem können keine “Fuzzy Queries” gestellt werden, z.B. nicht mit Wildcard gesucht werden.

Der Unterschied zu DNS besteht darin, dass DNS Namen auf IPs abbildet. Eine DHT kann als Wert eine Adresse, Daten, Dokumente oder sonstiges haben. DNS hat außerdem eine hierarchische Struktur und erfordern eine aufwendige Administration, die bei DHTs wegfällt. DNS ist noch performanter als DHTs (O(log₂N)). Hashalgorithmen wie SHA-1 liefern außerdem i.d.R. keine Gleichverteilung der IDs. Darauf wird später noch kurz einzugesehen sein. Die Realität zeigt außerdem, dass die Anfragehäufigkeit für URLs zipf-verteilt ist, also hoch für wenige, niedrig für viele. Auf bestimmte Knoten entfallen also hohe Lasten, während andere wenig tragen müssen. Als Gegenmaßnahme kann hier kollaboratives Caching dienen. Es ist bei DHT desweiteren schwierig, globale Software-Updates einzuspielen. Unangenehm ist auch das Leecher-Phänomen: Jeder will den Dienst nutzen, aber keiner bereitstellen.

DHTs müssen flexibel, verlässlich und skalierbar sein. Sie müssen eine gleichmäßige Verteilung der Daten bieten (zur effizienten Suche). Darüberhinaus sollten sie über Anpassungsmechanismen verfügen, die Fehler, Joins (Beitritte) und Exits (Austritte) abfedern. Da die Knoten jeweils für einen bestimmten Abschnitt des Adressraums für Daten zuständig sind, ändern sich bei Join und Exit die Verantwortlichkeiten.

Chord

Chord nutzt SHA-1 (mit 160 bit) als Hashfunktion. Der Adressraum wird dabei als Kreis gesehen. Der Nachfolger im Uhrzeigersinn verwaltet dabei die hinter ihm liegenden Key-Value-Paare. Jeder Knoten hat eine sogenannte FingerTable, die log N Links zu anderen Knoten speichert, wobei der Tabellenintrag i auf den Nachfolger n+2ⁱ verweist (”i-ter Finger”).

Der Routingalgorithmus läuft dann so ab: Jeder Knoten n leitet die Anfrage an den weitestentfernten Vorgänger des Schlüssels k weiter, bis n = Vorgänger(k) und Nachfolger(n) = Nachfolger(k). Die Antwort ist dann Nachfolger(n).

Der Beitritt eines neuen Knotens n wird wie folgt verarbeitet:

n fragt einen anderen Knoten o nach der eigenen ID.
o antwortet ihm mit Nachfolger(n) = s.
n informiert s über seine Existenz. Daraufhin aktualisiert s seinen Vorgänger-Pointer.
n fragt o nach Nachfolgern n+2ⁱ.
n hat validen Nachfolger und FingerTable, aber die anderen Knoten wissen noch nichts von n. Dafür wird nun die Stabilisierung eingeleitet.

Jeder Knoten führt periodisch eine Stabilisierung aus, um aktuelle Informationen über seine Umgebung zu erhalten. Dazu fragt er seinen Nachfolger nach dessen Vorgänger. Falls ein neuer Knoten n dazwischen liegt, kann k seinen Nachfolger-Eintrag aktualisieren und n informieren, dass k sein Vorgänger ist. n erhält dann alle Schlüssel zwischen sich und dem Vorgänger zur Verwaltung.

Updates der FingerTable sind teuer. Deswegen gibt es den Algorithmus fix_fingers(). Diese Aktion führt jeder Knoten periodisch aus. Dabei wählt er zufällig einen Finger i in seiner Tabelle aus und fragt nach dessen Nachfolger, um den wahren Nachfolger n+2ⁱ zu finden.

Die Wartung beinhaltet also einerseits die Stabilisierung und andererseits FixFingers. Beim Ausfall eines Fingers wird die Anfrage zum Vorgänger des Fingers weitergeleitet und der Finger mit seinem Nachfolger ersetzt. Außerdem gibt es einen periodischen Liveness-Check aller Finger. Dabei ist der Wartungs-Traffic mit Korrektheit und Liveness abzuwiegen. Beim Ausfall des Nachfolgers erhält man auf Anfragen eine falsche Antwort bzw. alle Anfragen scheitern. Die Lösung dafür wäre eine Liste von Nachfolgern. Das Ausscheiden von Knoten könnte man der Einfachheit halber auch als Ausfall des betreffenden Knotens verarbeiten. Bei einer geplanten Abmeldung ist es aber effizienter, wenn der betreffende Knoten an Nachfolger, Vorgänger und die Knoten in Finger-Distanz eine Benachrichtigung schickt und die Key-Value-Paare entsprechend kopiert werden. Join-, Leave- und Fail-Aktionen haben eine Komplexität von O(log²N).

Ein Nachteil von Chord liegt darin, dass kein Gefühl für Nähe vorhanden ist. Deswegen sind keine Optimierungen a la proximity-based Routing möglich (außer in entsprechenden Weiterentwicklungen). Chord-Ringe können außerdem in realistischen Situationen brechen.

Pastry

Auch bei Pastry teilen sich Knoten und Objekte einen ID-Raum. Pastry bietet außerdem eine Nahbereichsmetrik. Bei jedem Routingschritt kommt die Nachricht sowohl numerisch als auch physisch näher ans Ziel. Zwar gibt es keine Garantie der kürzesten Route, aber dennoch eine gute Performance. Die Lokalitätsinformationen werden entweder über Pings oder Hops (~ tracert) erschlossen.

Jeder Knoten hat folgende Routinginformationen:

Leaf Set: enthält L/2 numerisch naheste Knoten-IDs (sowohl größere als auch kleinere).
Routing Table: speichert präfixbasiert die je nach Adress-Level nahesten Knoten (siehe WP zur genaueren Erläuterung).
Neighborhood Set: enthält die M physisch nahesten Knoten (IDs und IP-Adressen). Diese werden nicht fürs Routing vorgehalten, sondern zur Wahrung von Lokalitätseigenschaften.

Der Beitritt eines neuen Knotens X läuft wie folgt ab:

Join-Nachricht an Knoten A (Bootstrap-Knoten, der physisch nahe an X liegt).
A leitet die Informationen weiter an B, C, …
Die Weiterleitung stoppt bei Z, das numerisch X am nächsten ist.
In Schritt 2 erhält X außerdem die Zustandstabellen der Knoten:
N-Set von X = N-Set von A
L-Set von X = L-Set von Z
Routingtabelle von X: Zeile 1 = Zeile 1 der Tabelle von A, Zeile 2 = Zeile 2 der Tabelle von B, … => Dadurch bleibt die Lokalität erhalten.
X sendet seinen Zustand an jeden Knoten in seinen Tabellen (L,R,N).

CAN (Content Adressable Network)

Bei CANs ist der Adressraum mehrdimensional. Jeder Knoten besitzt eine Zone, aber keine bestimmte ID. Datenobjekte werden beim Besitzer der Zone gespeichert, zu der der Schlüssel gehört. Knoten speichern nur Informationen über unmittelbare Nachbarn (IP und Port des Nachbarknotens und dessen Zone). Jeder Knoten hat bei d Dimensionen 2d Nachbarn. Es sind auch mehr “Realitäten” pro Knoten möglich, d.h. bei r Realitäten ist jedes K/V-Paar auf r Knoten gespeichert.

Die Wegewahl wird durch Greedy Routing bestimmt. Dabei leitet jeder die Nachricht zur Zone mit den nahesten Koordinaten bzgl. des Ziels weiter. Die Pfadlänge (O(d*n^1/d)) verringert sich durch Beitritte. Dadurch kommt es außerdem zu weniger Latenz und besserer Fehlertoleranz durch mehr Auswahl an Hops.

Der Beitritt eines neuen Knotens n läuft wie folgt ab:

n wählt zufällig einen Ort im ID-Raum.
n schickt eine Join-Nachricht an den existenten Knoten e, der die Nachricht an den betroffenen Zonenbesitzer d weiterleitet.
d teilt seine Zone dann in zwei Hälften und gibt eine davon n. Die Teilung verläuft abwechselnd entlang der X- bzw. Y-Achse.
d schickt n alle K/V-Paare, für die er nun zuständig wird.

Load Balancing bei DHTs

SHA-1 ist ziemlich gleichverteilt, führt aber beim Beitritt neuer Knoten (z.B. bei Chord) zur Inbalance. Schon oben wurde erwähnt, dass dadurch die Lastverteilung unfair wird. Deswegen hat man sich ein paar Wege einfallen lassen, dieses Problem abzumildern bzw. zu umgehen.

Einer davon nennt sich Power of Two Choices. Dabei gibt es eine Hashfunktion für Knoten und viele Hashfunktionen für Daten. Der Knoten mit dem niedrigsten Load speichert die Daten, die anderen speichern einen Pointer darauf (oder alternativ auch Daten). Bei einer Anfrage werden alle Hashfunktionen berechnet und die Anfrage an einen der Knoten mit Pointer geschickt, der dann zum Ziel weiterleitet (oder alternativ selbst die Daten hat). Dieses Verfahren führt zu einem besseren Load Balancing. Es gibt dabei allerdings auch Knoten ohne Load.

Eine andere Möglichkeit sind Virtual Servers (VS). Dabei werden virtuelle Knoten verwaltet, die für mehrere Intervalle im Adressraum zuständig sind. Man unterscheidet zwischen schweren (überlasteten) und leichten Knoten. Ein VS wird von einem schweren zu einem leichten Knoten nur dann verlegt, wenn (1) der leichte Knoten dadurch nicht schwer wird und (2) der VS der leichteste ist, der den schweren Knoten leicht macht. Wenn kein entsprechender VS vorhanden ist, dann nimmt man den schwersten. Im Grunde entspricht das Vorgehen dem Hinzufügen und Löschen von Knoten in der DHT. VS-Wechsel sind auf drei Arten möglich:

One-to-One: Ein leichter Knoten berechnet eine zufällige ID und fragt den zuständigen Knoten nach dessen Schwere.
One-to-Many: Leichte Knoten melden ihren Load an Directories. Schwere Knoten fragen dann bei den Directories an und kontaktieren dann die leichten Knoten für einen Austausch.
Many-to-Many: Directories berechnen einen Transferplan, den die Knoten nach Mitteilung ausführen.

Positiv an Virtual Servers ist, dass kein Knoten ohne Load bleibt. Allerdings gibt es einen höheren maximalen Load als bei Power of Two Choices.

Eine dritte Option ist das Modellieren des Systems nach der Wärmeverteilung, die Thermal Dissipation. Dabei werden Knoten nicht über den ID-Raum referenziert, sondern über ihr anvertrautes Intervall (ähnlich wie bei CAN). Es gibt mehrere Knoten pro Intervall (Redundanz für Fehlertoleranz). Alle Knoten im Intervall halten Kopien der zugewiesenen Dokumente. Das Routing geschieht mittels FIngerTables wie bei Chord. Pro Intervall müssen mindestens f Knoten vorhanden sein. Es dürfen maximal 2f Knoten vorkommen, sonst wird das Intervall geteilt. Die Abgabe von Knoten an andere Intervalle ist möglich; Intervallgrenzen können sich auch verschieben. Vorteilhaft ist, dass dadurch kein Knoten ohne Load bleibt, allerdings ist für die Thermal Dissipation auch mehr Aufwand nötig, der sich aber mit der Redundanz aufwiegt.

Ganz kurz angesprochen wurde auch noch das P-Grid, bei dem ich aber auf die Wikipedia verweise.

Verteilte Systeme

FB — Mon, 20 Sep 2010 00:28:17 +0000

Und weiter geht der Reigen… Die nächste Prüfung dreht sich, grob gesagt, um Netzwerktechnik. Erstes von drei Themen sind Verteilte Systeme – also Systeme, in denen Komponenten auf vernetzten, räumlich getrennten Computern durch Message Passing miteinander kommunizieren und ihre Aktionen koordinieren. Wie das genau aussieht, werde ich jetzt beschreiben.

1 – Grundlagen
2 – Suchen und Finden
3 – Dienste
4 – Uhrensynchronisation
5 – Prozesskooperation
6 – Sicherheit
7 – Maßnahmen zur Skalierbarkeit

1 – Grundlagen

Verteilte Systeme (VS) zeichnen sich durch Proaktivität, Wissenskombination (Kontextinformationen), Zustandsübertragung, Einbettung (Integration von Elektronik in geschlossene Systeme), Kontextsensitivität (Person, Ort, Entität) und allgegenwärtige Verfügbarkeit aus: “for everyone anywhere at any time”.

Die Kommunikation in Verteilten Systemen läuft parallel oder nebenläufig (Parallelität + Abhängigkeit bzw. Resource Sharing) ab. Sie ist entweder synchron (blockierend und meist ungepuffert, z.B. Telefonat) oder asynchron (nichtblockierend und gepuffert, z.B. SMS). Eine globale Uhr fehlt, deswegen muss Synchronität über spezielle Algorithmen und Techniken hergestellt werden, auf die ich später noch eingehe. Die beteiligten Systeme sind heterogen – Interoperabilität ist ergo ein weiterer Aspekt. Fehler in verteilten Systemen sind schwer zu lokalisieren; das System wird durch Redundanz erhalten.

Die schwere Lokalisierbarkeit wird auch als Transparenz bezeichnet. Es gibt nicht nur Fehlertransparenz, sondern auch Transparenz von…

Verteilung
Zugriff
Ort
Migration
Replikation
Ausfall
Abarbeitung
Gruppen
…

Das hat einerseits angenehme Effekte für den Endnutzer, bietet andererseits aber auch gehörige Herausforderungen für den Architekten eines verteilten Systems.

Das Architekturmodell eines VS sieht von unten nach oben folgendermaßen aus:

Computer und Netzhardware
Betriebssystem
Request-Reply-Protokoll
RPC / RMI
Dienst(e)

Die unteren beiden Schichten bilden die Plattform, die mittleren beiden die Middleware und die Dienste sind die verteilten Anwendungen. Ein Dienst wird definiert als Funktion, die durch ein Objekt an einer Schnittstelle zur Verfügung gestellt wird. Ein Remote Procedure Call (RPC) spielt sich so ab, dass der Client den Client-Stub aufruft. Der Stub schickt dann die Daten nach dem Marshalling übers Netzwerk an den Server-Stub, der nach dem Unmarshalling den Aufruf an den Server weiterreicht. Der Rückweg verläuft analog. Der Vorgang ist dabei für den Aufrufenden meist transparent, d.h. er bekommt nicht mit, dass im Hintergrund sein Aufruf übers Netz verschickt wird und die Antwort von einem entfernten Server kommt. RMI ist, grob gesagt, die objektorientierte Variante des RPC.

Manche VS sind auf Echtzeitanwendungen spezialisiert. Dabei gibt es eine obere Schranke für die Ausführungszeit von Prozessen. Um dieses Ziel zu erreichen, werden Zeitscheibenverfahren eingesetzt (z.B. Multi-Level Feedback Queue) und Prioritäten an Prozesse vergeben.

Neben der oben bereits erwähnten Transparenz gibt es noch einen zenralen Begriff bzw. Vorteil der VS, nämlich die Skalierbarkeit. Durch die Verteilung auf mehrere Systeme wird ein Bottleneck vermieden. Ein Single Point of Failure (SPoF), also die Lebensnotwendigkeit einer Komponente, kann dadurch besser ausgeschlossen werden. Zentrale Systeme zeichnen sich allerdings durch geringere Kosten aus; außerdem durch höhere Konsistenz und Aktualität. Auch die Archivierung und Sicherung fällt leichter. All diese Dinge sind in VS problematisch – deswegen nun auf zu den Lösungen!

2 – Suchen und Finden

Eine Schwierigkeit in Verteilten Systemen ist das Auffinden von anderen Teilnehmern (z.B. Servern) und Diensten. Eine Möglichkeit, das Problem zu umgehen, ist das feste Einkodieren der Server-Adresse in die Anwendung (Sockets). Das ist natürlich zu statisch, um sinnvoll zu sein. Flexibler ist ein Discovery Service. Dabei broadcastet der Suchende eine Anfrage und der passende Server antwortet. Problem daran ist, dass es durch den Overhead eines Broadcast und der Last auf allen Teilnehmern nicht skaliert. Das kann man mit einer zentralen Komponente umgehen, also einem Nameserver mit fester Adresse (Binder). Ein Analogon dazu wäre z.B. die Telefonauskunft. Neue Server müssen sich dabei beim Binder anmelden. Dieser antwortet den Clients mit einem Handle auf ihre Anfrage, das sie zum Kontaktieren des passenden Servers verwenden können. Positiv an diesem Vorgehen ist die Lastbalancierung und die (mögliche) Authentifizierung. Allerdings ist auch bei diesem Verfahren der Overhead ein Problem, da der Binder ein Bottleneck darstellt und als SPoF ein Risiko darstellt.

Zu unterscheiden sind drei Arten von Suchdiensten:

(Domain) Name Service (DNS): Ähnlich wie die “Weißen Seiten” = Telefonbuch. Der Dienst bildet Namen auf Adressen ab.
Directory Service: entspricht den “Gelben Seiten”. Man kann auch mit unvollständigen Informationen suchen.
Lokalisierungsdienst: dient z.B. dazu, ein Handy bei einem Anruf zu finden.

Zum Speichern und Finden von Entitäten sind drei Informationen wichtig:

Name: ordnet einer Entität einen Verweis zu.
Access Point bzw. Adresse: physikalische Adresse einer Entität.
Identifikator: verweist konstant auf genau 1 Entität oder ist ungültig (Ortstransparenz).

Name und Adresse können sich über die Zeit ändern. Auch der Identifikator ist nicht eineindeutig, auch er kann sich über die Zeit ändern. Jede Entität hat maximal einen Identifikator und einen Namen zu einem Zeitpunkt. Die Abbildung von Name auf Identifikator heißt Name Service, die Abbildung von Identifikator auf Adresse(n) heißt Location Service.

Die Namensauflösung kann dabei iterativ oder rekursiv ablaufen. Iterativ bedeutet, dass je eine einzelne Anfrage an den Nameserver auf jeder Ebene geschickt wird. Dadurch entsteht ein hoher Overhead, da es zu Verbindungen über große Distanz kommt. Root-DNS-Server verwenden iterative Namensauflösung. Rekursive Auflösung funktioniert so, dass eine Anfrage an den Root-Nameserver geschickt wird, der sie dann nach unten weiterreicht, bis der Name aufgelöst ist. Die Antwort schickt dann der Root-NS an den Anfragenden zurück. Dabei wird der Rootserver stark belastet. Allerdings ist dadurch auch Caching möglich und es entsteht weniger Netzlast.

Es gibt vier Möglichkeiten, einen Lokalisierungsdienst anzubieten:

Broadcast / Multicast: … einer Nachricht mit Identifikator an jeden Rechner. Antwort ist die Adresse des Access Point. Die Methode ist sehr einfach, weit verbreitet und oft auch alternativlos, da keine Infrastruktur nötig ist. Allerdings skaliert sie wegen der exorbitanten Netzlast nicht und kann zu DoS-Attacken missbraucht werden.
Forwarding Pointers: Bei Migration wird eine Referenz auf den neuen Ort hinterlassen (”Schnitzeljagd”). Dieses Verfahren ist sehr fehleranfällig, da bei einem Riss der Kette keine Möglichkeit besteht, die Komponente zu lokalisieren. Sie wird nur für kleine Netze verwendet. Außerdem skaliert sie nicht.
Home Location (Mobile IP): Zur Lokalisierung schickt man ein Paket an die IP-Adresse des mobilen Hosts (MH). Der Home Agent (HA) antwortet darauf mit einer Care-of-Adresse (CoA) des aktuellen Aufenthaltsort und leitet das Paket an die CoA weiter. Der suchende Client sendet weitere Pakete nun direkt an die CoA. Dieses Verfahren ist schon recht gut skalierbar, hat aber noch einen Schönheitsfehler: Wenn Client und MH im selben Subnetz sind, entsteht durch die Anfrage an den HA ein unnötiger Overhead. Besser ist deswegen, zuerst zu prüfen, ob der MH lokal verfügbar ist. Problematisch ist, dass die Existenz und Erreichbarkeit der Home Location bzw. des HA einen SPoF darstellt.
Globe Location Service (GLS): Beim GLS wird eine Domainhierarchie mit einer Baumstruktur aufgebaut. Der Wurzelknoten jeder Domäne kennt alle Entitäten der Domäne und speichert Location Records für jede Entität. Übergeordnete Domänen legen ebenfalls Location Records an, verweisen aber lediglich per Zeiger auf die nächstniedrigere Domäne. Eine Entität kann auch (durch Replikation) mehrere Adressen haben. Das Verfahren weist lokale Skalierbarkeit auf und wird durch Pointer Caching (Verweis auf kleinsten gemeinsamen Verzeichnisknoten) nochmals verbessert. Bei Migration finden Updates entweder bottom-up oder top-down statt. Nachteilig an GLS ist die Last auf dem Wurzelknoten (bei Suchvorgängen und Updates) und das Löschen unreferenzierter Identitäten (Distributed Garbage Collection).

Grundsätzlich ist die Lokalisierungsstrategie von der Call-to-Mobility-Rate (C2M) abhängig. Ist sie hoch, so wählt man GLS; ist sie niedrig, nimmt man Broadcast. Im Handynetz drückt sich das so aus, dass vom Home Location Register (HLR) zu den Visitor Location Registers (VLR) GLS verwendet wird – hier “PositionUpdate” genannt. Es kommen viele Anrufe rein, aber es geschieht recht selten, dass ein Handy sein VLR wechselt. Anders ist die Sache bei Funkzellen, denn diese werden doch recht häufig gewechselt. Die C2M-Rate ist also niedrig, da wenige Anrufe im Verhältnis zu viel Mobilität stehen. Verwendet wird deswegen Broadcast, in diesem Fall “Paging” genannt.

Unreferenzierte Entitäten, die z.B. bei GLS vorkommen, kann man mit einem Referenzzähler angehen. Dabei gibt es zwei Probleme, die man bedenken muss. Zum einen kann die Bestätigung (ACK) des Referenzzählers verloren gehen. Dann würde das Objekt nochmals eine Erhöhung des Referenzzählers verlangen und dadurch doppelt gezählt werden. Deswegen ist es angebracht, idempotente Nachrichten (mehrmaliges Schicken führt nicht zu mehrmaliger Änderung… f^n(x) = f(x)) oder Seriennummern zu verwenden. Das andere Problem entsteht beim Kopieren oder Migrieren. Dabei kann es zu ungewolltem Löschen der Referenz kommen, wenn die Subtraktion der alten Referenz vor der Addition der neuen Referenz geschieht. Besser ist deswegen, temporär eine Referenz zu viel auf dem Konto zu haben, deren Empfang mit ACK an die ursprüngliche Referenz zu bestätigen, die dann erst ihre Löschung an den Referenzzähler bekanntgibt.

Mobilität wird z.B. vom Session Initiation Protocol (SIP) unterstützt. Die verschiedenen Arten von Mobilität sind…

Terminalmobilität: Netzübergreifende Übertragung einer laufenden Session von Endgerät zu Endgerät.
Persönliche Mobilität: Der Nutzer ist überall erreichbar.
Dienstmobilität: Bereitstellung persönlicher Dienste unabhängig von Netz und Terminal.

3 – Dienste

Ein Dienst ist eine Funktion, die durch ein Objekt an einer Schnittstelle zur Verfügung gestellt wird. Dabei ist der Dienst vom Diensttyp und dem Dienstangebot zu unterscheiden. Der Diensttyp ist z.B. ein Compiler oder ein Drucker, der Dienst dabei dann etwa ein C++-Compiler für Windows oder ein Laserdrucker und das Dienstangebot das Kompilieren mit irgendwelchen Parametern oder das Ausdrucken einer PDF.

Bei der Dienst(v)ermittlung kommt es zu einer Kommunikation zwischen drei Parteien: Exporter, Importer und Trader. Sie läuft in vier Schritten ab:

Exportieren: Der Exporter meldet sich beim Trader an und teilt ihm Diensttyp, Adresse, Dienst und Dienstangebote und -eigenschaften mit.
Dienstanfrage: Der Importer fragt beim Trader einen bestimmten Dienst an. Dabei kommt es zu “Search”, in die Diensttyp und Diensteigenschaften einbezogen sind und deren Ergebnis eine Auswahl an Diensten sit, und “Selection”, die via Superlativkriterium über mindestens eine Diensteigenschaft dann genau einen Dienst auswählt.
Importieren: Der Trader übergibt dem Importer eine Referenz auf die Schnittstelle (Adresse).
Direkter Kontakt von Importer und Exporter und Dienstnutzung

Diensteigenschaften können statisch und dynamisch sein. Statische Eigenschaften (z.B. Hersteller) entsprechen den Calls bei C2M, dynamische Eigenschaften (z.B. Füllstatus der Druckerpatronen) der Mobilität. Bei einer hohen C2M-Rate wird die Diensteigenschaft im Trader gespeichert (Caching), bei einer niedrigen Rate on demand abgerufen (Polling). Statische Eigenschaften könnte man auch als Fähigkeiten paraphrasieren, dynamische als Verfügbarkeiten.

4 – Uhrensynchronisation

Als einleitendes Beispiel bei der Uhrensynchronisation wurde GPS gewählt. Die 24-36 nötigen Satelliten umrunden die Erde und besitzen sehr genaue Cäsium-Rubidium-Uhren. Für den Betrieb beispielsweise eines Navigationsgeräts sind 4 Satelliten notwendig. Drei Satelliten dienen zur Ortsbestimmung (1 – Kugel, 2 – Kreis, 3 – zwei Punkte, von denen einer verworfen werden kann) und einer zum Herausrechnen der Zeitverschiebung der Uhr des Autos. Dabei strahlen die Satelliten nur einen Zeitcode und ihre augenblickliche Position aus. Welcher Satellit gerade als Kommunikationspartner dient, findet man über CDMA heraus. Eine genauere Beschreibung findet sich bei der Gesellschaft für Informatik.

Bei der Uhrensynchronisation ist die logische von der physikalischen Synchronisation zu unterscheiden. Logisch bedeutet, dass alle Uhren gleich gehen, also in richtiger Reihenfolge sind. Dabei ist es egal, wie genau die Uhrzeit ist. Physikalische Synchronisation bedeutet hingegen, dass alle Uhren die absolut exakte Zeit (UTC) anzeigen.

Beim Stellen der Uhr ist außerdem immer darauf zu achten, dass die Uhr nicht zurückgestellt wird, sondern in diesem Fall langsamer läuft, bis die korrekte Uhrzeit angezeigt wird.

Ein Algorithmus zur physikalischen Uhrensynchronisation ist der Algorithmus von Cristian. Dabei schickt der Client zum Zeitpunkt T0 eine Synchronisationsanfrage an den Zeitserver, der die Nachricht zum Zeitpunkt T1 empfängt. Zur Verarbeitung benötigt er die Zeit I und schickt zum Zeitpunkt T2 die Antwort an den Client, die die UTC enthält. Der Client empfängt sie zum Zeitpunkt T3 und berechnet die Uhrzeit, die er einstellen muss, wie folgt:

t = t_utc + (T3-T0-I) / 2 ;   wobei I := T2 - T1

Problematisch bei diesem Algorithmus ist, dass er nicht berücksichtigt, dass die Laufzeit für den Hinweg (Anfrage) nicht unbedingt gleich der Laufzeit für den Rückweg (Antwort) ist.

Zur logischen Uhrensynchronisation dient der Berkeley-Algorithmus. Er funktioniert mit einer zentralen Komponente, die Zeitdämon genannt wird:

Der Zeitdämon fragt regelmäßig jeden Rechner nach seiner Zeit.
Aus den Antworten berechnet er den Durchschnitt und teilt ihn an alle mit.
Alle Rechner passen ihre Uhrzeit gemäß der Vorgabe an.

Standard zur Synchronisierung von Uhren ist NTP (Network Time Protocol). Zweck des Protokolls ist es, Internet-Clients gemäß UTC zu synchronisieren. Der Nachrichtenaustausch erfolgt dabei über UDP. NTP ist durch die Hierarchie der Strata (Schichten) skalierbar und ausfallsicher. Stratum 0 sind Zeitquellen mit UTC-Genauigkeit. Server im Stratum 1 synchronisieren sich mit Servern im Stratum 0. Synchronität wird über verschiedene Modi erzielt:

Multicast: periodischer Multicast (im LAN)
Procedure-Call: funktioniert wie Algorithmus von Cristian. PC ist genauer als Multicast.
Symmetrischer Modus: Server im selben Stratum tauschen Zeitinformationen aus, um ihre Genauigkeit zu erhöhen.

Die Theorie der logischen Uhren von Lamport begründet eine temporale Logik durch die Lamportsche “vor”-Relation. Sie wird als Pfeil dargestellt: a→b bedeutet, dass a vor b eintritt. Beispielsweise tritt das Senden einer Nachricht immer vor ihrem Empfang ein. Die Relation ist transitiv, d.h. wenn a→b und b→c, dann a→c.

5 – Prozesskooperation

Man kann Kooperation entweder mit einem zentralen oder verteilten Ansatz angehen. Beim zentralen Ansatz dient ein Prozess als Koordinator, der eine Warteschlange (FIFO-Queue) hat. Prozesse bitten ihn um Eintritt in den kritischen Bereich (in den nur 1 darf) und sagen ihm beim Austritt aus dem kritischen Bereich Bescheid. Das Verfahren ist fair, da die Reihenfolge erhalten bleibt und kein Prozess ewig warten muss. Außerdem ist es einfach zu implementieren, da nur drei Nachrichten vonnöten sind (”will rein”, “darfst rein”, “bin fertig”). Allerdings ist der Koordinator ein Engpass (Bottleneck) und darf nicht ausfallen (SPoF).

Der verteilte Algorithmus nach Ricart und Agrawala setzt voraus, dass eine totale Ordnung der Ereignisse existiert. Ein Prozess, der in den kritischen Bereich will, schickt eine Anfrage an alle Prozesse (auch sich selbst) mit dem Namen des Bereichs, der Prozessnummer und der aktuellen Zeit. Dann kommt es zu einer von drei Möglichkeiten: (1) Der Empfänger ist nicht im krit. Bereich und will auch nicht rein. Er antwortet mit OK. (2) Der Empfänger ist im krit. Bereich. Er sendet kein OK, sondern ordnet den Sender in seine lokale Warteschlange ein. (3) Der Empfänger will auch in den krit. Bereich. Dann werden die Zeitstempel der Nachrichten verglichen und der frühere gewinnt. Wenn ein Prozess von allen anderen das OK erhalten hat, darf man in den kritischen Bereich. Beim Austritt bekommen alle anderen ein OK zugeschickt. Das Verfahren ist deadlockfrei und fair, verursacht allerdings eine hohe Netzlast durch 2(n-1) Nachrichten für 1 Anfrage bzw. 2n(n-1) Nachrichten für n Anfragen. Ausfallsicher ist es außerdem nur dann, wenn ein Timout für Antworten eingeführt wird. Darüberhinaus ist es schlecht skalierbar, langsam und wenig robust.

Wahlalgorithmen

Ein Koordinator kann durch Wahlalgorithmen (Election-Algorithmen) bestimmt werden. Der bekannteste ist der Bully-Algorithmus. Dabei schickt ein Prozess eine Election-Nachricht an alle Prozesse mit höherer Prozessnummer. Kommt gar keine Antwort, hat er die Wahl gewonnen und ist Koordinator. Wenn eine Antwort (OK) kommt, dann ist die Arbeit des anstoßenden Prozesses erledigt; die anderen machen mit dem Algorithmus weiter, bis eine Komponente übrigbleibt. Diese teilt ihre Wahl zum Koordinator dann allen anderen mit. Neueinsteiger mit höherer Nummer initiieren wieder einen Bully-Algorithmus.

Eine andere Variante ist Token-Ring. Dabei kreiert eine Komponente die Election-Nachricht, schreibt ihre Nummer hinein und schickt sie an ihren Nachfolger im Ring. Die Nachfolger machen das selbe, bis der Ausgangspunkt wieder erreicht ist. Die höchste Nummer in der Election-Nachricht wird in eine Coordinator-Nachricht verpackt und rotiert einmal durch den Ring. Dann wissen alle von der Wahl Bescheid.

Deadlockerkennung

Auch bei der Deadlockerkennung gibt es einen zentralen und einen verteilten Ansatz. Beim zentralen Verfahren entstehen Ketten von Belegungen und Forderungen – beispielsweise (A)→|R|→(B)→|S|. Das bedeutet, dass A die Ressource R anfordert, die aber von B belegt ist. B fordert Ressource S an. Wenn S von A belegt ist, haben wir einen Deadlock. Problematisch ist, dass sich in Verteilten Systemen Nachrichten überholen können, wodurch die Deadlockerkennung und -vermeidung scheitert. Ein möglicher Ausweg aus der Situation wären Zeitfenster und Zeitstempel mit Lamportscher Relation.

Das verteilte Verfahren stammt von Chandy, Misra und Haas. Positiv daran ist, dass Prozesse mehr als ein Betriebsmittel auf einmal anfordern dürfen. Der Algorithmus wird aufgerufen wenn ein Prozess auf ein belegtes Betriebsmittel wartet. Dabei wird an den belegenden Prozess eine Nachricht geschickt, die dieser dann seinerseits an weitere belegende Prozesse weitergibt. Wenn beispielsweise Prozess A auf Prozess B wartet (um Betriebsmittel M), dann schickt A an B die Nachricht (A,A,B), d.h. A hat den Algorithmus initiiert und A wartet auf B. B schickt dann an C die Nachricht (A,B,C) usw.. Wenn ein Zyklus entsteht, den man an der Konstellation (A,_,A) erkennt, dann gibt es einen Deadlock. Der kann gelöst werden durch einen “Selbstmord” des initiierenden Prozesses oder dadurch, dass die Prozesse ihre Nummer an die Nachricht anhängen und der höchste dann beginnen darf.

Fehlerquellen bei entfernten Prozeduraufrufen

Oben wurde schon kurz auf RPC und RMI eingegangen. Bei entfernten Prozeduraufrufen kann es zu folgenden Fehlern kommen:

Der Client kann den Server nicht lokalisieren.
Die Anfragenachricht (Client an Server) geht verloren. Lösung: Wiederholung nach Ablauf des Timeout.
Die Antwort (Server an Client) geht verloren. Lösung: Nur idempotente Nachrichten verwenden.
Der Server fällt nach Erhalt der Anfrage aus. Hier gibt es drei Möglichkeiten:
1. direkt nach Empfang
2. nach der Ausführung
3. nach der Antwort an den Client
Möglichkeit 1 und 2 sind schwer zu unterscheiden. Nummer 3 ist egal.
Der Client fällt nach dem Senden der Anfrage aus. Es erfolgt eine sogenannte verwaiste Berechnung, die Ressourcen verschwendet. Außerdem kommt es zu Konfusion, wenn der Client dann seine Anfrage wiederholt.

Generelle Lösungen für die Probleme sind Nachrichtenidentifikatoren (z.B. Seriennummern). Der Server speichert in dem Fall die IDs der Nachrichten. Problematisch ist dann allerdings, wenn der Server abstürzt, da alle Nummern in der Tabelle verloren gehen. Eine andere Möglichkeit sind synchrone Uhren. Dabei wird jeder Nachricht eine ID und ein Zeitstempel verpasst. Der Server speichert für jede Verbindung den neusten Zeitstempel. Ältere Nachrichten werden abgewiesen.

6 – Sicherheit

Zur Sicherheit wird es noch einen eigenen Beitrag geben. Deswegen hier nur einige für Verteilte Systeme zentrale Aspekte.

Zuerst einmal die schöne Definition: Als sicher gilt etwas, wenn der Preis illegal heranzukommen höher ist als der eigentliche Wert.

Bei den verteilten Systemen haben wir Sicherheit in drei Aspekte unterteilt: Schutz der Kommunikation zwischen Nutzern oder Prozessen (Secure Channels), Zugriffskontrolle (Zugriff auf Ressourcen) und Sicherheitsmanagement (Kryptographie, Nutzerverwaltung, …).

Beim Thema Zuverlässigkeit sind vier Teilbereiche bzw. Begriffe zu unterscheiden:

Verfügbarkeit / Availability: Eine Sofortnutzung ist möglich.
Verlässlichkeit / Reliability: Die Komponente ist kontinuierlich fehlerlos.
Sicherheit / Safety: Es entstehen keine Probleme bei einem temporären Ausfall.
Instandhaltung / Maintainability: Die Reparatur ist einfach.

Im Bereich Sicherheit ist auch noch der Begriff der Vertrauenswürdigkeit wichtig. Sie unterteilt sich in folgende Teilgebiete:

Vertraulichkeit / Confidentiality: Information ist nur autorisierten Personen zugänglich.
Echtheit / Integrity: Unerwünschte Modifikationen (Einfügen, Löschen, Ändern, …) und Rückgängigmachung werden erkannt.
Privacy: Private Daten werden geschützt, die Herausgabe von Informationen kontrolliert.
Anonymisierung: erfolgt entweder durch Pseudonyme oder durch k-Anonymität (”Untertauchen in der Masse”).

Authentifizierung

Authentifizierung ist der nächste zentrale Begriff, den es zu eruieren gilt. Sier ermöglicht einem Empfänger sicherzustellen, dass der Sender der Identität entspricht, die er vorgibt zu sein. Autorisierung bezieht sich hingegen auf die Rechte einer Entität, auf eine bestimmte Ressource zugreifen zu dürfen, und ist ohne Authentifizierung nicht möglich. Authentifizierung hängt auch eng mit der Nachrichtenintegrität zusammen, denn das eine macht ohne das andere wenig Sinn. Eine erfolgreiche Authentifizierung ist wertlos, wenn der Inhalt der Nachricht modifiziert werden kann, genauso wie eine integre Nachricht wenig Wert hat, wenn der Autor nicht klar ist.

Authentifizierung kann mit einem gemeinsamen Sitzungsschlüssel (Shared Secret Key) erreicht werden, im folgenden K genannt. Ein Challenge-Response-Protokoll mit gemeinsamem Schlüssel sieht wie folgt aus:

A → B: A
B → A: R_B
A → B: K ( R_B )
A → B: R_A
B → A: K ( R_A )

R wird “Nonce” genannt und ist eine Zufallszahl. Dieses etwas umständliche Protokoll kann man folgendermaßen optimieren:

A → B: A, R_A
B → A: R_B, K ( R_A )
A → B: K ( R_B )

Es ist allerdings anfällig für Reflection Attacks, die so ablaufen:

C → B: A, R_C
B → C: R_B, K ( R_C )
C → B: A, R_B
B → C: R_B, K ( R_B )
C → B: K ( R_B )

Dabei ist in Schritt 2 der Schlüssel K für C unbekannt. Er behilft sich deswegen durch eine Reflektion von R_B in einer zweiten Session (Schritt 3 und 4) und nutzt die gewonnene Erkenntnis zur richtigen Antwort in der ersten Session (1,2,5).

Die Verwendung eines gemeinsamen Schlüssels ist aufwendig. Jeder Teilnehmer verwaltet n-1 Schlüssel (1 pro anderem Teilnehmer). Insgesamt gibt es also n(n-1)/2 Schlüssel. Diesen unnötigen Aufwand kann man durch ein Key Distribution Center (KDC), auch als Trusted Third Party (TTP) bekannt, umgehen. Die Authentifizierung läuft dann wie folgt ab:

A → KDC: A, B
KDC → A: K_A,KDC( K ), K_B,KDC( K )
A → B: A, K_B,KDC( K )

K_B,KDC( K ) ist dabei der gemeinsame Schlüssel von KDC und B und wird “Ticket” genannt, da es über A zu B geschickt wird. Dieses Prinzip wurde zum Needham-Schroeder-Authentifizierungsprotokoll erweitert, das folgendermaßen abläuft:

A → KDC: A, B, R_A1
KDC → A: K_A,KDC( K, R_A1, B, K_B,KDC(A,K) )
A → B: K ( R_A2 ), K_B,KDC(A,K)
B → A: K ( (R_A2 – 1), R_B)
A → B: K ( R_B – 1 )

Die Schritte 4 und 5 dienen der Verhinderung von Replay-Attacken. Da K als Sitzungsschlüssel nur A und B bekannt ist, kann eine Entschlüsselung, Dekrement und neue Verschlüsselung nur vom jeweiligen Sitzungspartner vollzogen werden.

Für einen übelwollenden Angreifer bieten sich folgende Möglichkeiten:

Er kann das KDC blocken und sämtlichen Verkehr von A zum KDC abfangen und A einen bekannten Schlüssel geben und die folgende Kommunikation mit B entweder abhören (”Man In The Middle”) oder selbst als B auftreten (”Masquerade”). Ein solcher Block ist aber als unwahrscheinlich anzusehen, da dafür entweder K_A,KDC kompromittiert sein müsste oder A einen von C erdachten Schlüssel blind akzeptieren müsste.
Eine Umleitung des kompletten Verkehrs lässt sich auch dadurch erreichen, dass C die 1. Nachricht abhört und den Adressaten von B in C ändert. Diese Sicherheitslücke lässt sich durch eine Verschlüsselung der Nachricht mit K_A,KDC schließen.
Wenn K_B,KDC kompromittiert ist (und damit auch K), ist Abhören oder Maskieren auch kein Problem. Selbiges gilt auch für K allein. Dann reicht das Wiederholen der dritten Nachricht, um einen sicheren Kanal zu B vorzutäuschen. Deswegen ist es ratsam, die Sitzungsschlüssel periodisch zu ändern.

Um die Probleme zu umgehen, kann man das Protokoll um zwei vorausgehende Schritte erweitern:

A → B: A
B → A: K_B,KDC( R_B1 )
A → KDC: A, B, R_A1,K_B,KDC( R_B1 )
KDC → A: K_A,KDC( K, R_A1, B, K_B,KDC(A,K,R_B1) )
A → B: K ( R_A2 ), K_B,KDC(A,K,R_B1)
B → A: K ( (R_A2 – 1), R_B2)
A → B: K ( R_B2 – 1 )

Dies ist die sicherste Variante des Protokolls.

Authentifizieren kann man sich auch mittels Public Key bzw. asymmetrischer Verschlüsselung. Der öffentliche Schlüssel eines Teilnehmers wird hier zur Verdeutlichung mit einem + versehen, der private mit einem -. Der Ablauf ist wie folgt:

A → B: K_B+(A, R_A)
B → A: K_A+(R_A, R_B, K)
A → B: K ( R_B )

Mittels asymmetrischer Verschlüsselung lassen sich auch digitale Signaturen erstellen. Dabei schickt Alice an Bob eine nur für ihn lesbare Nachricht, die sie zur Integritätssicherung und Zurechenbarkeit mit ihrem privaten Schlüssel absichert. B prüft dann die Integrität durch Vergleich:

A → B: K_B+( m, K_A-(m) )
B: m =?= K_A+(K_A-(m))

Problem dabei ist, dass K_A- geheim bleiben muss. Schlüssel sollten sich generell von Zeit zu Zeit ändern (siehe oben). Dafür ist eine unabhängige Autorität (TTP) zur Schlüsselverwaltung notwendig. Außerdem ist asymmetrische Verschlüsselung rechenintensiv. Deswegen behilft man sich im Normalfall mit Hashes bzw. Message Digests zur Integritätssicherung. Ein Message Digest ist ein Bitstring mit fester Länge h = H(m). H ist eine kryptographische Hashfunktion. Obiger Ablauf sieht dann so aus:

A → B: K_B+(m), K_A-( H(m) )
B: H(m) =?= K_A+(K_A-(H(m)))

Zugriffskontrolle

Eine Anfrage wird nur dann ausgeführt, wenn der Client auch Zugriffsrechte hat. Deren Kontrolle wird als Zugriffskontrolle bezeichnet. Die Erteilung und Erfüllung von Zugriffsrechten heißt Autorisierung. Den Schutz von Objekten gegen Zugriff und allgemein die Verwaltung von Zugriffen erledigt ein Referenzmonitor, der zwischen Subjekt und Objekt steht und autorisierte Anfragen ans Objekt weiterreicht. Ein Beispiel für einen Referenzmonitor ist eine Firewall.

Zugriffsrechte kann man beispielsweise mit einer Access Control Matrix (ACM) modellieren. Dabei wird jedes Subjekt durch eine Zeile und jedes Objekt durch eine Spalte repräsentiert. Bei Anforderung der Methode m prüft der Referenzmonitor, ob m in M(S,O) aufgelistet ist. Wenn nicht, scheitert die Operation. Das Verfahren ist nicht so gut skalierbar. Deswegen gibt es alternativ die Access Control List (ACL). Dabei verwaltet jedes Objekt eine Liste von Zugriffsrechten der Subjekte, die auf dieses Objekt zugreifen dürfen. Man könnte natürlich auch die Subjekte als Verwalter der Listen einsetzen. Dabei würde dann jedes Subjekt eine Liste von Capabilities verwalten, die es für jedes Objekt hat. Eine weitere Vereinfachung kann durch Gruppen erreicht werden.

7 – Maßnahmen zur Skalierbarkeit

Skalierbarkeit ist dann nötig, wenn eine zentrale Komponente zum Engpass wird. Das ist vor allem bei Diensten in großen Netzen der Fall. Viele Nutzer wollen in der selben kurzen Antwortzeit Zugriff auf angeforderte Ressourcen oder Dienste. Hier ist Performance gefragt. Möglich wird Skalierbarkeit durch Replikation, Caching und/oder Load-Balancing.

Bei der Replikation liegt die Ausfallsicherheit bei P = 1 – pⁿ. Die bessere Sicherheit wird durch Probleme bei der Konsistenz und bei der Überprüfung von Zertifikaten (Chain of Trust). Auch Kosten und Wartungsaufwand steigen. Die Replikation soll außerdem transparent für den Nutzer sein.

Replikate werden von sogenannten Replica-Managern (RM) verwaltet, die in einem Replica-Manager-Dienst zusammengefasst sind. Front Ends (FE) kommunizieren mit den RM. Der Client kommuniziert nur mit dem FE, von den RM muss er nichts wissen. Dabei gibt es die Gossip Architecture, wo Front Ends eigenständige Prozesse sind und Clients über sie mit einem individuellen Replica Manager für jede Operation kommunizieren. Eine andere Möglichkeit ist das Primary Copy Model, bei dem alle Front Ends mit dem gleichen Server kommunizieren, der die gewünschten Änderungen an die anderen RM (Slaves) weitergibt. Bei einem Ausfall wird ein anderer RM zum Primärserver ernannt. Ein drittes Modell ist der Shared Editor.

Die Anfragebearbeitung bei Replikaten teilt sich auf in fünf Phasen:

Anfrage: FE stellt Anfrage an einen oder mehrere RM.
Koordination und Replikationskonsistenz durch FIFO, kausale Ordnung oder totale Ordnung.
Vorläufige Ausführung, ggf. unerwünschte Änderungen können rückgängig gemacht werden.
Zustimmung: Wenn die RM beim Ausführen der Anfrage zu einem Konsens kommen, wird das Ergebnis festgeschrieben (Commit). Andernfalls wird es verworfen (Abort).
Antwort: Ein oder mehrere RM antworten dem FE.

Die genannte FIFO-Ordnung ist so definiert: Falls ein korrekter Prozess erst ein multicast(g,m) und dann ein multicast(g, m’) aufruft, dann erhält jeder korrekte Prozess, der m’ erhält, zuvor erst m. Bei Replikation besagt die FIFO-Ordnung also, dass jeder korrekte RM die Anfragen eines FE in der Reihenfolge der Anfragestellung bearbeitet.

Die kausale Ordnung ist so definiert, dass falls multicast(g,m) → multicast(g, m’) in Lamportscher “vor”-Relation stehen, dann gilt für jeden korrekten Prozess, der m’ zustellt, dass er m vor m’ zustellt. Im Falle der Replikation bedeutet das, dass jeder korrekte RM die Anfragen gemäß der zeitlichen Reihenfolge der Anfragestellung behandelt. Die kausale Ordnung impliziert die FIFO-Ordnung.

Die totale Ordnung definiert, dass falls ein korrekter Prozess die Nachricht m vor der Nachricht m’ erhält, dann gilt das auch für jeden anderen korrekten Prozess, der m’ zustellt, dass m vor m’ zugestellt wird. Dabei kann es auch sein, dass die Nachrichten willkürlich geordenet sind (z.B. umgekehrte Reihenfolge), solange die Ordnung in allen Prozessen dieselbe ist. Bei der Replikation bedeutet das, dass falls ein korrekter RM r vor r’ behandelt, dann handhabt jeder andere RM, der r’ behandelt, r noch zuvor – völlig unabhängig davon, wann das FE die Nachrichten verschickt hat bzw. in welcher Reihenfolge das passiert ist.

Im Kontext der Replikationstransparenz erscheint für die meisten Anwendungen eine FIFO-Ordnung angebracht.

Eine Anfrageordnung wird durch die Hold-back-Technik erreicht. Dabei werden eintreffende Anfragen von den RM nicht verarbeitet, solange keine Ordnungsbedingungen erfüllt sind. Beispielsweise werden “Re: Betreff”-Mails zurückgehalten, solange keine “Betreff”-Mail verarbeitet wurde. Hierzu bedient man sich nach dem Verfahren von Schneider zweier Warteschlangen. Ankommende Anfragen werden zunächst in der Hold-Back-Queue (HBQ) eingereiht und bleiben dort, bis ihre Ordnung bestimmt wurde. Wenn die Anfrage stabil ist (d.h. alle vorher abzuarbeitenden Anfragen bzgl. der Ordnungsrelation ausgeführt sind und die Anfrage die nächste ist), wird sie in eine FIFO-Processing-Queue eingereiht.

Dabei gibt es zwei wichtige Eigenschaften:

Safety: Keine Anfrage aus der HBQ wird anders als mit der FIFO-PQ verarbeitet.
Liveness: Keine Anfrage darf ewig zurückgehalten werden.

Bei der Implementierung totaler Ordnungen wird ein Sequencer verwendet. Dabei handelt es sich um einen Server, der alle Anfragen erhält und ihnen aufsteigende IDs zuordnet, die er an die RM weiterleitet. Die RM warten dann mit der Verarbeitung einer Anfrage (d.h. ordnen sie in die HBQ ein), bis sie aufgrund ihrer ID an der Reihe ist. Bei dieser Methode kann der Sequencer natürlich zum Bottleneck oder SPoF werden.

Statt einem zentralen Sequencer gibt es auch einen verteilten Ansatz. Dabei sendet das FE eine Anfrage an die RM mit einer temporären ID F_max, die größer als alle vorangegangenen ist. Darauf schicken die RM eine Antwort ans FE mit einem neuen Vorschlag ID_RM für die ID, wobei ID_RM = max(F_max,P_max) + 1 + i/N. Dabei ist P_max die vom RM selbst vergebene oder gespeicherte eigene größte ID, N die Anzahl von RM und i die Nummer des jeweiligen RM (i/N ist somit eine “Adresse” des jeweiligen RM). Dann sammelt das FE alle vorgeschlagenen IDs und nimmt die größte davon als ID_FE. Die schickt sie dann an alle RM zurück, die wiederum eine Neuordnung gemäß der vorliegenden IDs vornehmen. Der Algorithmus ist relativ teuer, da drei Nachrichten je RM benötigt werden.

Für die Implementierung kausaler Ordnungen nutzt man Vektoruhren. Ein FE darf von der Version eines RM nur dann lesen, wenn die Version mindestens so aktuell ist wie die Version, die zuletzt von irgendeinem RM gelesen und beim FE gespeichert wurde (ergo mindestens so aktuell wie die beim FE gespeicherte Vektorzeitmarke). Schreiben darf ein FE auf einen RM nur dann, wenn der RM bereits alle vorangegangenen Updates berücksichtigt hat. Beide Bedingungen können leicht von den Vektoruhren abgelesen werden.