Önskemål kring Studentstadens bredband och UpUnet-S

Önskemål kring Studentstadens bredband och UpUnet-S Jerker Nyberg <jeny0611@student.uu.se> HUS Kristina Repa <kristina.repa.1622@student.uu.se> HUS 12 december 2005 http://www.update.uu.se/~jerker/upunets/onskemal.pdf 1 Önskemål kring Studentstadens bredbandsnät 1.1 Terminologi port I första hand UDP/TCP-port, när det inte annat framgår av sammanhanget. protected port Ciscos term för att begränsa vilka portar i en switch som inte får prata med varandra. Kallas även port security. HP kallar en motsvarande teknik för traffic security. svartnät Slang för privata IP-adresser enligt RFC 1918. 1.2 Lista med önskemålen i prioritetsordning 1. Nätet ska fungera. 2. Det ska gå att kommunicera inom nätet. 3. Begränsningen på antalet MAC-adresser per port ska bort. Uppdatering 2005-05-20 Nu tillåts två olåsta adresser per port 4. Nätet ska förberedas för flera operatörer. 5. Pressa kostnaderna för drift av nätet. 1

Vi förväntar oss att detta ska ske inom ramen för de nuvarande avgifterna för bredbandsanslutningen. 1.2.1 Nätet ska fungera Kontrollera att buggarna i IP-Login2 som diskuterats är fixade. Kontrollera varför netlogon.student.uu.se ibland går jättesegt och tar flera minuter på sig för att presentera en websida. DNS-problem? Se till att inte någon kan köra en DHCP-server på sitt bredbandsuttag som sänker hela nätet för alla andra anslutna. Se kapitel 1.3 Säkerheten på nätet. Minimera möjligheten för illvilliga att sänka nätet med (D)DoS. Det förefaller inte omöjligt att det för en enskild användare går att sänka netlogon-servrarna genom många snabba HTTP-anrop som inte kopplas ner. En målsättning är att nätet inte ska kunna gå ner av sådana problem, bara extrem bandbreddsanvändning ska kunna störa, och då ska nätet bara bli långsammare, inte gå sönder. Inför möjlighet till personliga brandväggar på nätnivå. Se 1.3 Säkerheten på nätet. Öka hastigheten på de mest belastade länkarna. Uppdatering 2005-05-20 Utrustning beräknas anlända för att uppgradera Flogsta hög och Hamberg till två gigabitförbindelser Uppdatering 2005-06-10 Kapellgärdet har nu delats upp på två 100 Mbit/s förbindelser. Använd riktiga IP-adresser. Se kapitel 2 UpUnet-S. Uppdatering 2005-05-20 Nya IP-adresser har anlänt! Se till att det går att blockera direkt i bredbandssuttaget utan att den anslutna kan kontakta andra anslutna på samma switch så att någon som inte kan logga in på nätet inte heller kan sprida eller bli smittad av virus och maskar av andra anslutna. Se kapitel 1.3 Säkerheten på nätet. Fördela bandbredden rättvist. Se kapitel 2 UpUnet-S. Uppdatering 2005-06-10 För Kapellgärdet begränsas p2ptrafiken till halva kapaciteten vilket gör att länkarna ut inte blir överfulla. 2

1.2.2 Det ska gå att kommunicera inom nätet. Begränsningarna för kommunikation mellan vissa områden ska bort. Uppdatering 2005-04-10 Detta har lösts. Problemet berodde på felaktigheter i konfigurationen av vissa routrar. Om anslutna inom samma fastighet inte kan prata med varandra går trafiken ut på förbindelserna som sammanbinder studentbostadsområdena eller ut på Internet vilket är ineffektivt. Uppdatering 2005-05-20 Inom Hamberg och vissa hus i Flogsta hög pågår nu försök med att öppna upp trafiken inom området. Om ingen kan prata med någon alls så blir det förstås säkrare, men då faller poängen med nät. Vissa erkänt farliga portar (windowsfildelning och aktuella säkerhetshål) skulle kunna begränsas per default, men inte all trafik. Med brandväggsmöjligheter vid inloggningen så skulle varje ansluten kunna ha en individuell brandvägg i nätet. Detta rör egentligen kapitel 1.3 Säkerheten på nätet. Det kan finnas skäl till att begränsa kommunikationen direkt mellan anslutna som sitter på samma broadcastmedium, samma switch. Men det ska ändå gå att prata med varandra. Mer om det i kapitel 1.3 Säkerheten på nätet. Vid övergång till riktiga IP-adresser finns det några olika strategier för att lösa det eventuella problemet med att adresserna inom vissa områden kan ta slut. Här är fyra alternativ. 1. Se till att allokera tillräckligt med IP-adresser så att varje port får minst två adresser. Räkna med att varje ansluten har en dator och eventuellt en laptop eller IP-telefon till det. Fördel: Borde funka bra. Nackdel: Kan vara problematiskt att beställa fler adresser från RIPE. 2. Släpp bara ut en MAC-adress per port. Tilldela bara en IPadress per MAC-adress. Fördel: Funkar bra. Nackdel: De användare som har flera datorer måste köpa router med NAT. Och nu har vi (HUS) redan förhandlat med Studentstaden om att tillåta två MAC-adresser. 3

3. Fortsätt släppa ut två MAC-adresser per port, olåsta. Tilldela två IP-adresser per port. Håll ögonen öppna för det samtidiga användandet av adresserna, om det överstiger säg 90tilldela fler adresser. Fördel: Borde funka ok, de flesta klarar sig på två MACadresser och två IP-adresser. Nackdel: Om de tilldelade adresserna inom ett område tar slut så kan inga fler adresser tilldelas just då. Routingtabellerna kommer att se skumma ut när fler nät tilldelats ett visst område för att adresserna inte räckt till. 4. Som punkten ovan med tillägget: Om adresserna, mot förmodan, tar slut så tilldela svartnätsadresser till dess att fler adresser kan tilldelas det aktuella området. I övrigt samma som ovan. Fördel: Det går alltid att surfa. Nackdel: Det kan komma att tilldelas svarnätadresser om ansvarig inte hinner med att lägga till fler subnät, men alternativet är som sagt att inte få några adresser alls. ISC DHCP-server verkar inte stödja att tilldela adresser med olika prioritet. Eventuellt går det att lösa genom att köra en sekundär server med lägre prioritet, eller genom att förbereda och varna när adresserna tar slut och då temporärt ta till svartnät. 5. Tilldela svartnätsadresser till alla anslutna. Adressöversätt i yttre brandvägg. Fördel: Funkar? Nackdel: Adressöversättning, det som vi ville slippa... 6. Ge alla bara en MAC-adress och lås upp de så att de som behöver får fler MAC-adresser. Fördel: Funkar i alla lägen. Det går att se tekniskt när det har öppnats upp för fler samtidiga MAC-adresser än vad det finns tillgängliga IP-adresser i dhcp-servern och då kan man bromsa utdelningen innan det blir problem... Nackdel: Det blir svårt att börja införa en sådan begränsning, folk har börjat köra med två MAC-adresser, hur vet man vilka detta är? Och så trixigt, för att man skall kunna få sin nya burk att funka samtidigt som sin gamla så måste man anmäla det till operatören.. 4

1.2.3 Tag bort begränsningen på antalet MAC-adresser per uttag. Tag bort meningslös fördyrande (både för de anslutna och för Studentstaden genom ökad administration) begränsning på antalet MAC-adresser per bredbandsuttag då det numera inte finns någon vettig teknisk, ekonomisk eller administrativ förklaring till detta. Att det infördes en begränsning av antalet MAC-adresser har flera olika skäl. Ursprungligen var ett av skälen att det inte skulle gå att dela med sig med anslutningen till sina grannar - anslutningen skulle vara personlig. Med hjälp av dels nätinloggningen som förbjuder vidareförmedling av nätet och dels begränsningen av antalet MAC-adresser så fanns det alltså en teoretiskt möjlighet att stoppa säg en hel korridor att dela anslutning. Enligt SYSteam finns också skälet att switcharna bara kan lagra ett visst antal MAC-adresser per switchport. Genom begränsningen i antal MAC-adresser så går det att, om man har information om vilken MAC-adress som eftersöks, kunna spåra vilken switchport och därmed vilket bredbandsuttag och lägenhet en eftersökt dator är kopplad till. Det känns som att det vanligaste användningsområdet för den här typen av felsökning är om någon lägger beslag på routerns IP-adress. Genom att helt låsa antalet MAC-adresser så försvårar det att låta lura sina grannar med ARP-spoofing. Många datorer i en lägenhet drar mycket ström. Men nu till skälen varför det inte bör finnas en begränsning. Att med hjälp av antalet MAC-adresser begränsa möjligheten till att ansluta sina grannar är idag passé eftersom i princip alla hyresgäster ändå tvingas betala avgift för bredbandsuttaget. Det borde gå att regelbundet hämta den information som behövs från switcharna, säg en gång per dygn, och då nollställa de sparade MAC-adresserna. Då får man dessutom en historik istället för att förlita sig på att switcharna ska ha kvar informationen och att någon manuellt ska ut och leta när något har hänt. Begränsning i antalet MAC-adresser hjälper inte om någon snott routerns IP-adress, även om det i moderna routrar borde gå att blockera att ingen tar routerns MACadress, om det skulle hjälpa. 5

Korskopplingsskåp Operatör Ett 1 2 3 4 Operatör Två Figur 1: Uppdelning mellan operatörer på länk-nivå Alla som bor i lägenhet betalar sin egen ström, så där kan effektförbrukningen inte spela någon roll. Och om det är väldigt viktigt att begränsa detta för boende i studentrum som inte betalar sin egen ström så är begränsning med antalet MAC-adresser en ovanligt dum metod eftersom det är trivialt att gå runt det genom att använda adressöversättning. Endast en begränsning av antal MAC-adresser hjälper inte för att identifiera en viss dator. Dels kan de bytas ut, men det måste även finnas en koppling mellan <IP-adress, användare vid inloggning> eller <IP-adress, MAC-adress och switchport/lägenhet> för att kunna identifiera. Och om man har en koppling mellan lägenheterna/användare och IP-adresser så räcker bara det. Idén om att en ökning av begränsningen från en MAC-adress till ett par skulle medföra en kostnad för Studentstaden som motiverade hyreshöjning med 5 kr/mån eller vad det nu var är för övrigt absurd. 5 kr/mån för säg 6000 lägenheter ger 30000 kr/mån. Skulle det krävas mer än en en halvtidstjänst, i dessutom obegränsad tid, för att ordna till detta fel? Vansinne. 1.2.4 Förbered för flera operatörer Gör nätet operatörsoberoende. Detta går att göra på olika sätt. Här är tre förslag. 1. Uppdelning på länklagret genom att andra operatörer fysiskt sätter utrustning i korskopplingsskåpen, se figur 1. Fördel: Operatören är ansvarig för all sin egen aktiva utrustning och inga ytterligare mellanhänder behövs. Nackdel: Det kan bli ineffektivt (dyrt) att låta varje operatör ha utrustning i varje korskopplingskåp 2. Uppdelning på ethernetlagret genom att dela upp olika operatörer använda olika VLAN, se figur 2 (eller annan tek- 6

Korskopplingsskåp Local Internet Exchange 1 2 3 4 Operatör Ett Operatör Två Operatör Ett Operatör Två Figur 2: Uppdelning mellan operatörer på ethernet-nivå Korskopplingsskåp Local Internet Exchange 1 2 3 4 Operatör Ett Gemensam switch Operatör Två Figur 3: Uppdelning mellan operatörer på IP-nivå nisk lösning på denna nivå - det kan vara en fördel om operatörerna själva kan disponera alla VLAN oberoende av varandra) Nackdel: Operatörerna blir beroende av en tredje part och har inte fullständig tillgång till utrustningen. 3. Uppdelning på IP-lagret genom att olika operatörer adressöversätter de anslutnas IP-adresser till sitt nät, se figur 3. Stockholmopen.net (KTH etc) kör med något liknande. Nackdel: Adressöversättningen. Fördel: Konsolidering. Ett operatörsoberoende nät är intressant eftersom: Det är inte säkert om SUNET/UU/SLU tänker fortsätta subventionera bredband till studentbostadsområden. Även de som inte är studenter och bor inom Studentstaden kan använda bredbandsuttaget via en annan operatör. De som tar studieuppehåll kan fortsätta använda bredbandet men genom en annan operatör. För de anslutna kan andra operatörer vara intressanta genom olika erbjudanden som olika former av telefoni, olika servicenivå eller annan typ av tjänst (fasta IP-adresser, multicast etc) Om det blir ett riktigt operatörsoberoende nät, tänk då på: Det bör troligen inte vara Studentstadens uppgift att göra detta, men det kan gå att skapa en egen organisation med direkt anslutning till SUNET för de anslutna studenterna utan 7

att gå via UU på samma sätt som i Göteborg. Det är dock osäkert politiskt hur en sådan lösning kommer att hålla och hur den ska se ut, men oavsett så bör lösningen utformas för att på bästa sätt passa SUNETs framtida planer. Det bör finnas vissa minikrav hos leverantörerna som ska ansluta sig. Till exempel bör de utbyta trafik med de andra leverantörerna, gärna lokalt i Uppsala. Men samtidigt finns det intresse hos användarna att det bör finnas flexibilitet. Ska ett gäng användare kunna gå ihop och dela på en fast anslutning till nätet? Det skulle helt klart ge ökad konkurrens. 1.2.5 Pressa kostnaderna för drift av nätet Idag betalar användarna av nätet i runda slängar 750 kkr/mån för nätet. Universitetet har kostnader i runda slängar runt 2 Mkr/mån. Till detta tillkommer kostanden för Internetbandbredden och SUNET. I princip står alltså studenterna för cirka 78 1.3 Säkerheten på nätet Ethernet är ett broadcastmedium och särskilda hänsyn måste tas för att uppfylla krav på spårbarhet, säkerhet och nåbarhet inom nätet. 1.3.1 Hur nätet är trasigt idag Tanken bakom att begränsa ethernet broadcast segmenten är inte fel. Urprungligen såg nätet i princip ut så som i figur 4. Men genom att dela upp de ursprungliga ethernet segmenten i mindre delar utan at dela upp subnäten i olika ethernetnät så började nätet gå sönder. Se figur 5. Det går att laga det befintliga nätet genom att se till att de subnät som används speglar det ethernet-nät som är uppbyggt. Se figur 6. Men vad man i framtiden vill är troligen att varje användare avdelas på ett säkert sätt från alla sina grannar, på ett eller annat sätt. Se figur 7. 8

SUNET UpUnet SUNET UpUnet S UpUnet UpUnet S Hamberg Kantorn Blodstenen ingen routing ingen routing ingen routing Hamberg Kantorn Blodstenen 10.3.3/24 10.3.2/24 10.3/16 10.3.1/24 10.2.3/24 10.2/16 10.2.2/24 10.2.1/24 10.1/16 10.1.3/24 10.1.2/24 Figur 4: Från början funkade det. 10.1.1/24 Figur 5: Dagens trasiga nät. I princip. SUNET UpUnet UpUnet S SUNET UpUnet Hamberg Kantorn Blodstenen routing routing routing UpUnet S 10.3.3/24 10.3.2/24 10.3.1/24 10.2.3/24 Hamberg Kantorn Blodstenen proxy arp proxy arp proxy arp 10.1/24 10.2/24 10.3/24 10.2.2/24 10.1/24 10.2/24 10.3/24 10.2.1/24 10.1.3/24 10.1.2/24 10.1.1/24 Figur 6: Nätet lagat, eller hur det borde ha varit. 10.1/24 10.2/24 10.3/24 Figur 7: Med protected ports och proxy-arp blir nätet säkert och alla kan nå varandra. 9

1.3.2 Förslag på lösningar Subnätsuppdelning Låt trafik på IP-nivå att gå via routern genom att sätta varje ansluten, eller mindre grupper av anslutna, på ett eget subnät. Nackdel: Ineffektiv användning av IP-adresser. Fördel: Enkel teknik. Utrustning: Kräver protected port. Layer-3 switch Byt utrustning till sådan som hanterar routing i ändutrustningen. Nackdel: Dyr ny utrustning. Fördel: Hårdvarulösning. Effektiv användning av IP-adresser. Bra att trafiken stannar i switchen om den inte behöver gå ut i området. Utrustning: Kräver stöd för layer-3 switching. Bryggning mellan VLAN. Se även RFC3069 - VLAN Aggregation for Efficient IP Address Allocation. Låt varje ansluten få ett eget VLAN. Bryggning kan användas i brandväggen istället för routing Nackdel: Jobbigt att trassla med VLAN och bryggning. Bryggning inte lika vanligt som routing i brandväggar. Fördel: Effektiv användning av IP-adresser. Utrustning: Kräver VLAN. MAC-forced forwarding Se även RFC1027 - Using ARP to implement transparent subnet gateways. Genom att dels aktivera protected port i switchen samt låta routern svara på alla ARP-förfrågningar kommer all trafik att gå via routern. Detta liknar IETF-draften om MAC-Forced Fowarding men med skillnaden att routern svarar på alla ARP-förfrågningar då den inte har information om från vilken port en viss ARP-requst kommer. (Det finns eventuellt tekniska lösningar för att gå runt detta problem (att trafik som egentligen inte skulle gå via routern går via den ändå) men det är troligen inte värt besväret.) Nackdel: Trafik som skulle kunna stannat inom en anslutens egna nät kan komma att gå via routern. Fördel: Effektiv användning av IP-adresser. Enkelt att implementera. Bara routing i routern och ingen bryggning. Utrustning: Kräver att switcharna klarar protected port. Detta är den lösning HUS rekommenderar Studentstaden och UpUnet-S att implementera. PPPoE Se även RFC2516 - A Method for Transmitting PPP Over Ethernet (PPPoE). PPPoE är en möjlig lösning. Nackdel: Folk måste ändra inställningar och alla operativsystem som ska användas måste ha stöd för PPPoE. Knepigt att implementera. Stödjer inte multicast på effektivt sätt. Fördel: Effektiv användning av IPadresser. Utrustning: Okänt, men behöver antagligen byta routrar. 10

2 UpUnet-S Det nuvarande systemet med är förvirrande för nya användare. Skriv tydligare instruktioner om hur inloggning på nätet går till på lappen med användare och lösenord till UpUnet-S. Använd ett äkta certifikat så att användare slipper få frågor om att acceptera det. Koppling mellan användare och switchport (fqpn - fully qualified port name) ger fördelen att systemet med nätinloggning inte behövs längre. Många problem med netlogon (tappade inloggningar, problem med brandväggar, maskiner som startas om och utloggade användare, svårigheter att göra nätinstallationer av operativsystem, svårigheter att ansluta annat än datorer med webläsare etc) skulle då kunna elimineras. Användare skulle få riktig Internet hem. Ökad bandbredd till användaren ger generellt en bättre tjänst så länge bandbredden där flaskhalsar finns fördelas rättvist. Exempel: två fastigheter har 100 Mbit/s mellan sig. Inom varje fastighet är varje lägenhet ansluten med 10 Mbit/s. När filer delas kommer det gå lika snabbt oavsett om filen hämtas inom fastigheten eller externt. Om istället lägenheterna var anslutna med 100 Mbit/s så skulle det gå mycket snabbare att hämta filer inom fastigheten, och förbindelsen mellan fastigheterna skulle bli mindre belastad under förutsättning att mängden data som skickades var konstant. Undersök möjligheten att vid inloggning på nätet kunna aktivt scanna datorn som loggar in efter kända säkerhetshål och öppna portar. Om det behövs så skulle användaren kunna bli skickad vidare till en websida med instruktioner för uppdatering av operativsystem, installation av brandvägg och antivirusprogram. Publicera alla filtreringar i brandväggar Konkreta förslag till förbättringar. Tag bort blockering av ping. Ersätt med ratelimiting. Tag bort blockering av DNS. Tag bort blockering av NTP innan inloggning för att undvika långsam uppstart av datorer som använder NTP under uppstart. 11

Publicera trafikstatik. Trafikstatistik för studentnätet underlätta felsökning bland studenter och ökar förståelsen kring studentnätet. Använd riktiga IP-adresser i nätet istället för svartnät. Spårbarhet ökar - när någon gör något dumt ute på nätet så går det att se från vilken IP-adress det sker. Blockering av sådana elaka användare drabbar inte alla på hela nätet. Det blir enklare att bygga ett mer robust nät och det börjar bli teoretiskt möjligt att införa multicast på nätet. 2005-05-20 UU har fått nya riktiga IP-adresser, ett nät i med storlek /18 och ett med storlek /20, vilket ger totalt 20480 IP-adresser. Hurra! Gör en tidsplan för IPv6. I förlängningen - fimpa adressöversättaren. Rättvis fördelning av bandbredden Internet är gjort för att alltid kunna hantera ett överlastat nät, eller snarare, ett nät med begränsad mängd bandbredd. Det går alltid så fort det kan gå, tills en viss länk i kedjan inte klarar snabbare. Om det ändå inte fungerar tillräckligt bra bör begränsning ske genom att fördela bandbredden rättvist. Det finns ett par olika sätt att försöka fördela trafiken rättvisare: Begränsningar på protokollnivå. Nackdelar: Legitim trafik (spel, distribution av olika mjukvara etc) använder dessa protokoll. Det är svårt att inte få in godtycke. Dessutom är rättsläget osäkert. Uppdatering 2005-06-09 Detta är den lösning UpUnet-S har valt att implementera. Bandbreddskvota för användare. Nackdelar: Svårt att veta var man ska mäta - lokal trafik är billigare än trafik som går längre sträckor. Olika tider används nätet olika mycket och trafiken är värd olika mycket. (Om någon tankar filer på natten när ingen annan använder nätet, ska det då gå långsammare på dagen?) Det finns färdig utrustning som kan köpas in. Fair Scheduling. Varje router begränsar de som kör mest trafik så att de som har mindre trafik får plats utan begränsning. Färdig teknik finns till Linux. Detta är den rekommenderade metoden. 12