Vom 31.10.2011 bis 04.11.2011 trafen sich 465 Teilnehmer zum bisher größten RIPE Meeting in Wien, an dem für uns Carsten Schiefner teilnahm. Zur Teilnehmerliste: http://ripe63.ripe.net/attendee-list/
Zwei Themen standen eindeutig im Vordergrund: die Diskussion um DNS-Filterung und -Blockierung und um den RPKI-Dienst (Resource Public Key Infrastructure).
1. DNS-Filterung und -Blockierung am Beispiel des neuen BIND-F[ault|eature]s „RPZ“ (Response Policy Zones)
Die überwiegende Mehrheit der Teilnehmer war der Meinung, dass DNS-Filterung und -Blockierung wegen seiner Ineffektivität abzulehnen sei. Außerdem wurde gefragt, ob es aus politischen und gesellschaftlichen Gründen wünschenswert sei, das lange geforderte und gerade in der Ausroll-Phase befindliche DNSSEC zu konterkarieren, da sich die letzte BIND-Version mit den „Response Policy Zones“ und DNSSEC quasi gegenseitig ausschließen.
Siehe auch: http://www.heise.de/netze/meldung/BIND-Entwickler-macht-sich-mit-DNS-Filtern-unbeliebt-1379457.html
ISC, die Entwicklerfirma hinter BIND, argumentierte, dass viele Kunden eine DNS-Filterung wünschen und deswegen eigene Patches entwickeln und veröffentlichen. Dies sei aber im Interesse der BIND-Stabilität besser zu vermeiden, da viele dieser Patches den Test- und Qualitätskriterien von ISC nicht standhielten.
2. Der RPKI-Dienst (Resource Public Key Infrastructure)
Resource Public Key Infrastructure (RPKI), also known as Resource Certification, is a specialized public key infrastructure (PKI) framework designed to secure the Internet’s routing infrastructure, specifically the Border Gateway Protocol (BGP). RPKI provides a way to connect Internet number resource information (such as Autonomous System numbers and IP Addresses) to a trust anchor. The certificate structure mirrors the way in which Internet number resources are distributed. That is, resources are initially distributed by the IANA to the Regional Internet Registries (RIRs), who in turn distribute them to Local Internet Registries (LIRs), who then distribute the resources to their customers. RPKI can be used by the legitimate holders of the resources to control the operation of Internet routing protocols to prevent route hijacking and other attacks.
Quelle: https://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure
Es wurde angemerkt, dass das System das globale IP-Routing durch signierte Announcements sicherer machen würde. Ein vollständiges Verlassen auf dieses System im Sinne einer Automatisierung würde das globale IP-Routing aber in eine direkte Abhängigkeit von der Gültigkeit der verwendeten Zertifikate bringen. Werden die Zertifikate entzogen, z.B. aufgrund einer einstweiligen Verfügung, werden die Announcements des betroffenen Providers von allen anderen Providern, die RPKI verwenden, nicht mehr akzeptiert.
Die RIPE-Community hat hier ein klares Signal gesetzt, dass sie die Diskussion um den Einsatz von RPKI und dessen Umsetzung noch nicht für beendet hält. Ein erster Policy-Vorschlag fand keinen Konsens und wurde schließlich zurückgezogen.
Im Gegensatz dazu wurde RIPE NCC von seinen Mitgliedern, den LIRs, per Beschluss mandatiert, die RPKI-Aktivitäten weiter voranzutreiben. Dies führt erstmalig zu der unkomfortablen Situation, dass eine RIPE-NCC-Aktivität nicht durch eine Policy, entwickelt durch Community-Konsens, abgedeckt ist. Die weiteren Auswirkungen auf den Policy-Entwicklungsprozess insgesamt bleiben abzuwarten.
Mehr Infos über den RPKI-Dienst, den RIPE NCC seinen Mitgliedern, den LIRs (Local Internet Registries), anbietet:
https://www.ripe.net/lir-services/resource-management/certification/
3. Was war sonst noch berichtenswert?
- Die Einführung von IPv6 verläuft langsamer als gewünscht: viele Provider scheinen mehr in die Verlängerung der IPv4-Nutzung zu investieren als in die Überführung ihrer Infrastruktur zu IPv6
- Erstmalig wurde die vorgeschlagene Beitragsstruktur durch die RIPE-NCC-Mitglieder abgelehnt; es gilt somit weiterhin die bisherige Beitragsregelung.
Hier finden Sie den Tagungsbericht des RIPE NCC:
http://ripe63.ripe.net/programme/report/