15 April SKA v6 2009 1(19)
Innehåll 1 Inledning... 4 2 SKA v6... 5 2.1 Behöver vi IPv6?...5 2.2 Är det bara att slå igång IPv6?...5 2.3 Några myter och sanningar om IPv6...6 2.4 Adresstilldelning av IPv6-adresser...6 2.5 Typer av stads- och bredbandssnät...6 3 IPv6 tunnlas över IPv4... 7 3.1 6to4...7 3.2 Teredo...9 3.3 Sixxs...10 4 En modell för IPv6 i bredbandsnät... 11 4.1 Skydda backbone mot DOS attacker...11 4.2 Kundaccessen...12 4.3 Problem/frågeställningar...12 5 IPv6 med delad broadcastdomän.... 13 5.1 Krav...13 5.1.1 IPv6 Stateless Address Autoconfiguration ( RFC2462 ) Snooping... 13 5.1.2 IPv6 snooping... 13 5.1.3 DHCPv6 (RFC 3315) snooping... 13 5.1.4 Router Advertisment (RFC 2462, RFC 5006) snooping... 14 5.1.5 Dynamic "IPv6 neighbor solicitation/advertisment" (RFC 2641) inspection... 14 5.1.6 Neighbour Unreachability Detection (NUD, RFC 2461) snooping... 14 5.1.7 Duplicate Address Detection (NUD, RFC 4429) snooping... 14 5.1.8 IPv6 Multicast Listener Discovery v2 (RFC 3810) snooping... 14 5.1.9 IPv6 Routing Header (RFC 2460, Next Header value 43) snooping... 15 5.1.10 UPNP filtrering... 15 6 Vad kan hända om vi gör fel?... 16 6.1 Ingen spärr av IPv6 RA...16 6.2 Ingen spärr av DHCPv6...18 6.3 Sammanfattning...18 7 Projektdeltagare... 19 2(19)
3(19)
1 Inledning En av de första vårdagarna 2009, då jag bor i Skåne och inte i delar av Sverige som då var snötäckta, fick jag ett första utkast av SKA v6 av. Jag läste rapporten med förtjusning, då jag helt delar rapportens syn. Den att IPv6 är nästan lika som IPv4, och därför enkelt att komma igång med, men samtidigt har egen hantering av främst kopplingar till L2, och därför mycket annorlunda. Jag tror att vi nu i inledningen av användning av IPv6 kommer upptäcka ganska många barnsjukdomar. Såväl i implementeringar i hård och mjukvara som i arkitektur och design av nät. Därför tycker jag det är extremt bra att det på ett så här tidigt stadium skrivs ett dokument med generella råd och riktlinjer. Allt eftersom tar jag för givet att dokumentet, precis som ursprungliga SKA-dokumentet, kommer att komma ut med nya förbättrade råd. Tex vet jag att det är stor mängd utrustning som inte klarar av de krav som listas i detta dokumentet. Därmed tycker jag inte man skall låta bli att börja använda IPv6. Istället skall man veta vad bristerna är, och designa därefter. Man kanske kan acceptera en del statisk konfiguration så här i början, innan vi har en fullt säker implementering av DHCPv6 tex? För IPv6 behöver vi, det är det ingen diskussion om -- hoppas jag. Alternativa, främst NAT-baserade lösningar, är extremt mycket sämre och jobbigare än det arbete som denna rapport beskriver för att få en säker IPv6-miljö. //Patrik Fältström, Cisco Systems 4(19)
2 SKA v6 SKA v6 är ett projekt som koncentrerar sig på hur IPv6 skall aktiveras i bredbandsnät. SKA v6 är helt fristående från SKA v3.1, som handlar om IPv4, men vissa delar är gemensamma varför det ibland hänvisas till krav i SKA 3.1. Detta dokument skall ge stadsnät och andra bredbandsnät råd om hur man aktiverar IPv6 i nät som ännu inte är förberedda och anpassade för IPv6. Samtidigt anges även vilka krav som ställs på nätet för att native IPv6 skall kunna implementeras, på samma sätt som SKA 3.1 ställer krav för IPv4. Samtliga lösningar som påvisas i detta dokument fungerar tillsammans med IPv4 som den körs idag utan förändringar. Läs mer om IPv6 på: http://en.wikipedia.org/wiki/ipv6 Eller mer om projektet SKA v6 på: http://www.ska-v6.se. 2.1 Behöver vi IPv6? Diskussionen om IPv6 har pågått i över 10 år. Om det behövs och när det behövs? För att göra projektets åsikt kort, tydlig och klar i denna fråga så formulerar vi oss så här: Behövs IPv6? Ja! När ska vi börja med IPv6. Nu! Andra åsikter som oftast kommer upp är att IPv4 håller för all framtid. De som tycker att t.ex carrier grade NAT är en lösning som skalar inför framtiden får gärna framkomma med konkreta exempel på hur den lösningen ska kunna växa obehindrat och ge ett för kunderna rättvist och robust Internet i framtiden. 2.2 Är det bara att slå igång IPv6? IPv6 stöd finns redan i många utrustningar. Tyvärr är stödet ofta inte anpassat för användning i bredbandsnät. Innan ni har kontroll på hur ni skall göra eller har vetskap om er utrustning har tillräckligt stöd så bör ni helst spärra all IPv6 mellan alla kundportar och minst enligt kraven i SKA 3.1. Idag finns det inte mycket, om någon, hårdvara för att bygga ett säkert IPv6 nät ute i accessen. Centralt, i nätens stora backbone routrar mm, har det funnits stöd för IPv6 i flera år. Ju närmare kunden vi kommit desto större har/är bristen på utrustning, vilket har visat sig tydligast i bristen på CPE/hemmaroutrar med bra stöd för IPv6. 5(19)
2.3 Några myter och sanningar om IPv6 Det är omöjligt att hitta alla hostar ett IPv6 prefix på 2^64 bitar, det tar för lång tid att skanna igenom det. Fel I IPv6 finns det välkända multicastadresser som varje host skall svara på. Det går alltså lika snabbt att skanna igenom ett IPv6 segment som ett IPv4 segment. Ex. ~ ping FF02::1 IPv6 är mer komplext och kräver mer vid uppsättningen. Sant Man måste tänka till så att man filtrerar sina multicast korrekt. Om t.ex en ntp klient skickar en NTP fråga till FF0E::101 så kan det i teorin ställa samma fråga till alla NTP-servrar på Internet. En sniffer säger mer än 1000 ord. Sant En passiv sniffning i ett nät ger ofta en hackare tillräcklig information över hur miljön ser ut. Men det är lika nyttigt i både IPv4 och IPv6. http://www.usipv6.com/6sense/2007/jan/article01.htm Inspiration till stycket är hämtad från adressen ovan, som visar på många fler saker att tänka på, men som inte skiljer sig nämnvärt från IPv4 världen. Två av punkterna ovan talar också emot att bygga IPv6 med delad broadcastdomän, då IPv6 är mycket mer komplext på nivå två än IPv4. Se kapitel fyra och nästa punkt för mer information. 2.4 Adresstilldelning av IPv6-adresser Det finns två stycken sätt att få en IPv6-adress tilldelad. En stateless, Router Advertisment ( RA, RFC 2416, RFC 5006) och en statefull, DHCPv6 ( RFC3315 ). RA, med sin tämligen enkla funktionalitet, fungerar bra i kontorsnät eller hemma hos privatpersoner. I en operatörsmiljö där man i regel vill ha högre spårbarhet och mer funktionalitet så är DHCPv6 ett bättre val. RA har i grunden bara stöd för att dela ut adresser men i och med tilläggen i RFC5006 så får RA utökad funktionalitet, bland annat kan man numer skicka med DNS information i RA. RFC5006 är dock fortfarande experimentell. DHCPv6 är den rekommenderade vägen att gå gällande bredbandsnät. Av spårbarhetsskäl är det viktigt att man som bredbandsnätsägare inte aktiverar RA eller DHCPv6 i delade broadcastdomäner. Spårbarheten kommer att gå förlorad och det är enkelt att sätta upp falska IPv6-routrar och DHCPv6-servrar och på så sätt skapa MITM-attacker. Dessa anledningar var de som ursprungligen startade projektet SKA, men då för IPv4, och vi vill inte att samma misstag göres för IPv6. 2.5 Typer av stads- och bredbandssnät För att kunna ge råd och tips för hur vi ska aktivera IPv6 så måste vi ta fram en lista på vilka modeller/typer av stadsnät det finns i Sverige. Vi tycker oss se att det finns sju olika typer av stadsnät, där varje stadsnätstyp som levererar egna eller andras tjänster på nivå två eller tre har olika möjligheter och utmaningar att leverera IPv6 på ett kvalitativt sätt. 6(19)
Tyvärr är det så, eller det är i alla fall vårt högst kvalificerade antagande, att det idag finns mycket få stads- eller bredbandsnät som är byggda för att hantera IPv6. Stadsnätstyper: 1. Ett vlan / kund, egen tjänsteleverantör av Internet, trafiken routas lokalt i stadsnätet 2. Ett vlan / kund, flera tjänsteleverantörer av Internet, trafiken routas lokalt i stadsnätet 3. Delad broadcastdomän, egen tjänsteleverantör av Internet, trafiken routas lokalt i stadsnätet 4. Delad broadcastdomän, flera tjänsteleverantörer på Internet, trafiken routas lokalt i stadsnätet 5. Ett vlan / kund, nivå två till tjänsteleverantörer 6. Delad broadcastdomän, nivå två till tjänsteleverantörer Sedan finns det nät med en blandning av flera typer av leveranser där det skiljer sig mellan olika accessteknologier. 3 IPv6 tunnlas över IPv4 Ett sätt att aktivera IPv6 är att tunnla IPv6 i IPv4. Det är ett snabbt, enkelt och oftast billigt sätt att få igång IPv6 i nätet. Vi behandlar här 6to4 och Sixxs Aiccu tunnlar. Det finns flera typer av IPv6-tunnlar men dessa är de som är enklast att aktivera och som du som bredbandsleverantör har bäst kontroll över. Både 6to4 och Sixxs Aiccu kan samexistera i det befintliga IPv4 nätet utan att IPv4 behöver förändras. Läs mer om IPv6-tunnlar på: http://en.wikipedia.org/wiki/ipv6#tunneling. 3.1 6to4 Om nätet inte är byggt för att hantera IPv6 så är 6to4-tunnel en väg att gå. 6to4 (RFC 3056, 3068) är en standard som Windows Vista, Windows XP, Mac OSx och Linux har stöd för och är enkel att komma igång med. 6to4 är en IPv4 anycasttjänst så även om ni inte sätter upp en egen 6to4 gateway kommer det förmodligen fungera. Fördelen med egen 6to4-gateway är att ni terminerar 6to4-tunneln så snabbt som möjligt och höjer därmed kvaliteten på IPv6-tjänsten. En egen 6to4 gateway passar bäst för stadsnättyperna 1 och 3. De andra typerna av stadsnät bör kräva att deras tjänsteleverantörer av IPv4 skall sätta upp egna 6to4 gateways. Kravet på den som har en 6to4 gateway är att de har IPv6 transit i sitt nät. 7(19)
Nackdelen med 6to4 är att det inte kan komma igenom en NAT:ande brandvägg och att stödet för 6to4 än så länge är svagt i hemmaroutrar. http://www.ipv6ready.org/ På sidan enligt ovan ser ni några routrar och de är de enda vi hittat med 6to4 stöd, förutom Apples Airport accesspunkter. Det finns en del stöd för 6to4 i opensource program som t ex DD-Wrt och Openwrt, men det är inte helt enkelt att komma igång med dem. Väljer man att inte ha någon brandvägg/router fungerar 6to4 utan problem i de nät där det är aktiverat. Router utan stöd för 6to4, 6to4 stoppas Router med stöd för 6to4 och host ansluten utan brandvägg/router En egen 6to4 gateway kan sättas upp i t ex en Ciscorouter, Linuxburk eller Windows 2003 eller nyare server. 8(19)
3.2 Teredo Teredo (RFC 4380) är precis som 6to4 en teknik för att få IPv6 konnektivitet i nät där IPv6 inte är igång. Samma typer av stadsnät, 1 och 3, kan installera en egen relä/server och de andra typerna skall ställa krav på ISP:erna att sätta upp egna servrar. Skillnaden mot 6to4 är att Teredo klarar av att adressöversättas genom en brandvägg. Teredo är som 6to4 default igång i Windows Vista om Ipv6 installeras. I Mac OS X, Linux och i *BSD måste man installera extra paket för att få det stödet. Ofta heter de paketen Miredo som är den öppna och fria implementeringen av Teredo. Nackdelen med Teredo är att Microsoft Windows Vista och XP använder servern teredo.ipv6.microsoft.com som Teredo server. Det innebär att det oftast blir långsamt att använda Teredo, då trafiken måste tunnlas lång väg innan den blir native IPv6. Detta kan man lösa genom att i nätets lokala resolvrar byta ut adressen mot vilken teredo.ipv6.microsoft.com pekar mot till en lokal Teredo-server. Man bör också uppmärksamma de legala problem som kan uppstå av det här. 9(19)
3.3 Sixxs Det finns ett antal IPv6 tunnel brookers på marknaden. Sixxs är en holländsk IPv6- tunnelbroker som kan placera lokala tunnelmaskiner i stadsnät. Fördelen med Sixxs är deras egenutvecklade Aiccu-protokoll, som jämfört med 6to4 är kan klarar en NAT:ande brandvägg/router. En annan fördel är att kunden alltid får samma IPv6 adress och den adressen är inte beroende av IPv4 adressen som 6to4 adressen är. Aiccu finns för de vanligast förekommande operativsystemen. 10(19)
4 En modell för IPv6 i bredbandsnät Detta avsnitt visar en idé om hur man kan designa nätet för att få en så bra IPv6 implementering som möjligt. En idé är att lägga hela backbone i ett prefix och på så sätt skydda den utrustningen med rate limiting och accesslistor mot DOS-attacker. Kunderna ansluts med att IPv4 och IPv6 tilldelas dynamiskt med DHCP och DHCPv6 alternativt statisk tilldelning. Kunderna tilldelas en eller flera IPv4 adresser och ett eget /48 IPv6 prefix. Om någon adressöversättning skall ske så sker det på IPv4 -> IPv4 och inget NAT-PT skall finnas i nätet. 4.1 Skydda backbone mot DOS attacker Genom att lägga alla routrar och annan nätutrustning i t ex en /48 kan vi enkelt sätta samma filter/rate-limit på alla vägar in i nätet och på så sätt skydda utrustningen för DOS-attacker. Backbone /48 Rate limit Trafik till routers etc. 11(19)
4.2 Kundaccessen Kunden måste ha en router/brandvägg som hanterar IPv4 med NAT och IPv6 DHCPv6 och DHCPv6 prefix delegation (PD). Mellan PE och CPE används IPv6 Link Local adresser. Om en delad broadcastdomän (oftast LAN) används måste samtliga punkter under rubrik 5 IPv6 med delad broadcasdomän uppfyllas. Alternativt alltid ett VLAN/kund med de tillkommande problemen i de nät som inte är designade för det från början. DHCPv6 servern placeras i PE router/switch eller i annan hårdvara. PE routern kan vara en switch lokalt placered nära kunden eller en större servicenod som hanterar tusentals kunder. 4.3 Problem/frågeställningar En kort lista på ett antal frågeställningar som vi ännu inte har klart för oss hur det ska lösas, alternativt dåligt hårdvarustöd. Link Local adress måste (eller bör?) användas mellan PE och CPE eftersom PE skyddas genom dess /48 och sätter vi kundens /48 i PE:n försvinner skyddet av PE:n. Kan PE routa en /48 mot en Link Local address? Går det att bygga med Link Local adress här eller måste vi använda global unicast? CPE måste kunna lägga ett prefix på ett loopbackinteface för management och egen access mot Internet. Finns det sådana CPE:r? Vad finns det för CPE:r med IPv6 stöd? Delad broadcastdomän alternativt ett VLAN/kund, finns idag ingen utrustning som hanterar IPv6 i en delad broadcastdomän, kommer det sådan? Finns det utrustning för delad broadcastdomän och stöd för Relay Agent Remote- ID, RFC4649? Hur ska routingtabellan uppdateras när ett /48 tilldelas? 12(19)
5 IPv6 med delad broadcastdomän. SKA 3.1 för IPv4 ställer krav som är relativt enkla att implementera i hårdvara. IPv6 är fundamentalt helt annorlunda i designen och här måste helt andra funktioner till för att vi ska kunna bygga näten med en delad broadcastdomän. 5.1 Krav Kraven återges nedan med en kortfattad förklaring på de funktioner som måste finnas på nivå två i en accessutrustning. 5.1.1 IPv6 Stateless Address Autoconfiguration ( RFC2462 ) Snooping Utrustningen måste skapa tabeller med de autogenererade link local adresserna så att inte samma adress kan finnas på flera ställen. 5.1.2 IPv6 snooping Det ska inte gå att spoofa en IPv6 adress, det är bara den som tilldelats med DHCPv6 som source IPv6 adress och link lokal adress som autogenererats som får användas som source adress. Utrustningen skapar tabeller/port för denna 5.1.3 DHCPv6 (RFC 3315) snooping Precis som i DHCP för IPv4 måste snooping av DHCPv6 meddelanden finnas så att inte falska DHCPv6 servrar kan sättas upp. De röda kundportarna skall bara kunna sända DHCPv6 client meddelanden till den gröna up-linkporten och DHCPv6 server. Eller sända DHCPv6 server meddelanden till de röda portarna. Se RFC3315 för detaljer på alla DHCPv6 meddelandena. DHCPv6 servern kan finnas i samma broadcastdomän eller bakom ett DHCPv6 relay. DHCPv6 snooping 13(19)
5.1.4 Router Advertisment (RFC 2462, RFC 5006) snooping http://ietfreport.isoc.org/idref/draft-chown-v6ops-rogue-ra/ I länk ovan finns en mängd föreslagna lösningar och Router Advertisment (RA) snooping är en av dem. RA snooping krävs för att inte falska routrar ska kunna aktiveras i nätet och på så sätt styra om trafiken dit man vill. Router advertisment RA Snooping 5.1.5 Dynamic "IPv6 neighbor solicitation/advertisment" (RFC 2641) inspection IPv6 använder IPv6 neighbour solicitation/advertisment för att mappa mac-adresser mot IPv6 adresser. Precis som i IPv4 där dynamic arp inspection krävs måste IPv6 neighbour solicitation inspekteras så att inte trafik kan styras om. Tabellen med Lokal Link och global unicast och mac-adress skapas med hjälp av DHCPv6 snooping. 5.1.6 Neighbour Unreachability Detection (NUD, RFC 2461) snooping Funktion som används typiskt för att kontrollera att default gateway fungerar. Använder normalt IPv6 neighbour solicitation/advertisment för denna kontroll. 5.1.7 Duplicate Address Detection (DAD, RFC 4429) snooping Funktion för att förhindra adresskrockar i nätet. Bara IPv6-adresser och mac-adresser som lagts till en port genom DHCPv6 snooping, enligt 4.1.3, är tillåtna att köra DAD från en port. 5.1.8 IPv6 Multicast Listener Discovery v2 (RFC 3810) snooping Multicast Listener Discovery v2 (MLD) snooping krävs för att inte multicast skall flöda fritt till portar som inte är medlem i de aktuella multicastgrupperna, t ex olika kanaler i IP-Tv. 14(19)
5.1.9 IPv6 Routing Header (RFC 2460, Next Header value 43) snooping IPv6 paket med Routing Header skall aldrig tillåtas mellan kundportar och kundportar och uplink för att förhindra att routing loopas injiceras i nätet. Se även RFC 5095, Deprecation of Type 0 Routing Headers in IPv6. 5.1.10 UPNP filtrering UPNP skall, precis som i SKA 3.1, antingen filtreras eller på annat sätt spärras mellan kundportar. 15(19)
6 Vad kan hända om vi gör fel? Nedan beskrivs ett par exempel på vad som kan inträffa i nät som inte är designade/anpassade för att leverera en IPv6-tjänst till slutkunder. Attackerna handlar precis som i IPv4 om MIM där vi i ett fall kan styra kundens trafik precis som vi vill. Attackerna är baserade på att kunderna sitter i en delad broadcastdomän, se punkt 5 för vidare info. Båda sätten som beskrivs är prövade och fungerar i nät som inte uppfyller kraven för SKA v6 eller SKA 3.1. Idag finns, vad vi känner till, inga färdiga verktyg för MIM-attacker över IPv6, som det finns för IPv4, utan hackaren måste själv sätta upp miljön. Viktigt att känna till är att de flesta operativsystem väljer IPv6 före IPv4 och på så sätt har IPv6 som det primära protokollet. 6.1 Ingen spärr av IPv6 RA Nedan är host B en IPv6-router som sänder ut RA och annonserar ett IPv6-prefix i sin broadcastdomän. Router Default Gateway Delad broadcastdomän IPv4 utan spärr av IPv6/RA RA A B 16(19)
Host A som har IPv6 aktiverat accepterar host B:s annonserade prefix och sätter host B som default IPv6 router. Nu har host A IPv6 aktiverat och host B kan avlyssna all Ipv6 trafik som dator A skickar och tar emot. Router Default Gateway Delad broadcastdomän IPv4 utan spärr av IPv6/RA IPv6 över IPv4 tunnel IPv6 A B 17(19)
6.2 Ingen spärr av DHCPv6 I bilden nedan beskrivs följande scenario Host A har IPv6 aktiverat och är även DHCPv6 klient Host B är en IPv6 router, DHCPv6 server, DNS och har NAT-PT, adress och protokollöversättning mellan IPv6 och IPv4 aktiverat. Host B kan med hjälp av DHCPv6, DNS och NAT-PT styra all IPv6 och IPv4 trafik till sig och skapa en total IPv6 och IPv4 MIM attack. 6.3 Sammanfattning De två fallen ovan visar hur otroligt viktigt det är att vi bygger rätt från början. Om det råder osäkerhet kring tillvägagångssättet med IPv6 så var försiktiga och tag hjälp av någon som kan analysera aktuellt nät. Använd tunnlar så mycket som möjligt om ni är osäkra. Det finns mindre bredbandssnät som idag aktiverat IPv6 på ett bra sätt och de använder sig av statiska tunnlar till kunder som vill ha fasta IPv6 adresser och har aktiverat en egen 6to4 gateway för att snabba upp den typen av tunnel. 18(19)
7 Projektdeltagare Jörgen Eriksson Jan Östling Mikael Abrahamson Kristian Larsson Interlan/SSNF IIS Cisco Systems Tele2 Tele2 I projektets linda skickades frågan ut till alla SKA-certifierade tillverkare om de ville medverka i detta projekt. De enda som svarade var Cisco och därför är de med i projektet. Andra intresserade får gärna bidra och kanske även delta med idéer och kunskap om hur vi skall kunna utveckla detta på bästa sätt. Allt som projektet kommer fram till kommer att publiceras på nedan angiven sida där det även finns ett diskussionsforum. http://www.ska-v6.se Projektet bekostas av Interlan,.SE, SSNF samt företagen som ställt upp med resurser i övrigt. 19(19)