CH Internet Szene

von Fredy Künzler



NANOG #45 ist zwar bereits Geschichte, trotzdem gibt es noch einige erwähnenswerte Präsentationen respektive Themen dieser Konferenz, auf die ich meine geschätzte Leserschaft gerne hinweisen möchte. Eine davon ist von den Kollegen bei Renesys. Sie analysierten im Detail die Routingtabellen während des hier auch notierten Sprint (AS1239) vs. Cogent (AS174) Depeering und ziehen eine Lehre daraus, nämlich die der sogenannten Captive ASN resp. Captive Prefixes - also der "gefangenen" Netze.

Als Kunde mit einem multihomed Netzwerk ist es sinnvoll zu überprüfen, welche sogenannten Tier-1 Transits der Provider hat. Als Beispiel wird auf Seite 12 der Präsentation AS40844 (Winn-Dixie Stores, Inc.) angeführt. Das Netz ist zwar multihomed hinter AS7018 (AT&T) und AS6389 (BellSouth.net), da aber BellSouth als Tocherfirma von AT&T ausschliesslich von AS7018 Transit hat, entspricht das sozusagen einem einzigen Provider. Hätte AT&T ein ähnlicher Knatsch wie Sprint und Cogent vor einigen Monaten, wäre für AS40844 in der Zeit des Depeerings nicht mehr das ganze Internet sichtbar. Genau dieser Effekt hatten nicht bloss eine Handvoll Netze, deshalb ist es ratsam, seine Upstreams sorgfältig auszuwählen.

Eine Sidenote: in der Präsentation sind alle Netze gelistet, die der "Default Free Zone" angehören. Also alle Netze, die sogenannte Tier-1 Carrier sind. Ich mag den Begriff Tier-1 nicht sonderlich, weil es aus technischer Sicht nicht relevant ist, ob ein Carrier mit allen anderen Tier-1 nur Settlement-Free-Peering hat, oder für manche Interkonnektionen auch gezahlt wird, was dann nicht mehr als "Tier-1" gelten würde. Deshalb ist Default-Free oder Transit-Free ein viel besserer Begriff, weil ein Peering ein Peering bleibt, unabhängig von den kommerziellen Abmachungen. Und hier ist diese Liste der Default-Free Netzen, die Renesys aus den Routing-Daten errechnet hat:

The Default-Free Zone (DFZ)

AS174 Cogent
AS209 Qwest
AS293* Energy Sciences Network
AS701 Verizon
AS1239 Sprint
AS1299 TeliaSonera
AS2828 XO
AS2914 NTT
AS3356 Level 3
AS3549 Global Crossing
AS6453 Tata Communications
AS6461 Abovenet
AS7018 AT&T

(* AS293 peers with all members of the DFZ, but is not a player in the commercial space)

von Fredy Künzler

Dieses Thema wollte ich seit dem SwiNOG #17 Meeting aufnehmen, doch wurde es durch Aktualität oder Zeitmangel immer wieder verschoben.

Blenden wir zurück: vor gut zwei Jahren gab es die Kampagne "Stopp Kinderpornografie im Internet!", getragen von Schweizerischen Kriminalprävention SKPPSC und dem Kinderschutz Schweiz. Ich hatte mich damals ausführlich dazu geäussert, warum die Aktion nicht fertig gedacht war und nicht wirklich funktionieren kann. Etwas später kam es dann die hässliche Kehrseite in den Medien - der Schuss ging hinten raus. Und auch Politiker wie der FDP-Ständerat Rolf Schweiger machten auf Kosten missbrauchter Kinder billigen Wahlkampf.

KOBIK, die Koordinationsstelle zur Bekämpfung der Internetkriminalität, stellte am SwiNOG #14 Meeting das Projekt "DNS Blockade" vor, doch die Community der ISP Techniker lehnte das Ansinnen aus technischen Überlegungen grossmehrheitlich ab. Die vorgesehenen Fake-DNS Einträge funktionieren nicht wirklich: Einschlägige URLs werden auf den DNS-Servern des Access-Providers übersteuert, und der Surfer wird statt auf den illegalen Inhalt auf eine Warnseite umgeleitet. Umgehen kann man diese "Sperre" ganz einfach - man benutzt einfach unzensurierte DNS Server, die zu hunderten im Netz verfügbar sind.

Auch die Blockierung auf IP Ebene ist nicht wirklich das gelbe vom Ei: Zwar effektiv, verursacht aber grosser Kollateralschaden. Auf einem Server mit einer IP Adresse sind typischerweise Dutzende oder gar Hunderte von Websites gehostet. Die Sperrung der IP-Adresse eines Servers mit KiPo-Inhalt sperrt unter Umständen weitere harmlose und ehrbare Websites, die zufällig auf dem selben Server gehostet sind.

Vom politischen Rummel um die Frage der Kinderpornografie unbeeindruckt entwickelten die Kollegen von Practeo eine Lösung, die alle technischen Mängel der ursprünglichen Ideen Fake-DNS und IP-Sperrung eliminiert. Sie nennt sich "Netclean Whitebox":

Netclean Whitebox basiert auf automatischen BGP4-Updates, damit entfällt das manuelle Einpflegen der aktualisierten Sperrliste beim Serviceprovider. Gemäss KOBIK-Vorschlag wäre die "schwarze Liste" nur alle paar Wochen aktualisiert worden, was natürlich kaum im Sinne des Erfinders ist.

Netclean Whitebox funktioniert zweistufig: 1. wird via BGP4 die Liste der verdächtigen IP Adressen in die Routingtabelle eingepflegt. Derzeit sind das um die 450 IP Adressen. Traffic von diesen Websites wird auf die Whitebox umgeleitet. Auf dieser erfolgt 2. die DNS resp. HTTP Inspection, und die Whitebox ist damit in der Lage, zwischen illegalem und harmlosen Inhalt zu unterscheiden, der sich zufällig an der selben IP Adresse befindet.

Wäre bei jedem Accessprovider eine oder mehere solcher Whiteboxen installiert, könnten diese zentral durch die KOBIK administriert werden, und das real-time. Wenn immer irgendwo in der weiten Welt eine Site mit KiPo Inhalt auftaucht, könnte KOBIK auf Knopfdruck den Inhalt sperren. Die ISP wären von fragwürdiger Zensurarbeit entlastet, und anstelle von periodischen Updates alle paar Wochen arbeitet das System zeitnah.

Weil nur der Traffic zu fragwürdigen Adressen via Whitebox "gewaschen" wird, kommt das System auch mit grossen Trafficmengen klar. Die laufende Testinstallation bei einem Schweizer Accessprovider zeigt, dass via Whitebox bloss einige Dutzen Kilobit pro Sekunde geleitet werden, während der restliche "saubere" Traffic von 900 mbps unbehelligt am System vorbeigeschleust wird. Damit sind Fragen zur Performance hinfällig:



Natürlich kostet Netclean Whitebox etwas. Pro Million Benutzer werden ca. 150'000 Franken pro Jahr fällig. Das ist vergleichsweise günstig, doch der erste Gedanke, dass der ISP dafür aufkommen soll, greift zu kurz. Schäbige Szenarien sind dann nämlich denkbar: ISP X wirbt "wir sind sauber - kein KiPo dank Netclean Whitebox" und ISP Y wirbt mit "keine Zensur, wir lassen Sie alles sehen". Das ist nicht was wir wollen, und zudem bin ich auch der Meinung, dass nicht ISPs für eine gesellschaftliches Problematik aufkommen soll.

Vielmehr möchte ich hier anregen, dass die KOBIK das System für alle Schweizer Internetbenutzer beschafft und es zentral administriert. Ich kann selbstverständlich nicht für alle ISPs reden, aber einer Implementation steht meines Erachtens aus technischer Sicht nichts im Wege. Die politischen, ethischen und gesellschaftlichen Fragen zur Problematik lassen wir einfach mal offen.

von Fredy Künzler

Die De-Peering-Übung dauerte bis Sonntagabend (resp. Sonntagnachmittag, US Lokalzeit), dann wurden die Netze von Cogent (AS174) und Sprint (AS1239) wieder zusammengeschaltet. Offenbar war der Druck auf Sprint zu gross, als dass sie sich weiterhin ein zweigeteiltes Internet leisten konnten. Immerhin hat Cogent klar den schwarzen Peter auf Sprint geschoben. Diese veröffentlichten ein hastig zusammengestiefeltes Statement und versuchten ihre Sicht der Dinge darzulegen.

Renesys analysierte die Routing-Tabelle vor und nach dem Re-Peering:

[...] Previously, we saw Sprint selecting 2700-2900 prefixes from Cogent (that is, picking Cogent as the best path for that many network prefixes). We saw Cogent selecting about 7500-8000 prefixes from Sprint. Now that they have reconnected, Sprint is selecting 2538 prefixes from Cogent and Cogent is selecting 7016 from Sprint. [...]

Vermutlich ist das einer der spannenderen De-Peering Fälle der Geschichte:

The fact that Sprint has reconnected this indicates clearly that they intend to fight this battle in court rather than in the routing tables or in the court of public opinion. This fact alone makes this likely to be one of the more interesting peering disputes of the last few years. [...]

von Fredy Künzler

Die De-Peering History von Cogent ist um ein weiteres Kapitel reicher: seit gestern ca. 22:00 Uhr GMT sind die Interkonnektionen von Cogent (AS174) und Sprint (AS1239) unterbrochen. Cogent veröffentlichte ein Presserelease, in dem alle Schuld auf Sprint geschoben wird.

In den Fachblogs wird das neueste De-Peering, in dem Cogent involviert ist, freiliche differenzierter betrachtet. GigaOM zitiert Cogent:

“It is no longer possible for many Sprint customers and Cogent customers to directly communicate across the Internet,” Cogent said, and alleged that Sprint was in “violation of a contractual obligation to exchange Internet traffic with Cogent on a settlement free peering basis.” The two companies are in litigation over the issue.

Telecom Ramblings schreibt dazu:

So what prompted this war? Cogent usually makes the case that their opponent has been offended by their low pricing and is retaliating by breaking contractual agreements and such. Their opponents usually make the case that Cogent’s traffic ratios are off and that Cogent is misusing peering to get a free ride. But really, none of this matters because peering agreements are voluntary. They are determined by two things: 1) relative economic benefit, and 2) power. Peering wars generally mean that one side wants to change the first because they think they have the second.

Der Zufall (respektive die Liste der dort verfügbaren Provider) will es, dass das Office in Ann Arbor meines Ex-Arbeitgebers Zattoo multihomed zwischen Cogent und Sprint ist, und ich habe deshalb um ein "show ip bgp summary" gebeten (danke Dirt!):

router-to-cogent#show ip bgp summary

Neighbor   V    AS  MsgRcvd  MsgSent  TblVer  InQ  OutQ  Up/Down  State/PfxRcd

x.x.x.x   4    174  1146085   162373  322118     0    0  16w0d    258562

router-to-sprint#show ip bgp summary

Neighbor   V    AS  MsgRcvd  MsgSent  TblVer  InQ  OutQ  Up/Down  State/PfxRcd

x.x.x.x   4   1239   534460   162369  568050    0     0  7w6d     263188

Zum Vergleich die Grösse der Routing-Tabelle von Init7 (Quelle: Looking Glass):

init7-lg#show ip bgp summary

Neighbor   V    AS  MsgRcvd  MsgSent  TblVer  InQ  OutQ  Up/Down  State/PfxRcd

x.x.x.x    4 13030   151313      572       0    0     0 09:29:21  266129

Die Frage ist also, ob Cogent oder Sprint mehr unter dem De-Peering leidet. Basiert auf der Auswertung der Routing-Tabelle könnte man vermuten, dass Cogent mehr Ärger hat, in deren Routingtabelle scheinen mehr Prefixe zu fehlen. Die vergangenen Peering Disputes haben Cogent-Kunden sensibilisiert, und sie werden sich wohl kaum mehr ausschliesslich auf Cogent verlassen. Damit findet Sprint die meisten Cogent-Kunden über einen alternativen Pfad ... doch das sagt noch nichts über die "Kundenbefindlichkeit" aus. Fiktives Beispiel: eine populäre Applikation wie Facebook, exklusiv gehostet im Netz von Cogent, würde natürlich viel mehr Druck auf Sprint ausüben, weil deren Kunden nicht mehr zugreifen könnten, während Cogent-only Kunden vom De-Peering nichts wahrnehmen würden. Oder umgekehrt.

Wie üblich haben die Kollegen von Renesys eine umfassende Analyse des Cogent vs. Sprint Peering Knatsch geschrieben.

von Fredy Künzler

Über die Endlichkeit der 16-Bit AS Nummern (Autonome Systemnummern) habe ich hier schon zweimal geschrieben. Je nach Prognose ist der Vorrat an ASN bis ca. 2010 erschöpft, und das würde bedeuten, dass niemand mehr multihomen könnte.

Dass sich etwas tun muss, war der Internet Community eigentlich schon länger klar, doch was und bis wann, darüber konnte man sich trefflich streiten. Doch seit einigen Monaten geht was. RIPE beispielsweise gibt seit neuestem 32-Bit AS Nummern aus. Diese sind aus dem Range AS3.0 - AS3.1023. Theoretisch könnte man von AS 0.0 bis AS 65535.65535 ausgeben, was schätzungsweise bis zum Ende dieses Planeten und darüber hinaus reichen sollte.

Hauptproblem ist die notwendige Umstellung. Alle BGP fähigen Router müssen global mit neuer Software bestückt werden - die es übrigens noch von keinem Hersteller als 'stable release' gibt: weder der C, der J oder der F Vendor kann schon Pfade à la

^13030_6695_3.2$

in einer produktiven Umgebung verarbeiten. Die Open-Source Projekte Quagga und OpenBGPd sind da weiter: für Quagga gibt es einen 32-Bit ASN Patch, ebenso für OpenBGPd. Doch mehr und grössere Tabellen und umfangreichere Software ruft unweigerlich auch nach besserer Hardware.

Ältere Router werden durch diese neuen Software Releases hoffnungslos überfordert sein. Das überall eingesetzte Arbeitspferd 7206VXR mit NPE-300 kann nur bis 256Mbyte Memory adressieren, und ohne Tricks (memory-size iomem xy) läuft dieses Gerät bereits heute nicht mehr mit einer vollen BGP Tabelle. Der je nachdem frühzeitige Ersatz von Hardware dürfte nicht überall auf Gegenliebe stossen.

Wer mit dem Gedanken spielt, "irgendwann" mal zu multihomen (übrigens auch durch die Gartner Group empfohlen), soll nicht zu lange warten. Der Ausverkaufs-Rush auf die herkömmlichen 16-Bit ASN wird irgendwann einsetzen, und eine ASN 3.45678 kann - zumindest in den ersten Jahren der 32-Bit Ära - zu Problemen führen. Deshalb sprechen Sie besser bald einmal mit dem Provider ihres Vertrauens.

Mehr Infos zur 32-Bit ASN Problematik gibt es übrigens in dieser RIPE Präsentation.