So, Leute: Es wird ernst. Die Root-Zone ist schon eine ganze Weile signiert und man soll auch dort mal die Schlüssel wechseln. Das ist nicht einfach, weil alle Betreiber rekursiver Resolver daran mitwirken müssen.

Es gibt drei Typen von Betroffenen:

  • Der Resolver macht kein DNSSEC, dann vergesst es.
  • Der Resolver validiert DNSSEC und es interessiert Euch nicht, dann plant einen Paniktag ein.
  • Der Resolver validiert DNSSEC und ihr wollt Panik vermeiden, dann lest und testet.

Worum geht's?

Fragt man die Root-Nameserver nach ihrem Schlüsselmaterial so gibt es folgende Antwort:

;; QUESTION SECTION:
;.                      IN DNSKEY

;; ANSWER SECTION:
.                       DNSKEY  257 3 8 (
                                AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
                                ...
                                9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
                                ) ; key id = 20326
.                       DNSKEY  257 3 8 (
                                AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
                                ...
                                LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
                                ) ; key id = 19036
.                       DNSKEY  256 3 8 (
                                AwEAAYvxrQOOujKdZz+37P+oL4l7e35/0diH/mZITGjl
                                ...
                                jpi+V7pgh0o1KYXZgDUbiA1s9oLAL1KLSdmoIYM=
                                ) ; key id = 15768
.                       RRSIG   DNSKEY 8 0 172800 20170831000000 (
                                20170810000000 19036 .
                                D2D0oJblRe/C86Eti+vOLIHll7hvI9mN/O6S9gZqKvN2
                                ...
                                fkMFPGKWv4Gi1BlE+r+a9FDFz4ypjwdbvA== )

Die Root-Zone hat also aktuell drei Schlüssel:

  • Einen Arbeitsschlüssel (key id = 15768) und
  • zwei  Hauptschlüssel von denen Ihr bisher den mit der ID 19036 auf der Platte habt.
  • Der Schlüssel mit der ID 20326 ist neu.

Zum 11. Oktober 2017 wird die Root-Zone mit dem neuen Schlüssel unterschrieben. Dann müsst Ihr den neuen Key auf der Platte haben, sonst fällt bei Euch DNS komplett aus.

Ich habe das selbst schon mal hinbekommen, als am 26.12. mir die Signaturen der Nameserver-Records meiner Test-Root ausliefen. Ein Remote-Zugriff klappte nicht mehr, weil die SSH die IPs nicht nachschlagen konnte, die einzelnen Geräte in Panik die Dienste neu starteten und diese schon beim Start keine Gegenstelle mehr erreichen konnten (IPs nachschlagen ging nicht mehr) und sich instantan wieder beendeten.

Manuell konnte ich an der Konsole des rekursiven Nameserver den Fehler beheben. Nach einer frostigen Fahrradtour in die Firma. Ich habe geschwitzt!

Was ist zu tun?

Eure Software sollte also erkennen, dass es einen neuen Schlüssel gibt und den auf die Platte legen.

Nehmen wir an, es sei unbound. Dann findet ihr eine Datei /etc/unbound/root.key (o.ä.)

; autotrust trust anchor file
;;id: . 1
;;last_queried: 1502962961 ;;Thu Aug 17 11:42:41 2017
;;last_success: 1502962961 ;;Thu Aug 17 11:42:41 2017
;;next_probe_time: 1503005390 ;;Thu Aug 17 23:29:50 2017
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       172800  IN      DNSKEY  257 3 8 AwEAAaz/t...V74bU= ;{id = 20326 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1502399011 ;;Thu Aug 10 23:03:31 2017
.       3696    IN      DNSKEY  257 3 8 AwEAAagA...ihz0= ;{id = 19036 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1291045951 ;;Mon Nov 29 16:52:31 2010

Diese Datei enthält bereits beide Schlüssel und alles ist gut(TM).

Hat man dagegen unbound irgendwann mal aufgesetzt und nie richtig eingerichtet, so schaut die Datei so aus:

;;id: . 1
;;last_queried: 1414101618 ;;Fri Oct 24 00:00:18 2014
;;last_success: 1414101618 ;;Fri Oct 24 00:00:18 2014
;;next_probe_time: 1414143412 ;;Fri Oct 24 11:36:52 2014
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       86390   IN      DNSKEY  257 3 8 AwEAA...k1ihz0= ;{id = 19036 (ksk), size = 2048b}
   ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1291283901 ;;Thu Dec  2 10:58:21 2010sdf 

Wie fixed man das?

Zuerst einmal sollte unbound wissen, dass er die Datei selbst aktualisieren soll:

$ fgrep root.key /etc/unbound/unbound.conf
 auto-trust-anchor-file: "/etc/unbound/root.key"

Klar soweit?

Wenn auch das nicht hilft, kann es sein, dass die Datei nicht die notwendigen Rechte hat.

-rw-r--r-- 1 root root 758 Okt 24  2014 /etc/unbound/root.key
-rw-r--r-- 1 unbound unbound 1250 2017-08-17 11:42 /etc/unbound/root.key 

Das ist doch wohl deutlich, oder? Und natürlich leicht zu fixen.

Und andere Resolver-Software? Im Kern geht es um RFC 5011 Unterstützung. Die findet man bei Bind und anderer Software.

Achja, bitte schaut doch mal nach den Kundensystemen, von denen ihr wisst oder ahnt.

In letzter Zeit kommt es immer wieder vor, dass die Warteschlange der ausgehenden E-Mails gewaltig anwächst. Es handelt sich dabei oft im Spam-Mails mit gefälschtem Absender und aktivierter Empfangsbestätigung. Ein paar trickreiche Sendmail-Kommandos räumen auf.

In der Warteschlangen stehen hunderte von E-Mails, hier exemplarisch zwei herausgenommen:

~# mailq
v7DB2pot018012     2519 Sun Aug 13 13:02 MAILER-DAEMON
                 (Deferred: Connection refused by habacland.com.)
                                         <hulda1tdnap3@habacland.com>
v7DKLjhL019655     2125 Sun Aug 13 22:21 MAILER-DAEMON
                 (Deferred: Connection refused by habacland.com.)
                                         <marien4j06sq@habacland.com>

Zum einen liegen diese E-Mails schon lange in der Warteschlange (es ist ja Donnerstag, der 17. August). Dies lässt die Warteschlange anwachsen.

Zum anderen wird ein vermutlich unschuldiger Server mit Backscatter attackiert. Auch das ist nicht gut.

Also erst einmal dem Kram wegräumen und manuell begutachten:

~# sendmail -Q"strange backscatter" -qR@habacland.com

Alle E-Mails, die an diese Empfängerdomain gehen, werden mit der Meldung "strange backscatter" in Quarantäne geschoben.

Dies bewirkt zweierlei:

  • Erstens versucht der Mailserver nicht mehr die E-Mails zuzustellen.
  • Und zweitens sind die E-Mails nun leicht erkennbar (die Spooldateien beginnen mit einem 'h').

Da die E-Mails nicht mehr in der normalen Warteschlange auftauchen, muss man ein anderes Kommando zur Anzeige bemühen:

# mailq -qQ
v7DKLjhL019655     2125 Sun Aug 13 22:21 MAILER-DAEMON
     QUARANTINE: strange backscatter
                 (Deferred: Connection refused by habacland.com.)
                                         <marien4j06sq@habacland.com>
v7DB2pot018012     2519 Sun Aug 13 13:02 MAILER-DAEMON
     QUARANTINE: strange backscatter
                 (Deferred: Connection refused by habacland.com.)
                                         <hulda1tdnap3@habacland.com>

Es ist schön zu sehen, dass der Quarantänegrund extra genannt wird. Man kann also mehrere Arten von Quarantäne gleichzeitig betreiben und trotzdem voneinander trennen.

Nachdem ich mich davon überzeugt habe, dass all diese E-Mails die gleiche Art Backscatter sind ...

H??Content-Type: multipart/report; report-type=delivery-status;
        boundary="v7..."

... wird die Zustellung dieser E-Mails abgebrochen.

# mailq -qQ |
  sed -n '/^v/s/[    ].*//p' |
  while read a; do
    sendmail -Q -qQ -qI$a
    sendmail -qI$a -O Timeout.queuereturn=now
  done

Dazu wird pro interner Mailkennung (mit sed extrahiert) der Quarantäne-Mails (mit mailq -qQ selektiert)

  • die Mail aus der Quarantäne genommen (mit sendmail -Q) und
  • die individuelle Queue-Verteilzeit auf 0 gesetzt.

Es wäre natürlich auch möglich gewesen, die E-Mails einfach zu löschen. Aber das ist Ansichtssache.

Bleibt die Frage. woher man so etwas lernen kann: Im Sendmail-Contrib-Verzeichnis gibt es ein Tool qtool.pl, dass all diese Dinge kann und leicht zu lesen ist.

Heute lag eine seltsame Abuse-Mail im Posteingang: Ein Kunde habe einen Angriff vorgenommen und sei deswegen von fail2ban geblockt worden. Als Beleg wurden gesperrte HTTP-Zugriffe auf den Webserver angegeben. Das Verhalten ist reproduzierbar.

Dear Sir/Madam,

We have detected abuse from the IP address ( 217.17.197.14 ), which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Any feedback is welcome but not mandatory.

Log lines are given below, but please ask if you require any further information.

(If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was generated by Fail2Ban.)

IP of the attacker:  217.17.197.14 

You can contact us by using: abuse-reply@<protect-the-hoster>.de

Addresses to send to:
abuse@iks-jena.de

==================== Excerpt from log for 217.17.197.14 ====================
Note: Local timezone is +0200 (CEST)
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.498758 2017] [evasive20:error] [pid 11057:tid 139621224589056] [client 217.17.197.14:60994] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/bottom-menu-bg.png, referer: http://www.<protect-the-customer>.de/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.499515 2017] [evasive20:error] [pid 11057:tid 139621300123392] [client 217.17.197.14:60988] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-bl.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.499542 2017] [evasive20:error] [pid 11057:tid 139621241374464] [client 217.17.197.14:60986] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-bg.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:18.500119 2017] [evasive20:error] [pid 11057:tid 139621266552576] [client 217.17.197.14:60990] client denied by server configuration: /home/users/hwburgk/www/j15/templates/rt_terrantribune_j15/images/footer-br.png, referer: http://<protect-the-customer>/templates/rt_terrantribune_j15/css/template_css.css
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.007673 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.220530 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/favicon.ico
/home/users/hwburgk/logs/error.log:[Mon Aug 07 10:32:25.260728 2017] [evasive20:error] [pid 11057:tid 139621350479616] [client 217.17.197.14:60998] client denied by server configuration: /home/users/hwburgk/www/j15/favicon.ico

Zunächst ist auffällig, dass als Begründung für die Sperre die letzten Einträge des Logfiles verwendet werden. Dies ist eine gute Idee, denn so weiß der betroffene Abuse-Bearbeiter, was vorgefallen ist.

Allerdings werden die Logs erst nach der Installation der Sperre bei der Erzeugung der Beschwerde-Mail ausgelesen. Sie enthalten also nur noch die Einträge, die aufgrund der Sperre geblockt wurden. Eine Ursachenermittlung ist so nicht möglich.

Beim schnellen Test am Arbeitsplatz wird die Webseite angezeigt. Soweit so gut.

Drückt man aber F5-neu laden einige Male, so erscheint nur noch das folgende Bild:

2017-08-07-121848_881x287_scrot

Tests von verschiedenen anderen Systemen aus zeigten immer das gleiche Verhalten. Sobald man die CSS-Dateien schnell neu läd, erfolgt die Sperre. Es genügt offenbar auch, die /favicon.ico mehrfach schnell neu zu laden. Diese Datei existiert nicht und liefert einen 404.

Bei jedem dieser Versuche geht eine E-Mail an den Abuse-Kontakt des Internet-Providers, den man nutzt. Also Vorsicht!

Zur Klärung des Problems habe ich den Hoster angerufen und mit der Hotline gesprochen. Nach einigen Erklärungen hatte man das Problem verstanden (und vermutlich den Hotline-Rechner gesperrt). Eine Verbindung in die Abuse-Abteilung war aber nicht möglich, da "Die Kollegen Tag und Nacht im Einsatz sind, so dass sie heute erst nach 15 Uhr wieder rein kommen."

Andrew McConachie hat bei ICANN59 einen sehr interessanten Vorschlag eingebracht. Er belauscht den HTTPS Verbindungsaufbau und blockt den Datenverkehr, wenn die übermittelten Schlüssel nicht zu den vorhandenen TLSA Records aus DNSSEC passen. Auf diese Weise schützt er an zentraler Stelle seine Clients.

Vorgehensweise

Im RFC 6698 wird definiert, wie man mittels DNS Einträgen festlegt, welche Zertifikate für die Webserver benutzt werden dürfen. Das Verfahren heißt kurz DANE (DNS-Based Authentication of Named Entities). Mittels DNSSEC lässt es sich gegen Fälschungen schützen.

Die Middleware, z.B. eine Firewall, sieht normalerweise vom verschlüsselten Verkehr gar nichts. Jedoch muss zum Verbindungsaufbau mit einer prinzipiell unbekannten Gegenstelle zuerst Klartext gesprochen werden, bis man sich auf eine Verschlüsselung einigen konnte.

Durch die IPv4-Adressknappheit hat nicht jede Webseite ihre eigene IP-Adresse, sondern der Webserver muss vorab erfahren, welche Webseite der Client abrufen will, damit er das passende Zertifikat für diese Seite präsentieren kann. Dieses Verfahren heißt SNI (Server Name Indication) und ist im RFC 6066 definiert.

Genau an dieser Stelle greift Andrew ein:

  • Er schneidet bei der Client-Anfrage den angeforderten Servernamen mit und extrahiert das vom Webserver gelieferte Zertifikat aus dessen Antwort beim Verbindungsaufbau.
  • Anschließend prüft er mittels DANE und DNSSEC, ob für diesen Servernamen ein TLSA Record existiert und prüft das Zertifikat gegen diesen Record.
  • Fehlt der TLSA Record oder passt er, passiert nichts weiter.
  • Widerspricht allerdings das Zertifikat dem TLSA Record, so fügt er eine Access-Regel ein, die den Datenfluss für diese Verbindung unterbindet.

Im Endergebnis wird bei einem fehlerhaften Zertifikat (nicht zum TLSA passend), der Client daran gehindert, mit einer wahrscheinlich bösartigen Gegenstelle zu reden.

Praktische Umsetzung

Andrew hat auch gleich noch Code für dieses Konzept geschrieben.

Die Software heißt "danish" und kommt trotzdem mit englischer Dokumentation. Sie läuft auf einem OpenWRT oder LEDE-Router. Wer mag kann damit spielen

Von meiner Seite: Beifall! Großartige Sache, Andrew!

Letzte Woche gab es einen interessanten Fall von Paketverlust, der sich in kein bisher bekanntes Schema passen wollte. Normalerweise hat man bei Leitungsstörungen (DSL) eine bestimmte Rate an defekten Paketen. Und dann gibt es Bandbreitenbegrenzungen, die schlagartig zu erhöhtem Paketverlust führen. In diesem Fall stieg aber die nutzbare Bandbreite weiter an, nur der Paketverlust steigt massiv.

Überraschung

Auf einer Kundenleitung trat ein erhöhter Paketverlust auf, sobald mehr Last auf die Leitung geschoben wurde.

Ein zentraler Server liefert über diese Leitung an Endgeräte Daten aus. Er misst die Bandbreiten und Paketverluste in aggregierter Form.

packet-loss-lacp-asymmectric-praxis

Man sieht deutlich, dass bis knapp 2Gbps die Paketverluste nahezu konstant sind, was auf sporadische Fehler auf einer ungeschirmten Leitung hindeutet. Die meisten Endgeräte befinden sich hinter DSL Anschlüssen, das passt also ganz gut.

Der Rest der Graphik, der danach folgt, ist allerdings seltsam: Die Kurve knickt ziemlich plötzlich ab und steigt dann fast linear an.

Was kann das sein?

Fehlersuche

Die erste Annahme ist selbstverständlich eine Bandbreitenbegrenzung. Allerdings sollte dann die Bandbreite auch nicht weiter ansteigen.

Testweise habe ich mal eine solche Leitung bei 2Gbps per QoS-Policy limitiert und dann durch gemessen:

packet-loss-bandwidthlimit

Sobald die Ziel-Bandbreite erreicht wird, steigt der Paketverlust an. Aber es geht nicht mehr durch die Leitung durch als konfiguriert wurde.

Eine einfache QoS-Policy ist es also nicht.

Beim genauen Ablaufen des Leitungsweges stellt sich heraus, dass der Kunde folgendes gebaut hat.

packet-loss-netzplan

Interessanterweise treten die Probleme nur auf, wenn das LACP-Bündel aus Leitung 3 und Leitung 4 im Spiel sind. Werden die Strecken 5, 6 oder 7 anders zugeführt, so treten dort bei gleichem Lastverhalten keine Probleme auf.

Dafür gibt es keine gute Erklärung, weil die Bandbreite mit 2x10Gbps mehr als ausreichend ist, um die Daten durch zu schieben. Trotzdem muss der Fehler an einem der an diesem Tunnel beteiligten Switche liegen.

Eine explizite Messung über diese Strecke 2-(3,4) mit 8 Gbps ergab einen Paketverlust von fast 50%. Damit ist die Eingrenzung auf diese Strecke definitiv. Offenbar gibt eine der beiden Leitungen 3 oder 4 unter Last den Geist auf.

Bei einer gründlichen Untersuchung der Konfiguration stellte sich heraus, dass auf dem zentralen, linken Switch eine QoS-Konfiguration vorliegt, die auf Leitung 4 aktiv ist. Auf Leitung 3 fehlt diese QoS-Einstellung. Diese QoS-Policy definiert eine maximale Bandbreite von 1Gbps für den betroffenen Datenverkehr.

Nach Deaktivierung der Policy läuft die explizite Messung problemlos durch.

Erklärung

Das LACP-Bündel verteilt ziemlich gleichmäßig die Datenpakete auf die beiden Leitungen. Die QoS-Policy schmeißt dann alle Pakete, die das Gigabit überschreiten einfach weg.

Das lässt sich einfach modellieren und mit den Messwerten vergleichen:

packet-loss-lacp-asymmectric-theorie

Bei kleinen Bandbreiten ist der Abknick-Effekt sowohl im Modell als auch in der Messung in deutlicher Übereinstimmung.

Aber auch bei 8 Gbps Durchsatz ist der Paketverlust im Modell über 40%, was der realen Messung sehr nahe kommt. Das Modell passt also für kleine und große Werte sehr gut.

Nachdem wieder mal Kritik an xz hoch gekocht ist, habe ich mich zuerst gefreut, dass ich auf zunehmend auf zstd setze. Dann gab es aber Nachfragen, wie sich den zstd so schlagen würde. Besonders im Hinblick auf den Hutter Prize. Also habe ich mal gemessen.

Der Hutter Prize

Der Informationsgehalt natürlicher (englischer) Sprache liegt bei einem Bit pro Zeichen. Soweit behauptet das die Shannon-Theorie.

Aber wie weit kann man wirklich an das Limit kommen?

Der Hutter Prize stellt vereinfacht gesagt folgende Aufgabe:

  • Gegeben ist eine 100MByte Auszug der englischen Wikipedia in XML.
  • Nimmt man 1bit/Zeichen als Limit an, so müsste sich dieser Auszug auf 12,5 MByte packen lassen.
  • Damit die Aktion fair bleibt und das Kompressionsprogramm nicht selbst den ganzen Text enthält, zählt die Größe des Dekomprimierprogrammes mit.
  • Als Qualifikation sind weniger als 16MByte zu schaffen.
  • Es gibt eine Zeitbeschränkungen von 10h.
  • Da es inkrementelle Fortschritte gibt, wird der Preis auch nur inkrementell ausgezahlt.

Es steht natürlich nicht zu erwarten, dass allgemeine Kompressionsprogramme so dicht heran kommen. Stattdessen ist das theoretische Limit nur dann zu erreichen, wenn man den Kontext der englischsprachigen Welt bereits kennt.

Genauer gesagt, sollte die Dekompression eher wie eine freie Rede unter Zuhilfenahme eines Stichpunktzettels (das Komprimat) ablaufen. Es läuft also auf eine Entwicklung einer partiell begabten künstlichen Intelligenz hinaus, die den Kontext es Stichpunktzettels richtig zu deuten weiß.

In einer solchen Liga spielen die handelsüblichen Programme  natürlich nicht.

Messungen

Ich habe das Testfile des Hutter Prizes als Grundlage eigener Messungen genommen. Es entspricht in etwa den Datenbank-Dumps oder den Webseiten typischer CMS-Syteme und damit einem unserer Backup-Szenarien.

Gemessen wurden:

  • Kompressionsrate als Anteil der Dateneinsparung. 20% heißt also die 100MByte Datei ist 20% (20MByte) kleiner, die komprimierte Datei hat also 80Mbyte. Größer sind besser.
  • Die Zeit zum Komprimieren ist vor allem eine praktische Eigenschaft. Schnelle Algorithmen belasten das System weniger. Kleiner ist besser.
  • Speicherbedarf beim Komprimieren ist analog. Insbesondere sollte vermieden werden, dass die Maschine swappen muss. Kleiner ist besser.
  • Die Zeit zum Entpacken ist im Recovery-Fall wichtig. Wenn man an Backups ran muss, ist der Zeitdruck meist schon groß. Wenn man dann noch auf's entpacken warten muss, kann das die Nerven völlig zerrütten. Kleiner ist besser.
  • Speicherbedarf beim Entpacken ist analog. Ausgepackt wird im Notfall auf stark belasteten Maschinen evtl. sogar parallel. Kleiner ist besser.

zstd läuft hier in zwei Modi: Einmal mit extra Dictionary (-D) und einmal normal. Das Dictionary wurde mit einer Auswahl einiger tausend page-Elemente aus der Originaldatei trainiert. Auf welche Art und mit wie vielen Elementen trainiert wird, macht keinen praktischen Unterschied.

Die Kompressionsoptionen laufen von 1 (schneller) bis zu hohen Werten (kompakter). Die Optionen sind nicht vollständig angegeben.

Programm Rate Zeit (comp) MB (comp) Zeit (decomp) MB (decomp)
gzip -1 58% 2,64 3 1,13 3
gzip -9 64% 8,14 5 1,02 3
bzip2 -1 67% 12,24 5 4,11 3
bzip2 -9 71% 12,86 27 4,91 16
zstd -3 64% 1,96 12 0,51 8
zstd -9 68% 9,51 45 0,64 12
zstd -19 72% 78,83 231 0,46 36
zstd -22 75% 126,17 2948 0,62 385
zstd -D 64% 2,12 16 0,48 9
zstd -D -9 68% 11,67 78 0,45 13
zstd -D -19 72% 81,88 426 0,45 37
zstd -D -22 75% 128,38 5508 0,63 386
xz 74% 98,70 376 2,40 36
xz -9 75% 125,93 2688 2,16 260
xz -9e 75% 134,20 2688 2,47 260
Shannon 88%  
sha256   0,44  
sha1   0,21  

Zum Vergleich habe ich die theoretische Grenze und die Verarbeitung der Originaldatei mit zwei Hashverfahren hinzugenommen. Letzteres dient vor allem der Abschätzung, was so beim reinen Durchpumpen der Daten durch die CPU an Arbeit entsteht.

Auswertung

Zuerst zur Kompressionsrate:

image009

Alles über 70% ist großartig, über 60% ist gut. xz und zstd sind also prima, bzip2 kommt nahe ran. Auffällig ist, dass zstd einen großen Bereich an Kompressionsraten abdeckt.

Also schauen wir als nächstes auf die Laufzeiten.

image006

Hier sind die Unterschiede massiv. xz fällt jedoch in allen Varianten aus dem Rahmen.

Also mal nur eine Auswahl der praktisch relevanten Zeiten:

image008

Bei bzip2 überraschen die hohen Entpackzeiten.

Was kann die hohen Packzeiten verursacht haben? In erster Linie könnte die Maschine ins Swappen kommen, wenn der RAM Bedarf die Größe der Testmaschine übersteigt. Das ist tatsächlich ein praktisch relevanter Fall. Also schauen wir mal:

image010

Die Testmaschine hat 2GB RAM, was zum Packen von 100M eigentlich ausreichen sollte. Alles über 1GB ist schlicht indiskutabel. Über Zeiten braucht man da nicht mehr reden.

Auffällig ist, dass zstd mit einem extra Dictionary gar nicht gut fährt. Dieser Modus ist ganz offensichtlich ausschließlich für sehr kleine Dateien wir JSON-Objekte gedacht.

Schauen wir uns noch die relevanten Kandidaten an, die in der großen Übersicht ja gar nicht zu sehen waren. Alles unter 100MByte RAM ist nutzbar:

image007

gzip und bzip2 sind standardmäßig sparsam mit RAM, zstd greift schon gut zu.

Fazit

Ich glaube, dass ich mit zstd gut fahren werde. Die Kompressionsrate ist besser als bei gzip und bzip2, das Einpacken geht schnell und das Auspacken geht doppelt so schnell wie bei den Konkurrenten. Es packt so schnell aus, wie die Prüfsummenberechnung mit sha256 braucht. Das ist beachtlich.

Ich betreibe ja schon etwas länger eine eigne CA. Seit 1998 wechsle ich jährlich die Root-CA Schlüssel, die jeweils zwei Jahre gültig und so überlappend wirksam sind. Und natürlich habe ich dafür einen OCSP Responder selbst schreiben müssen, weil es die Idee erst seit 1999 gibt. Die aktuellen Vorfälle von LetsEncrypt demonstrieren, wie wichtig es ist, sich intensiv mit den Clients zu befassen.

Aufgabestellung

OSCP ist ein Protokoll, bei dem online bei der CA nachgefragt werden kann, ob ein bestimmtes Zertifikat noch gültig ist.

Vor OCSP hatten wir CRLs, also Listen von zurückgerufenen Zertifikaten.

Ich ziehe OSCP der CRL aus mehreren Gründen vor:

  • Eine CRL muss regelmäßig neu erstellt und übertragen werden.
  • Eine CRL muss sämtliche Rückrufe enthalten, während der Gültigkeit der CA-Schlüssel ausgestellt wurden.
  • Damit Clients mit einer (i.d.R. riesigen) CRL etwas anfangen können, müssen sie diese einige Stunden oder Tage cachen, bevor sie eine neue Liste übertragen. In der Zeit bekommen Sie von Zertifikatsrückrufen nichts mit.
  • OCSP ist live, d.h. die Reaktion auf einen Zertifikatsrückruf ist praktisch unmittelbar.
  • OCSP beantwortet nur die konkrete Frage, ob ein bestimmtes Zertifikat einer bestimmten CA jetzt gültig ist.
  • Die (kleine) OCSP-Antwort hat ebenfalls einen (kleineren) Timeout und kann solange gecached werden.
  • OCSP lässt sich seitens des Websservers zentralisieren und mit an die Clients ausliefern. Die Clients müssen dann nicht selbst bei der CA anfragen.

Das Protokoll sieht vor, dass der OCSP Dienst in der Anfrage gesagt bekommt, um welche Seriennummer des Zertifikat es geht und von welcher CA die ausgestellt wurde. Das ist wichtig, wenn man – wie ich – zwei CAs parallel betreibt.

Die Anfrage ist ein ASN.1-Binärblob und kann auf zwei verschiedene Arten gestellt werden:

  • Als POST-Request mit einem binären Blob als Payload.
  • Als GET-Request mit der BASE64-codierten Variante des Blobs.

So weit, so einfach.

Implementierung

Als ich damit anfing, war die einzige verfügbare Software openssl.

Anfangs habe ich diesen als Dienst einfach laufen lassen, aber das ging nicht lange gut.

  • Zum einen kann der Dienst nur mit einer CA arbeiten, ich musste also immer die Neuste nehmen.
  • Anfragen zu Bestandszertifikaten der alten CA wurden mit einem Kenn-ich-nicht-Fehler abgewiesen.
  • Die Software ist im Serverbetrieb instabil, sie dient eigentlich nur dem schnellen Test.

Mit der zunehmenden Validierung von Zertifikatsketten im Browser, wurden OCSP-Fehler zu einem ernsthaften Problem. Also musste es anders gelöst werden.

Als Server dient nun der normale Apache, der ein PHP-Script aufruft, das dann die OSCP Validierung durchführen kann.

<VirtualHost *:8888>
  ServerName ocsp.iks-jena.de
  AcceptPathInfo On
  AllowEncodedSlashes On
  RewriteEngine On
  RewriteRule .* /index.php [L]
</VirtualHost>

In den Zertifikaten wird als OCSP-URL //ocsp.iks-jena.de:8888/ angegeben. Das ist konsistent mit dem Betriebsmodus des openssl Servers.

Anfragen an die URL werden dem PHP-Script vorgeworfen, was für POST-Requests anstandslos klappt.

Problematisch sind die GET-Requests. Die schauen so aus:

"GET //MEMwQTA%2FMD0wOzAJBgUrDgMCGgUABBRFLlbvANe4EFL%2F%2Fg56rSJuL2puEQQULWVsPIwYJRoGyp0azlVnHz5%2FsOoCAgIf HTTP/1.1" 200 2081 "-" "Microsoft-CryptoAPI/6.3"
"GET /MGgwZjA/MD0wOzAJBgUrDgMCGgUABBQmq5X/jwfX2qs7ZfkkUfZHOvrMbAQU6DQvbfzWJ21xpLYn9t9RpDf4gY4CAgICoiMwITAfBgkrBgEFBQcwAQIEEgQQw9lx90TbtLT+H7mqNucYhg== HTTP/1.1" 200 2125 "-" "Mozilla/5.0 (X11; FreeBSD amd64; rv:53.0) Gecko/20100101 Firefox/53.0"

Es gibt aber auch beliebige Mischformen, bei denen der initale Slash doppelt oder einfach ist, die Slashes, Gleichheits- oder Pluszeichen im String literal da stehen oder urlencoded sind.

Es ist dabei nicht einmal sicher gestellt, das eine bestimmte Codierung konsequent eingehalten wird. Proxies neigen bspw. dazu, selbst einige Zeichen zu encodieren. Im Extemfall es sogar auftreten, dass auch normale Buchstaben encodiert werden.

Was tut nun der Apache?

  • Mit AcceptPathInfo regt er sich nicht darüber auf, dass die URL einen nicht existenten Pfad referenziert, denn eine Datei dieses Namens existiert ganz offensichtlich nicht.
  • Mit AllowEncodedSlashes weist der Apache encodierte Slashes nicht mehr ab, die er sonst für einen Angriff hält und die Bearbeitung verweigert.

Im PHP Script kann ich dann schauen, welche CA angefragt wurde und die passende OCSP Antwort für die jeweilige CA bereit stellen.

Das tut einfach schmerzfrei.

Slash me

Nun zur Frage, wie man mit führenden Slashes umgeht. Ab wann ist der Slash Bestandteil der Anfrage und bis wann ist er noch Ergebnis der Anfragekonstruktion der Software.

Die Software bekommt aus dem Zertifikat eine OCSP-URL und muss dort ihren Request anhängen. Einige Software benutzt dazu "%s/%s" und andere benutzt "%s%s". Für beide Varianten gibt es gute Gründe.

In meinem Fall hat die OCSP-URL aber keinen Pfad. Der URI-Standard gibt es aber nicht her, den abschließenden Slash wegzulassen, um das Ende des Hostnamens zu markieren. Also hat meine URL einen finalen syntaktischen Slash, der allerdings semantisch gar nicht existiert.

Eine anders konstruierte OCSP-URL könnte lauten http://ocsp.example:12345/ocsp.asp?req=. Hier soll offensichtlich kein Slash angefügt werden.

Noch anders wäre der Fall bei http://ocsp.example:54321/cgi-bin/ocsp.pl. Hier wird erwartet, dass der Slash literal (und nicht encoded) eingefügt wird, weil sonst das Script nicht gefunden werden kann.

Das eigentliche Problem liegt also darin begründet, dass der OCSP Standard leichtsinnig eine Codierung gewählt hat, die reservierte Zeichen im benutzten Protokoll generieren kann. Kurz gesagt: Die Norm ist fehlerhaft.

Aber sie ist draußen und wir müssen damit leben.

Die entscheidende Frage ist also, wie man entscheiden kann, wo die realen Daten anfangen. Dazu muss ins Protokoll geschaut werden.

Es liegt immer eine ASN.1 Seqzenz vor:

OCSPRequest     ::=     SEQUENCE {
 tbsRequest                  TBSRequest,
 optionalSignature   [0]     EXPLICIT Signature OPTIONAL
} 
TBSRequest      ::=     SEQUENCE {
 version             [0]     EXPLICIT Version DEFAULT v1,
 requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
 requestList                 SEQUENCE OF Request,
 requestExtensions   [2]     EXPLICIT Extensions OPTIONAL
}

Das erste ASN.1 Byte für diesen Anfang ist also 0x30 (SEQUENCE). Die Dekodierung eines Slashes aus Base64 heraus ist mindestens 0xfc.

Damit ist es unmöglich, dass ein Slash den Anfang eines base64 kodierten OSCP-Requests darstellen kann. Im Gegenteil, das erste Zeichen einer ASN.1 Sequenz in Base64 ist zwingend ein M (genau genommen kann der Base64 Teil nur mit MA bis MP anfangen.

Die praktische Lösung des Problems ist also einfach:

  • Man dekodiert alles, was nach URLEncode aussieht.
  • Man entfernt alle führenden Slashes.
  • Man dekodiert den Rest mit Base64.

Fazit

Alles, was man tun muss, ist ins Logfile schauen. Das Internet existiert nur wegen eines Grundsatzes: Be conservative in what you do, be liberal in what you accept from others.

Ich hatte gerade im Lab mit DirectAccess gespielt. Da bietet es sich an, auch mal zu schauen, was passiert, wenn DNSSEC dazu kommt. Das Ergebnis ist eine faustdicke Überraschung.

Neue Zone

Als ersten lege ich eine neue Zone sec.adatum.com mit DNSSEC an. Das ist einfach: Einfach an der Zone im Kontextmenü DNSSEC auswählen. Es bietet sich an, die Trust Anchors innerhalb der Domain gleich mit zu verteilen.

Diese Zone bekommt einen WWW Eintrag, der auf den Webserver im Lab verweist. Und das tut dann auch.

Die Antwort besteht aus drei Teilen:

PS dns> Resolve-DnsName -DnssecOk -Name www.sec.adatum.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.sec.adatum.com             CNAME  3600  Answer     www.adatum.com

Name        : www.sec.adatum.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : CNAME
Algorithm   : 8
LabelCount  : 4
OriginalTtl : 3600
Expiration  : 5/19/2017 3:41:34 PM
Signed      : 5/19/2017 8:41:34 AM
Signer      : sec.adatum.com
Signature   : {39, 75, 194, 190...}

Name       : www.adatum.com
QueryType  : A
TTL        : 3600
Section    : Answer
IP4Address : 172.16.0.10

Auch auf dem Client, der irgendwo remote steht, tut es anstandslos. Hier gibt es aber nur zwei Teile in der Antwort:

PS client>  Resolve-DnsName -DnssecOk -Name www.sec.adatum.com

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.sec.adatum.com             CNAME  600   Answer     www.adatum.com

Name       : www.adatum.com
QueryType  : AAAA
TTL        : 600
Section    : Answer
IP6Address : fd68:d6bf:56b6:7777::ac10:a

Man sieht schön die Wirkung von DNS64 und das Ergebnis überzeugt:

Pinging www.adatum.com [fd68:d6bf:56b6:7777::ac10:a] with 32 bytes of data:
Reply from fd68:d6bf:56b6:7777::ac10:a: time=1ms
Reply from fd68:d6bf:56b6:7777::ac10:a: time=1ms

Allerdings wurde keine DNSSEC Validierung durchgeführt, wie man an dem Fehlen der RRSIG Antwort bemerkt haben könnte.

Validierung

Die Validierung von DNSSEC kann man per Gruppenrichtlinie erzwingen.

Technisch gesehen wird hier per Policy Based DNS, die Validierung pro Domain eingefordert. Die Trust-Anchors wurden ja schon verteilt.

Nach Verteilung der Gruppenrichtlinie auf den Client stellt sich die Situation ganz anders dar:

PS client>  Resolve-DnsName -DnssecOk -Name www.sec.adatum.com
Resolve-DnsName : www.sec.adatum.com : Unsecured DNS packet

Konsequenterweise funktioniert dann auch nichts mehr:

C:\> ping www.sec.adatum.com
Ping request could not find host www.sec.adatum.com. Please check the name and try again.

DNSSEC hat also erfolgreich DNS64 erkannt und die Modifikation verhindert!

Und IPv6?

Nehmen wir einen IPv6 Host im lokalen Netz an:

PS dns> Resolve-DnsName -DnssecOk -Name test.sec.adatum.com -type aaaa

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
test.sec.adatum.com                            AAAA   3600  Answer     2001:db8::1

Name        : test.sec.adatum.com
QueryType   : RRSIG
TTL         : 3600
Section     : Answer
TypeCovered : AAAA
Algorithm   : 8
LabelCount  : 4
OriginalTtl : 3600
Expiration  : 5/19/2017 4:02:43 PM
Signed      : 5/19/2017 9:02:43 AM
Signer      : sec.adatum.com
Signature   : {162, 99, 191, 91...}

Die Antwort besteht aus zwei Teilen, dem AAAA und dem RRSIG. Das tut. Nun zur Sicherheit noch einen nicht existierenden Namen.

PS dns> Resolve-DnsName -DnssecOk -Name test3.sec.adatum.com
Resolve-DnsName : test3.sec.adatum.com : DNS name does not exist

Aber tut es auch auf dem Client? Schließlich muss ja keine Umschreibung durch DNS64 stattfinden.

PS client>  Resolve-DnsName -DnssecOk -Name test.sec.adatum.com

Huch? Das tut nicht? Es fehlt auch komplett eine Antwort! Ist das denn von DNSSEC bestätigt?

PS client>  Resolve-DnsName -DnssecOk -Name test3.sec.adatum.com
Resolve-DnsName : test3.sec.adatum.com : Unsecured DNS packet

Nein, der DirectAccess-Resolver macht DNSSEC kaputt.

Richtig kaputt.

Über DirectAccess hatte ich schon einiges erzählt, und natürlich auch ausprobiert. Was ich aber noch nie angesehen habe, war DirectAccess ohne IPv6 im inneren oder äußeren Netz, also total legacy. In der Schulung habe ich die Gelegenheit dazu und möchte die Ergebnisse nicht vorenthalten.

IPv4 only Lab

Nachdem der DirectAccess Client in die weite Welt verschwunden ist, und er voller Verzweiflung nach Hause telefoniert hat, bietet sich folgendes Bild.

C:\> ipconfig
Ethernet adapter Ethernet 2:
   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::a19f:cc85:1320:8c4%5
   IPv4 Address. . . . . . . . . . . : 131.107.0.2
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
Tunnel adapter iphttpsinterface:
   Connection-specific DNS Suffix  . :
   IPv6 Address. . . . . . . . . . . : 2002:836b:c8:1000:1934:30a2:9e84:cdf4
   Temporary IPv6 Address. . . . . . : 2002:836b:c8:1000:f037:3b8d:cabc:bfcb
   Link-local IPv6 Address . . . . . : fe80::1934:30a2:9e84:cdf4%24
   Default Gateway . . . . . . . . . :

Es gibt also ein Interface im Internet mit öffentlichen Adressen ohne IPv6 Versorgung. Und dann gibt es den Tunnel nach Hause. Da sowohl Client als auch der DirectAccess Server öffentliche IPs haben, wurde der Tunnel mit 6to4-Adressen aufgebaut.

In den Schulungsunterlagen steht Notice the IP address for Tunnel Adapter is IPHTTPSInterface starting with 2002. This is an IP-HTTPS address. (Fehler sind so übernommen)

Nein, Microsoft! Es ist eine 6to4 Adresse. Offenbar habt Ihr wirklich keine praktische Erfahrungen mit IPv6.

Die zugehörige Routingtabelle zeigt:

c:\> route print -6
===========================================================================
Interface List
  5...00 15 5d 64 4d 4d ......Microsoft Hyper-V Network Adapter #2
  1...........................Software Loopback Interface 1
 24...00 00 00 00 00 00 00 e0 iphttpsinterface
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  1    331 ::1/128                  On-link
 24   4171 2002::/16                fe80::d92f:34d4:3add:e715
 24    331 2002:836b:c8::/48        fe80::d92f:34d4:3add:e715
 24    331 2002:836b:c8::/64        fe80::d92f:34d4:3add:e715
 24    331 2002:836b:c8:1::/64      fe80::d92f:34d4:3add:e715
 24    331 2002:836b:c8:5::/64      fe80::d92f:34d4:3add:e715
 24    331 2002:836b:c8:1000::/64   On-link
 24    331 2002:836b:c8:1000:1934:30a2:9e84:cdf4/128
                                    On-link
 24    331 2002:836b:c8:1000:f037:3b8d:cabc:bfcb/128
                                    On-link
 24    331 fd68:d6bf:56b6:7777::/96 fe80::d92f:34d4:3add:e715
  5    271 fe80::/64                On-link
 24    331 fe80::/64                On-link
 24    331 fe80::1934:30a2:9e84:cdf4/128
                                    On-link
  5    271 fe80::a19f:cc85:1320:8c4/128
                                    On-link
  1    331 ff00::/8                 On-link
  5    271 ff00::/8                 On-link
 24    331 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Das Routingziel ist eine Link-Local-Adresse, wie es sich für IPv6 gehört. Prima! Und die Adresse ist auch über den Tunnel erreichbar.

C:\>netsh int ipv6 sho nei 24
Internet Address                              Physical Address   Type
--------------------------------------------  -----------------  -----------
2002:836b:c8:1000:d92f:34d4:3add:e715                            Reachable (Router)
fe80::d92f:34d4:3add:e715                                        Reachable (Router)

Spielt man nun mit Browser und Explorer im Netz rum, gibt es offene Verbindungen:

C:\> netstat -n
Active Connections
  Proto  Local Address          Foreign Address        State
  TCP    131.107.0.2:49782      131.107.0.200:443      ESTABLISHED
  TCP    [2002:836b:c8:1000:f037:3b8d:cabc:bfcb]:49785  [fd68:d6bf:56b6:7777::ac10:c8]:80  ESTABLISHED
  TCP    [2002:836b:c8:1000:f037:3b8d:cabc:bfcb]:61893  [fd68:d6bf:56b6:7777::ac10:b]:80  ESTABLISHED

Die Verbindungen sind also offenbar über IPv6 zu einem ULA-Ziel (bäh!).

Das DirectAccess-Gateway macht noch NAT64, bettet also die IPv4 Adressen der LAN-Geräte ins IPv6 ein. Sieht man deutlich.

Dazu muss das Gateway offenbar auch DNS64 machen, um die DNS Antworten umzubiegen. Das sieht man leicht:

c:\>ipconfig /displaydns
Windows IP Configuration
    directaccess-webprobehost.adatum.com
    ----------------------------------------
    Record Name . . . . . : directaccess-WebProbeHost.Adatum.com
    Record Type . . . . . : 28
    Time To Live  . . . . : 213
    Data Length . . . . . : 16
    Section . . . . . . . : Answer
    AAAA Record . . . . . : fd68:d6bf:56b6:7777::ac10:c8

Aber warum macht der Client das? Der hat doch einen ganz anderen DNS Server?

C:\>netsh name show eff
DNS Effective Name Resolution Policy Table Settings

Settings for .Adatum.com
----------------------------------------------------------------------
DirectAccess (Certification Authority)  :
DirectAccess (IPsec)                    : disabled
DirectAccess (DNS Servers)              : 2002:836b:c8:3333::1
DirectAccess (Proxy Settings)           : Bypass Proxy

Settings for DirectAccess-NLS.Adatum.com
----------------------------------------------------------------------
DirectAccess (Certification Authority)  :
DirectAccess (IPsec)                    : disabled
DirectAccess (DNS Servers)              :
DirectAccess (Proxy Settings)           : Use default browser settings

Der Client hat also eine Policy für die Namensauflösung, die bei bestimmten Domains einen anderen DNS Server befragt. Genau, das Gateway.

C:\> ping lon-svr1.adatum.com
Pinging lon-svr1.adatum.com [fd68:d6bf:56b6:7777::ac10:b] with 32 bytes of data:
Reply from fd68:d6bf:56b6:7777::ac10:b: time=4ms
Reply from fd68:d6bf:56b6:7777::ac10:b: time=10ms
Reply from fd68:d6bf:56b6:7777::ac10:b: time=1ms
Ping statistics for fd68:d6bf:56b6:7777::ac10:b:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 10ms, Average = 5ms

Allerdings funktioniert das nur, wenn diese Policy Regeln auch von der Applikation berücksichtigt werden:

C:\> nslookup lon-svr1.adatum.com
Server:  UnKnown
Address:  131.107.0.100

DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

Fragt man den richtigen Server, gibt es ganz andere Antworten:

C:\> nslookup lon-svr1.adatum.com 2002:836b:c8:3333::1
Server:  UnKnown
Address:  2002:836b:c8:3333::1

Non-authoritative answer:
Name:    lon-svr1.adatum.com
Addresses:  fd68:d6bf:56b6:7777::ac10:b
          172.16.0.11

All das ist mir all die Jahre verborgen geblieben, weil ich IPv6 ausgerollt hatte.

Ich vermisse nichts.

Was IPv6 ändert

Wird auf dem Außeninterface natives IPv6 eingesetzt, verschwinden sofort die 2002-er 6to4 Adressen. Dazu ist anzumerken:

  • Das im Lab die Kommunikation geklappt hatte, liegt daran, dass Microsoft das 2002:836b:c8:1000::/64 auf dem Interface betreibt.
  • Um mit 6to4 Adressen zu kommunizieren, muss man sich auf externe 6to4 Gateways verlassen. Dies kommt ins Spiel, weil der DNS Server 2002:836b:c8:3333::1 angesprochen wird.
  • Da beide Hosts über den IPv4-HTTPS-Tunnel IPv6 im externen Routing komplett umgehen, benötigen sie keine 6to4 Router im Internet.
  • Da beide Server extern öffentliche IPv4 Adressen haben, wird überhaupt 6to4 benutzt. Steht ein Gerät hinter NAT wird es auf Teredo zurück fallen.
  • Teredo funktioniert nicht mit allen NAT-Typen, speziell gibt es Probleme, wenn die öffentliche NAT-IP nicht stabil ist (z.B. bei Carrier Grade NAT oder Large Scale NAT)
  • Mit RFC 6540 ist IPv6 auf den Außeninterfaces Pflicht für die ISPs.

Wird IPv6 im LAN eingesetzt, verschwindet sofort das fc00::/7 ULA Netz. Stattdessen bekommen die Clients die gleiche IP, wie sie auch im LAN hätten. Das hat folgende Implikationen:

  • Der Client ist intern, wie extern unter der gleichen IP ansprechbar.
  • Die Fernwartung wird damit im Unternehmen unabhängig vom Aufenthaltsort des Clients.
  • Da Server und Clients IPv6 einsetzen, entfällt DNS64 und NAT64.
  • Applikationen können mit allen benötigten Ports Verbindungen in alle benötigten Richtungen ausführen. Es ist nicht notwendig im DirectAccess-Server NAT-Helper pro Protokoll zu haben.
  • Auf diese Weise funktionieren Protokolle wie Telefonie, Videokonferenzen, FTP, etc. pp. einfach auch extern.
  • Fremdapplikationen, die ihre eigene Namensauflösung fahren, funktionieren problemlos, weil sich nur das Routing zum DNS Server ändert. Es ist nicht länger notwendig, sich Domainabhängig an unterschiedliche DNS Server zu wenden.

Man sollte sich also wirklich überlegen, ob man weiter auf IPv6 verzichten will.