Göran Marby var på plats och presenterade sig själv och sitt uppdrag på ICANN. Pratade gärna med RIPE-deltagarna om vad Göran ska göra på ICANN.
Rekordhögt deltagande på RIPE-mötet, över 600 deltagare.
TDC har 55% av bredbandsmarknaden i Danmark, och har kontor i hela Norden.
Stockholm är nordens "Interconnection Hub", alla peerar där, inkl ryssarna. Köpenhamn är "The Gateway to the Nordics", resten av Europa ansluter dit för access mot Norden. Helsingfors är "The Gateway to the East", Ryssland, Kina och de baltiska staterna. Island har billig el ("gratis") och kylning, men har dyr konnektivitet.
TDC:s huvudsakliga stomnät är triangeln mellan Olso, Stockholm och Köpenhamn. Köpenhamn har dock en stor sårbarhet med en stor samling kablar inom en 5km area. Helsingfors jobbar på att komma förbi Stockholm genom direktfiber ner till Rostock.
IXP:ar i Köpenhamn, COMIX från Netnod, ansluter ca 40 nät. (Fun fact, 40% av svenskarna bor närmare Köpenhamn än Stockholm.) DIX körs av Technical University och andluter 44 nät. Netnod ökar i storlek, kör ~55G och DIX är stabil/minskar och kör ca ~77G trafik.
IXP:ar i Sverige är Netnod, Netnod och Netnod, samt STHIX.
IXP:ar i Norge är NIX1 och NIX2, båda i Oslo. Det finns mindre knutpunkter i Bergen, Trondheim, Stavanger och Tromsø, men de är bara relevanta för lokala operatörer.
Tidigare var brevduvorna snabbare på att leverera data än ISP:erna i Afrika. (Tester utförda med brevduvan Winston.) Sydafrikas största ISP Telkom numera kända under namnet Openserver har äntligen öppnat upp och är reda att peera med andra.
Afrika är en ung marknad för IXP, med 54 länder så har de 34:a IXP:er i 26 länder. Äldska IXP:en startades 1996. Största IXP:n finns i Sydafrika och kör ca 96Gbps trafik nu. AF-IX Association grundades 2013.
Affärsmodellerna länderna emellan skiljer sig mycket. Avgifterna för en port är relativt höga, och man säljer fortfarande 10Mbit-portar.
Den mesta av internettrafiken i Afrika går till Europa och USA, och mycket av den interna trafiken i USA går också den dyra vägen via Europa pga bristande peering. Priserna för transit är också väldigt höga.
Kommande "Hotspots" är Tanzania, Elfenbenskusten, Ghana och Niguera, de har bra anslutningar och kommer att ha bra fungerande marknader så länge de har bra tillgång till elkraft. Men just nu är Johannesburg, Lagos och Kapstaden topp tre platser att bygga på.
Vad ska man se upp för? Korruption, dålig kvalitet på konstruktioner (byggnader), multinationella företag är riktigt långsamma, politisk instabilitet, valutan kan vara instabil, olika standarder och infrastrukturen för elkraft. Nu byggs dock elkraften ut snabbt, då detta är ett starkt tillväxtområde.
Länderna närmast kusten har enklast att få bra anslutning mot internet, längre inåt land är det betydligt svårare. Men det hänger också ihop en del med den politiska korruption som också blir värre inåt kontinenten.
Niels ten Over och Shane Kerr har byggt en liten enkel hotspot för att enkelt dela ut internet till flyktingar (papperslösa m.fl.) på temporära boenden i Nederländerna. Projektet är sponsrat av SIDNfonds och ISOC-NL. COA, Centraal Orgaan opvang Asielzoekers är de som registrerar flyktingarna, COA policy bestämmer att flyktingarna ska ha tillgång till internet. Men de kan inte. Så projektet förser dessa ofta tillfälliga platserna med trådat och trådlöst internet.
Just nu är två centers anslutna, och processen fungerar. HacksHackers haf haft ett hackathon för att få igång detta projekt.
Kraven på utrustningen, tålig och portabel, ett minimum av konfiguration, delbart internet, rimliga förväntningar på säkerhet, informationssida, remote administration och relativt billig.
Raspberry Pi med python. Det har tagit längre tid att få det att fungera än väntat. Nu blir det lättare då RPi3 kommer med inbyggt wifi. En 3G-dongel drar med el än väntat.
Informationssidan är översatt till en massa språk för att underlätta för användarna.
Framtida förbättringar, bättre installations-script, betatesting med "We Are Here"-kollektivet, förpackning med De Waag Society, mer storskaligt testande med kollektiv i Hamburg, Berlin och Bryssel, och sedan resten av Europa.
Projektet behöver webbdesigners, betatestare, idéer och pull requests.
Varför DNSSEC? Bla bla. Möjliggör DANE och andra typer av PKI:er.
Nejsägare: "Det är svårt", det kommer att ha sönder saker, det löser ingenting, vi måste lita på ICANN/root-servrarna.
Pauls erfarenheter: automatisera annars blir det svårt, det hjälper mot cache-poisoning, vi använder redan DANE för e-post, vi litar redan på ICANN och root-servrarna, och kunder förväntar sig den säkerhet som DNSSEC ger.
Comcast ser en hel del validation-failures. De har implementerat NTA:s (Negative Trust Anchors, RFC 7646). De har strax under tio NTA varje månad. Vad de ser är mest signaturer som gått ut, och sedan i fallande ordning, inkorrekt borttagande av signering, omedveten signering och nyckelrullningar som gått fel.
Comcast har rullat ut både IPv6 och DNSSEC - vilket var svårast? IPv6 var något svårare, inte minst då hårdvaruleverantörerna är något mindre lyhörda för förbättringspotential...
DDoS ser ut att vara skolledigt-relaterat. Kunder börjar klaga när de får packet-loss. Gamers och VoIP är mest känsligt.
Var kommer trafiken från (vilka AS)? Är trafiken spoofad? Kan vi filtrera ut non-BCP38-trafik?
Tittar man på en knutpunkt finns det "bra" peers och "dåliga peers". Bra peers är sådana man normalt utbyter trafik med. När man får en DDoS är det peers man normalt inte utbyter trafik med som skickar mycket trafik.
Om man söker på Github finns det en hel del scripts för att generera DDoS-trafik, så att man kan se hur det fungerar... Genom Shodan kan man enkelt själv börja generera en rätt rejäl DDoS.
Med SFlow hos AMS-IX kan man se trafikflöden per peer. På trafikmönstren kan man lätt se vilka peers som är med i en DDoS. Genom en lista med "dåliga peers", kan man börja skicka skräptrafiken till andra portar:
- Lista alla AS som bara skickar trafik under en DDoS-attack
- Peera med dessa AS på en "skräp"-port på IX:en
"A simple include / exclude in RIPE RPLS was all it took"
Den vanliga trafiken flyter på som vanligt, DDoS-trafiken går då till en skräp-port och påverkar ingen. Kräver dock två AS-nummer.
Frågor ... varför finns visa AS-nummer på naughty-listan? Kan man förutse att någon hamnar där? Genom att skapa en databas med alla AS-nummer, och med metadata som antalet öppna resolvrar, NTP-serverar, SNMP osv per AS. Samt antalet annonserade prefix per AS från RIPE RIS API. En hög naughty-rating betyder inte att det är en dålig peer, men en ska den trafiken gå genom dina kvalitets-länkar? Är det här sättet att välja peers på "juste"?
En "naughty rating"-lista kan man publicera. A2B:s lista baseras i stort på hur stora möjligheterna att genomföra amplifikations-attacker genom tjänster i det AS:et.
Datat ska publiceras, man ska kunna mata in ett AS-nummer och få ut en rating och hur metadatat ser ut.
Hur kan man förbättra sin ranking? Implementera abuse.io (det är gratis och open source). Efterfråga rapporter från shadowserver.org.
Om man vill ha en egen "naughty-port" hos AMS-IX hjälper A2B gärna till, och delar med sig data. Allt man behöver är en extra AMS-IX-port och ett extra AS-nummer.
Vad kommer EU:s nätneutralitetsdirektiv säga om detta? Den här metoden påverkas inte av detta, annat än under DDoS-attacker. Också enligt EU-direktiv måste man agera vad gäller abuse.
Vad är Cryptech? En open source-HSM, en referensdesign.
Det finns ett stort bekymmer kring sårbarheter i viktig internetinfrastruktur, routers, servrar, brandväggar etc. HSM:er skyddar mycket av den viktigaste infrastrukturen.
Status: vi har fungerande alpha-brädor! All viktig funktionalitet ser ut att lira. Utvecklarna fortsätter att testa brädorna.
DNSSEC ska fungera först, sedan RPKI.
Community review, https://trac.cryptech.is/ - vi behöver hjälp med review, att testa, dokumentation, och att bygga produkter! Och Cryptech behöver finansiering.
A case study of hijacking millions of IP address invisibly...
Spamcop började rapportera om abuse från deras nät. Bytte datacenter för de IP-adresser som rapporterades. Spamcop-rapporterna borde inte komma alls nu. De trodde att deras IP-adresser hade hijackats.
Yahoo berättade att de sett x.x.x.x/18 i deras loggar. Outside Heaven annonserad dock bara x.x.x.x/12-16.
Yahoo hade fått peering i DE-CIX från ett dött AS. Vem var AS17445? Ett icke-existerande kinesiskt företag, som använt ett hijackat prefix. Använde också hijackat AS, och ett icke-delegerat AS. Men de var kund hos DE-CIX. De bytte AS-nummer direkt efter att ha blivit kund hos DE-CIX.
Summering: de blev kund hos IX, peerade direkt med en gratis mail-leverantör, sedan annonserade de hijackat prefix med hijackat AS, och nådde väldigt mycket mailservrar för att skicka spam...
Svårt att förhindra, svårt att identifiera, och det är svårt för en stor organisation att uppmärksamma detta med ett litet antal Spamcop-rapporter som underlag.
Hur åtgärdade Outside Heaven detta? Genom goda kontakter med både Yahoo och DE-CIX. Så åk på möten och skapa personliga kontakter!
APNIC samlar in data genom annonser, har du hört det förut? För det använder de unika DNS-namn.
Dessa unika DNS-frågor existerar endast en enda gång. TTL är en sekund.
Men dessa frågor ser ut att återkomma! Vissa frågor kan återkomma så sent som tre år senare. 50% av dessa zombie-frågor är mer än sex månader gamla.
Vilka är dessa vrickade resolvrar? Resolvrar i Guatemala är värst... Men Team Cymru är också rätt märkliga.
Tre typer av zombie-fabriker. Stalkers som bara ställer en fråga som någon annan ställde, storers som ställer frågor i bulk om sånt som setts, samt de totala galningarna som bara spammar.
En mer fullständig presentation av denna hölls på DNS-OARC-mötet i Buenos Aires. Om den finns på Youtube rekommenderas den, framför denna. Här är slides från denna.
WPAD, Alert TA16-144A. Ny attack-vektor. Folk har använt wpad internt i företag men det läcker. Använder man en TLD som inte finns i root för sina "enterprise"-nät men som plötsligt dyker upp i root så är man i trubbel. Plötsligt finns det data i wpad.TLD som inte tidigare funnits där.
WPAD-protokollet finns inte bara i Microsoft-produkter, utan finns även i andra produkter. Stäng av automatisk proxy-konfigurering!
Det finns ett väldigt omfattande användande av wpad...
Vad man kan se i root idag är över 20 miljoner frågor per dag, som kan leda till direkta attacker.
Det som händer är att en domän registreras, sedan sitter man och bara väntar på att en proxy konfigureras den vägen, och så äger man den webb-trafiken.
LacNOG har nya dokument, notifieringar vid incidenter, rekommendationer hur man implementerar IPv6, CSIRT-samarbeten, best practices for IXPs, DDoS-mitigation.
Africa BCOP gör framsteg. Operatörerna samlades i Nairobi i mars. Målen var att börja dokumentera best current operational practices (BCOP), inte att bara prata om det längre. De samlade ihop till ett antal utkast på BCOPs. Fraud information sharing, fiber optic building and maintenance, procudures for network infrastructure sharing, peering policy best practices.
Förra RIPE-mötet presenterades dessa dokument på tyska, men de har börjat översättas till engelska (länkar i presentationen). Dokumenten täcker DNS, DDoS, Malware och IDR. Finns det villiga personer att jobba vidare med dessa? Var, wg eller BCOP? DNS-dokumenten hör hemma i DNS-arbetsgruppen givetvis, men de andra?
Good MANRS, filtering, anti-spoofing osv.
Syftet är att förenkla deployment av MANRS. Förhindra propagering av inkorrekt routing-info, använd RPKI, förhindra spoofing osv. Men best practices är inte en config-fil... Inte ens copy&paste i de allra flesta fall.
Dokumentet finns tillgängligt nu. Behöver feedback.
Det är onödigt att uppfinna hjulet på nytt, gäller i synnerhet vid automatisering av nät. Vi kommer att i den här presentationen titta närmare på Ansible och Salt, Puppet och Chef är inte lika kompletta.
Salt saknar features för nätverkskonfiguration, har gamla referenser i dokumentationen, passar inte små VM-nät. Men man väljer det verktyg som passar verksamheten bäst. Cloudflare har kört Salt väldigt länge och har därmed stor erfarenhet av detta verktyg. Därför använder man det också för allt nätautomatisering. Salt innehåller däremot en massa fördelar framför Ansible, se slide 10.
Cloudflare presenterar nu NAPALM-Salt som öppen källkod. Innehåller moduler för NET, BGP, NTP och Probes.
...
Data Driven Ops at Scale: Sensors, Telemetry and Analytics in Large Data Centre Networks, Hossein Lotfi, Google
Googles trafikmängd inne i datacentren har ökat ordentligt över tid. De har gjort en hel den "nätverksinnovationer", det här handlar om deras "Jupiter". Med Jupiter kan man köra 1.3Tbit/s.
Google kör inte superdatorer, utan använder commodity-hårdvara. Tiny RTT, massive multi-path, latency är viktigt, homogent nät väldigt viktigt (att modifiera protokoll är enklare), all Google-programvara kör på samma plattform.
Google har ett Software Defined WAN, kallas B4. Ovanpå det har man ett nätvirtualiseringssystem man kallar Andromeda.
Senaste decenniet har man börjat använda det Google kallar Cloud 1.0, man sätter servrar i molnet. Det som händer idag är Google 2.0, där man kör HW-on-demand, man provisionerar baserat på hur tjänsterna utnyttjas. Nästa steg blir Cloud 3.0, "compute, not servers". Bry dig inte om minne, lagring eller prestanda. Why Balance Mattars @ Building Scale. Ett obalancerat datacenter betyder att vissa resurser är bristvara, och andra resurser inte används.
App-level SLA at Scale. Hela deras miljö är virtuell och enorm, så man probar hela nätet och dess tjänster randomiserat. När det fungerar så vet man att hela nätet och dess tjänster fungerar. De ligger lite före alla andra... SNMP är inte något som fungerar för dem. S
Next Generation Network Telemetry: OpenConfig. En open source-stack för model-based streaming telemetry.
Det finns bara två sätt att titta på Jupiter, ett är att joina teamet, det andra är att göra den virtuella turen.
Läsvärda slides.
IoT: What is the Problem?, or “How To Explain To Your Boss That IoT Won't Make the Company Rich....”, Shane Kerr, Beijing Internet Institute
Inget med IoT är nytt, bara en buzz. Det är "newish", det är tekniskt, men inte svårt. Alla fattar. Man fattar att det är lite coolt, och ingen vill vara efter.
A Big Thing for Bosses, inte som Web 2.0, virtualisering, SDN, cloud computing, Open Stack (som är större grejer för någon som kan teknik). En kort IoT-definition. Gårdagens internet anslöt människor, morgondagens nät ansluter "saker".
Fråga 1: Kommer det att skala?
Att skala upp nätet kommer alltid att vara nödvändigt. Men vi har klarat oss så här långt. /etc/hosts till DNS, IPv4 till IPv6, osv. Att IoT skulle kräva 10000x prylar, är inget som är ett problem idag. Kräver möjligen horisontell skalning, SQL vs NoSQL, kanske blockkedjor och liknande. Man skulle också kunna tänka sig hierarkisk skalning (som DNS). Här finns inga uppenbara begräsningar.
Fundamental teknik, IP-adresser, BGP och DNS.
IP: Det finns tillräckligt med adresser med IPv6.
Routing: BGP. Internal vs external. SDN kan dock förändra en del av landskapet, inte löst.
DNS: Funkar. Använd det.
Svar på fråga 1: Adresser, ja! Routing, ja sannolikt. Namn: ja!
Frågga 2: Vad är utmaningarna?
Kompatibilitet, gamla prylar, säkerhet.
Företag strävar efter inlåsningseffekter. Skapar isolerade system "walled gardens" (tänk Apple vs Android). Måste gå mot öppenhet.
Gamla prylar, icke nätverkade saker tycks fungera utmärkt fortfarande... Men. Hur gammal är din telefon? Finns inga bra lösningar för att uppgradera gammal hårdvara. En tre år gammal IP-TV kommer aldrig att få en ny firmware. Open source kommer sannolikt att förbättra detta.
Current best practice: patcha buggar. Funkar rimligt på telefoner.
Kan IoT göra mig rik? Kort svar: nej. Långt svar: ja. Hitta folk som vill lösa dessa problem, lös dem och bygg en affär av det. Ett bättre svar: nej, men du kan bygga en affär av det.
Bonus-slide med konspirationsteori om IP vs Telco. RIPE startade för att jobba runt Telco och arbeta med IP, och IP vann! Regeringar gillar inte ett öppet nät, men ett svar här kan vara IoT, där vi återfår propietära protokoll och ett Telco-styrt samhälle där de pratar 5G istället för IP med proprietär utrustning.
Det är väldigt svårt att förstå säkerhetsproblemen med IoT. Bilar som hijackas osv. Vi kommer att se många hemska saker.
ITU startar en ny study group, nummer 20 i höst, som ska studera IoT. Study group 17, om säkerhet ska också se över sitt charter. Detta händer i höst, man kan prata med t.ex. PTS eller vem som nu deltar i arbetsgrupperna om vad som bör göras.
IPv6-programmet på Comcast började 2005. Redan då insåg man att IPv4 inte skulle räcka till, och att IPv6 är nödvändigt.
98% av enheterna som Comcast administrerar använder idag enbart IPv6 (för administration av enheten), blir snart 100%.
Steget efter det var att börja köra dual stack på bredbands-anslutningarna. Idag har 87% av Comcast kunder dual stack, med native IPv6. I början av nästa år räknar det med att det är strax över 90%.
X1 är deras nya settop-box för TV. I år har 40% av Comcast kunder denna box, och det växer hela tiden - IPv6 only.
Om någon undrar ifall IPv6 fungerar eller inte, Comcast visar tydligt att det fungerar alldeles utmärkt i stor skala.
Incrementalism är ordet de står för, bygg små saker hela tiden som funkar. Have a plan, A, B, C, D...
Approach, se över alla byggstenarna. Bygg från kärnan av nätet och utåt. Slå på IPv6 för en tjänst i taget. Native IPv6, inte några transitions-mekanismer.
Nästa steg, minimera och ta bort beroenden på IPv4. IPv4 erbjuder inget på lång sikt. Användandet av IPv6 fortsätter att växa, för närvarande ligger åtkomsten till Comcasts externa tjänster på 25% v6. De ska också använda IPv6 som en plattform för innvovation på nätsidan.
Vägen till enbart IPv6. Facebooks trafik över IPv6 ligger på över 60%. Comcasts interna infrastruktur kommer att bli enbart IPv6 inom kort, samt deras egna interna molntjänster. X1 blir IPv6-only.
IPv4aaS, tilläggstjänst för de som behöver det...
Vad säger specen om multicast? MLD = Multicast Listener Discovery. Finns i alla IPv6-stackar. Lyssnarna skickar rapporter om vilken trafik man lyssnar på. Man kan också ställa frågor för att se vad det finns för lyssnare. Generiska frågor skickas till FF02::1.
En nod måste processa en fråga som matchar adressen som tillhör det mottagande interfacet, unicast eller multicast.
MLD kommer påslaget i Windows Linux och FreeBSD. Inte i OpenBSD. Alla går med i flera multicast-kanaler. Man kan alltså sitta på en länk och passivt lyssna på vilka som är där, samt vilket OS som används.
För att göra fuzzing på MLD, protokollen så kan man använda verktygen Chiron och Dizzy. Ger en del router-problem när man börjar köra, enorma MLD-rapporter sänker routrar. Ger också stora möjligheter till amplifikations-attacker. (Kräver dock att man sitter på local-link.)
Många svagheter med MLD påslaget... Routers borde inte acceptera frågor till FF02::2 och FF02::16. Filtrera MLD-frågor på switch-nivå, deny icmp any any mld-query. Överväg också no ipv6 mld router. Se fler råd i presentationen.
Measuring Webpage Similarity from Dual-Stacked Hosts, Vaibhav Bajpai, Jacobs University Bremen, Germany
Antalet webbsajter med tillgänglig AAAA-post har ökat ordentligt de senaste åren. Men hur många fungerar som det är tänkt? Vilka faktorer är det som gör att innehållet över IPv6 ofta skiljer sig från det över IPv4?
Nytt verktyg: simweb. Ett verktyg för att mäta web similarity över IPv4 och IPv6. 27% av webbsajterna har vissa element som inte lyckas över IPv6. Felen beror ofta på problem med DNS-uppslag med bl.a. bilder, CSS och js.
Referensmätningar gjorde med Alexa topp 100.
Metodiken är enkel, simweb körs två gånger (IPv4, IPv6) och körs en gång per timme. Mätningarna körs från 80 dual-stacked SamKnows-prober. Mätningarna är gjorda under 65 dagar under 2015.
27% har något fel. 9% har mer än 50% fel över IPv6. 6% misslyckas helt över IPv6. Se sida 10.
Att bara titta på HTML-resursen för förstasidan leder till en överestimering av fungerande IPv6-sidor. Man måste titta på alla resurser som används också.
Presentationen görs av Nurani, Netnod. Förhoppningsvis den sista presentationen i den här processen...
ICANN Accountability var inte färdigt sist. Mer om det senare.
ICANN 55-mötet såg till att den sista delen i "IANA-paketet" skickades in.
Fas 1 är således färdigt. Fas 2 är NTIA Review & Evaluation, så nu ska arbetsgrupperna förtydliga eventuella frågetecken från NTIA.
Arbetet har tagit två år, intensivt arbete. Löpande och öppen kommunikation med RIPE-communityt.
I efterföljande diskussion tackar alla varandra.
A Happy Story of Inter-RIR Transfer of Legacy Blocks from ARIN to RIPE, Randy Bush, Internet Initiative Japan (IIJ)
ARIN har policy-folk som inte gillar legacy-space. Svårt att hantera det där. RIPE däremot är legacy-vänliga. Man kan göra det mesta med sina legacy-block hos RIPE.
RGNet (Randys nät) har fyra legacy-block inom ARIN, och han har jobbat med RPKI länge, och är RIPE-medlem. Randy ville flytta dessa block från ARIN till RIPE, för att få RPKI och sånt (svårt inom ARIN utan avtal). Processerna för att flytta verkade vara dokumenterad.
ARIN har en knapp på webbsajten som handlar om att förflytta resurser, och de hade ett formulär online för detta. Man kunde flytta adresserna, men inte AS-numren. Detta kostade $500 hos ARIN.
RIPE bad Randy att verifiera att han ville ta emot denna transfer, samt berätta om infrastrukturen inom RIPE-regionen. En sen besluta sig för att bli en medlem eller använda en annan sponsoring LIR. Men också skicka in bevis för att RGNet LLC existerar, samt skriva på avtal om sponsoring LIR legacy-adresser. Var också tvungen att skapa en massa objekt i RIPE-databasen för alla block osv.
Reverse-DNS för dessa block blev rätt problematiska... Det blev ett par timmars glapp då reverse-DNS inte alls fungerade.
Målet var dock att få upp RPKI, och det gick bra när allt väl var flyttat till RIPE.
Philippe är från Ukraina, och driver ett företag som erbjuder kundanslutningar där. Pratar om censur i Ryssland, ett land som erbjuder många bra internettjänster för kunder även i Ukraina.
Svartlistor och accessfiltrering, använder ursprungligen för att blocka barnpornografi. Men har även börjat blocka mycket annat. Online-casinon, gambling, självmordsinformation, illegala droger osv.
ISP:er använder svartlistor på DNS-nivå, IP-nivå eller genom att filtrera URL:ar genom HTTP. En lista på blockade sajer finns här: http://reestr.rublacklist.net/
Denna typ av blockering leder ofta till collateral damage, dvs annat material blockeras också indirekt.
Varför bryr sig Ukraina? Vissa transit-providers åker enbart genom ryska ISP:er. Några länder kan endast åka genom Ryssland. Ibland gör operatörerna misstag som råkar exportera censuren till världen utanför. Leder ofta till att det blir svårt att nå många användbara resurser, som t.ex. nyhetssajter.
Rutracker.org (AS47105)-incidenten. En torrent-tracker, usch. Denna sajt svartlistades av en domare i Ryssland, som en permanent blockering. Genom en DDoS-attack mot sajten senare så försökte man avvärja den genom att annonsera ut trafiken andra vägar. En av vägarna var genom en rysk operatör som hade felkonfigurerat blockeringen. Detta ledde till att sajten blev helt onåbar från vissa europeiska länder. Några användare i Ukraina fick den ryska blockerings-sidan.
NetAssist började mäta denna typ av blockering med RIPE Atlas (metodik på sida 15).
Några länder drabbas av rysk censur direkt, Kazakhstan, Uzbekistan och Kyrgyzstan. Inte alla prober påverkas dock inte i ett par av länderna. Georgien, Azerbaijan och Armenien påverkas också stort av den ryska censuren, trots icke-ryska backbones. Europeiska länder drabbas inte.
Operatörer konfigurerar ofta censur-mekanismerna felaktigt. Ett globalt känt exempel på detta är Youtube-incidenten 2007.
Dmitry Burkov sa för många år sedan att censur av det här slaget dödar transit genom operatörer i det här landet. Så detta bevisade påståendet genom en oberoende granskning från utsidan.
Passiva mätningar i DNS för att mäta resolvrar som validerar DNSSEC. Funkade inte så bra, det är svårt att veta vad resolvrarna gör. Andra försöket, aktiva mätningar med 500 RIPE Atlas-prober i Nederländerna. Metoden är att göra mätningar på både fungerande DNSSEC-domäner och domäner som är felaktiskt signerade (SERVFAIL), och testa mot resolverns lokala resolvers.
.nl har 2,5 miljoner signerade domäner, men i Nederländerna finns väldigt få validerande resolvrar. Målet med dessa mätningar är att öka antalet resolvrar som validerar.
Men vilken resolver hanterar frågorna? Lokala resolvrar kan göra en forward till en upstream-resolver (vilken t.ex. kan vara 8.8.8.8). Det kan också vara en lokal dnsmasq som gör validering som proxy. För att undvika detta så väljer man bara att mäta mot resolvrar som används av mer än en unik Atlas-probe.
Resultatet var 65 unika resolvrar i 9 olika AS. 24 validerande resolvrar hittades, mot 41 som inte validerade. 6% av frågorna i testet gick genom validerande resolvrar, vilket är en väldigt liten del.
Jämfört med APNICs mätningar som gav 12% validerande resolvrar så är detta bara hälften i Nederländerna. Men det är också baserat på en väldigt liten mätning, och flera Nederlänska ISP:er saknades med denna metod.
Om man vill titta på mätningarna så har de id 2671531, 2671532 och 3671533.
Framöver kommer man att analysera skillnaderna mellan APNICs mätning, samt mäta detta över tid.
Det vore trivialt att genomföra samma test i Sverige och jämföra resultatet länderna emellan.
Vantage Point Selection for IPv6 Measurements: Benefits and Limitations of RIPE Atlas Tags, Vaibhav Bajpai
RIPE Atlas-systemet har möjlighet att tagga upp proberna, användare kan också tagga noder. System-taggar är meta-data om noderna om med såna saker som att IPv6 fungerar inte, vilken version av systemet som körs osv.
2,2k av 9,3k av proberna har fungerade dual-stack. Om dessa noder står i Tyskland är det väldigt stor sannolikhet att de står hos Deutsche Telekom, eller om de står i USA är sannolikheten väldigt hög att de står hos Comcast.
Lita inte på user tags. System-taggarna är stabila.
Kan vi köra internet över UDP?
Man kan köra Atlas för UDP-mätningar. Stora UDP-paket är inte några större problem, och de fungerar bra över hela nätet. 3% failure är ändå rätt mycket, men om man kan göra fallback till TCP är det bra.
Fler protokoll kommer att köras över UDP, som QUIC och DTLS vilket möjliggör nya tjänster.
Distributionen av proberna globalt blir sakta bättre. 9412 anslutna prober, 1611 övergivna och 4558 inte anslutna.
10000 aktiva användare av proberna, 3500 mätningar per sekund. 6,33% av alla AS täcks in för IPv4, och 11,22% av IPv6 - i 181 länder. 27 RIPE Atlas Anchors.
https://github.com/sbenthall/bigbang ska (eller har?) användas för att analysera communityt.
Fler och fler vill ha utbildning i hur man gör mätningar, och det har också varit fler Hackathons i år.
Nya feature i Atlas presenteras här: https://atlas.ripe.net/resources/announcements/
Man har utökat antalet prober man får använda vid en mätning till 1000.
Ytterligare 15 ccTLD:er har lagts till i DNSMON, och många second level domains använder DomainMON (jag kör den själv för en av mina egna domäner). Se exempel på DomainMON här: https://flic.kr/p/HvcVQg
Nytt diskussionsforum: https://www.ripe.net/participate/mail/forum/ripe-atlas
I framtiden planeras Wifi-mätningar i samarbete med Eduroam. Prober som virtuella maskiner planeras också. OpenIPMap-as-a-service.
Verktyg framtagna av communityt:
- https://github.com/pierky/ripe-atlas-monitor
- https://ripe-atlas-monitor.readthedocs.org/
- https://labs.ripe.net/Members/pier_carlo_chiodi/ripe-atlasmonitor
CLI-verktygen finns i de flesta distributioner nu.
RIPE Atlas Halo, det vinnande projektets kod finns här: https://github.com/RIPE-Atlas-Community/ripe-atlas-halo
"A heads-up display for your network", snygg webbsida som visar eventuella failures i ett lands internetinfrastruktur. Gränssnittet är lätt att använda, mata in ett AS-nummer, en landskod eller ett prefix. Visar en karta över området, och en graf över händelser.
ntop är ett företag startat 1998, utvecklar nätverksapplikationer för monitorering. Kan lagra nätverkstrafik i alla hastigheter och i alla paketstorlekar. Grundprogramvaran är öppen källkod, men har också kommersiella verktyg. All open source-programvara finns numera på Github.
Programvaran ntop börjar bli åldersstigen, så man har börjat på en hel omskrivning med ntopng.
ntopng monitoring engine är skriven i C++. Också nytt, nDPI ovanpå ntopng för deep packet inspection. nDPI stöder över 200 olika protokoll.
Det nya webbverktyget ser verkligen användbart ut.
Martin Winter är en av medgrundarna till Open Source Routing, ett projekt från NetDef.
Martin fokuserar på testning av programvaran. Statisk analys med Clang-Analyzer, kan ge väldigt mycket varningar. Statisk analys med Coverity Scan fungerar bättre, hittar mycket copy&paste-fel. Välj inte bara ett av verktygen, kör båda.
Code Coverage, görs inte ännu, men måste göras så småningom.
Andra programvaror gör interoperabilitetstester med Juniper och Cisco, men det är inte samma sak som RFC Compliance-tester. Funkar dåligt med felhantering och BGP Transitive Attributes.
För RFC Compliance-tester använder man Ixia ANVL. Det är dock väldigt dyrt. Testar inte bara compliance, utan hittar också mycket andra problem. Kan ta flera dagar för ett fullt test.
Man använder också Protocol Fuzzer, i det här fallet Spirent SPS-8000, den kan alla routing-protokoll.
Prestandatester och skalningstester är också viktiga. Hur många routes OSPF hanterar, osv.
Man vill automatisera alla dessa tester, inkl tolkning av resultaten från testerna.
Ett mer omfattande paper om hur man testar finns här: https://www.opensourcerouting.org/2016/05/whitepaper-how-opensourcerouting-tests-quagga/
Honeypots är intressanta om man vill hitta ny skadlig kod. Det finns inte så många plattformar för att köra honeypots. Om man gör det kan man snabbt hamna i olika blacklists, så man vill ha dedikerade IP-adresser för att köra dem. Det är också svårt att simulera äkta plattformar.
CZ.NIC har utvecklat "Honeypot as a service" för att köras i Turris. Man vidarebefordrar extern SSH-trafik mot Turris-maskinerna till en centraliserad tjänst. Användaren installerar en väldigt tunn programvara på sin Turris, och det är en port per instans i klienten. Honeypoten simulerar bara SSH.
Honeypot-plattformen är baserad på Cowrie, skriven i Python. Det är en fork av den populära Kippo-plattformen.
SSH-honeypoten på Turris baseras på mitmproxy.
Av Turris-användarna har man ca 350 användare på honeypot-tjänsten.
13 000 attacker har man hittat genom tjänsten i år så här långt. 70% av attackerna kommer från Argentina. 50% av dessa användare (som attackerna kommer från) har port 7547 öppen, vilket kan bero på en specifik sårbarhet eller en infekterad dator.
CZ.NIC ser gärna samarbete med annan honeypot-programvara. Kanske ett federerat system för informationsutbyte, för olika länder.
(Denna presentation hölls även på CENTR R&D under Jamboree 2016.)
Internet är ett nät av nät, partitionerat i 300 miljoner domännamn, med 7000 service providers. Marknadskrafterna har gett ett priskrig på konsumenttjänsterna, och innovationen host ISP:erna och hostingproviders har avstannat. Inte mycket uttrymme för nya tjänster.
Visionen, "repopulate a decentralised global internet that offers security and privacy by design". Ta fram en ny stack för den professionella hosting-industrin. En drop-in replacement för befintliga tjäsnter. Standard-baserad med best practices, som t.ex. DNSSEC och IPv6.
Projektet har dessa partners justnu, NLNet Foundation, OpenFortress och InternetWide.org. Utvecklarteamet består av 8 personer.
ARPA 2 i fyra faser:
- SecureHub, 'usable TLS'
- IdentityHub, 'bring your own identity'
- PluginHub, 'plugin services for your identity'
- SocialHub, 'connect witout intermediaries'
SecureHub med TLD, DNSSEC och DANE, LDAP för koordinerade credentials, Kerberos. Komponenter i detta: TLSPool, TLS-KDH, och SteamWorks.
Fas 1 med SecureHub ska vara färdigt nu i juli.
Fas 2 ska komma igång med identitets-sakerna nu.
Man letar efter mer pengar.
ISC vill ändra licensen för BIND 9.11. Man använder sin egen licens, baserad på BSD som är väldigt tillåtande. Förmodligen blir den nya licensen Mozilla Public License (MPL) 2.0. Det betyder att om man modifierar koden måste man bidra tillbaka (likt GPL), eller betala för en undantagslicens.
Man vill ha input från community angående detta. Maila direkt till Jeff på jeff@isc.org.
För att inkluderas i OpenBSD måste man ha motsvarande BSD- eller MIT-licens. Detta är ett avsteg från detta.
Anand planerar att gå över från DNSCheck till Zonemaster i sina pre-delegation-tester. Säger att Zonemaster är väldigt väldesignat. Skiftet ska ske senare i 2016.
RIPE NCC har lämnat tillbaka sju stycken /24 till communityt.
De gör regelbundet mätningar med RIPE Atlas mot deras K-root-anycast-nät. De ser med Atlas att de lokala noderna tjänar sin lokala geografi som det är tänkt. Dock, nästan alla prober i Belgien går mot K-root i Miami.
77 ccTLD:er använder RIPE:s DNS-hosting. De utvärderas just nu under policyn RIPE-663, publicerad i december 2015. Några ccTLD:er kommer att upphöra att få sin tjänst. En ccTLD har migrerat bort själva redan.
RIPE:s egna DNS-tjänster (för t.ex. .arpa) har fått ytterligare namnservrar. RIPE NCC är bekymrade över trenden med den ökande mängden DDoS-attacker. CouldFlares namnservrar är tillagda, och de klarar många Gbit/s. Det är dock tillfälligt, de letar efter en mer långsiktig annan lösning.
RIPE NCC erbjuder sekundär namnservertjänst för de LIR:ar som vill ha reverse för sin baklängesuppslagning. Deras pre-delegation-tester hanterar dock inte tester av ns.ripe.net förrän delegeringen är gjord, så de behöver någon form av filter i programvaran som gör detta (DNSCheck! Snart Zonemaster!) så att de kan ignorera fel från denna namnserver.
ns.ripe.net har 4069 zoner konfigurerade. 1946 zoner har expirerat (47%).
.arpa-zonerna gjorde en lyckad algoritmrullning i november 2015.
Om bytet från 1024-bitars ZSK till 2048-bitars ZSK. För några veckor sedan utfördes frsta signeringen, i augusti signerar man 2016Q4 ZSK:erna. Den 20 september publiceras den första 2048-bitars ZSK:n i root-zonen. I skiftet mellan september och oktober publiceras 1024- och 2048-bitarsnycklarna parallellt. I december/januari kommer rullningarna enbart att bestå av 2048-bitarsnycklar.
Hur ser då svarsstorlekarna för DNSKEY ut? Just nu har man paketstorlekar med 883 bytes. Under 1024-2048-rullningen kommer man att ha 1011 bytes. Under en vanlig 2048-2048-ZSK-rullning är paketstorlekarna 1139 bytes.
RRSIG:arna växer från 159 bytes till 287 bytes.
Någon fragmentering av svaren tycks inte förekomma. En viss procent, ca 5%, kommer att behöva göra fallback till TCP vid DNSKEY-frågor. Ökningen för samtliga frågor går från 0,5% till ca 1,5%. (Vid nyckelrullningar!)
Det finns en fallback-plan, även fast man är övertygad om att allt kommer att förlöpa smärtfritt. Man kan backa till 1024-bitars-ZSK. ICANN signerar då två KSR:s, en med ett fallback-nyckelset. Fallback görs endast om något oväntat och allvarligt händer, och det verkligen inte går att lösa på något annat sätt.
Testa ditt eget nät genom att använda tjänsten http://keysizetest.verisignlabs.com/
KSK-rullningsprocessen påbörjas omedelbart när ZSK-rullningen är genomförd. ICANN och Verisign utformar planerna tillsammans just nu, tillsammans med "community design team".
RFC7258, Internet är under attack, pervasive monitoring är ett problem som måste lösas. DNS har en hel del att göra inom det här området med att minimera dataläckaget. DNS-datat är helt publikt och okrypterat idag. Trenden går också mot att publicera personliga identifierare där, med t.ex. S/MIME- och PGP-nycklar.
RFC6973, Privacy Considerations for Internet Protocols. 6.1 säger något om Data Minimization, och 6.3 om säkerhet och konfidentialitet.
En resolver idag frågar om hela frågenamnet hela vägen från root och neråt i DNS-hierarkin. Det innebär att man exponerar alldels för mycket data till tredje part (root, TLD-operatörer m.fl.). DNS Query Name Minimisation to Improve Privacy, RFC 7816 specifierar ett sätt att ta bort detta, och minimera dataläckaget till minsta möjliga. Root kommer alltså inte att få frågan om hela namnet, utan bara om en referens till toppdomänen.
Detta är implementerat i Unbound 1.5.7 och uppåt, allt man behöver göra är att lägga till "qnameminimisation: yes" i sin konfiguration.
Qname Minimisation ger fler frågor, men betydligt mer privacy.
Processen för att hantera lite märkligt konfigurerade zoner har förbättrats i version 1.5.9. Samt har man optimerat processen för att minimera antalet frågor som krävs.
Testa om din resolver har Qname Minimisation:
dig txt qnamemintest.internet.nl +short
BIND 10 lades ner 2014. Release av 9.10 samma år. Mycket buggfixar, reolsver mitigation osv under 2015. I år ska 9.11 släppas, med många prestandaförbättringar.
I år har ISC nyanställt ytterligare utvecklare.
2014-2015 har fokus varit på DDoS-mitigering. OpenStack har haft en del kvar på provisionering av zoner. "RNDC del zone" var extremt långsamt, och stora konfigurationer har lidit av Notify-congestions.
Man vill också ha en databas-backend, som PowerDNS har.
Ny feature: Catalog Zone. En ny zone som på mastern innehåller en lista på alla zoner (Catalog). Baserat på Paul Vixies förslag om MetaZones från 2014. Då kan sekundärnamnservarna uppdateras baserat på katalogzonen, genom att man lägger till zonen till den. Den är testat med 100 000 zoner och tycks fungera bra, ska testas mer. Finns som internet-draft.
Listan på nyheter i BIND 9.11 är lång. Negative Trust Anchors, dnstap-loggning, CDS/CDSKEY auto generation, IPv6 bias, förbättringar i RNDC, refuse ANY, mm. mm.
Alpha 2 släpptes 25:e maj. FINAL-release i augusti 2016.
Ny iOS-app, Dig! (Fråga Ray Bellis om du vill beta-testa.)
DPRIVE wg har haft fullt upp:
- RFC7626 - DNS Privacy Considerations
- RFC7858 - Specification for DNS-over-TLS
- RFC7830 - EDNS0 Padding Option
- (RFC7816 - DNS Query Name Minimisation to Improve Privacy)
- I-D: DNS-over-DTLS
- I-D: DNS-over-(D)TLS authentication profiles
Vi har standarderna nu. På klientsidan har getdns kommit långt. Som recursor jobbar Unbound på det.
Vi behöver erfarenhet av att köra detta i praktiken, under en längre tid för att förstå hur det fungerar i produktion, samla in statistik osv.
Behövs en allmänt tillgänglig resolver som man kan köra DNS-over-TLS att testa mot? (Fråga till RIPE-communityt.)
Vad är bra och dåligt med DNS?
It is time to consider fundamental changes to the protocol. These changes should:
- Keep most of what DNS has gotten right
- Throw away most of what DNS has gotten wrong
- Allow DNS to more easily evolve in the future
Call to action: Utveckla protokollet, ersätt det inte.