2. April 2010
SmartMeter (intelligente Stromerfassungsgeräte) im Selbstbau und Selbstversuch. Ein SmartMeter kann dazu verwendet werden, das Stromverbrauchsprofil zu analysieren. Insbesondere kann der zeitliche Ablauf sehr genau analysiert werden um unnötige Verbraucher z.B. Standby in der Nacht zu ermitteln. Spätestens Ende 2010 müssen alle Energieversorger einen Tarif anbieten, der einen Anreiz zum Energiesparen setzt. Zukünftig ist eine monatliche Stromrechnung geplant.
Anhand von detaillierten Verbrauchsprofilen kann man beispielsweise genutzte Geräte wie Kühlschrank, Backofen, etc. identifizieren. Daraus entstehen detaillierte Rückschlüsse auf die Lebensgewohnheiten.
Gesetzlich ist nicht geregelt, ob und wie der Energieversorger erfasste Daten nutzen darf, wie oft er Daten erfassen darf (zeitliche Auflösung) und wie Daten gegebenenfalls weitergegeben werden (Aggregierung, Anonymisierung). Die Kombination aus Nutzeridentifizierung und hoher zeitlicher Auflösung ist dabei kritisch zu sehen.
Den Volkszähler muss man sich selbst einbauen, Kenntnisse in E-Technik und Stromversorgung sind dabei seeeehr hilfreich. Es gibt einzuschleifende Hutschienenzähler, optische Zähler, Stromzangen (mit und ohne Spannungsmessung) und Zwischenstecker. Für die Weiterleitung und Auswertung der Daten gibt es ebenfalls mehrere Lösungsansätze. In Frage kommen ein zentraler Server im Internet, ein eigener Server oder z.B. eine Speicherkarte.
Beim Controller und bei der Auswertung ist noch vieles in der Entwicklung.
Das Wiki dazu wird von Wikia gehostet.
IPv6 ist bekanntlich der Nachfolger von IPv4 und wird seit rund 20 Jahren entwickelt. Inzwischen ist man soweit, dass man IPv4 durch IPv6 ersetzen könnte. Es bewegt sich nur nichts.
Mythos 1: Sicherheit – IPv6 bringt vor allem einen größeren Adressraum. Das Internet wird durch IPv6 nicht per se sicherer. Der einzige Vorteil (für die staatlichen Überwacher) wäre, dass man mit fest zugeordneten Adressen den Nutzer eindeutig adressieren kann. Für Administratoren treten eher Sicherheitsprobleme durch unausgereifte Implementierungen und fehlende oder unvollständige Unterstützung in Firewalls auf. NAT selbst hat noch nie eine wirklich größere Sicherheit geliefert.
Mythos 2: Geschwindigkeit – Das Internet wird auch nicht schneller, QoS lässt sich im Internet praktisch kaum flächendeckend umsetzen, IPv4 wird genau wie IPv6 inzwischen in Hardware gehandhabt.
Mythos 3: Einfache Konfiguration – IPv6 unterstützt Stateless Address Autoconfiguration und Stateless DHCP, DHCP funktioniert mit IPv4 aber längst auch stabil.
Mythos 4: Mobility – Mobile IP ist mit IPv6 zwar deutlich besser gelöst, eine feste IPv6-Adresse könnte über beliebige Netzwerke mitgenommen werden. Praktisch scheitert das meist am automatischen Netzwerkzugang. Ohne Seamless Roaming bringt Mobile IPv6 folglich wenig.
Security-Aspekte
Der Betrieb von Firewalls wird in der Anfangszeit mühsam. Alle IPv6-Objekte müssen neu erfasst werden, alle Regeln müssen praktisch doppelt (für IPv4 und IPv6) getestet werden. Windows Vista und 7 tunneln automatisch IPv6 durch IPv4, wenn der Zielrechner eine IPv6-Adresse hat. Das selbst dann, wenn am lokalen Interface nur IPv4 konfiguriert ist. Dafür fallen ein Teil der Portscans weg, weil der Adressraum extrem groß wird.
Privacy
Mobile IPv6 Clients sind unheimlich gut durch verschiedene Netze und Provider und dadurch auch räumlich trackbar. Deshalb gibt es eine extra Privacy Extension (RFC 3041).
Insgesamt war der Vortrag gespickt mit Informationen zu IPv6, da werde ich das eine oder andere sicher noch nachlesen …
Link: SixXS IPv6 Tunnel Provider
Florian Schießl berichtet über den Zwischenstand des freien Linux-Desktops der Stadt München. OpenOffice ist ausgerollt und in Verwendung, der Linux-Basisclient ist noch nicht soweit. Bisher sind 3000 Arbeitsplätze komplett auf Linux umgestellt. Die anderen Arbeitsplätze verwenden noch Microsoft Windows, nutzen aber OpenOffice, Thunderbird, Firefox, Gimp, etc. Basis des Linux-Clients ist aktuell Debian Etch mit KDE. Der Basisclient ist für alle Arbeitsplätze identisch. Software-Verteilung erfolgt mit FAI der Uni Köln.
Makros, Formulare und Vorgänge werden plattform- und Office-Anwendungsunabhängig mit Hilfe der Eigenentwicklung WollMux (ein Wortspiel aus der eierlegenden Wollmilchsau und dem Maskottchen Mux) abgebildet, die Formulare z.B. mit Hilfe von Datenbankabfragen automatisch füllen kann. Datenaustausch erfolgt überwiegend mit PDF nach außen, wenn Bearbeitung erfolgen soll mit ODF. Ziel ist jedoch immer die Verwendung offener, standardisierter Formate.
Links:
There is no answer to the question „How far can TCP go?“
TCP Authentication Option (AO)
TCP MD5 (RFC 2385) wird abgelöst von Authentication Option (AO). Die MD5-Prüfsumme steht in einer TCP-Option. Das Segment wird verworfen, wenn die Prüfsumme nicht stimmt. AO erlaubt beliebige Hash-Algorithmen, unterstützt Rekey, Replay-Protection und benötigt 16 Byte im TCP-Header. TCP-AO ist aktuell als IETF-Draft verfügbar. Schlüsselwörter: Sequence Number Extension (SNE), Master Key Tuple (MKT). Links: Draft TCP-AO, Draft TCP-AO Crypto.
SACK Loss Recovery
Frühzeitige Erkennung von verlorengegangenen TCP-Paketen Mit Hilfe der TCP-Option Selective Acknowledgement. Links: Draft SACK Recovery.
Mobile Ad-hoc Netzwerke
Mobile Ad-hoc Netze müssten über ein dynamisches Routingprotokoll benachbarte Systeme erkennen. Verwendet wird dafür das Optimized Link State Routing Protocol (OLSR, RFC 3626). Schlüsselwörter: Mobile Ad-hoc Netzwerk (Manet). Links: Draft OLSRv2, Draft DYMO, Draft SMF.
Staukontrolle
Staukontrolle (RFC 2581) soll eine zu hohe Belegung des Netzwerks verhindern. Dabei werden verschiedene Verfahren der Congestion Control verwendet. Die Hauptarbeiten stammen von Van Jacobsen, der Congestion Control in TCP entworfen hat. Bei UDP fehlt die Staukontrolle. Deshalb wird versucht mit einem eigenen Protokoll, Datagram Congestion Control Protocol (DCCP, RFC 4340) dieses Problem anzugehen. Zusätzlich könnte man sich die ermittelte Bandbreite zu einem Kommunikationspartner auch nach Ende der Verbindung merken. Ein weiteres Hilfsmittel ist Quick Start TCP.
TCP Cookie Transaction
Damit soll verhindert werden, dass Daten einer alten mit einer neuen Verbindung vermengt werden. Früher hat man einfach einen Socket und Port länger gesperrt, inzwischen versucht man das Problem anders zu lösen. Dabei kommt ein TCP Cookie zum Einsatz. Links: Draft TCP TIME_WAIT, Draft TCP CT.
Interessant ist für mich jetzt primär die Entwicklung von TCP-AO. Ich könnte mir vorstellen, dass es in naher Zukunft Netzwerkkarten gibt, die die komplette TCP-AO-Berechnung auf der Karte durchführen (Offloading) und damit ein großer Teil zukünftiger Netzwerkverbindungen mit TCP-AO authentisiert werden kann. Dann würden vermutlich Man-in-the-Middle-Angriffe erheblich erschwert. Die anderen Punkte beschäftigen sich hauptsächlich mit der Verlässlichkeit und Verfügbarkeit von Datenübertragungen und das finde ich persönlich jetzt nicht so interessant.
In diesem Zusammenhang verweise ich auch gerne auf den TCP Security Draft von Gont.
15:17 – „Willkommen in München“. Sec eröffnet die 10. Easterhegg, 2010 in München.
- Rauchen ist verboten, auch Tabak!
- Wireless LAN funktioniert, aber noch langsam
- Es gibt permanent Frühstück, allerdings nur so bis ca. 23:00 Uhr
- Die ersten 300 angemeldeten Teilnehmer haben eine Tasse bekommen
- Der Fahrplan ist online. Saal 1 im EG, Workshop 1 im 2. OG, Workshop 2 im 1. OG
- Sonderräume sind der Lötraum (Löt, 2. OG), Amateurfunkraum (AFU), RepRap-Raum (3D-Drucker), Bar (Keller)
- T-Shirts werden ab morgen in der Bar verkauft
- Die Löt-Rabbit-Platine kann mit Atmel, IR, Display, Audio, USB, etc. für 10 Euro aufgerüstet werden
- Es gibt noch Tageskarten für die Einzeltage
- Das POC stellt ein DECT-Netz zur Verfügung
- Für Saal 1 und Workshop 1 gibt es Aufzeichnungen aber kein Streaming
Und nun ran an’s Spielzeug 😉
