Der HIPL Quellcode ist aktuell in einem sehr experimentellem Stadium und ist auf eigene Verantwortung zu nutzen! Zum Testen von HIPL sollte VMWare, Xen oder User Mode Linux verwendet werden. Die deutsche Überstzung weicht mittlerweile an einzelnen Stellen vom Original ab. Neben einer Umstruktutierung wurden auch einige Neuerungen eingearbeitet. Im Zweifel sei hiermit auf das Original verwiesen. Es wird empfohlen die neuesten Quellen zu verwenden und selbst zu kompilieren. Als Alternative können binäre Pakete von http://hipl.hiit.fi/hipl/release/ geladen werden. Falls Sie Bugs melden wollen verwenden Sie bitte die neuesten Quellen anstelle der binären Pakete. Denn es könnten die Fehler bereits repariert worden sein. Des weiteren finden die eine auf Knoppix basierende Live CD auf der HIPL Webseite. Erste Bedingung ist grundlegende Kenntnis im kompilieren des Linux Kernels. Schlagen Sie unter linux/README für weitere Anweisungen nach. Sie benötigen folgende Software um HIPL zu bauen und zu betreiben: Linux Betriebssystem Einen BEET patched Linux 2.6 Kernel mit Unterstützung für: dummy device XFRM_USER IPv6 IPsec AES, 3DES, SHA1 Diese sollten als Module kompiliert werden, können aber auch fest integriert sein. Folgende Schalter müssen aktiviert sein: CONFIG_IP_ADVANCED_ROUTER CONFIG_IP_MULTIPLE_TABLES OpenSSL-Bibiliothek und Header-Dateien GNU make die neuesten Versionen von: autoconf, automake, autoreconf and libtool iproute inkl. Header-Dateien wxgtk 2.6.2 und libgtk-2.x Bibiliothek und Header-Dateien iputils-ping (oder netkit-ping): ping, ping6 ipsec-tools: setkey iptables Userspace Tools und IPv6 netfilter im Kernel (nur zum Testen der HIP Firewall) iptables Header-Dateien (HIP Firewall) glib (www.gtk.org) und Header-Dateien (HIP Firewall) netcat6 latex, dvips, dvipdf, fig2dev, doxygen (zum Erzeugen der HIPL Dokumentation aus den Quellen) java Kompiler für "jip" (java hip resolver) wenn Sie Java-Programme mit HIP funktionalität schreiben wollen Netzwerk Anforderungen Stellen Sie sicher, dass die Firewall der Hosts HIP und ESP Pakete nicht blockiert (versuche iptables -L). Als provisorische Lösung versuchen Sie den NAT-Modus auf den Hosts zu aktivieren. Stellen Sie sichern das Router den HIP Datenverkehr nicht blockieren. Falls eine Firewall ziwschen den Hosts betrieben wird, so könnten der HIP oder ESP Pakete blockiert werden. Falls NAT zwischen den Maschinen betrieben wird, so könnte auch dies den Datenverkehr blockieren. Entweder stellen Sie sichern, die Router erlaben HIP und ESP Pakete oder Sie veruschen NAT auf den End-Knoten zu verwenden. Architektur Dokumentation: % cd hipl/doc % make design_choices.dvi design_choices.ps design_choices.pdf Quellcode Dokumentation: % cd hipl/doc % doxygen Die Dokumentation zur HIPL API finden Sie unter: http://hipl.hiit.fi/hipl/hip-native-api-final.pdf (Anmerkung: dieses API-Dokument ist nicht mehr aktuell, achten Sie auf Änderungen in den Schnittstellen und Variablen.) Um HIPL einsetzen zu können muss zum Einen der Kernel mit dem BEET-Patch versehen werden und zum Anderen das hipsock-Kernelmodul und die HIP-Bibliotheken kompiliert werden. Falls Sie zuvor noch keinen Kernel kompiliert haben konsultieren Sie vorher linux/README. Wir haben ein paar Konfigurationsdateien als Beispiel in hipl/test/configs für "typische" Systeme hinterlegt. Sie können diese Vorlagen als Grundlage für Ihre eignen Systemkonfigurationen verwenden und anpassen. Lesen Sie zuvor hipl/test/configs/README. Der Kernel-Patch: Die Patches aus dem Verzeichnis patches/kernel/KERNEL_VERSION sind dem entsprechenden Kernel beizufügen um das hipsock Modul verwenden zu können. cd /usr/src/linux cat patches/kernel/KERNEL_VERSION/PATCH_FILE | patch -p1 Den gepatcheten Kernel neu kompilieren. Ins hipl/hipsock Verzeichnis springen und Kernelmodul mit make kompilieren. Das Makefile setzt voraus, dass sich die Kernelquellen in /usr/src/linux befinden. Anderenfalls kann mit make LINUX=/path/to/linux/ das entsprechende Verzeichnis angegeben werden. Die 2.6er Kernel-Serie sollte mit gcc 2.9x und 3.x kompatibel sein. Wir empfehlen die letztere zu verwenden. (Keine Angaben zu gcc 4.x) Konfigurieren Sie den Linux Kernel mit folgenden Optionen:  Legende: [*] eingebaut [ ] nicht verwendet <M> Modul erstellen < > Modul geeignet Optionen im Ablauf  [*] Prompt for development and/or incomplete code/drivers  Processor type and features  Networking ---> Networking options --->  <M> IPsec user configuration interface  [*] TCP/IP networking  <*> The IPv6 protocol  <*> IPv6: IPsec BEET mode  Cryptographic options --->  <*> IPv6: Null algorithms IPsec, IPv6 security support, SHA1 und 3DES solten automatisch aktiviert werden nachdem sie HIP ausgewählt haben. Wir empfehlen, dass Sie HIP als Kernel-Modul kompilieren und IPv6 fest integrieren. Der hipd Daemon versucht die notwendigen module automatisch zu laden. Sie sollten die /etc/modules dem entsprechend konfigurieren. Fügen Sie "xfrm6_tunnel", "xfrm4_tunnel", "xfrm_user", "dummy", "esp6", "esp4", "ipv6", "aes", "crypto_null", und "des" in /etc/modules ein. Der BEET-Patch hat in den Vanilla-Kernel ab 2.6.19-rc2 einzu gehalten. Ein Patches des Kernel sollte somit entfallen. Allerdings ist der Patch für 2.6.19-rc2 nicht ausreichend. Es ist z.B. das Limit für die Protokollnummer weiterhin 32 und nicht 33. Damit kann HIP mit Protokollnummer 32 nicht aktiviert werden. Nachdem Sie den Kernel erfolgreich kompiliert, installiert und beide Systeme neu gestartet haben müssen Sie die Userspace Anwendungen kompilieren um HIP zu nutzen. Beginnen wir mit dem springen ins obere HIPL Verzeichnis: cd hipl Wenn die Datei autogen.sh existiert führen Sie diese aus: ./autogen.sh Als nächstes bauen Sie hipd, libinet6, tools und Programme im Verzeichnis test wie folgt: ./configure && make Es ist nicht notwendig make install auszuführen. Sie können die Anwendungen direkt aus deren Verzeichnis starten. Beachten Sie, dass zur Zeit vom Hauptverzeichnis nicht die Java-Bibiliotheken oder Telnet erstellt wird. Folgen Sie den späteren Anleitungen um dies zu erstellen. Einige Eigenschaften, wie HIP-Firewall, werden nicht automatisch mit erstellt. Führe ./configure --enable-FEATURE aus um einzelne zu aktivieren. ./configure --help liefert eine vollständige Liste der Optionen. Der HIP Socket Handler is eine Komponente der HIPL HIP Implementation. Es wir zum abfangen der HIP Socket API Aufrufe genutzt. Das hipsock Kernel Modul wird zum registrieren der neuen Protokollfamilie und zum handhaben der Socket Systemaufrufe für genau diese Protokollfamilie verwendet. Mit insmod hipsock.ko laden Sie das Modul zum laufenden Kernel. Prüfen Sie Systemmeldungen in dmesg. Mit rmmod hipsock.ko kann das Modul wieder entladen werden. Falls Sie die Fehlermeldung insmod: error inserting 'hipsock.ko': -1 Invalid module format erhalten muss ggf. das Verzeichnis zu den Kernelquellen gesetzt werden. Prüfen Sie auch ob der BEET-Kernelpatch richtig installiert wurde. In der Datei /etc/hip/hosts werden die Hostnamen auf deren HIT/LSI abgebildet. Es müssen also die HITs der entfernten Hosts und deren Host-/Domainnamen eingetragen werden. Jede Zeile enthält HIT und durch Leerzeichen (Whitespaces) gefolgt den Hostnamen. Es genügt die HITs der Zielhosts dort einzutragen. Ein Beispiel für den Host crash, welcher eine Verbindung zu oops initiieren soll: # cat /etc/hip/hosts 2001:78:e6df:1f27:b0f4:855a:1798:1931 oops 2001:73:3e7d:e72e:7f6e:e25d:d979:c284 sip Die HITs für crash selbst können ebenfalls in der Datei stehen. Somit braucht für alle bekannten Hosts nur eine Version der Datei gepflegt werden. Im später dargestellten Opportunistic Mode kann ein Eintrag in /etc/hip/hosts entfallen. Ein Host verwendet i.d.R. mehrere HITs gleichzeitig. Zur Zeit allerdings versagt der Dienst wenn auf verschiedene HITs eines Dienstes nacheinander folgend Verbindung aufgenommen wird. Die Daten des ersten Durchlaufs aller HIP-Verbindungen werden noch übertagen, eine zweite, nachfolgende Verbindung ist dann aber nicht mehr möglich. Tragen Sie deshalb nur eine HIT je Ziel in /etc/hip/hosts ein bzw. verwenden Sie das '#' Zeichen um einzelne HITs auszukommentieren. Die HIPL-Entwickler verwenden zwei Maschienen unter den Bezeichnungen crash (3ffe::1) und oops (3ffe::2). Diese Namen werden als Beispiele auch in diesem Dokument verwendet. Es ist auch möglich IPv4-Adressen "auf dem Kabel" zu verwenden, aber die Anwendungen verwenden aktuell nur IPv6. Wir erwarten, dass Sie zwei Hosts mit den Namen crash und oops zum Testen von HIP verwenden. Sie sollten diese Kommandos auf den zu testenden Hosts als Super-User (root) starten. conntest-client-gai und conntest-server können auch unter nicht-Root Rechten laufen. Allerdings ist die Verwendung von Ports kleiner 1024 Root vorbehalten. oops: ifconfig eth0 inet6 add 3ffe::2/64 cd irgendwo/hipl hipd/hipd # (für Daemon Modus verwende -b Schalter) test/conntest-server tcp 1111 Crash wird die Verbindng initiieren, deshalb muss die hosts Datei auf crash anpassen (die Verwendung von IPv4 ist auch möglich): crash: /etc/hosts: 3ffe::2 oops /etc/hip/hosts: HIT_OF_OOPS oops Sie gewinnen die HIT_OF_OOPS aus der inet6 Adresse auf oops (ifconfig dummy0) ifconfig eth0 inet6 add 3ffe::1/64 cd irgendwo/hipl hipd/hipd test/conntest-client-gai oops tcp 1111  <geben Sie beliebigen Text auf crash ein, drücken Enter und Strg+d.> Anschließend sollten Sie den Text als Ausgabe auf den Hosts sehen Es wird eine Verbindung zwischen den beiden Hosts aufgebaut (wenn Sie virtuelle maschinen einsetzen, kann dies einige Zeit in anspruch nehmen). Sie sollten HIT_OF_XXX mit den HITs des Hosts ersetzten. Der hip Daemon lädt (und erzeugt falls nötig) die Host Identitäten automatisch aus /etc/hip/. Die HITs des lokalem Hosts finden sie durch ifconfig dummy0 oder ip addr show dummy0 heraus. Das Abbilden zwischen HITs und IP-Adressen geschieht gewöhnlich automatisch unter Verwendung der hosts Dateien. Eine manuelle Konfiguration ist möglich, aber nicht nötig: tools/hipconf add map PEER_HIT PEER_IP Es ist auch möglich DNS und OpenDHT für die Abbildung zu verwenden. Lesen Sie dazu den entsprechendne Abschnitt dieses Dokumentes. IPv6 Link Local Adressen werden nicht gut unterstützt, bitte verzichten Sie auf dessen Verwendung. Der Grund dafür ist die Schwierigkeit ob die Gegenstelle am gleichen lokalem Netzwerk verbunden ist oder nicht. Lesen Sie die log Meldungen für Informationen über das Ergebnis des HIP base exchange und USAGI IPsec Verhandlungen. Tcpdump oder ethereal sind gute Werkzeuge zur Überwachung des Datenverkehrs während des base exchange. Verwende tcpdump -n -i any esp or proto 253 or port 50500 um ausschließlich HIP Daten aufzufangen. Es gibt darüber hinaus ein Programm hip/test/hipsetup für den schnellen base exchange Test. Starten Sie es ohne Argumente um eine Anleitung zur Verwendung zu erhalten. Sie können hipconf verwenden um HIP Security Associations (SA) manuell zu schließen. Verwenden Sie hipconf hip rst all um alle SAs zu schließen. Der Handover Code basiert auf draft-nikander-hip-mm-00 Spezification. Nicht alle dieser Funktionen sind zur Zeit implementiert und die Qualität des Codes ist weit entfernt von Schußsicher. Ein einfaches Handover Test gibt folgendes Beispiel. Es wird vorausgesetzt, das der base exchange zwischen beiden Hosts bereits etabliert ist. Ausserdem benötigen Sie des Programm nc6 (www.deepspace6.net/projects/netcat6.html) Das Beispiel verwendet IPv6 aber IPv4 ist auch möglich.  <als erstes wird eine HIP-Verbindung, wie in den vorherigen Kapiteln aufgeführt, aufgebaut> oops # nc6 -l -p 12345 crash # nc6 <HIT_OF_OOPS> 12345 crash # <beliebigen Text eingeben Enter drücken> oops # <der auf crash eingegebene Text sollte auf oops Konsole erscheinen> crash # ifconfig eth0 inet6 del 3ffe::1/64 crash # ifconfig eth0 inet6 add 3ffe::3/64 crash # <beliebigen Text eingeben Enter drücken> oops # <der auf crash eingegebene Text sollte auf oops Konsole erscheinen> IPv6 verwendet von Haus aus mehrere IP Adressen auf einem Interface. Um einen nahtlosen Übergang zu erreichen kann die Netzadresse des zukünftigen Netzes konfiguriert werden bevor die alte IPv6 Adresse gelöscht wird. Diese Methode ist vorallem bei den Spezifikationen zur Gültigkeitdauer von IPv6 Adressen angedacht worden. Das Verfahren sollte dann wie folgt verlaufen: oops # nc6 -l -p 12345 crash # nc6 <HIT_OF_OOPS> 12345 crash # <beliebigen Text eingeben Enter drücken> oops # <der auf crash eingegebene Text sollte auf oops Konsole erscheinen> crash # ifconfig eth0 inet6 add 3ffe::3/64 crash # ifconfig eth0 inet6 del 3ffe::1/64 crash # <beliebigen Text eingeben Enter drücken> oops # <der auf crash eingegebene Text sollte auf oops Konsole erscheinen> Es sind also hinzufügen und löschen von IP Adressen vertauscht. Leider unterstützt HIPL dieses Verhalten noch nicht. Verwenden Sie keine Link-Local-Adressen für mobilitäts Szenarien, ausser Sie wissen was Sie tun! Wenn Sie zum Beispiel nach Problemen beim Aufbau von HIP SAs zwischen zwei mobilen und korrespondierenden Knoten fragen, welche Link-Local-Adressen verwenden und in ein anderes Netzwerk wechseln. Die Umadressierung schlägt fehl, da jeder Knoten keinen Weg kennt den anderen zu erreichen. Stellen Sie sicher die Route für die neue Adresse hinzuzufügen sobald die neue Adresse hinzugefügt wird. Wenn die Route fehlt werden die Update Pakete nicht gesendet. Der Daemon wartet für ein paar Sekunden auf ein Update für die Neuübertragung. Die HIPL Software enthält ausserdem eine Java-Wrapper-Bibiliothek um Zugriff auf den libinet6 Resolver zu ermöglichen. Die Bibiliothek heißt "jip" und befindet sich unter "path-to-hipl/jip". Die Verwendung der Java Bibliothek setzt einen funktionierenden HIP Socket Handler, wie bereits beschieben, voraus. Sie benötigen entweder Blackdown oder Sun java jdk 1.4.x oder neuer zum Kompilieren von jip. Kompilieren mit Java 1.3 wird nicht funktionieren. Die Installation geht von Blackdown 1.4 JDK aus. Wenn Sie SUN JDK verwenden setzen sie die Umgebungsvariable "JAVA_HOME" auf Ihr Java Installationsverzeichnis. Kompilieren von libinet6.so und jip: # cd path-to-hipl/libinet6 # cd path-to-hipl/libinet6 # make libinet6.so # cd ../jip # make Libinet6 wird nun automatisch mit kompiliert. Das Ergebnis jip.jar, des letzen Kommandos, können sie verwenden um HIP in ihren Java-Anwendungen zu ermöglichen. Um die Javadoc Dokumentation zu erstellen rufen Sie zusätzlich make apidoc auf. Die Dokumentation finden sie anschließend unter path-to-hipl/doc/jip-api. Es befinden sich drei Beispiel Java-Anwendungen im Verzeichnis test, welche Sie gesondert kompilieren müssen. Verwenden Sie folgende Prozedur: # cd ../test # javac -classpath ../jip/jip.jar HipClient.java # javac -classpath ../jip/jip.jar HipUserkeyClient.java # javac -classpath ../jip/jip.jar HipServer.java Sie sollten bereits Ihre Netzwerktestumgebung, wie unter Abschnitt "HIP-Verbindung zwischen zwei Hosts testen" beschrieben, eingerichtet haben. Ggf. wird hipd ihre öffentlichen Schlüssel erzeugen, darüber brauchen Sie sich keine Gedanken machen. Um ihre bisherigen Java Anwendungen mit der HIP Funktionalität auszustatten genügt es nicht die Socket eigenschaften zu setzen. Sie müssen entweder sicherstellen, dass der Hostname nur zu IPv6 Adressen aufgelöst wird, oder dass die niemals hostnamen an Methoden in der Socket und ServerSocket Klasse senden. Letzteres kann durch die Verwendung der HipAddress Klasse, wie im Beispiel demonstriert, sichergestellt werden. Verwenden der Beispiel Anwendung wie folgt: crash # cd path-to-hipl/test crash # ./java HipServer 12345 oops # cd test oops # ./java HipClient crash 12345 54321 <beliebigen Text eingeben und Enter drücken> Das Shell-Skript test/java enthält einige LD_PRELOAD-, Bibiliotheken- und ClassPath informationen, welche zum ausführen der HIP-Java Anwendungen notwendig sind. Die Klasse HipUserkeyClient ist andererseits die gleiche wie die HipClient Klasse, ausgenommen ihr viertes Argument. Dies ist eine Datei aus der die anwendungsspezifischen Endpoint Informationen geladen werden sollen. Wir haben netkit-telnet von usagi (www.linux-ipv6.org) verändert um die native HIP Funktionalität zu ermöglichen. HIP wird durch einen Kompiler Schalter aktiviert, so dass Sie die Änderungen im Quelltext nchvollziehen können (ifdef USE_HIP). Hier die Anleitung zum Kompilieren der Telnet Anwendungen: # cd test/telnetd # ./configure # make # cd ../telnet # ./configure # make Bevor Sie nun telnet starten sollten das HIP Kernelmodul geladen sein. Es wird für telnet benötigt, da es die native API von HIP nutzt (und nicht den alten Modus). Anschließend können Sie mit telnet experimentieren: oops # telnetd/telnetd -debug 12345 crash # telnet/telnet -l username oops 12345 Anmerkung: der Nutzname darf nicht root sein. Portieren Sie die Anwendung auf die native API. Sehen Sie telnet als praktikables Beispiel. Das API-Dokument finden Sie unter der URL: http://hipl.hiit.fi/hipl/hip-native-api-final.pdf (Anmerkung: dieses API-Dokument ist nicht mehr aktuell, achten Sie auf Änderungen in den Schnittstellen und Variablen.) Verlinken Sie ihre Anwendung neu. Linken Sie auf libinet6 der HIPL Software. Anschließend verwenden Sie eine der folgenden Methoden: Setzen Sie das AI_HIP Flag im getaddrinfo Aufruf. Dies wird getaddrinfo veranlassen nur HITs anstelle von IPs zurückzuliefern. Keine IP-Adresse wird zurückgeliefert. Das Mapping von HIT auf IP-Adresse wird von getaddrinfo veranlasst. Sie verwenden den transparenten Modus im Resolver (siehe HIP_TRANSPARENT_API Kompilerflag in libinet6/Makefile.in). Nur ein erneutes Linken ist notwendig, Änderungen an den Anwendungen bleiben aus. Dynamisches Überschreiben der Resolver Bibiliothek: Übergeben des Binaries als Argument von hipconf: "hipconf run normal <EXECUTABLE>" Überschreiben der getaddrinfo Funktion von der Kommandozeile: http://www-106.ibm.com/developerworks/linux/library/l-glibc.html?ca=3Ddgr-ln= z.B. env LD_PRELOAD=~/hipl--main--2.6/libinet6/.libs/libinet6.so:~/hipl--main--2.6/libhiptool/.libs/libhiptool.so firefox hipserver.infrahip.net Oder hinzufügen zu .bash_profile LD_PRELOAD=libinet6.so:libhiptool.so und LD_LIBRARY_PATH=~/hipl--main--2.6/libhiptool/.libs/:~/hipl--main--2.6/libinet6/.libs/ Wenn Sie die Bibliothek installiert haben stellen Sie sicher, dass sie auf /usr/lib Referenzieren und nicht auf ihr Home Verzeichnis. Stellen Sie weiterhin sicher, dass libinet6 mit HIP_TRANSPARENT_API in libinet6/Makefile.in kompiliert ist. CFLAGS += -DHIP_TRANSPARENT_API Beachte: Methode zwei und drei haben zwei Vorbedingungen! Erstens, die Anwendung muss IPv6 unterstützen um HITs handhaben zu können. Zweitens, die Anwendug muss tatsächlich die getaddrinfo Funktion verwenden. Anderen Falls wird der das senden der HIT an das Kernelmodul nicht funktionieren. Folgende Anwendungen verwenden getaddrinfo auf FC4: telnet, firefox, lynx, ssh. Nicht verwendet wird getaddrinfo von: ping, ping6, tla, svn. Einfügen der HITs in /etc/hosts anstelle von /etc/hip/hosts. Dann muss aber das HIT-zu-IP Mapping durch hipconf add map HIT IP erfolgen. Dies ist eine quick-and-dirty Methode ... Verwenden des Opportunistic Modus, wie Beschrieben in Abschnitt "opportunistic mode". Denken Sie daran die Anwendung gegen libopphip, libinet6 und libhiptool in dieser Reihenfolge zu linken. Verwenden Sie /usr/lib prefix für die Bibliotheken oder folgendes (für den Fall, dass Sie kein make install ausgeführt haben): hipconf run opp <EXECUTABLE> export LD_PRELOAD=~/hipl--main--2.6//libopphip/.libs/libopphip.so:~/hipl--main--2.6/libinet6/.libs/libinet6.so:~/hipl--main--2.6/libhiptool/.libs/libhiptool.so Verwenden Sie die HIP Agent GUI um die Anwendung zu starten. Dies ist eine neue, nicht ausreichend getestete Funktion, welche aber funktionieren sollte. Sie können eine Anwendung über die GUI ausführen und deren Library-Pfad anpassen. Auch sollten sie eine Liste der über die GUI ausgeführten Prozesse sehen. Der Rendezvous Server is vergleichbar dem Home Agent bei Mobile IP. Der Rendezvous Server vergibt eine stabile IP an den Responder and leitet das initiale I1 Packet weiter zum aktuellen Ort des Responders. Vorbedingungen: ./configure --enable-rvs Das hipconf Tool muss die rvs Option unterstüzten: hipconf add rvs <hit> <ip> Zur Zeit ist es das Beste wenn alle an der Kommunikation beteiligten Hosts den Rendezvous Mechanismus aktiviert haben, auch wenn es für den initiierenden Host nicht benötigt wird. Auch sollten Sie den Base Exchange einmal ohne Rendezvous Server starten um vertraut mit Konfiguration von /etc/hosts und /etc/hip/hosts zu werden. Die Teilnehmen:  I = Initiator  RVS = Der Rendezvous Server  R = Responder Die Idee dabei ist es Verbindung mit R's HIT aufzunehmen aber nur RVS's IP-Adresse zu kennen (RVS repräsentirt R). Wir werden zeigen wie RVS die native HIP Beispiel Anendungen verwendet (es kann auch mit nc6 oder den anderen conntest Test Anwendungen genutzt werden). Schritte: ----- 1. Starte und initialisiere das HIP Module auf jedem Host: 2. Auf dem Initiator müssen die die "/etc/hosts" Datei anpassen. In der Datei müssen der Hostname des Responders auf die die IP-Addresse des Rendezvous Servers abgebildet werden. Es darf nicht auf die IP Addresse des Responders zeigen, da ansonsten der Rendezvous Server nicht verwendet wird! Die Datei /etc/hip/hosts sollte den Hostname und die HIT des Responders, wie für normales Base Exchange, enthalten. 3. R teilt dem RVS mit, dass er den RVS Service verwenden möchte: responder # hipconf add rvs <RVS-hit> <RVS-ip> Dies wird eine HIP SA zwischen dem Rendezvous Server und dem Responder aufbauen. 4. Füge einige Serverangaben bei R ein: responder # test/conntest-server tcp 5000 5. Starten der Verbindung auf I: initiator # test/conntest-client-gai <responder-hostname> tcp 5000 6. Beliebigen Text eingeben ... Anmerkung:  * Wenn der RVS das I1 Paket nicht weiterleitet, bitte prüfen Sie ob die HIT, welche der Responder für sich selbst verwendet mit einer der HITs übereinstimmt zu welcher der Innitiator versucht Verbindung aufzubauen. Der HIT, welche vom Responder für die eigene Registrierung beim RVS gewählt wurde, kann eine der vier vorgegebenen sein.  * Der implementierte Mechanismus leitet einfach I1 Pakete mit umgeschriebener Quell- und Zieladresse weiter.  * Keine Änderungen werden im REA/mm-mode gemacht, was z.B. bedeutet dass das doppelte Sprung Szenario nicht funktioniert.  * Der Mechanismus entspricht nicht zu 100% dem RVS-00 draft.  * Wir verwenden nicht REA TLV in R1 (vom Responder zum Initiator). Die gleiche Funktionalität wird auch durch Verwendung der Sender IP-Adresse im R1-Paket erreicht.  *  * Die VIA_RVS TLV wird auch ausgelassen, da es nur zum Zweck der Diagnose und Tests enthalten ist und nichts zur Impelemtation beiträgt (außer Bugs :)  * Zur Zeit wird nicht gantiert, dass der Rendezvous Mechanismus mit anderen Implemenationen interoperabel ist. Um BOS Pakete zu erzeugen (senden an die globale Multicast Adresse an alle Interfaces), verwenden Sie folgende Kommandos: hipconf hip bos BOS-fähige Hosts werden die HOST ID, HIT, und IP Adresse des Hosts aufnehmen. Sie können auf die Kernelliste der bekannten HIP Parnter durch die native getendpointinfo Schnittstelle zum auflösen von Hostnamen zurückgreifen. Normalerweise prüft die Schnittstell zuerst die /etc/hip/hosts Datei auf einen passenden Host. Wenn keiner gefunden wird, wird der Kernel nach passendem HIP Partner angefragt und dessen Listen durchsucht. Falls nur die Kernel Liste durchsucht werden soll, setzen Sie hints.ei_flags auf AI_HIP | AI_KERNEL_LIST. Dies wird ausschließlich die Kernerlliste durchsuchen und nicht die hosts Datei. Um eine Liste der bekannten Gegenstellen vom Kernel zu erfragen, setzen Sie hints.ei_flags auf AI_HIP | AI_KERNEL_LIST und den Hostnamen auf NULL. Dies wird den Kernel abfrage und eine vollständige Liste zurückliefern. In Ip6tables muss eine Regel definiert werden damit HIP und ESP Pakete im User-Space verarbeitet werden. Diese Regel muss allen anderen Firewallregeln vorausgeht damit HIP und ESP Pakete nicht verändert werden. Falls ESP Pakete nicht gefiltert werden können ESP betreffende Regeln (-p 50) weggelassen werden. ip6tables -A FORWARD -p 99 -j QUEUE ip6tables -A FORWARD -p 50 -j QUEUE ip6tables -A INPUT -p 99 -j QUEUE ip6tables -A INPUT -p 50 -j QUEUE ip6tables -A OUTPUT -p 99 -j QUEUE ip6tables -A OUTPUT -p 50 -j QUEUE ip6_queue muss mit "modprobe ip6_queue" geladen werden Die Firewall kann mit "./firewall <file_name>" "timeout value" im Firewall-Verzeichnis gestartet werden. file_name ist der Pfad zu der Datei mit den Firewall regeln und timeout value bestimmt die Zeit in Sekunden. Falls ein timeout von Null oder negativer Wert angegeben wird, so wird keine timeout Prüfung vorgenommen. Alle Regeln müssen in einer separaten Zeile stehen. Die aktuellen Firewallregeln geben Debug-Informationen über Regelanalyse und gefilterte Pakete aus. Die Regeln folgen lose der Linux Iptables Syntax: Grundformat von Regeln: HOOK [match] TARGET Hier ist HOOK einer der netfilter Haken: "INPUT", "OUTPUT", "FORWARD". TARGET ist entweder "ACCEPT" oder "DROP", je nachdem ob das Paket weiter geleitet oder verworfen wird. Match ist eine Kombination von Filteroptionen wie im folgenden beschrieben. Filter Optionen: -src_hit [!] <hit value> --hi <file name> Vergleichen der Quell-HIT in Paketen. HI kann durch --hi Optionn und durch definition eines Pfades zur Public Key Datei als Argument. Damit können Sender Signaturen überprüft werden. Die Datei muss entweder "_rsa_" oder "_dsa_" enthalten abhängig davon ob der RSA- oder der DSA-Algorithmus verwendet wird. -dst_hit [!] <hit> Vergleichen der Ziel-HIT in Paketen. -type [!] <hip packet type> Vergleicht HIP Pakettyp. Der Typ ist einer der folgenden Typen: "I1", "R1", "I2", "R2", "CER", "UPDATE", "NOTIFY", "CLOSE", "CLOSE_ACK" -i [!] <incoming interface> Vergleichen auf hereinkommendes Interface. Das Argument enthält den Namen des Interfaces. Diese Regel kann nicht für OUTPUT-Regeln verwendet werden, denn die Pakete haben kein Incoming Interface. -o [!] <outgoing interface> Vergleichen auf ausgehendes Interface. Das Argument enthält den Namen des ausgehenden Interfaces. Diese Regel kann nicht für INPUT Regeln verwendet werden, denn diese Pakete haben kein ausgehendes Interface. -state [!] <state> --verify_responder --accept_mobile Vergleichen auf Status der HIP Verbindung: "NEW" oder "ESTABLISHED". ESP Pakete werden auch gefiltert als Teil der Verbindung. Mit der "--verify_responder" Option speichert die Firewall die Responder HI des R1 Paketes und nutzt es zur Überprüfung der Paketsignaturen. Mit der "--accept_mobile" Option aktualiseirt die Firwall den Status der Verbindung wenn ein mobiler Host das durch die Firewall geschützte Netzwerk betritt. In der Praxis bedeutet dies, dass das vorherige Interface runtergefahren und im neuen Netzwerk reaktiviert werden muss. Management der Interfaces: Das Firewall-Management-Interface enthält Funktionen um die Regel der laufenden Firewall zu verändern. Die Funktionen sind in firewall/rule_management.h definiert und in firewall/rule_management.c implementiert. Die Datei Rule_management.c enthält auch Funktionen zum kopieren, vergleichen, löschen von Regeln usw. Falls eine Funktion aussehalb des rule_managment benötigt wird, kann diese in den Header Dateien definiert werden. Das Argument "hook" ist der Haken zu Netfilter für dessen Regel er gedacht ist. Der Haken ist definiert in linux/netfilter_ipv6.h als NF_IP6_LOCAL_IN, NF_IP6_FORWARD, NF_IP6_LOCAL_OUT. Die Struktur des Arguments rule ist unter rule_management.h beschrieben. Die Struktur enthält Zeiger zu den Optionen. Wenn eine Option nicht definiert ist muss der Wert NULL sein. Die Strukturen der Optionen sind ebenfalls in rule_management.h definiert. Die Funktion rule * parse_rule(char * string) kann zur erzeugen einer rule Struktur aus einem String genutzt werden. Der String wird auf die Korrektheit gegenüber der rule Syntax geprüft. void insert_rule(const struct rule * rule, int hook): Einfügen des Arguments rule an die hook Funktion. Insert erzeugt eine lokale Kopie des Argumentes rule. int delete_rule(const struct rule * rule, int hook): Löscht die lokale Regel die dem Argument rule entspricht. GList * list_rules(int hook): Erzeugt eine Kopie der Regelliste und gibt diese zurück. Die Aufrufende Funktion muss die Freigabe des Speichers regeln. int flush(int hook): Löscht alle Regeln. HIPL unterstützt auch die Initiierung einer Verbindung aus einen Netzwerk hinter NAT. Die grundlegende Idee ist das der Initiator die HIP Steuerpakete und ESP Daten in UDP Pakete kapselt. Auf diesem Weg können die Pakete die NAT Box durchqueren. Um dies zu ermöglichen müssen aber Initiator und Responder die NAT Erweiterung unterstützen. Zur Zeit kann ein Responder nicht hinter NAT lokalisiert werden. Experimente mit NAT können in einem ähnlichem Weg wie bereits in einem vorherigen Abschnitt beschrieben durchgeführt werden. Der einzige Unterschied ist, dass Sie dem Initiator manuell über den NAT Status informieren müssen - verwenden Sie dazu hipconf hip nat on. Danach können Sie den Base Exchange gemäß der vorherigen Anweisung initiieren. Die manuelle Konfiguration ist zur Zeit noch notwendig, da die automatische NAT Erkennung (STUN) noch nicht implementiert ist. Wenn Sie Probleme mit der Verwendung des NAT Codes habe um die I1 aufzunehmen (z.B. mit conntest-client-gai (ereignet sich mit Kernel 2.6.16.5)), dann könnten Sie den Quell-HIT Explicit angeben. Das Verfahren zum Initiieren einer Verbindung hinter NAT ist folgendes: tools/hipconf hip nat on tools/hipconf add map peer_hit peer_ipv4_addr ping6 -I source_hit dst_hit Stellen Sie sicher, dass die Quelle ist die selbe wie in der ip xfrm policy Ausgabe. Wir sind uns des Problems bewußt (siehe BugID 161) und es wird gelöst. Auch scheint es, das der Responder nicht automatisch die Pakete zum NAT routet, so dass ein ip route add nat_ipv4_addr dev xx am Responder notwendig wird (ereignet sich mit Kernel 2.6.16.5). Drei Fälle von Mobilität des Initiators wurden in den NAT Code implementiert. Mobilität ausgehend hinter einem NAT hinter das selbe NAT: Für diesen Fall, das Standardverfahren zum Update nach dem Base Exchange, ist die Prozedur vollständig. Das Update wird in UDP Pakete gekapselt. Mobilität von öffentlich adressiertem Netzwerk hinter ein NAT Netzwerk: Wenn eine HIP Verbindung zwischen zwei Hosts errichtet werden soll, bei welcher sich beide in einem öffentlichem Netzwerk befinden und einer in ein NAT Netzwerk wechseln soll, dann sollte der Knoten zuerst die öffentliche Adresse löschen, die NAT Erweiterung durch hipconf aktivieren und dann die NAT-IP-Adresse und Route an die Schnittstelle binden. Das Update wird ab dann auf UDP basieren und die zukünftige Kommunikation in UDP gekapselt (beides, HIP Steuerung und ESP-Pakete). Mobilität von NAT Netzwerk zum öffentlich adressiertem Netzwerk: Wenn ein Knoten eines NAT Netzwerks eine HIP Verbindung etabliert hat und nun in ein Netzwerk mit öffentlichen IP Adressen wechseln soll dann sollte die private IP Adresse zuerst gelöscht, die NAT Erweiterung abgeschalten (verwende hipconf) und anschließend die öffentliche IP Adresse inkl. Route gesetzt werden. Danach wird die HIP Verbindung nicht mehr UDP gekapselte Pakete senden. Auch die Update Funktion wird normale HIP Pakete ohne UDP-Kapselung verwenden. HITs mit grafische Benuzterschnittstelle verwalten. Werden neue HITs empfangen, diese und lokale HIT werden durch den HIP Agenten gefiltert, wird der Nutzer nach akzeptanz des HIT Paares fragt. Danach werden die HIT in der Datenbank gespeichert und akzeptanz/verworfen wird an den Daemon zurückgeliefert. Die HITs können darüber hinaus durch das Interface verwaltet werden. Das Interface ist unter Entwicklung und noch im Alpha-Stadium. Um den Agenten und das GUI zu kompilieren werden folgende Softwarepakete benötigt (vorausgesetzt Sie nutzen Debian): 1. gcc und g++ Kompiler, beide solten mindestens Version 4.0 sein. 2. Pakete: xbase-clients - miscellaneous X clients 3. GTK 2.x und Development Pakete (Paket libgtk2.0-dev). Wenn Sie das "System Tray Icon" verwenden wollen brauchen Sie mindestens GTK Version 2.10.0. Damit der Agent ordnungsgemäß mit richtigem Fenster und System Tray Icon verwendet werden kann müssen Sie mit make install die Dateien ins richtige Verzeichnis installiert werden. Anderenfalls wird das System Try Icon nicht angezeigt. Die HIT Datenbank wird per default aus $HOMEDIR/.agentdb geladen und gespeichert. Um den Agenten auszuführen rufen Sie hipagent auf. Sie sollten die mit normalen Nutzerrechten (nicht Root) laufen lassen. unpack patches/misc/hip-dht-04052006.tgz make a link called "hipl--main--2.6/hip-dht" that points to the unpacked hip-dht directory Compile hipl--main--2.6 with ./configure --enable-opendht Um dies zu testen starten Sie conntest-server und conntest-client-gai wie gewohnt zwischen den Hosts. Sie erhalten Meldungen vom hipd und conntest über DNS->HIT->IP Auflösungen. Alles sollte ohne zusätzliche Aktionen laufen. Sie könnten die Adresse des OpenDHT Kontaktservers ändern, die Liste der zur Zeit laufenden erhalten Sie unter http://www.opendht.org/servers.txt. Dokumentation finden Sie auch unter http://kom.aau.dk/group/05gr680/. unpack http://i3.cs.berkeley.edu/download/i3_0_3.tar.gz make a link called "hipl--main--2.6/i3" that points to the unpacked i3_0.3/i3 directory Compile hipl--main--2.6 with ./configure --enable-hi3 Dies wurde für lange Zeit nicht getestet. Um es zum Laufen zu bringen werden einige Einstellungen am lokalem i3 Server auf einer i3 Distribution oder PlanetLab notwendig. Siehe http://hipl.infrahip.net/i3_status.html oder http://rose.cs.berkeley.edu:8080/i3_status.html. Der Opportunistic Mode ist standardmäßig beim Kompilieren aktiviert. Folgenden Sie diesen Angaben um den Opportunistic Mode für HIP zu aktivieren: 1. Move to top level of HIPL cd hipl 2. Run autogen.sh ./autogen.sh 3. Run configure with flag --enable-opportunistic. See "./configure --help" for a full list of options ./configure --enable-opportunistic 4. Run make make 5. Run hip daemon on both "crash" and "oops" hipd/hipd 6. Verwenden Sie hipconf um den HIP Opportunistic Mode auf beiden Hosts manuell zu aktivieren. Das "tools/hipconf set opp on|off" Kommando wird verwendet um den Opportunistic Mode ein- und auszuschalten. tools/hipconf set opp on Nun ist der Opportunitic Mode aktiviert, Um dies zu testen müssen die die HIT von crash aus /etc/hip/hosts löschen und den Schritten in Kapitel 6 folgen.