De achilleshiel van het internet

Het lekke border gateway protocol

De jaren tachtig

Internet stamt uit de jaren tachtig en dat is te merken. Het is geen geheim dat protocollen als tcp/ip en dns niet bepaald perfect zijn, en vandaag de dag totaal anders ontworpen zouden worden. Zo bevat tcp/ip van origine geen vorm van encryptie.

Een van de technieken die fundamenteel zijn voor de werking van internet is misschien nog wel het meest gebrekkig en tegelijk relatief onbekend. Het border gateway protocol knoopt alle individuele netwerken aan elkaar, maar doet dat op een manier die eigenlijk niet meer past bij het internet van vandaag de dag.

Om dat te kunnen begrijpen is het eerst nodig om te weten wat het bgp doet (Werk je bij een internetprovider? Ga dan gerust door naar de volgende pagina). Zonder het bgp zou het internet een grote verzameling van individuele netwerken zijn, die niet met elkaar kunnen praten. Het bgp zorgt ervoor dat netwerken elkaar kunnen vinden.

In zekere zin is het bgp vergelijkbaar met het dns. Waar het dns vertelt welk ip-adres bij een domeinnaam hoort, zorgt het bgp ervoor dat providers weten welk netwerk vervolgens bij dat ip-adres hoort. Dat is niet triviaal; het internet bestaat uit honderdduizenden netwerken, die onmogelijk altijd van elkaar kunnen weten waar ze zich bevinden. Als je zelf een eigen netwerk aanlegt met verschillende routes, kun je die nog wel handmatig invoeren, maar op internet is dat niet realistisch. Er zijn zoveel mogelijke routes, die bovendien kunnen veranderen, dat er een manier nodig is om dat te automatiseren.

Gossip based protocol

Die manier is het bgp. De wijze waarop het bgp werkt is relatief simpel. Elke border gateway protocol-router vertelt aan de bgp-routers waarmee hij is verbonden welke routes het autonomous system waarvan hij deel uitmaakt accepteert, bijvoorbeeld route 202.22.22.0/30. Autonomous systems zijn bijvoorbeeld internetproviders of grote internetbedrijven. Vervolgens vertellen die routers weer aan hun 'buren' dat je bij die router terechtkunt voor pakketjes in die reeks.

Op die manier kunnen routers volautomatisch een routingtabel aanleggen. Als een gebruiker uit Australië een website in IJsland wil bezoeken, is die route dankzij het bgp direct toegankelijk, hoewel dat een route is die waarschijnlijk weinig zal worden gebruikt. Tcp/ip of udp zorgt er vervolgens voor dat die pakketjes daadwerkelijk op hun plek komen, maar zonder bgp zouden die transportprotocollen als een kip zonder kop functioneren.

Het protocol werkt vaak prima, maar wat de opstellers van de eerste versie van het bgp niet konden bedenken, is dat internet zou evolueren tot een plek waar mensen niet per se eerlijk tegen elkaar zijn. Soms is het zelfs een gevaarlijke plek, waar mensen elkaar proberen te hacken om toegang te krijgen tot geld of data, waar criminelen actief zijn, maar ook overheden die burgers of andere overheden in de gaten willen houden.

Doordat de opstellers van het bgp dat niet zagen aankomen, en wie kan hun dat kwalijk nemen gezien de bescheiden grootte van internet in 1989, bevat het bgp geen mogelijkheid tot authenticatie. Als je een bgp-router hebt, kun je in principe elke route aankondigen die je wil. Vervolgens vertellen alle routers waarmee je een verbinding hebt gemaakt dat weer door aan andere routers. "We noemen het bgp daarom ook wel een gossip based protocol", zei Andree Toonk van BGPmon op de Black Hat-beveiligingsconferentie, begin deze maand in Las Vegas.

Foto op frontpage: Stilfehler

Problemen

Het gebrek aan controle door het bgp levert problemen op. Een internetprovider kan per ongeluk een fout maken. Een voorbeeld hiervan betreft een Nederlandse provider die IPv4-adressen (deze zijn eindig) aan een Palestijnse provider had verkocht. De Nederlandse provider was vergeten om zijn routers aan te passen. Verkeer naar de Palestijnse provider werd daardoor omgeleid via Nederland.

Afbeelding: Andrew Gallo

Een berucht incident komt uit 2008, toen Pakistan per ongeluk YouTube wereldwijd twee uur uit de lucht haalde. Pakistan wilde YouTube blokkeren, maar kondigde dat per ongeluk ook aan de rest van de wereld aan. In hetzelfde kader kondigde een Turkse provider in 2004, waarschijnlijk eveneens per ongeluk, aan de rest van de wereld aan in feite het hele internet te zijn en dat iedereen voor alle routes bij hem terecht kon.

Er zijn talloze voorbeelden te vinden van gevolgen van gemaakte fouten met het bgp protocol. Doug Madory van dns-provider DynDNS heeft veel onderzoek gedaan naar bgp-aanvallen. "In maart was er bijvoorbeeld een incident waarbij een provider in Oekraïne adressen voor British Telecom aankondigde", aldus Madory tegen Tweakers. Door de foutieve announcement maakte verkeer dat voor British Telecom was bedoeld een omweg via Oekraïne. "Ik weet niet of dat met opzet was of per ongeluk", zegt hij. Daarbij ging het om verschillende klanten van BT, waaronder Coca-Cola en T-shirtmaker Fruit of the Loom, maar ook om het atoomagentschap van het Verenigd Koninkrijk.

Doordat het verkeer via Oekraïne verliep, zou de Oekraïense provider die het verkeer accepteerde een man in the middle-aanval kunnen uitvoeren en verkeer kunnen onderscheppen of zelfs manipuleren. Dat gaat redelijk ver en websites versleutelen helpt daar niet tegen; de onderscheppende partij kan immers een ssl-stripping-aanval uitvoeren, waarbij hij zelf als client voor het ssl-verkeer functioneert en het onversleuteld doorsluist naar de klant, die dan goed zou moeten opletten of het slotje in zijn browser ontbreekt. Daarnaast kan een onderscheppende provider malware toevoegen aan een webpagina.

Ssl-hacken

Volgens Doug Madory wordt bgp-hijacking in de praktijk bijvoorbeeld gebruikt om spam te verzenden met andermans ip-adressen, om malware te verspreiden of om botnets aan te sturen. Het bgp kan echter evengoed worden gebruikt voor interessantere aanvallen. Een voorbeeld daarvan is het aanvragen van ssl-certificaten. Om een certificaat te kunnen bemachtigen moet je bewijzen dat een domein van jou is. Dat kan bijvoorbeeld door een document met een code te uploaden naar een webserver, waarna de certificaatautoriteit controleert of de code echt op de webserver staat. Ook kan het via een e-mailtje.

Wat als je de communicatie tussen de certificaatautoriteit en de webserver kunt onderscheppen? Maar wat als je de communicatie tussen de certificaatautoriteit en de webserver kunt onderscheppen? In dat geval kan een aanvaller net doen alsof hij een website bezit, doordat hij de verbinding in zijn beheer heeft, en kan hij een valse verificatiepagina serveren aan de certificaatautoriteit, die vervolgens een valide certificaat genereert. Dat scenario werd geschetst door beveiligingsonderzoeker Artyom Gavrichenkov op Black Hat in Las Vegas.

Het vals bemachtigde ssl-certificaat werkt vervolgens op álle verbindingen ter wereld, niet enkel op de onderschepte. Hoewel dit aanvalsscenario misschien niet waarschijnlijk is - een aanvaller moet in de praktijk bovendien de verbinding van een slachtoffer kunnen onderscheppen om het valse certificaat te injecteren - toont het wel aan dat bgp-hijacking onverwachte gevolgen kan hebben.

Volgens Madory gebruiken aanvallers daarnaast bgp-hijacking om hun sporen te wissen. "Ip-adressen worden vaak gebruikt om aanvallen te herleiden", aldus Madory. "Maar met bgp-hijacking word je om de tuin geleid."

Oplossingen

Zijn we dan aan de aanvallers overgeleverd? "Er is geen techniek om bgp-hijacking te voorkomen", zegt Doug Madory van dns-provider DynDNS. Omdat het bgp zo'n fundamenteel deel uitmaakt van internet, is het lastig te vervangen, dus is de kans klein dat het bgp binnen afzienbare tijd door iets beters wordt opgevolgd. Zie bijvoorbeeld hoe lang het duurt voordat ipv4 is vervangen door ipv6.

Wel worden er maatregelen genomen om het gebrek van het bgp met behulp van pleisterwerk te repareren. Zo zijn er bgpsec en rpki. Met rpki kunnen bgp-updates cryptografisch worden ondertekend, zodat er geen valse updates kunnen worden uitgevaardigd. "Je legt dan eigenlijk lijsten aan van wat er mag gebeuren met je ip-adressen", zegt Erik Bais van netwerkprovider A2B Internet. Daardoor kan worden gecontroleerd of een bepaalde provider ook echt geautoriseerd is om de route-updates uit te vaardigen. Bgpsec draait bovenop rpki; met behulp van de geografische caches kan de authenticiteit van bgp-updates worden gecontroleerd.

Bgpsec heeft een groot nadeel: het protocol werkt enkel als twee providers ze ondersteunen, anders is het nog steeds mogelijk om valse route-updates uit te geven. Veel providers ondersteunen de standaard nog niet, waardoor bgpsec op dit moment geen waterdichte oplossing is. "Ongeveer 35 procent van de autonomous systems ondersteunt rpki", zegt Bais. "Providers moeten natuurlijk wel meedoen."

Een ander probleem is dat niet alle bgp-routers rpki al ondersteunen. "Juniper en Cisco hebben nu software voor hun routers die rpki ondersteunt", zegt Bais, die zelf heeft meegeschreven aan een aanbevelingsdocument over de integratie van rpki. Daarnaast moet ook de hardware compatibel zijn. Cryptografisch ondertekende route-updates kosten meer rekenkracht om te worden verwerkt dan updates in platte tekst.

Het enige wat er dan nog opzit, is filtering toe te passen. Zo kunnen providers filtering toepassen om te voorkomen dat bgp-routers van klanten verkeerde announcements de wereld insturen. Ook kunnen vreemde announcements van andere providers in de gaten worden gehouden, bijvoorbeeld met een tool als bgpmon. Een groot nadeel daarvan is dat het altijd achteraf is; pas als een announcement wordt gedaan kan actie worden ondernomen. Bovendien is het allerminst waterdicht; er kunnen altijd verkeerde aankondigingen doorheen glippen.

Ook is het onmogelijk om op álles te filteren. Zeker op grote internet-exchanges en bij grote internetbedrijven is dat technisch niet mogelijk, stelt Bais. "Een grote partij als Hurricane Electric heeft zoveel verschillende klanten dat ze niet alles kunnen filteren", zegt Bais. "Dan loop je tegen de limieten van hardware aan, waardoor niet alles nog kan worden gefilterd."

Een Nederlandse internetprovider is daarom bezig met een waarschuwingssysteem dat de provider in een eerder stadium op de hoogte moet stellen van bgp-hijacking. "Maar dit bevindt zich nog in de ontwikkelingsfase", aldus het hoofd beveiliging van die provider, die vanwege de gevoeligheid van het onderwerp niet bij naam genoemd wil worden.

Al met al is er, althans op dit moment, geen waterdichte oplossing voor bgp-hijacking. Als bgpsec en rpki eenmaal goed zijn ingeburgerd en alle providers daarop zijn overgestapt, zijn de problemen grotendeels opgelost, al valt zelfs dan niet uit te sluiten dat een malafide provider zonder ondersteuning van die protocollen valse updates uitvaardigt.

Reacties (154)

[Verwijderd]

Ik word niet zo blij van dit artikel.
Ik word vooral niet blij van de toon van dit artikel.

Er wordt hier gesuggereerd dat BGP oud, slecht, onflexibel, onverbeterbaar en achterlijk is. Het tegendeel is waar. BGP is misschien wel het allerbeste protocol van allemaal. Ik durf te stellen, zonder BGP was er geen Internet geweest. En geen Tweakers.


BGP stamt uit 1989. Ik kan je verzekeren dat mensen als Rekhter (ik ken hem een beetje) en Lougheed echt wel wisten waar ze mee bezig waren. En beseften toen zeker al hoe hard het net toen al groeide. Echter, het zijn twee mensen met een hele praktische inslag. Kijken welk probleem moet worden opgelost, simpel beginnen, iets bouwen dat werkt, en daar op verder bouwen. BGP2 and BGP3 waren van korte duur. In 1993 kwam BGP4. In 1994 was iedereen over van BGP3 naar BGP4.

We gebruiken nog steeds BGP4. Dat is niet omdat BGP4 moeilijk te vervangen is. In tegendeel, je zou BGP incrementeel kunnen vervangen. Stukje hier, stukje daar, met "translators" aan de grenzen van de BGP4 en BGP5 eilandjes. Tot iedereen over is. Maar dat is niet nodig. BGP4 is zo'n beetje het meest flexibele, en extensible protocol dat er is ! BGP4 is tientallen keren veranderd en uitgebreid, en we noemen het nog steeds BGP4. Van enkel IPv4 zijn we gegaan naar IPv6, VPNs, MPLS en multicast. Je kunt makkelijk ieder protocol toevoegen dat je wilt. We hebben later route-reflectors, peer2peer authenticatie en encryptie toegevoegd. Communities. Outbound filtering (je buur vertellen wat hij moet filteren). Tools voor blackholing van DOS traffic. Graceful restart. 65k ASNs niet genoeg ? We hebben nu 4-byte ASNs. Geen probleem. Allemaal substantiele verbeteringen. Zonder dat we een nieuw protocol nodig hadden, zonder transitions of flag-days. 22 Jaar ontwikkeling, en we noemen het beestje nog steeds "BGP versie 4". BGP4 is awesome !

Daar komt bovenop dat BGP het meest misbruikte protocol van allemaal is. 564 DUIZEND prefixes in the Default-Free-Zone. (DFZ is het "midden" van het Internet, waar je geen default routes kunt gebruiken, en alle routes moet kennen die er wereldwijd zijn). Het was nooit de bedoeling dat iedereen gewoon een half miljoen prefixes in BGP zou gooien. Maar de gebruikers (ISPs, etc) bleven en blijven maar meer en meer prefixes in het systeem gooien. Omdat dat zo lekker makkelijk is Terwijl iedereen weet dat dat niet goed is. En BGP blijft werken. Klaagt nooit. Geen probleem. 10k, 100k, 500k, over een tijdje 600k. Waar stopt het ? Bij 12 miljoen /24's ? BGP echter blijft werken. En snel ook nog. Probeer een 500k routes in OSPF te doen. Of in RIP. Veel succes.


Er zijn hier twee fundamentele problemen. En die hebben niks met BGP te maken. Als iemand een oplossing voor die problemen had, dan zou BGP ze waarschijnlijk makkelijk kunnen uitvoeren. Zonder dat er een nieuwe versie van het protocol nodig is.

Probleem 1).
Hoe vertrouw je iets wat iemand aan de andere kant van de wereld heeft gezegd ? Je kunt je buren vertrouwen. Je kunt encryptie en authenticatie doen met je buren (wat al heel lang gebeurd). Dat wil niet zeggen dat je ook kunt vertrouwen wat je buurman van je buurman van je buurman heeft gezegd. Dit is niet BGP's probleem. Dit is ook niet een probleem dat makkelijk op te lossen is. (Anders hadden we onderhand wel simpele oplossingen gehad). RPKI is een stap in de goede richting. Echter, als ik het goed begrepen heb, is RPKI zelf ook niet perfect. En daarom zijn er ISPs die het niet willen gebruiken. Want een hoop moeite, en je blijft nog steeds vertrouwen op vertrouwen.
Laat iemand eerst dit probleem oplossen. En dan zal BGP4 die oplossing direct gaan gebruiken.

Probleem 2).
Applicatie developers verwachten dat een ip-adres een vorm van authenticatie is. En dat is het niet. Een ip-adres is enkel een adres. Een zogenaamde "locator". Het vertelt je waar iemand is. Niet wie iemand is. Een adres is geen identifier. Er zou een scheiding in semantiek moeten komen tussen "locator" en "identifier". Daar zijn oplossingen voor verzonnen. Er zijn nieuwe protocols verzonnen en geimplementeerd. Voor zowel IPv4 als IPv6. Google eens op LISP en ILNP. Maar de acceptatie van die protocollen gaat niet snel. Als we locator-identifier separation zouden hebben, en goede authenticatie/encryptie in applicaties, dan wordt BGP hijacking een veel minder groot probleem. Er zou dan nog steeds een DOS probleem zijn. Maar het security probleem zou dan zijn opgelost.

Maar om alles op het bordje van BGP te schuiven, en hard te roepen: BGP IS KUT, dat strijkt me echt tegen de haren.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Lupusceleri]

Gryz, top post.

Met betrekking tot probleem 1: iedereen kan met gemak bij hun RIR zoals RIPE/ARIN/APNIC/LACNIC/AFRINIC voor de eigen address space RPKI Route Origin Authorisations aanmaken en de wereld in sturen. De RIR's zijn de instanties die de address space aan ISPs (LIR) toewijzen en dus precies weten wie de echte eigenaar van een block address space is.

Veel netwerken hebben nog geen ROA's gemaakt, en daarom kun je bij de implementatie van RPKI eigenlijk alleen prefixes met een invalid ROA blokkeren terwijl je de prefixes zonder ROA gewoon moet accepteren. Je kunt een ISP immers niet van 93% van het internet afsluiten.. http://rpki-monitor.antd.nist.gov/

Maar het echt grote probleem met RPKI verification is het feit dat niet iedere ISP het implementeert. De reden daarvoor kan zijn dat er gewoon geen animo voor is binnen de organisatie, maar er zijn ook router vendors die RPKI verification helemaal niet ondersteunen (zoals Brocade en Microtik) ook als hun klanten wel graag RPKI zouden willen implementeren. Bij een route hijack zullen deze ISPs de prefix alsnog accepteren en doorgeven, ondanks het feit dat er een invalid ROA is!

Je beschermt hier dus niet het slachtoffer van de prefix hijack mee (bijvoorbeeld Google als Pakistan besluit om YouTube te blokkeren), want die hebben nog steeds downtime voor een deel van hun klanten bij eyeball ISPs die geen RPKI implementeren. Maar de Certificate Authority die RPKI implementeert kan natuurlijk van een IP block met invalid ROA geen e-mails ontvangen, dus dat probleem vang je hier mee af.. :-)

================================================

Nota bene dat trouwens ROA alleen de route ORIGIN valideert. Als een netwerk een prefix hijacked waarbij het origin AS nog wel klopt, maar het AS path niet meer, beschermt RPKI je daar niet tegen. Bijvoorbeeld: http://research.dyn.com/2...ral-damage-of-tmnet-leak/

[Verwijderd]

Gryz, top post.

Dank je wel. Ik ben soms bang (altijd bang) dat ik maar een oude chagerijnige gek ben die weer wat te zeiken heeft. Goed om te horen dat dat meevalt.

Bedankt voor je view vanuit de praktijk. Vooral je opmerking "dat trouwens ROA alleen de route ORIGIN valideert" was heel nuttig voor mij. Het was lang geleden dat ik naar RPKI en dergelijken had gekeken. Je opmerking was geheel to the point. En eigenlijk de ontkrachting van de kern van het artikel van Joost Schellevis. Hij klaagt over BGP, maar eigenlijk weten we nog steeds niet hoe het probleem echt op te lossen.

[polthemol]

het trust-issue, als je dat opgelost krijgt, dan los je een probleem op wat niet alleen speelt met netwerken (of software for that matter), maar zelfs met zakendoen of wat dan ook in het offline leven.

Misschien is het enige wat het echt kan oplossen dat er een vorm van een trackrecord wordt bijgehouden. "buurman van mijn buurman" heeft in ~90% van de gevallen goede updates of informatie gegeven, dus ik vertrouw hem niet helemaal en zijn update wordt een last resort voor me als ik andere opties heb.

[the_stickie]

Men noemt iemand expert omdat die persoon meer weet over een onderwerp.
Een echt expert noemt zichzelf zelden expert omdat die beseft dat ie lang niet alles weet en angst heeft 'ontmaskerd' te worden door iemand die nog meer weet, de 'echte' expert...

Om maar te zeggen dat angst en bescheidenheid maskerade kunnen zijn voor echte expertise. Ik ben alvast zeer blij met jouw gefundeerde mening!

/offtopic

[bogy]

de zelf-propagerende experts weten vaak een pak minder; dat merk ik zelf ook als ik pc's herstel waar de zogenaamde computerexpert van de familie aan gewerkt heeft en bv een bios paswoord heeft opgezet...
als je dan niet van usb kan booten en wel moet booten dan moet je dus die expert bellen en die weet dan niet meer welk wachtwoord hij gebruikt heeft.
als je dan vraagt waarom die een wachtwoord op het bios gezet heeft krijg je zo'n antwoord als; jamaar ik wou niet dat mijn nonkel (oom voor de nederlanders) in de bios kon om de pc onbruikbaar te maken...

is dus dikke bs want elke keer ik in een bios ga bij een standaard pc gebruiker krijg ik te horen dat ze dat scherm nog nooit gezien hebben; niemand die me ooit vertelde van "ah ja, daar ben ik ook al in geweest maar ik kon het probleem niet oplossen of vinden"

computer "experts" die op andermans systeem een wachtwoord achterlaten doen dat in mijn ogen als soort van 'handtekening'... zodat er iets op die pc achterblijft dat van hen is en in sommige gevallen iets waardoor de gebruiker afhankelijk blijft. Dat vind ik een not-done praktijk; het is de gebruiker zijn systeem en behalve waarschuwen voor de gevaren en zeggen wat ze beter niet mogen doen heb jij je niet te moeien met hun systeem of wat ze ermee mogen/kunnen doen. Enkel als de pc constant onder jou hoede staat kan je een wachtwoord gebruiken; bv om de gebruiker zelf een user-account te geven zodat ze niets kunnen installeren en je ook virussen via de beenhouwerij van rosse mia kan buitenhouden. Maar je moet dan wel echt ook die pc beheren en zorgen dat die up to date blijft en er dus een geldige reden is waarom jij beheerder bent en niet de eigenaar/hoofdgebruiker. (zo is de pc van mijn vader voor hem ook maar een userland; maar hij is dan ook totaal niet mee. Na 10 jaar en 2 computers verder weet hij nog altijd niet wat een update betekent, een adresbalk gebruiken kan hij niet 'google is internet', mailen lukt nog wel maar hetgeen waar hij het allerbeste in is... dat doet hij als niemand kijkt..; naar de beenhouwerij van rosse mia gaan waar het stikt van virussen en andere computermicroben... Als hij admin zou zijn, kon ik elke week zijn pc herinstalleren... nu is alleen zijn gebruikersaccount enorm traag tov de andere accounts; duidelijk gevolg van de honderden pogingen vna malware dat zichzelf probeert te installeren en restanten achterlaat. In zo'n geval is het dus gerechtvaardigd dat jij een wachtwoord op een pc zet; anders doe je dat niet.

Ik noem mezelf ook nooit dé expert of verklaar dat ik alles weet... ik ben gewoon een computerhersteller en heb zo'n 23 jaar ervaring in m'n backpack zitten... ik lees tweakers en heb alle gangbare windows-os'en in gebruik en werk ook met linux en installeer dit ook voor gebruikers waar het aangewezen is (xp bakken bvb; daarmee kunnen ze terug bankieren, inloggen bij de overheid middels e-ID, etc). Er is altijd wel iemand die dingen weet die jij niet weet, er is ook geen wedstrijd van 'het meeste expertise". Ik probeer gewoon altijd zo goed mogelijk m'n vak te doen en bij te blijven met alles wat er in het wereldje aan de hand is. Het enige waar ik over zou durven zeggen dat ik een expert ben; is dat ik een expert ben in het uitleggen in mensentaal wanneer het op IT aankomt, al is dat volgens mij geluk bij je talenten dan iets wat je jezelf kan aanleren. Ik ken namelijk zeer goede techniekers, maar vraag ze niet teveel of ze worden pissig, verliezen concentratie of beginnen je gewoon straal te negeren. Mij mogen ze alles vragen...

[PcDealer]

Ik ben ervan overtuigt dat je een goed punt aanhaalt, maar je gebruikt zoveel afkortingen zonder uitleg dat het voor mij als leek helemaal niets toevoegt aan de discussie.

[Lupusceleri]

Dan op verzoek even wat extra uitleg:

IANA uit Amerika is de naam van de organisatie die IP addressen toewijst. In het begin ging dat per eerste nummer van een prefix, en zo kan het bijvoorbeeld gebeuren dat Daimler/Mercedes-Benz heel 53.0.0.0/8 in handen heeft (aka 16 miljoen IPv4 addressen): http://www.iana.org/assig.../ipv4-address-space.xhtml

Toen zijn er Regional Internet Registries gekomen zodat men beter de address space kon verdelen:

- RIPE NCC voor Europa, Midden-Oosten en Rusland
- ARIN voor Noord-Amerika en de Caribbean
- APNIC voor Azië/Pacific/Oceania
- LACNIC voor Zuid-Amerika
- AfriNIC voor Afrika

Deze RIR's krijgen van IANA hele grote blokken IP space en andere Internet resources zoals AS nummer toegewezen. Het is de taak van de RIR om deze vervolgens aan ISPs uit hun regio toe te wijzen, en ISPs die lid zijn van een RIR noemen we LIR (Local Internet Registry). Omdat een RIR altijd weet aan wie ze een block IP space toewijzen kunnen zij dus uitstekend als authority dienen voor RPKI (Resource Public Key Infrastructure) delegations. Eigenlijk dient de RIR dus een beetje als certificate authority voor IP space zoals bedrijven a la Verisign of Comodo dat voor SSL zouden doen.

Wanneer jij als LIR zijnde dus een IP block van een RIR hebt gekregen mag je daar een RPKI certificate voor maken waarin staat welk AS nummer dat IP block het internet op mag sturen, en dat noemen we een Route Origin Authorization (ROA).

Als jouw IP block door een ander AS nummer dan wat er in de ROA staat het Internet op wordt gestuurd klopt de Route Origin niet, en wordt hij dus door RPKI als invalid bestempeld.

[Reactie gewijzigd door Lupusceleri op 22 juli 2024 14:22]

[WhatsappHack]

Toch vind ik het een enigszins eng idee dat je dan weer moet vertrouwen op slechts 1 instantie... Single point of failure, en single point of entry. En dan maar de vraag hoe betrouwbaar de instantie is, en of er niet gerotzooid wordt. Al is dat snel te detecteren, maar toch...

[Lennie]

Het lijkt erger dan het is.

1. IANA doet bijna niks, zij verdelen alleen IP-adressen in hele grootte blokken over de regios. Ze hebben niks te vertellen over wie/wat/waar/whatever

2. De RIRs doen het echte werk en daarvan hebben we er 5. Zij zijn eigenlijk een soort vereniging van netwerk-providers. De providers bepalen wat er gebeurt (door beleid te maken), niet de RIR zelf. In ieder geval zo gaat het in Europa (dus bij RIPE).

Het Internet wordt niet alleen voor peer2peer protocollen gebruikt, het is van peer2peer organisatie structuren en protocollen gemaakt.

[WhatsappHack]

Ja ik weet hoe dat werkt; ik bedoelde meer dat we die vijf als een soort CA moeten gaan zien. Per regio is dat er 1, en dus 1 bedrijf/organisatie.
Dat zint me niet zo.

[Lennie]

Als je je er heel erg in de techniek gaat verdiepen blijkt dat de provider de CA is voor zijn eigen certificaat.

Maar goed, organisatorisch gezien is dat wel 1 CA per regio.

Je kunt trouwens ook wel een IP-blok of AS-nummer vanuit een andere regio krijgen. Je moet daar dan registeren, betalen, etc. Misschien moet je wel in die regio een 'brievenbus' bedrijf hebben.

Maar hoe dan ook, als het echt moet, kan een heleboel.

[thegve]

Als ik het goed heb (*) worden die blokken uitgegeven aan organisaties in de regio van een RIR, maar vervolgens kunnen ze wel vrij worden verhandeld. Van een training waarbij BGP ook kort voorbij kwam begreep ik dat dit een levendige handel is tegenwoordig en er soms zelfs bedrijven worden overgenomen puur vanwege de address space die ze hebben.
Via het linkje dat even hiervoor werd gepost met address spaces zie ik dat 1 van de 2 blokken dat wij van onze provider/LIR hebben gekregen, in Nederland, aan de ARIN toebehoord, dus een Amerikaans blok. Het andere blok is wel RIPE.

[Lennie]

Ja dat klopt, sommige mensen in RIPE hebben hard gewerkt om transfer, zoals het volgens mij heet, mogelijk te maken.

Daarna hebben de andere RIRs dergelijke ideeen overgenomen en daarna is het ook mogelijk geworden dat zelfde te doen tussen regios.

Ik had het dus vooral over de afhankelijkheid van de RIR, die is er dus niet als je redelijk makkelijk ergens anders 'zaken' kunt doen.

En als je 1 maal een IP-blok en AS hebt kun je die overal op de wereld gebruiken zoals je zelf wilt. Die zijn niet regio gebonden.

(kan wel zijn dat bij aanvraag van nieuwe IP-blokken daarna ze moeilijk gaan doen - je moet namelijk verantwoorden als je een IP-blok aanvraagt)

[Verwijderd]

Dit is geen simpele materie. Het probleem is al 20 jaar bekend. Er wordt al 20 jaar over nagedacht en gexperimenteerd. En er is nog steeds geen echte perfecte oplossing. Je kunt hier niet over praten zonder met een hoop technische termen te gooien.

RIR = Regional Internet Registry, die delen ip adressen uit.
RIPE in Europa, APNIC in Azie, Arin in Noord Amerika, etc.

RPKI is een database waar iedere ISP hun netwerken in kan registeren, met cryptografische authenticatie. Echter, niet alle ISPs gebruiken dit (al).

ROA = Route Origination Authorizations (zie RPKI). ROAs zijn de inhoud van die database van RPKI. De informatie welke ip addressen van wie zijn, en door wie geadverteerd mogen worden.

Een prefix is een reeks ip adressen. Bv 180.180.180.0 tot en met 180.180.180.255. Die reeks noemen we 180.180.180/24. Dat is een prefix. De woorden "prefix", "route", "path", "advertisement", "announcement" zijn allemaal ongeveer hetzelfde, maar gebruik je net in een andere context.

We hebben het hier over "bleeding edge technology". Dan duurt het altijd eventjes voor je je hebt ingelezen. Ik ben zelf meer van de theoretische kant van routing. Ik heb nooit voor een ISP gewerkt, en de praktische kanten gezien. Lupusceleri geeft ons info vanuit die invalshoek.

Lupusceleri's opmerking dat "trouwens ROA alleen de route ORIGIN valideert" is erg belangrijk. RPKI vertelt je dus alleen wie de originele bron van een prefix is. Dan kun je niet zeggen: "ik ben google, en je moet google's traffic hier heen sturen". Maar je kunt wel zeggen: "google zit direct achter mij, dus als je snel traffic naar google wilt sturen, dan moet je het via mij sturen". Bijna net zo erg. En dat is een van de redenen dat RPKI misschien toch niet zo'n goede oplossing is. Niet perfect in ieder geval.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Lennie]

RPKI is gewoon een eerste stap, een laag waarop andere lagen opgebouwd kunnen worden. Tevens zorgt het er voor dat als je wat opzoekt bij een RIR met whois dat je zeker(der) weet dat de informatie die daar staat ook klopt. Dat is/was bij sommige registries nog wel een probleem (in het verleden ?).

[koelpasta]

maar je gebruikt zoveel afkortingen zonder uitleg dat het voor mij als leek helemaal niets toevoegt aan de discussie.

Maar hoeveel moeite is het om het even op te zoeken?
Ik bedoel, netwerken kun je niet leren zonder dat je gigantische hoeveelheden afkortingen tegenkomt.
En daarbij is het internet natuurlijk een ideale bron om iets over het internet te leren.

[Verwijderd]

Ik word niet zo blij van dit artikel.
Ik word vooral niet blij van de toon van dit artikel.

Er wordt hier gesuggereerd dat BGP oud, slecht, onflexibel, onverbeterbaar en achterlijk is. Het tegendeel is waar. BGP is misschien wel het allerbeste protocol van allemaal. Ik durf te stellen, zonder BGP was er geen Internet geweest. En geen Tweakers.


BGP stamt uit 1989. Ik kan je verzekeren dat mensen als Rekhter (ik ken hem een beetje) en Lougheed echt wel wisten waar ze mee bezig waren. En beseften toen zeker al hoe hard het net toen al groeide. Echter, het zijn twee mensen met een hele praktische inslag. Kijken welk probleem moet worden opgelost, simpel beginnen, iets bouwen dat werkt, en daar op verder bouwen. BGP2 and BGP3 waren van korte duur. In 1993 kwam BGP4. In 1994 was iedereen over van BGP3 naar BGP4.

We gebruiken nog steeds BGP4.

In 1994 kon je niet voorzien dat deze problemen zouden ontstaan. Ook omdat het internet nog erg klein was en het er nog niet naar uit zag dat internet door iedereen gebruikt zou gaan worden.

Het is IMO een slechte zaak dat het bij een protocol versie van 1994 is blijven hangen.

Ik durf te stellen dat als er geen BGP zou er iets anders zijn.

Tevens zou BGP gemakkelijk te vervangen zijn, je zou met een dual stack device kunnen werken dat zowel BPG aankan en het nieuwe veiligere protocol. Dit is veel gemakkelijker dan het vervangen van ipv4 door ipv6, omdat het puur een router feestje is terwijl ipv4 naar ipv6 het hele internet end to end betreft routers tm computers, smartphones etc.

Sorry dat ik het zeg maar mensen die vooral met routers bezig zijn, houden zich IMO minder bezig met beveiliging dan de mensen die zich met firewalls en systeem beveiliging bezig houden, puur omdat ze zelf minder last hebben van de gevolgen.

[Verwijderd]

In 1994 kon je niet voorzien dat deze problemen zouden ontstaan. Ook omdat het internet nog erg klein was en het er nog niet naar uit zag dat internet door iedereen gebruikt zou gaan worden.

Welles.
Niet iedereen heeft een totaal gebrek aan voorstellingsvermogen.

Het is IMO een slechte zaak dat het bij een protocol versie van 1994 is blijven hangen.

Nietes.
Je begrijpt duidelijk niet wat de woorden: flexible en extensible betekenen.

Ik durf te stellen dat als er geen BGP zou er iets anders zijn.

Zeker. Maar het is de vraag of dat zo goed zou zijn geweest als BGP4.

Tevens zou BGP gemakkelijk te vervangen zijn

Dat schreef ik al.
En het is niet gebeurd.
Omdat BGP4 zo awesome is, dat de opvolger hoogst waarschijnlijk niets meer te bieden zou hebben gehad. Als je het hier niet mee eens bent, geef dan eens *1* voorbeeld van iets dat BGP niet zou kunnen.

Sorry dat ik het zeg maar mensen die vooral met routers bezig zijn, houden zich IMO minder bezig met beveiliging

Sorry dat ik het zeg, maar het is 100% juist dat mensen die zich met routers zich helemaal niet druk maken over end-user security.

Routing is layer-3. De zgn "network-layer". Routing zorgt er voor dat data die verstuurt wordt, aankomt op de bestemming. Ongeacht waar op het netwerk.

Als je security wilt, dan doe je dat maar op layer-7. Of in je applicatie. Of misschien in layer-6 of layer-6.5. Zie mijn comments elders op deze pagina. Routing is al moeilijk genoeg. Als de routing layer ook al voor authenticatie zou moeten zorgen, dan wordt het helemaal een gecompliceerde janboel.

Een van de architectonische principes van het Internet is: slimme endstations, dom netwerk.

Als jij denkt het beter te weten, kijk dan eens naar alle vormen van netwerking die de PTTs en Telcos van vroeger wilden. Die wilden allemaal domme endstations (een simpele draaischijf-telefoon) en slimme netwerken. Resultaat: 1 euro per minuut om 56Kbps naar de US te doen.

Als je zo graag security en authentication in je application wilt hebben, bouw het lekker zelf. En laat routers gewoon pakketjes forwarden. Simpel.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Verwijderd]

[...]

Welles.
Niet iedereen heeft een totaal gebrek aan voorstellingsvermogen.

Dat heeft helemaal niets met gebrek aan voorstellingsvermogen te maken. Ze dachten dat DNS voldoene zou zijn. Nu blijkt dat DNSSEC nodig is.

[...]

Nietes.
Je begrijpt duidelijk niet wat de woorden: flexible en extensible betekenen.

Wat is dat voor een onzin. BGP4 ondersteund geen encryptie en authenticatie, en is ook niet via flexible en extensible toegevoegd.

[...]

Zeker. Maar het is de vraag of dat zo goed zou zijn geweest als BGP4.

Dat ligt er maar aan hoe kritisch je naar het protocol kijkt. Of alleen naar het goede kijkt of ook de mindere zaken wil zien.

[...]

Dat schreef ik al.
En het is niet gebeurd.
Omdat BGP4 zo awesome is, dat de opvolger hoogst waarschijnlijk niets meer te bieden zou hebben gehad. Als je het hier niet mee eens bent, geef dan eens *1* voorbeeld van iets dat BGP niet zou kunnen.

Dat waag ik te betwijfelen, IMO is de reden veel meer dat Cisco zeker in die tijd een monopolie had. En geen behoefte had aan verandering.

[...]

Sorry dat ik het zeg, maar het is 100% juist dat mensen die zich met routers zich helemaal niet druk maken over end-user security.

Routing is layer-3. De zgn "network-layer". Routing zorgt er voor dat data die verstuurt wordt, aankomt op de bestemming. Ongeacht waar op het netwerk.

En daar gaat het nu net fout. Omdat BGP niet meer van deze tijd is. Zoals je zegt interesseert deze security netwerk beheerders niet.
De Server beheerders gaan wel mee met de tijd, bijvoorbeeld DNSSEC als vervanger van DNS.

Als je security wilt, dan doe je dat maar op layer-7. Of in je applicatie. Of misschien in layer-6 of layer-6.5. Zie mijn comments elders op deze pagina. Routing is al moeilijk genoeg. Als de routing layer ook al voor authenticatie zou moeten zorgen, dan wordt het helemaal een gecompliceerde janboel.

Een van de architectonische principes van het Internet is: slimme endstations, dom netwerk.

Dat hoeft helemaal niet zo complex te zijn. Als je het goed doet. DNSSEC is ook niet veel complexer geworden dan standaard DNS.

Als jij denkt het beter te weten, kijk dan eens naar alle vormen van netwerking die de PTTs en Telcos van vroeger wilden. Die wilden allemaal domme endstations (een simpele draaischijf-telefoon) en slimme netwerken. Resultaat: 1 euro per minuut om 56Kbps naar de US te doen.

Als je zo graag security en authentication in je application wilt hebben, bouw het lekker zelf. En laat routers gewoon pakketjes forwarden. Simpel.

Hoe het was en toen mogelijk goed werkte heeft niets met de keuzes voor de huidige situaties te maken.
Ik kan alles veilig maken met een brak BGP protocol kan ik doen wat ik wil, dan heb ik nog steeds de problemen die in het artikel aangegeven worden.

[Verwijderd]

Wat is dat voor een onzin. BGP4 ondersteund geen encryptie en authenticatie, en is ook niet via flexible en extensible toegevoegd.

https://www.ietf.org/rfc/rfc2385.txt
Augustus 1998. BGP Authenticatie. Uit de tijd dat technologie nog deployed werd voordat er een RFC over geschreven werd.

Dat waag ik te betwijfelen, IMO is de reden veel meer dat Cisco zeker in die tijd een monopolie had. En geen behoefte had aan verandering.

Oh, daar gaat het over. Lekker cisco bashen ?
En vooral lekker cisco bashen uit de tijd dat jij nog CD-spelers repareerde.
Ik ben uitgepraat.

[Verwijderd]

[...]

https://www.ietf.org/rfc/rfc2385.txt
Augustus 1998. BGP Authenticatie. Uit de tijd dat technologie nog deployed werd voordat er een RFC over geschreven werd.

Lekker veilig een 16 bits MD5 hash die onversleuteld verstuurt wordt.

[...]

Oh, daar gaat het over. Lekker cisco bashen ?
En vooral lekker cisco bashen uit de tijd dat jij nog CD-spelers repareerde.
Ik ben uitgepraat.

Op de persoon spelen, als je je zin niet krijgt. Ten eerste ben ik sinds 1998 werkzaam in de IT, en hield me daarvoor hier ook mee bezig. Ik heb in die 17 jaar, die ik professioneel in de IT werk, gezien hoe Cisco opereert.

Ik vertel alleen hoe Cisco staat t.o.v. andere fabrikanten. Het is een groot gesloten bolwerk, het is IMO een goede zaak dat er nu ook Juniper, Huawai en Procurve als alternatief bestaan, dat ik veel gevallen goedkoper en sneller zijn. Maar waar beheerders een andere syntax voor moeten gebruiken, waar vele huiverig voor zijn. Wat anders, dat wil ik niet.

[Verwijderd]

Lekker veilig een 16 bits MD5 hash die onversleuteld verstuurt wordt.

1) Het waren 16 bytes, niet 16 bits.
2) RFC2385 is uit 1996. In 1996 waren 16-byte keys klaarblijkelijk genoeg.
3) Natuurlijk zijn de keys daarna breder geworden.
4) BGP heeft geen enkele moeite om een aanpassing te doen naar bredere keys.
5) Als je het precies bekijkt, is dit niet eens een BGP-issue. Encryptie, zoals ik al eerder zei, is een taak van hogere protocols. In dit geval TCP. De BGP-authentication option is dan ook een uitbreiding van TCP, niet van BGP !
6) Goeie protocollen zijn veranderlijk, muterend, en passen zich in de loop der tijd aan. Zie hier:
https://tools.ietf.org/html/rfc5925
https://tools.ietf.org/html/rfc5926

Ik heb in die 17 jaar, die ik professioneel in de IT werk, gezien hoe Cisco opereert.

Ik vertel alleen hoe Cisco staat t.o.v. andere fabrikanten. Het is een groot gesloten bolwerk...

Jouw idee over hoe cisco technologie en protocollen ontwerpt slaat compleet de plank mis.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Verwijderd]

3) Natuurlijk zijn de keys daarna breder geworden.

Maar de key is statisch (verandert niet) en als het MD5 is, wordt deze als niet meer veilig gezien.

5) Als je het precies bekijkt, is dit niet eens een BGP-issue. Encryptie, zoals ik al eerder zei, is een taak van hogere protocols. In dit geval TCP. De BGP-authentication option is dan ook een uitbreiding van TCP, niet van BGP !

Natuurlijk is dat ene BPG issue. Het is belangrijk dat er gene valse broadcasts toegestaan worden, zodat de problemen die in het artikel omschreven worden, ontstaan.

In het hedendaagse internet moet voorkomen worden dat verkeer anders gerouteerd kan worden dan de bedoeling is. Zodat er geen man in de middle sessie kan worden gestart. Dat security deel hoort bij de netwerkbeheerders thuis, en ik weet dat het daar helaas bij vele niet leeft.

6) Goeie protocollen zijn veranderlijk, muterend, en passen zich in de loop der tijd aan.

Dat klopt maar dat is juist het probleem dat is niet gedaan met BGP. Het huidige BGP is niet meer van deze tijd, dat is ook de strekking van het artikel. En of nu een verbeterde BGP of iets anders de oplossing is, is de vraag.

[...]

Je kunt het je misschien niet voorstellen, maar sommige van ons hebben het niet alleen van een afstandje staan kijken. Maar die hebben zelf voor cisco gewerkt. En sommige, heel sommige, hebben ook gewerkt voor cisco development. En zelfs in de groep die BGP deed.

Jouw idee over hoe cisco technologie en protocollen ontwerpt slaat compleet de plank mis.

Je kent me helemaal niet, en je weet niet wat ik al dan niet met Cisco gedaan heb.

Waarom zeg je "sommige van ons", je bent toch maar één persoon?

Dat iemand BGP development deed betelend dat hij/zij meer kennis van BGP heeft. Maar het gevoel dat ik bij jouw heb is dat je een tunnelvisie hebt. BGP is goed er zijn geen betere alternatieven.

Sorry maar voor alles zijn betere alternatieven mogelijk, internet is een netwerk dat continue door ontwikkeld. Momenteel door de commercie langzamer dan gewild, zo zou een goed alternatief voor bijvoorbeeld ssl wenselijk zijn.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Grrrrrene]

Probleem 1).
Hoe vertrouw je iets wat iemand aan de andere kant van de wereld heeft gezegd ? Je kunt je buren vertrouwen.

Is dat zo? Want als "je" (heel algemene term) je buren per definitie 100% kunt vertrouwen en voor je buren geldt hetzelfde, dan kun je de buren van je buren dus ook 100% vertrouwen. En dan kan het nergens mis gaan qua vertrouwensrelatie. Ergo: er is geen probleem of het statement dat je je buren 100% kunt vertrouwen is fout

Maar dat zeg ik als volkomen leek. Deze uitspraak specifiek viel me even op Het lijkt me een erg lastig oplosbaar probleem (wederom: als leek). Bedankt voor je stukje achtergrond bij dit artikel.

[Lennie]

Dit is wel hoe BGP werkt.

Maar je moet wel even duidelijk voor ogen hebben wie die buren dan precies zijn.

Je hebt grof weg 2 soorten relaties met buren (andere netwerk providers):
1. transit: je krijgt alle routes van de transit provider en het is meestal een betaalde dienst. Het gaat hierbij namelijk om het doorgeven van verkeer aan andere netwerken.
2. peering: je krijgt de routes van het andere netwerk en de directe klanten (het verkeer naar die routes blijft binnen het netwerk van de buur-provider). Dat kan in veel gevallen, vooral in Europa, vaak gratis via een Internet Exchange als AMS-IX, NL-IX, DE-CIX, etc.

Dus: bij transit krijg je alles en bij peering wissel je het onderlinge verkeer uit tussen beide netwerken via een Internet Exchange zodat je geen transit moet betalen.

Als kleinere partij geef je bij de peering partner en transit provider aan welke netwerken je hebt en dus kunnen die een filter toevoegen om alleen jouw IP-blokken (prefixes) toe te laten.

Daardoor is het zo dat in de meeste gevallen al lang bekend is welke routes via BGP worden doorgegeven. En dat waarborgt dat het behoorlijk veilig is, daarom gaat het ook zo weinig mis. Het gaat vooral mis als grootte partijen hun klanten niet goed filteren en het bijna onmogelijk is een lijst door te geven omdat er zo vaak wat wijzigt.

Nou is automatisering van het filteren ook mogelijk, maar dat gaat vaak op basis van de informatie van de regionale RIR.

Nu heb je enigszins een idee hoe dat zitten met die buren.

[NMe]

Er wordt hier gesuggereerd dat BGP oud, slecht, onflexibel, onverbeterbaar en achterlijk is. Het tegendeel is waar.

Van de eerste pagina:

Doordat de opstellers van het bgp dat niet zagen aankomen, en wie kan hun dat kwalijk nemen gezien de bescheiden grootte van internet in 1989, bevat het bgp geen mogelijkheid tot authenticatie.

Er wordt gewoon meteen gezegd dat het niet gek is dat die standaard op pragmatische wijze is opgezet. Sterker nog:

Ik durf te stellen, zonder BGP was er geen Internet geweest. En geen Tweakers.

Ook dát wordt gewoon onderkend in het artikel.

Je leest hier een hele hoop negativiteit die er helemaal niet staat. Kritiek en negativiteit is niet hetzelfde. Hoe goed de techniek achter het BGP ook is, je zal zelf toch ook wel onderkennen dat de manier waarop het systeem nu werkt zo lek als een mandje is.

Ik word juist heel vrolijk van dit soort artikelen. Zonder dit soort artikelen komt namelijk niemand van zijn kont af en blijft het internet in de jaren '80 en '90 van de vorige eeuw steken. Sommige protocollen zijn gewoon keihard aan vervanging (of incrementele updates) toe en die blijven veel te lang uit omdat het allemaal lastig is. In een maatschappij waarin we tegenwoordig álles aan het internet koppelen tot de boordcomputer van onze auto's aan toe lijkt het me bijzonder belangrijk om kwetsbaarheden zoals deze bespreekbaar te maken...

[Fawn]

De conclusie van het artikel is nog steeds dat het protocol bagger is, maar dat je het de makers niet kwalijk kunt nemen omdat het zolang geleden is opgesteld.
De reactie is dat het protocol wel degelijk goed is, ongeacht of het heel vroeg is ontwikkeld of recentelijk. Het heeft een probleem, maar dat zit niet ingebed in het protocol maar iets algemeens wat speelt.

Ik zou dus niet willen zeggen dat gryz het artikel niet goed genoeg heeft gelezen, eerder dat je zelf niet goed hebt gekeken naar zijn reactie.

[NMe]

Het zit niet in het protocol maar in de manier waarop het protocol gebruikt wordt. Er staat nergens in het artikel dat BGP zélf het probleem is, en BGP wordt ook niet afgekraakt. gryz leest negativiteit die er niet is en doet daarmee min of meer het hele artikel af als onzin, "want het protocol is gewoon goed." Er is toch wel degelijk iets mis en daar moet toch écht een keer naar gekeken worden.

[NMe]

...en nu wil je zeggen dat die niet klopt? Dat de manier waarop BGP op dit moment gebruikt wordt niet één groot gapend gat is waarlangs kwaadwillenden (of complete overheden!) "per ongeluk" al ons internetverkeer kunnen kapen?

[mysticyx]

Jij zegt: "Er staat nergens in het artikel dat BGP zélf het probleem is"

Terwijl de titel van het artikel is dat BGP de achilleshiel van het internet is. Ik heb te weinig verstand van BGP om inhoudelijk op het artikel in te gaan, maar er staat dus wél in het artikel dat BGP het probleem is.

[NMe]

Het acronym BGP wordt in de titel helemaal niet genoemd. Er staat alleen "De achilleshiel van het internet" en die wordt wel degelijk besproken in het artikel, inclusief de nuances waar om gevraagd wordt...

[mysticyx]

Ik weet niet of je me nu voor de gek aan het houden bent, maar ik lees hier toch echt, bovenaan de pagina:
"De achilleshiel van het internet - Het lekke border gateway protocol"

Ook de url van het artikel:
reviews: Border gateway protocol: de achilleshiel van internet

Het acronym wordt niet genoemd, nee, maar waar denk je dat het acronym voor staat? Misschien wel voor Border Gateway Protocol?

[NMe]

Er zijn blijkbaar een paar verschillende versies van die titel. In de titelbalk van de browser staat bijvoorbeeld alleen "De achilleshiel van het internet," in notificaties staat "Border gateway protocol: De achilleshiel van het internet" en bovenaan de pagina staat zoals je al zegt weer iets anders. In de ankeiler op de FP staat "De achilleshiel van het internet" met daaronder in het klein de rest van de titel die jij citeert als ondertitel. Ik had het dus verkeerd in mijn hoofd zitten en had even naar boven moeten scrollen.

Het woord "lekke" mag IMO wel weg uit de titel inderdaad, dat is overbodig en niet helemaal waar. De rest klopt wel: de manier waarop BGP nu werkt is een grote kwetsbaarheid in de werking van het internet.

[mnoorder]

Het is wel duidelijk dat jij je geld verdient met je BGP kennis. Het lijkt me niet nuttig om een heilige/persoonlijke oorlog te voeren over een protocol uit de 90s. De stelling in het artikel is toch steekhoudend en focust op de problemen met BGP. Dat kan zonder ook alle voordelen ervan op te noemen.

De evolutie van networking en Internet is door weinigen voorzien en elk protocol is ontwikkeld om een acuut probleem op te lossen met een vooruitblik window van misschien 5-10 jaar maximaal (wie kent immers de toekomst?). BGP addresseerde het issue van scaling. Er is natuurlijk een hoop evolutie geweest en dat heeft de houdbaarheid van het protocol verlengd. Je kunt eenzelfde artikel schrijven over IP. Ook dat is geevolueerd tot iets wat vandaag de dag gebruikt kan worden, maar toch zijn beperkingen heeft. Echter met de kennis van nu zou men het misschien anders hebben aangepakt. Houten heipalen onder onze huizen waren achteraf ook een minder goed idee, maar op dat moment loste het wel een groot probleem van verzakkende huizen op.
Je kunt hooguit stellen "achteraf kijk je een koe in z'n kont" en we zitten de facto opgescheept met keuzes uit het verleden. Dit functioneert naar behoren, maar heeft zo zijn uitdageingen. Dat mag gezegd worden. De status quo moet altijd worden uitgedaagd, dan komt er vooruitgang. En dat je in een artikel er een beetje provocerend in gaat om je punt kracht bij te zetten is ook begrijpelijk.

[Lennie]

Lees nog eens goed wat Fawn en eerder ook gryz proberen aan te geven:

het protocol is niet het probleem, het protocol is uitbreidbaar, dat is in het verleden ook regelmatig gebeurt en dat werkt prima.

Het probleem is de vertrouwen kwestie, de authenticiteit van de data.

Dat heeft niks met het protocol te maken, als iemand daar iets voor bedenkt dan kan dat gewoon aan BGP worden toegevoegd.

Zelfs het artikel vermeld: oa. BGPSec, ook dat is gewoon een toevoeging aan het bestaande BGP-protocol.

Ik ben het volledig eens met oa. gryz, het protocol zelf is niks mis mee. Het gaat er om hoe kunnen de correctheid van de data controleren.

En wel zo inbouwen dat niet als iemand 1 foutje maakt dat dan een groot stuk van de routing direct wegvalt. Want dat is de andere zorg. Als we het niet goed doen en het is te breekbaar dan valt het Internet met enige regelmaat in stukken uit een. En dat wil niemand.

[Kabouterplop01]

Helemaal eens, BGP is the bomb, ik heb liever dat alle providers eerst BCP 38/84 implementeren. Dat vind ik veel eerder een belangrijke norm en zou allang geen Best Current Practice meer moeten zijn, maar een regel.
BGP hoeft niet verbeterd te worden, alleen de beheerders moeten exact weten wat ze doen. Als een provider op het internet een fout maakt en providers (lees:peers) eromheen accepteren le /25 (het is op het internet een regel dat je nooit kleiner dan een /24 accepteert/adverteert in BGP) zouden ze gelijk moeten worden gedepeered. Totaal onacceptabel.
Komen we wel weer terug op Erik's statement: Alle providers moeten meedoen!

[NMe]

Hoe regel je dat op internationaal niveau? Compleet China maar van het internet afsluiten? Je kan beter de manier waarop BGP geïmplementeerd is verbeteren dan dat je afspraken gaat maken en achteraf als het eenmaal fout is gegaan de boosdoener kreupel slaan.

[WhatsappHack]

Prima post!
Hulde en dank!

Vond het artikel absoluut niet slecht trouwens, maar de conclusie is inderdaad wat jammer.

[Xieoxer]

Bedankt voor je duidelijk uitleg! Tweakers suggereert dus dat de BGP een slecht ding is, en ze hadden mij goed te pakken. Ik dacht namelijk ook na het lezen van het artikel, omdat ik eerlijk gezegd geen verstand van dit onderwerp heb waardoor je snel conclusies trekt. Je zou verwachten dat mensen achter Tweakers een beetje onderzoek hadden gedaan, maar blijkbaar niet. Hopelijk krijgt dit nog een staartje binnen in Tweakers, want dit kan natuurlijk niet. Gelukkig zijn er nog mensen zoals jou die de waarheid willen vertellen en de moete willen nemen om uit te leggen hoe nou wel in elkaar zit! Bedankt voor je informatie, +3 voor jou!

[Verwijderd]

Dat kun je Joost Schelvis niet kwalijk nemen. In principe heeft hij gelijk als hij zegt dat er een probleem is. En hij is correct als hij details en potentiele verbeteringen en oplossingen beschrijft (zoals RPKI, filtering, etc). Ik vind het alleen flauw om de schuld bij BGP te leggen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[Lennie]

Stoorde iemand anders zich er ook aan dat de BGP afkorting in kleine letters was geschreven ?

Dat is iets dat je nooit ergens ziet, dat terwijl heel veel andere dingen wel hoofdletters kregen. RPKI en BGPSec ook niet trouwens.

Ik vond dat raar omdat dat nu juist het onderwerp van het artikel was.

Helemaal niet blij met de manier waarop het artikel is geschreven. Ik wil mijn geld terug ! ;-)

[Ame_thyst]

Ben benieuwd of ik weer "Waarschuwing moderaties" in de bus krijg morgen...

[S1W]

Interessant artikel! Ik vraag me af hoe iemand daadwerkelijk een eigen BGP router in een netwerk kan plaatsen? Moet je daarvoor niet fysiek toegang hebben tot een datacenter bij een ISP of Exchange?

[KoeKk]

BGP zelf is gewoon een stuk software, kan met quagga (http://www.nongnu.org/quagga/) onder linux draaien en sinds Windows 2012R2 ook op het Windows platform. En natuurlijk draait dit ook op de routers gebruikt door ISPs.

De verdere ingredienten zijn een AS nummer, en een 'provider independent' IP subnet. Beide zijn te verkrijgen via RIPE (in europa), maar dat krijg je niet zomaar, en kosten uiteindelijk ook gewoon geld.

Dan kan je aan je upstream provider vragen of ze via BGP routes willen uitwisselen. Dan moet er aan beide kanten wat op de routers geconfigureerd worden (Geen enkele ISP zou dit zo open mogen hebben staan) en dan werkt het.

Zoals je ziet is het niet iets wat je zomaar kan aanzetten en dan vrolijk IP ranges kan kapen, vandaar dat het probleem ook sporadisch gebeurt, en als het gebeurd het een config fout blijkt te zijn (voor zover wij weten, natuurlijk)

[Verwijderd]

Dan kan je aan je upstream provider vragen of ze via BGP routes willen uitwisselen. Dan moet er aan beide kanten wat op de routers geconfigureerd worden en dan werkt het.

En, heel belangrijk, je upstream provider zou jouw announcements moeten filteren. M.a.w. als ze weten en verwachten dat je enkel en alleen 180.180.180./24 adverteert, dan zouden ze alleen die ene prefix moeten accepteren. Als je dan stiekum Google's prefixes advereert, dan zouden die zelfs niet eens 1 hop ver moeten kunnen komen.

Helaas gebeurt dat filteren niet altijd. Sommige ISPs zijn te lui, hebben geen geld/mankracht, of missen de technische vaardigheid. Bovendien is goede filtering voornamelijk een voordeel voor "het Internet als geheel" en minder voor de filteraar zelf.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[--Andre--]

En, heel belangrijk, je upstream provider zou jouw announcements moeten filteren. M.a.w. als ze weten en verwachten dat je enkel en alleen 180.180.180./24 adverteert, dan zouden ze alleen die ene prefix moeten accepteren. Als je dan stiekum Google's prefixes advereert, dan zouden die zelfs niet eens 1 hop ver moeten kunnen komen.

Maar dan mis je het hele punt van BGP. Als jouw netwerk een directe verbinding met Google heeft, en naar een ander netwerk (de upstream provider), kan jij adverteren dat je verkeer bestend voor Google kan routeren.

Een netwerk met een enkele upstream provider is niet zo interessant. BGP is juist interessant als jouw netwerk aan meerdere netwerken verbonden is.

[Verwijderd]

IGPs zijn gemaakt om de snelste weg door een netwerk te vinden. Bij BGP is dat niet noodzakelijkerwijs het belangrijkste. Bij BGP is "policy" veel belangrijker. Het netwerk bepaalt niet wat "het beste pad" is, maar de netwerk-admin. Omdat bij inter-AS verkeer meestal gewoon betaalt moet worden. (Of peering-arrangements die nagekomen moeten worden). ISPs willen dus eigenlijk nooit: "we configureren BGP, en we zien wel wat voor routes we krijgen".

Als je van te voren weet welke routes je verwacht, en welke je wilt gebruiken, etc, dan kun je net zo goed ook filtering configureren. Om er zeker van te zijn dat er niets onverwachts gebeurd. Beter voor de portomonee, maar ook beter voor security.

[Lennie]

Nou ja, het is niet zo heel anders dan een IGP. In de basis probeert BGP ook de kortste weg te vinden, een zo kort mogelijk AS-Path.

Natuurlijk zijn er andere eigenschappen en policy en natuurlijk betekend een kort AS-path niet altijd de snelste weg of minste aantal router-hops.

[Anoniem: 668730]

Je kunt zelf prima BGP routers inzetten om tussen je eigen netwerken onderling de routering te bepalen. (Al zou ik daar zelf OSPF ofzo voor inzetten.) Wil je echter Internet verkeer binnenkrijgen via BGP dan zal jouw BGP router moeten communiceren met een of meerdere andere BGP routers die reeds onderdeel zijn van het Internet.

Dat laatste is iets lastiger, in die zin dat het je geld gaat kosten en de meeste partijen die dergelijke routers beheren inderdaad zullen eisen dat je je router in hetzelfde datacentrum hangt. Verplicht of technisch noodzakelijk is dat echter niet.

[Verwijderd]

OSPF is voor speelgoed netwerken.
Echte netwerken gebruiken IS-IS als hun IGP.

(IGP = Interior Gateway Protocol. Een routing protocol wat je binnen je eigen netwerk gebruikt. In tegenstelling tot BGP, wat een EGP is, een Exterior Gateway Protocol. EGPs gebruik je tussen netwerken. EGP en IDRP waren ooit EGPs, maar alleen BGP4 is over. Dat geeft al aan waarom BGP4 zo awesome is).

BTW, er zijn mensen die BGP4 zo awesome vinden, dat ze het zelf *binnen* hun eigen netwerk gebruiken. Ze vinden BGP4 beter dan IS-IS of OSPF.

Microsoft is daar een voorbeeld van. Die gebruiken gewoon BGP (en geen IGP) in hun datacenters. Zie hier uitleg.
https://www.nanog.org/mee...tions/Monday/Lapukhov.pdf
https://tools.ietf.org/ht...v-bgp-routing-large-dc-02

[Yariva]

OSPF is voor speelgoed netwerken.
Echte netwerken gebruiken IS-IS als hun IGP.

Zou je deze mening kunnen uitleggen? Ik heb IS-IS een aantal keren langs zien komen maar mij er nooit in verdiept.

[Verwijderd]

Ik zou je uren kunnen onderhouden met allerlei details waarom IS-IS beter is dan OSPF.

Iemand (die het weten kan) vertelde me dat alle grote ISPs in de wereld tegenwoordig IS-IS draaien. Op eentje na (BT geloof ik).

IS-IS heeft het nadeel dat het minder bekend is bij de non-professional. (En dan bedoel ik professionals die echt grote backbones draaien). En de terminologie heeft wat oude OSI termen (systemid ipv router-id, ES ipv host, IS ipv router, SNPA ipv mac-address, etc). Als je daar aan gewend bent, wordt IS-IS eigenlijk veel makkelijker te begrijpen dan OSPF.

IS-IS en OSPF zijn qua idee gelijk. Het zijn alle twee link-state protocols. Je stuurt hellos om je buren te vinden, je wisselt Link-State pakketjes uit met alle routers in je area om te topologie te leren kennen, en je draait Dijkstra's SPF om topologie en routes te berekenen.

De twee grootste verschillen, imho:
1) De OSPF specificatie (RFCs) proberen alles tot in de kleinste puntjes vast te leggen. Ieder detail wordt beschreven. Alles wordt/werd gemicromanaged. Het resultaat is een specificatie die voor programmeurs geen enkele vrijheid overlaat om slimmigheidjes te implementeren. IS-IS geeft die vrijheid wel. Kleine veranderingen die lokaal binnen een router zijn, die de scalability of robustness verhogen. En omdat ze lokaal zijn, geeft het geen interoperability problemen. IS-IS gebruikt TLVs (Type Length Value) formaat. En is daarom erg makkelijk uit te breiden. OSPF is star en niet flexibel. Toen IPv6 kwam, heeft IS-IS gewoon nieuwe TLVs gedefinieerd, en klaar was kees. Voor OSPF moest er een heel nieuw protocol komen (OSPFv2 naar OSPFv3). OSPFv3 gebruikt ook TLVs (Opaque LSAs genaamd). Maar nog steeds is OSPF minder flexibel.

2) OSPF verdeelt de routing informatie in heel veel, maar heel kleine LSAs. Bijna 1 LSA per prefix die ergens geadverteerd wordt. Terwijl IS-IS veel grotere, maar veel minder LSPs heeft. Eigenlijk 1 LSP per router. De grootste uitdaging in een link-state protocol is het flooden van al die LSAs of LSPs. Niet hellos sturen, niet Dijkstra uitrekenen. Maar flooding. Omdat IS-IS veel minder LSPs heeft, kost het flooden veel minder werk. En dat is een van de (hoofd-)redenen waarom IS-IS veel beter scalet. Met andere woorden: met IS-IS kun je areas bouwen van een paar duizend routers. Met OSPF krijg je veel eerder problemen. IS-IS netwerken zijn daarom makkelijker te ontwerpen, te configureren en te troubleshooten.

Een ander voorbeeld waarom IS-IS beter is zijn de nieuwe bridging protocollen. Er zijn er twee: Shortest Path Bridging (IEEE801.aq) en Trill. Beide zijn gebaseerd op IS-IS. En niet op OSPF. Deze protocollen doen link-state stuff, maar niet met ip-prefixes, maar met layer-2 mac-adressen. Switches sturen elkaar hellos, net als in OSPF/ISIS. Ze wisselen LSPs uit. Ze doen Dijkstra om de topologie uit te rekenen. Alleen bouwen ze met die info geen layer-3 routing table met ip-addressen, maar een layer-2 forwarding table met mac-addressen. Zo komen we misschien ooit van Spanning-Tree af. SPB en Trill zijn IS-IS. Niet OSPF.

Er is genoeg info te vinden als je googlt. Maar imho heeft niemand ooit een echt goed artikel geschreven dat zowel de significante praktische als theorestische verschillen uitlegt. Sorry.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[RadianceBe]

Je bent 100% correct in alles wat je hier opmerkt. Maar ik wil toch ook even de kanttekening maken dat dat niet wil zeggen de gemiddelde KMO of zelfs enterprise beter af is met IS-IS. De voordelen van IS-IS zijn voornamelijk in theorie en op telco schaal.

In de praktijk is IS-IS enkel (zeer) goed ondersteund in de aggregation & core routers van de Big 4. En net doordat het zo flexibel is, is de exacte support voor RFCs erg verschillend tussen vendors. Telcos hebben ook de resources, tijd en budgetten om interop testing te doen, de armslag om vendors nieuwe features te doen integrereren etcc.. Als zakelijke klant heb je net om die redenen meer aan OSPF me dunkt; da's voor iedereen duidelijk (en dan nog ...) en zowat elke doos die een routing protocol ondersteunt zal ook OSPF doen.

Ik wil maar zeggen .. alle netwerkbeheerders die dit lezen en geen IS-IS draaien moeten er niet van wakker liggen. Spendeer je beperkte resources liever aan een IPv6 uitrol

[Verwijderd]

Ik wil maar zeggen .. alle netwerkbeheerders die dit lezen en geen IS-IS draaien moeten er niet van wakker liggen. Spendeer je beperkte resources liever aan een IPv6 uitrol

Als je OSPF gebruikt, en over gaat naar IPv6, moet je zowiezo je routing protocol veranderen. Van OSPFv2 naar OSPFv3. Dat is de uitgelezen kans om van OSPFv2 naar IS-IS over te stappen.

[Lupusceleri]

Je draait ze juist naast elkaar.. de OSPFv2 instance voor IPv4 en daar naast nog een OSPFv3 instance voor IPv6.

Wat ook wel eens gedaan wordt is dat mensen zowel IS-IS als OSPF op de zelfde routers draaien om IPv4 en IPv6 te scheiden ... lijkt me niet aan te raden maar toch. Hier is recent nog een discussie over geweest op NANOG: http://mailman.nanog.org/...nog/2015-June/076075.html

[Verwijderd]

Je draait ze juist naast elkaar..

Natuurlijk, tijdens de transitie moet je beide draaien. En de transitie naar IPv6 duur nu al 15-20 jaar, dus in feite draai je beiden tegelijkertijd. Voor altijd.

Maar dat is juist mijn punt. Als je IPv6 er bij gaat doen, moet je ook OSPFv3 er bij gaan doen. Je kunt dan net zo goed IS-IS er bij gaan doen, voor alleen IPv6. Als dat je bevalt kun je later IPv4 voor IS-IS aanzetten, en OSPFv2 uitzetten.

Afijn, voor "kleinere" netwerken maakt het allemaal niet zo veel uit. Ik schreef het (met een smiley) omdat ik zelf een IS-IS fanboy ben. En de meeste grote ISP netwerken draaien al IS-IS.

[mnoorder]

Zoals gezegd draait IS-IS onder SPB. En daar kun je in de enterprise heel leuke dingen mee doen. Je vervangt zowat je hele protocol stack door SPB. Inmiddels is ook L3 tunneling maar ook native multicast mogelijk met SPB (zonder PIM of ander mcast routing protocol). Dat gaat de enterprise netwerken minder complex maken. Bovendien hoef je voor een nieuwe service alleen aan de rand van het netwerk een vlan te koppelen aan een ISID (SPB tunnel) en IS-IS vindt het kortste pad voor je!
Heb je als admin een hoop tijd over voor leukere dingen dan op zondagavond vlans door je netwerk core te trekken....

[Yariva]

Hulde aan de manier van uitleggen, en dank u voor de introductie

Ik zal me er zeker verder in verdiepen. Maar zoals ik het hier lees vind ik het spijtig dat dingen zoals een Cisco CCNP ROUTE examen IS-IS lijken te ontwijken, en OSPF of EIGRP als IGP prefereren.

[cHoc]

En wel meer grote bedrijven doen dat ook, die routeren gewoon met BGP binnen hun tunnels.

[Verwijderd]

Wat bedoel je met "binnen hun eigen tunnels" ?
Heb je voorbeelden ? (Namen van bedrijven). URLs met meer info ?
Microsoft is een specifiek geval. En die gebruiken geen tunnels in dit specifieke geval.

[Lupusceleri]

Ik denk dat hij op private BGP met address space a la 192.168.0.0/16 in site-to-site VPN tunnels doelt.. dat is weer een hele andere tak van sport omdat zulke private BGP netwerken (vaak) niet met het Internet verbonden zijn.

[Verwijderd]

Bedoel je een groot netwerk (binnen bv een multinational), waar het netwerk in stukken wordt geknipt. Ieder stuk met zijn eigen IGP. En dan private BGP gebruiken om die stukken aan elkaar te breien ?

Ja, dat ken ik. Ooit zelf gedaan in 1995. Omdat EIGRP toen nog niet goed werkte, knipten we NA en EU los, en configureerden er BGP tussen. EIGRP in NA. EIGRP in EU. En BGP over de oceaan.

Maar wat Microsoft doet is toch nieuwer/anders. Die vervangen hun IGP met BGP. Vandaar dat ik die 2 links postte. Ik snap waarom MS het doet. Maar ik ben eigenlijk zelf een IS-IS fanboy. En dus vind ik het jammer dat er niet geprobeerd is met een IGP het einddoel te bereiken. Afijn, klant is koning.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[cHoc]

Idd, had ik moeten aangeven, IGP op locatie, soms niet meer dan een simpel DSL routertje voor het internet, waarnaar eerst de firewall komt en daarna de router van de klant, en private BGP tussen die klantrouters binnen de IPsec tunnel naar het hoofdkantoor over het internet .

[ColdRain]

Je moet 'redelijk dicht' op de core zitten. Hier is dat lastig, in Oekraïne veel minder.

[Yariva]

Zolang de router een route heeft naar de neighbor heeft het geen limiet tot plaatsing.

[_Arjen_]

Je kunt gewoon een router aan je internetverbinding hangen om via bgp netwerken cq routes te presenteren, dat is juist de kracht en tevens de zwakte van bgp.
Impact is trouwens niet altijd even groot, variërend van binnen isp tot daarbuiten.

[Reactie gewijzigd door _Arjen_ op 22 juli 2024 14:22]

[compufreak88]

Je provider moet ook een BGP sessie met je opzetten om dit te laten werken. Het is niet zo dat een router routes van elke willekeurige andere router accepteert.

[PcDealer]

De meeste Layer 3 switches zoals de Cisco Catalyst 3560 en 3750 ondersteunen BGPv4. Of je pakt een simpele Cisco 800 series router die het ook doet.

[Reactie gewijzigd door PcDealer op 22 juli 2024 14:22]

[Verwijderd]

Bv ook cisco's Nexus switches. Nexus BGP, beste BGP implementatie ooit !!!

[448191]

"Het is geen geheim dat protocollen als tcp/ip en dns niet bepaald perfect zijn, en vandaag de dag totaal anders ontworpen zouden worden. Zo bevat tcp/ip van origine geen vorm van encryptie."

Het is geen geheim? Het is geen gegeven. Zelf als TCP, UDP en IP outdated zouden zijn (behalve IP denk ik overigens niet dat dat zo is), het ontbreken van encryptie kan ik niet als een argument daarvoor zien. Encryption hoort in het OSI model in de Application Layer, niet in de Network Layer. Je kunt beter zeggen dat HTTP (1.0/1.1) outdated is, en dat zie je ook vernieuwen in de vorm van SPDY en HTTP 2.0.

[Jaco69]

Er is niet naar het OSI model gekeken bij de ontwikkeling van TCP/IP. De lagen laten zich daardoor niet 1 op 1 vertalen naar het OSI model.

[dmantione]

Bovendien is het OSI-model niet de bijbel... Het OSI-model komt net als TCP/IP uit een tijd dat de wereld anders in elkaar zit. Netwerkbeveiliging in anno 2015 een dusdanig integraal onderdeel van internet geworden, dat er veel voor te zeggen is om beveiliging in de netwerklagen te integreren.

TCP/IP laat beveiliging over aan de applicaties, maar het is juist doordat iedere afzondelijke applicatieprogrammeur over beveiliging moet nadenken, dat er zoveel onveilige protocollen zijn en zoveel lekken ontdekt worden. Als je veel beveiligingsproblemen weg kunt nemen door veiligheid in te bouwen in het netwerk, dan zou de wereld daar beter van worden.

[CAPSLOCK2000]

TCP/IP laat beveiliging over aan de applicaties, maar het is juist doordat iedere afzondelijke applicatieprogrammeur over beveiliging moet nadenken, dat er zoveel onveilige protocollen zijn en zoveel lekken ontdekt worden. Als je veel beveiligingsproblemen weg kunt nemen door veiligheid in te bouwen in het netwerk, dan zou de wereld daar beter van worden.

Er bestaat IPSEC, daarmee kun je encryptie en authenticatie op IP-niveau moet doen. Helaas IPSEC best lastig om te implementeren.
Het grootste probleem is echter dat een applicatie niet of een verbinding via IPSEC loopt of niet. De enige manier om als applicatieprogrammeeur zeker te weten dat je een veilige verbinding hebt is om zelf encryptie te doen.

[Lennie]

IPSEC is te ingewikkeld, dat is het probleem.

Daarom is het zo moeilijk om correct te implementeren.

Er zijn veel te veel applicatieprogrammeurs die het fout doen, dus het is schijnveiligheid.

Neem nu smartphone apps, een paar jaar geleden was het zo dat 80% van alle US banken apps hun HTTPS beveiliging verkeerd geïmplementeerd hadden. En dat waren dan de banken, die zouden daar juist extra aandacht aan moeten besteden. Misschien toch handiger om dat door experts te laten doen zoals browser bouwers.

Hoe dan ook de IETF (die Internet standaarden/protocollen maken) zegt alle bestaande protocollen waar nodig nog encryptie toepassen zodat er encryptie plaats vind op alle lagen.

[Reactie gewijzigd door Lennie op 22 juli 2024 14:22]

[448191]

Het punt is dat in een protocol stack elke layer moet doen waar het voor gemaakt is. Het OSI model is slechts 1 van de mogelijke conceptualisaties van zo'n stack.

[Jaco69]

Goed punt maar TCP/IP wordt hier dacht ik gebruikt als naam van het model met alle layers. Zo las ik het i.i.g.en begreep dus je punt niet en vandaar mijn antwoord TCP/IP model vs OSI model.

[mphilipp]

HTTP is maar een klein onderdeel van de stack. Door alleen dat aan te pakken los je nog steeds niets op, vooral niet als het gaat om de in het artikel beschreven problemen.
Dat de consument zich voornamelijk van HTTP bewust is (als ie zich daar al van bewust is) wil niet zeggen dat dat het enige is dat gebruikt wordt. Het is slechts een toplaagje. De meeste hacks en problemen bevinden zich om een lager, fundamenteler nivo.

[Verwijderd]

De meeste hacks en problemen bevinden zich om een lager, fundamenteler nivo.

HTTP is layer 6 of 6.5, correct ? Net onder layer-7, net onder de applicatie (web-paginas laten zien).

De meeste hacks bevinden zich HOGER in de stack. Op layer 7. Het zijn de applicaties die meestal vulnerable zijn.

Niet de protocollen op layer-2, layer-3 of layer-4. Veel succes met het hacken van je Ethernet frames. Zelfs IP of TCP geven weinig mogelijkheden tot hacks en inbreken. Maar kijk eens naar SQL-injecties, cross-site scripting, etc. Zie hier Google's lijsten van meest belangrijke security problemen. Allemaal layer 7 of 6.5.

En dan heb je nog layer-8. De users. "Social engineering". Ik durf te beweren dat enkel en alleen deze issues ook al een veel groter probleem zijn dan IP, TCP of BGP.

[mphilipp]

Waar gaat het artikel over?
Context...

[supersnathan94]

:facepalm:

Maar overigens denk ik wel dat ereen kern van waarheid in zit. De meeste problemen zijn vaak een geval PEBCAK. Zeker de afgelopen 5 jaar waarin phishing en social engineering enorm "verbeterd" zijn.

[tenpo]

Het grote probleem is ook niet de afwezigheid van encryptie maar van authentificatie. Waardoor spoofing (in de brede zin bedoeld) i.c.m. bv ssl stripping de encryptie van de hogere lagen teniet doet.

[martinelli]

Leuk artikel. Ik denk vast te simpel, maar een tweede tegenstrijdige gossip moet toch makkelijk te negeren zijn? Zodat je je niet voor kan doen als een ander?

[Kees]

Nee, want een route kan ook prima via verschillende netwerken lopen. Dat is juist een van de krachten van het internet. Zie bijvoorbeeld het plaatje op de tweede pagina, daar zie je dat het verkeer normaal gesproken ook al via twee routes naar de client toe kan.

Ook in de echte wereld is het heel normaal om via verschillende routes met elkaar verbonden te zijn. Bijvoorbeeld Tweakers en een Ziggo klant. Normaal gesproken gaat die route van AS9143 (Ziggo) via de AMS-IX naar AS15703 (True). Maar op het moment dat de AMS-IX stuk is dan loopt die route ineens via andere netwerken.

Waarschijnlijk gaat de route dan via de NLix lopen waar beide partijen op aangesloten zijn, of via netwerkproviders als Level3, Telia, Sprint etc. Maar dan moeten ze wel, voordat de amsix eruit ligt, van elkaar weten wat die eventuele alternatieve routes zijn zodat ze meteen kunnen omschakelen.

[Blokker_1999]

En wat ga je dan doen? Dat subnet gewoon totaal negeren? Dan word het voor aanvallers nog eenvoudiger om het internet uit elkaar te laten vallen.

[Pinkys Brain]

Waarom niet meteen een lijst maken van subnets die alleen maar Bgpsec uitzenden? Dan kunnen die tenminste niet gehijacked worden op de delen van het netwerk die Bgpsec ondersteunen.

Doe je het alleen voor IP4 op /24 niveau dan is de benodigde hardware miniem.

[Lennie]

Waarom een lijst maken van BGPSec gebruikers ? Als die BGPSec gebruiken kun je toch met crypto verifieren, dat is toch het hele doel ?

[Pinkys Brain]

Zolang nog niet alles over is op BGPSec blijven ze gewoon BGP accepteren, dus zonder zo'n lijst is BGPSec een beetje nutteloos.

Door een lijst met subnets te maken waarvan je weet dat nooit normale BGP aankondigingen van kunnen komen deel je het internet op in twee delen ... het deel waar BGP gespoofed kan worden en het deel waar dat niet kan. Dit maakt het internet veiliger (voor degene op het goede deel) en creëert een financiële prikkel voor het andere deel om over te stappen.

[Lennie]

Ik snap niet waarom je een lijst nodig hebt. Als je BGPSec gebruikt dan is een deel van de routes die je binnen krijgt voorzien van RPKI en BGPSec informatie. Als de BGPSec informatie correct is dan is het dus niet meer mogelijk over deze routes via niet-beveiligde weg informatie te sturen over die routes.

Dus heb je ook geen lijst nodig.

Als het goed is kun je zelfs zien dat routes die RPKI en BGPSec gebruiken van extra beveiligings informatie voorzien moeten zijn en zelfs als je de echte nog niet binnen had gekregen dan kun je dus incorrecte informatie weggooien.

[Reactie gewijzigd door Lennie op 22 juli 2024 14:22]

[Pinkys Brain]

Hmm, ja je hebt gelijk ... hij bouwt effectief de lijst dynamisch op.

Is de vraag alleen nog wat er gebeurt als er een route aangekondigd met BGPSec voor een /16 in zit, maar er een BGP announcement voor een /24 binnenkomt.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 14:22]

[Lennie]

Dat onderwerp had ik al aangesneden:

"Als het goed is kun je zelfs zien dat routes die RPKI en BGPSec gebruiken van extra beveiligings informatie voorzien moeten zijn en zelfs als je de echte nog niet binnen had gekregen dan kun je dus incorrecte informatie weggooien."

Neem DNSSEC als voorbeeld.

De parent geeft aan dat de child gesigned moet zijn.

Als je dus informatie binnen krijgt die niet gesigned is: automatisch fout.

[cHoc]

En nog steeds gehacked worden daarbuiten, en als er een lijst is van Bgpsec subnets, dan word er door hackers wel uitgezocht welke dat zijn, en hacken ze in een ander subnet, elke change in die lijst zal waarschijnlijk ook binnen 48 uur bij de echte grote hackers bekend zijn.

[Pinkys Brain]

En? Als verbindingen die van&naar beveiligde subnets gaan niet gehijacked kunnen worden is dat nog steeds vooruitgang.

Als ik mijn huis beter beveilig kijken dieven ook sneller naar mijn buren, is nog steeds geen reden om het niet te doen.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 14:22]

[MrDummy]

Ik denk dat ontbreken van beveiliging komt door:
- internet was origineel voor militair gebruik
- later wordt internet ook publiek beschikbaar gesteld
- vanwege groei internet en wereldwijde omvang wordt bgp ontwikkeld voor publiek, om al die netwerken met elkaar te kunnen verbinden
- doordat het voor publiek is bestemd dacht men ook niet meteen aan cryptografie en auth, want er was toen amper tot geen kwaad aanwezig.
- in begin beschikt niet iedereen over internet en zijn computers nog verre van krachtig, en heel duur
- aantal kwade mensen zijn nog toen heel beperkt, bijna niemand doet aanvallen, slechte software was toen nog niet zover gekomen.

En niemand kan vooruitkijken dat:
- computers in korte tijd steeds krachtiger worden en sneller kunnen kraken
- meer programma's komen erbij om netwerk af te kunnen tappen
- meer onrust in de wereld, vooral Rusland, China en aantal islamitische landen
- meer toename aan cyber criminaliteit, crackers en hackers
- zelfs aantal corrupte providers groeit in onrustige landen
- botnets, virussen en malware groeit en wisselt snel
- inbreken in diverse netwerken is zeer groot aanwezig
- zelfs geheime diensten maken daar gretig gebruik van, ze moeten niks van beveiligde verbindingen dus "open" bgp zijn ze nog wel blij mee.... hoe ironisch
- en zeker ook banken en andere belangrijke bedrijven op internet aangesloten... voorheen gaat het nog via stuk veiligere telefoonverbinding rechtsreeks met modem, daar kan je niet zomaar bij komen en aftappen.
- De groei is pas echt als Windows "volwassen" is geworden en dat is in jaren 90. Internet is al wereldwijd. De toename van gevaar is ook reden dat eerste virusscanners zijn ontwikkeld.

En dan hadden ze niet verwacht dat er later enorm behoefte is aan de veiligheid en beschermen van datastromen.
Ja, ik kan ze niet kwalijk nemen dat mens geen god is om alles te kunnen overzien. Ook al vind ik mooi dat Japan bijvoorbeeld technisch vooruit kan denken, maar internet is begonnen in Amerika. Japan was toen gesloten land en achteraf bestraft door hun WOII praktijken, ook met opgelopen oorlogsschade, het mocht niet veel doen. Later is dat minder geworden en kan Japan snel groeien in techniek, maar internet draait al een poosje. Hier kunnen aantal zaken dus niet bijgesteld worden.

Het is jammer helaas. Vandaag worden er daarom diverse oplossingen gemaakt die moeten waarschuwen of proberen kwetsbare netwerken goed af te schermen. Soort "guards" rond bgp.
Maar inderdaad, het is wel van groot belang dat veel providers meedoen, en dan heb ik nog niet over corrupte providers in onbetrouwbare landen, wat willen ze zelf wel?

[Lupusceleri]

Japan is echt niet zielig hoor, die hebben hun "achterstand" qua internet al lang ingehaald als ie er uberhaupt al was. De nummer drie carrier van de wereld - NTT Communications - is zelfs headquartered in Japan: http://research.dyn.com/2015/02/bakers-dozen-2014-edition/

Er zijn daar nog een aantal heel grote / internationaal sterke netwerken actief zoals IIJ, KDDI, Softbank/ODN (inmiddels eigenaar van Sprint uit de USA), etc.

[MrDummy]

Ja, Japan heeft tijd al snel ingehaald zodra beperkingen opgeheven zijn kort na oorlog.
En dus 1 van de besten op gebied van communicatie en internet.

[Lennie]

"Ik denk dat ontbreken van beveiliging komt door:
- internet was origineel voor militair gebruik"

Dat is niet waar.

Het leger was de gene die betaalde voor het onderzoek maar niet de enige gebruiker.

Het was ook vooral bedoeld om de universiteiten te koppelen. Mede om de budgetten van het onderzoek door universiteiten van het leger omlaag te krijgen (computers waren zeer groot en duur en konden via Internet gedeeld worden).

[NielsNL]

Mooi artikel. Ik mis er alleen een stukje in over IPv6. Als ik even snel zoek en lees, verbeterd er daar niet veel mee.

[Blokker_1999]

IPv4 en IPv6 hebben niet zo heel veel te maken met BGP net zoals deze niets te maken hebben met bijvoorbeeld DNS of http. In de meest essentiële vorm kan je BGP aanzien als een applicatie die voor de configuratie van je router zorgt terwijl IPv# niets met die applicatie te maken heeft maar enkel met de onderliggende netwerk techniek.

[Martinspire]

Maar als men overgaat op IPv6 en apparaten dus ook aan internet kunnen hangen, hoe wordt dan geregeld dat een pakketje weet waar hij moet zijn? Als je dus per verbinding meerdere IP adressen gebruikt. Of wordt dat IPv6 nummer dan nog steeds via de Provider uitgegeven?

[Verwijderd]

IPv6 word ook door een provider uitgegeven, en dan is dat specifieke IP gekoppeld aan een MACadres wat dan weer in BGP database zal staan.

[Lennie]

Dat vind ik een rare manier om het te omschrijven.

BGP, in praktijk, weet alleen iets over blokken van IP-adressen.

BGP is ook niet echt een database, de RIR (regio) heeft een database. Ook voornamelijk met IP-blokken.

BGP heeft gewoon informatie (voornamelijk routes) over IP-blokken in het geheugen staan. Een RIB, Routing Information Base, zou ik niet direct een database noemen. Daar hebben de meeste mensen toch andere associaties mee.

[Reactie gewijzigd door Lennie op 22 juli 2024 14:22]

[Durandal]

Als het alleen een applicatie is, is het dan mogelijk een nieuw en veiliger protocol te verzinnen en dat als 2e applicatie naast bgp te draaien en zo geleidelijk aan alle routers te updaten?

[Lennie]

Zolang sommige een providers op Internet de nieuwe applicatie niet gebruiken is het mogelijk om misbruik te maken van die situatie. Het protocol waarmee die informatie wordt verstuurd is niet zo belangrijk en BGP is flexibel genoeg. Dus we kunnen gewoon BGP blijven gebruiken. Het is een organisatorisch probleem vandaar ook dat RPKI in het artikel werd benoemd. En er zijn weer extra extenties nodig, zoals de BGPSec die in het aritkel is genoemd.

[Verwijderd]

Beetje te veel geabstraheerd.
BGP en IPv4 en IPv6 hebben *alles* met elkaar te maken.

De allerbelangrijkste functie van IPv4 en IPv6 headers, en dus van IPv4 en IPv6, is dat ieder pakketje een destination-address heeft. Alle andere functionaliteit van de IPv4 en IPv6 headers zijn daar aan ondergeschikt.

Om iets met dat destination-address te kunnen doen, heb je een route-tabel nodig. En die route-tabel wordt gebouwd door BGP. (En ook door IS-IS of OSPF, maar in het wereldwijde Internet is BGP nog belangrijker). Zonder BGP is de IPv4 of IPv6 header waardeloos. En zonder BGP en de ip-headers, en hoe ze samenwerken, is er geen Internet.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:22]

[grizzler]

Internet stamt uit de jaren zestig/zeventig. De eerste protocollen zijn van 1969.

[z1rconium]

Ja maar bgp bestond toch nog niet, internet/arpa groeide als een malle en daarom moest er een backbone oplossing komen, dat was in 1989 een feit.

Je kunt overigens de status van AS-en zien dmv looking glass. Daar kun je mee inloggen op bgp routers van bijv. providers en zien welke AS met welke AS praat. (sh ip bgp neigh/sum)

[Reactie gewijzigd door z1rconium op 22 juli 2024 14:22]

[Blokker_1999]

De eerste protocollen misschien wel, maar bijvoorbeeld DNS is pas veel later gekomen. Voordat DNS bestond maakte men gebruik van een hosts file die men ging downloaden. In die tijd was er dus 1 persoon die voor het hele toenmalige internet bijhield welk IP adres bij welk domein hoorde en iedereen die gebruik wilde maken van domeinnamen op het internet ging dat ene tekstbestandje downloaden.

Met BGP net hetzelfde. Toen het internet nog heel klein was, was het niet zo moeilijk om statische routes op te geven. Kwam er een nieuwe partij bij dan werd die handmatig toegevoegd aan de tabellen. Het is pas bij de latere commercialisering dat men oplossingen is gaan zoeken om geautomatiseerd te kunnen vertellen wie dat waar zit.

[Frankster]

Goed en informatief stuk! Een beetje extra kennis op de zaterdagochtend is nooit weg

[itlee]

Ik sluit me hier bij aan, thnx tweakers, weer wat geleerd! 👍🏼😊

[kodak]

Ik mis een belangrijk stuk: het toepassen van BGP best practices. Dit voorkomt al heel veel ellende voor jezelf als netwerk eigenaar en anderen. Er zijn alleen nog veel AS-netwerkeigenaren die het vertikken om de BGP best practices toe te passen of het niet snappen. Het feit dat een bedrijf of andere organisatie ooit een AS heeft gekregen wil niet zeggen dat deze nu nog capabel is om daar goed mee om te gaan.

Een AS krijg je niet al te makkelijk, maar als je er eenmaal een hebt zoek je het zelf maar uit hoe je er mee om gaat, of je nu wel of niet snapt hoe je er fatsoenlijk mee om moet gaan. Het zou niet de eerste keer zijn als een bedrijf met een AS 20 jaar geleden genoeg knowhow had en nu een management dat van toeten nog blazen weet. Als je het constant fout doet maak je niet veel vrienden, maar er wordt behoorlijk wat door de vingers gezien wat problemen veroorzaakt. Je klanten eruit trappen kost namelijk al snel heel veel geld.

Het ligt helaas kennelijk nogal gevoelig om eigenaren op hun verantwoordelijkheid te wijzen en eventueel sacties op te leggen. APNIC, ARIN, AFRINIC, LACNIC, RIPE voelen zich vooral verantwoordelijk voor goede uitgifte en voorlichting, terwijl ze eigenlijk over het gehele proces van allocering gaan. Dat is een andere zwakte van hoe de gemeenschap met ASen om gaat, terwijl dat actief op verantwoordelijkheid wijzen vanuit de RIRs en santies hanteren waarschijnlijk meer effect zal hebben dan hopen dat iedereen eens uit eigen beweging verantwoordelijkheid gaat nemen.

[Reactie gewijzigd door kodak op 22 juli 2024 14:22]

[GrooV]

Een AS nummer krijg je juist wel makkelijk, daar hoef je officieel niet eens multihomed voor te zijn