Op *nix systemen: traceroute. Voor windows: tracert.


Correctie, een packet kan een route in de header hebben staan. Dit wordt echter nergens meer geaccepteerd omdat het nogal een security risico met zich mee brengt.

http://en.wikipedia.org/wiki/Source_routing

Wat er bij die ISP mis ging heeft waarschijnlijk te maken met een verkeerd geconfigureerde BGP.

http://en.wikipedia.org/wiki/BGP

Iedere hop bepaalt zelf (adhv routeringsprotocol, statische routing, policy routing, source- en/of destiation address) hoe de packets worden gerouteerd. Je kunt geen "via" opgeven oid.

Inderdaad, je kunt niet zelf de routering bepalen. Iedere poging daartoe wordt (als het goed is) genegeerd. En terecht. BGP is een prima protocol binnen zijn grenzen en beperkingen.

EJ

BGP is niet zo best beveiligd. Gelukkig voor de gebruikers (lees: netwerkbedrijven) is het te technisch voor de algemene pers om over beveiligingsfalen te berichten.

Ik neem aan dat je bedoeld het route commando met tracert en traceroute kan je de hops volgen die je aflegt
aan de TS je kan tot bepaalde hoogte (de eerste hop) je route bepalen. Echter zijn er altijd manieren. Je zou je eens moeten verdiepen in http://en.wikipedia.org/wiki/Autonomous_system_%28Internet%29 :)

Je zou je eens moeten verdiepen in routing algemeen :)
Er staat geen route in een layer 3 header maar een source en destination adres :) aan de hand van de destination ga je routen :) (of aan de hand van de source maar dat komt veel minder voor)

Bekijk dat ook eens verschillende protocollen zoals RIP(v2)/OSPF/ en cisco proprietary EIGRP.

Je kan vaststellen welke route gebruikt word, maar hebt hier zelf bijna geen controle over.

Indien de globale peering-setup uit je land je gekend is, kan je soms wel je route bijsturen door een strategish geplaatste proxy er tussen te steken, maar dat is het dan ook weer, en maar goed ook !

Het internet is net zo opgebouwd om zelf-regulerend en zelf-corrigerend te zijn, om rond panne's en overvolle uplinks te kunnen routen.

Ooit van 'source routing' gehoord, en waarom dat zo evil is dat je dat wegfiltert? ;)

Om antwoord op je vragen je te geven:

Kort: Neen, die mogelijkheid heb je niet.

Langer:
Als gebruiker bij een ISP: Je krijgt van de ISP een 'default gateway' toegewezen tijdens het aanloggen op het netwerk, daarna zijn jouw pakketjes aan de grillen (routerings-wensen) van de ISP overgeleverd.

Als ISP zelf: Zeer beperkt. Je kunt in je eigen netwerk aangeven dat je bepaalde netwerken prefereert om verkeer voor een bepaalde destination heen te sturen, als je al kunt kiezen en soms zelfs met omliggende netwerken afspraken maken over naar welke netwerken zij het verkeer weer sturen (bij Peerings en ingekochte Transit) maar veel meer mogelijkheden heb je niet. Er zijn ongeveer 32 duizend van de 64 duizend AS'en in gebruik, vaak ga je door meerdere (4 of 5 of nog meer) van die AS'en heen om je bestemming te bereiken, na het 1e AS ben je echt overgeleverd aan de wensen van andere bedrijven.

Al deze netwerken zijn van bedrijven a-la UPC/KPN/Level3/Sprint enzovoort en praten BGP met elkaar. Elk netwerk maakt daarin uiteraard zijn eigen policies over waar welk verkeer voor welke bestemming wordt uitgewisseld, daar kun je als gebruiker dus niet in sturen.

Source-routing is in onbruik en dat is om diverse redenen maar goed ook, bovendien moet dat over het hele pad ondersteund worden om effect te hebben.


Er staat geen route in de header van je ip-pakket. (Er bestaat wel een optie in de header die LSRR heet, maar die kun je net zo goed vergeten want dat ondersteund niemand) Routering werkt niet door de route te lezen uit je ip-pakket, maar door te kijken waar het pakket heen moet (de destination in de ip-header), elk netwerk-element in het pad maakt zijn eigen beslissing om je pakket door te sturen. Binnen een Autonoom Systeem (afkorting "AS", is het netwerk van 1 partij/bedrijf, bijvoorbeeld het netwerk van Cogent (AS174) of KPN (AS286)) geldt een routeringspolicy waardoor alle elementen in dat netwerk dezelfde beslissing nemen, dezelfde route kiezen dus. Dus ja, de route wordt bepaald door de apparatuur in de data-centers en nee, je hebt daar (na de eerste 'hop') geen controle meer over.



Het Internet 'denkt' niet in landen, maar in netwerken (AS'en). Toevallig hebben sommige landen (Pakistan, China) hun eigen AS voor de inwoners neergelegd. Al die AS'en aan elkaar maken het Internet. Je moet het niet zien alsof je door Pakistan moet om naar India te komen. Je moet via jouw ISP, via waarschijnlijk nog een paar AS'en naar het AS van het destination ip (toevallig in India). Afhankelijk van de policies van alle tussenliggende AS'en kom je wel of niet door Pakistan.

Als kanttekening hierbij, zijn de meeste AS'en van die landen waar jij het over hebt, geen transit-partij en dus bijna altijd eindbestemming. De kans dat je pakketten hier dan doorheen moeten zijn nagenoeg nul.

/Wall of text

Bedankt voor alle reacties! (Tread-starter) en de duidelijke uitleg. Ik heb voorlopig weer wat dingen uit te zoeken wat betreft netwerk protocollen...

Groet,


Eldert.

Ik denk dat ik na 15 jaar best wel weet hoe het werkt.

Koop TCP/IP Illustrated eens.

http://books.google.com/books?id=-btNds68w84C&lpg=PA104&dq=tcp%2Fip%20lsrr&pg=PA104#v=onepage&q=tcp/ip%20lsrr&f=false

Inderdaad. SirDice geeft een goed advies voor beginners zoals genoemde anoniem.

Kijk anders eens heel snel bij http://users.telenet.be/bdr/IPv6/IPv6_extension_headers.html. Kernwoorden 'source routing'.

EJ

Het klopt dat in zowel IPv4 als in IPv6 een mogelijkheid tot het opgeven van een te volgen netwerkpad in het pakket is gedefinieerd.

Het is ook een feit dat deze optie door vrijwel alle netwerk operators om een aantal goede redenen genegeerd wordt, dus voor de vraag "kan ik als eindgebruiker mijn pad door Internet controleren" is source routing geen antwoord.

Vrijwel het enige wat je als eindgebruiker kunt doen om "andere routing" te krijgen is om je verkeer, of verkeer voor bepaalde bestemmingen, vanaf een host in een ander netwerk te laten lopen. (proxy, tunnel endpoint).

Als BGP-spreker (bijna altijd een ISP) heb je wat meer mogelijkheden, voor je uitgaande verkeer kun je controleren welke van de aangeboden paden naar een bestemmingsnetwerk je kiest door wat BGP beslisparameters aan te passen.
Voor je inkomende verkeer kan dat ook, alleen daar kan je peer/upstream jouw hints over rulen (net zoals jij dat kunt doen voor jouw uitgaande , en dus hun inkomende verkeer)
Je invloed op routing van en naar jouw netwerken "verderop" (buiten de direct aangesloten netwerken) neemt vrij snel af.
Verder is het geheel vrij grof, dus je gaat zelden op het niveau van een enkel netwerk zitten frutten, het doel is meestal om een forse berg verkeer een ander pad te laten nemen als een bepaalde connectie vol dreigt te lopen.

Kleine kanttekening bij anoniem maandag 12:02 : Ook landen als Pakistan en China hebben niet "een eigen AS voor hun inwoners neergelegd". Ook daar hebben de ISPs/Telco's gewoon een AS aangevraagd en gekregen van de lokale RIR (APNIC), of misschien nog van IANA als ze erg vroeg waren, en gebruiken dat voor al hun aansluitingen. Inderdaad zitten die aansluiten vooral of alleen in dat land, natuurlijk. Net zoals AS8737 bijvoorbeeld erg nederlands is. (KPN planet).
(verder een prima uitleg)

Een van de Pakistaanse ISPs die de opdracht kreeg van de Pakistaanse overheid om youtube voor zijn klanten onbereikbaar te maken deed iets fout bij de implementatie daarvan, en gecombineerd met het ontbreken van filters bij de upstream peer/transit ISPs had dat eventjes wereldwijde impact, in plaats van alleen ISP-pakistan wijde impact.

Maandag 12:02 was ik nog anoniem ..

Detail-vraagje, die ISP in Pakistan/China, is die niet voor 100% in overheids-handen? ;)

Wat erger is, en daar is eigenlijk nog niet echt een oplossing voor voor zover ik weet, is het probleem wat hier aangstipt wordt, route hi-jacking. Iemand kan zich 'netwerk-technisch' voordoen als Youtube en zo dus al het verkeer 'stelen' ..

Er zijn ontwikkelingen als BGPSEC (a-la DNSSEC) en andere open-source projekten die dit probleem proberen te tackelen, maar iets concreets lijkt er (nog) niet te zijn..

Een niet zo fijn stukje mbt het onderwerp: (van http://urbancomputerrepair.com/technical_informatio/computer-technology/internet-route-hijacking
and the scariest one of all…

During an experiment at DEFCON researchers showed that they could divert a companies unencrypted data and re-route it to a completely different location, eavesdrop on all the data and then send the data along to its final destination like nothing happened and the original company had no idea that this was going on behind the scenes!

We still don’t know if this “eavesdropping” is currently happening anywhere, or everywhere in the world today!

@Loserenzo:

(ben anoniem 14:04)

Het is een beetje nitpicken, maar goed, het AS is dus van een bedrijf, eventueel een staatsbedrijf, en niet rechtstreeks van een ministerie. In elk geval in Pakistan zou het trouwens best kunnen dat het inderdaad een echt privaat bedrijf is, en niet de enige aanbieder ook. (het youtube verbod zal natuurlijk door alle operators daar uitgevoerd moeten worden, en de rest deed dat dan zonder zichtbare impact); Ik heb het niet meer nagezocht, welke ISPs er zijn in .pk en wie het verknalde.
Voor de oekaze "wij verbieden site xyz, dus bedrijf, privaat of niet, blokkeer maar" maakt dat natuurlijk niet zo veel uit.

Route hi-jacking is alleen een probleem wanneer peers/upstreams niet filteren. Dat is mede waarom de bekende incidenten bekende incidenten werden, in plaats van een storing die alleen bij de ISP zelf opvalt.
Normaal gesproken heb je als (leaf)ISP [alleen eind-klanten] op je uitgaande BGP announcements filters waarin je alleen je eigen netwerken doorlaat, met nog wat sanity checks. Daarmee voorkom je dat een operator error (verkeerde netwerk, te kleine subnets) binnen je netwerk ook naar buiten toe gaat.
Dat ontbrak dus al in Pakistan. (daarnaast hadden ze de NO_EXPORT community moeten zetten op de youtube prefixen die ze intern wilden afvangen).

Aan de inkomende kant zou je eigenlijk moeten filteren dat je van je peer/klant alleen de geregistreerde prefixen accepteert, samen met nog weer wat sanity checks.
Dat ontbrak dus bij de upstream(s) van die Pakistaanse youtube hijackers.

Heel erg analoog aan ip spoofing filters feitelijk.

Die BGP filters kun je automatisch bouwen op grond van de gegevens in de whois databases van de internet registries.

Het enige is, je kunt het bijna alleen zinvol doen aan de randen, bij een upstream van een ISP/hoster die weinig of geen BGP-sprekende klanten meer heeft.
Een paar AS'en verderop is op dergelijke details niet meer te filteren.
En het invullen van de gewenste routing policies in die databases moet gebeuren door de eigenaar van de adressen, en sommige ISPs laten dat nogal liggen.

Dergelijke filters, of het goed invullen van registries ontbreken nog wel eens. En daar zit de hoofdzaak van het probleem, want een dergelijk systeem overgieten met een crypto sausje (dat is grosso modo wat BGPSEC/soBGP wil doen) helpt dan niet zo erg.
Er zitten zeker nuttige kanten aan de diverse secure routing voorstellen, en een manier om route filters automatisch in een netwerk te gebruiken maakt dingen operationeel zeker makkelijker, maar de grootste winst op moment zit gewoon in 'best practices' nu ook eens doen. Ik ben dus wat skeptisch of dat opeens wel gedaan gaat worden als er een laag crypto omheen gaat.

Die DEFCON quote is nogal overtrokken hype en paniekzaaierij.
Als je data integriteit *zo* belangrijk is moet je gewoon zelf encrypten, punt. Of het nu routes hijacken, glasvezel opgraven of corrupte personen bij je upstream zijn,in een aantal scenario's kan iemand op de juiste plek bij je data komen.
Voor routes hijacken is de juiste plek dat een netwerk wat BGP spreekt, aangesloten op een upstream die niet filtert (geen BGP en geen IP spoofing), en ook wat mitsen en maren rondom het de prefix(lengtes) van het victim bedrijf en diens 'eigen' provider.

Wie wil weten wat er ergens of overal aan het gebeuren is met z'n prefixen kan (oa) naar de [ripe] RIS tool kijken.
(Je zou nog een heel regionaal beperkte hijack kunnen missen, maar voor de rest heb je wel een goed beeld).
Wie echt serieus is met z'n high availability kijkt naar dit soort dingen; Vanuit je eigen NOC je eigen services monitoren zegt wel erg veel, maar niet alles , en vooral niet alles over wat je bezoekers zien of niet zien.

@ anoniem 14:04

Muggenziften, klopt ;)

Nou heb ik de RFC's voor BGPSEC niet gelezen, maar is het niet de bedoeling om route-objecten te signen, a-la dns-zones, en zo de herkomst ervan, het bron-AS, te kunnen identificeren? Crypto over bgp heen doen we toch al met MD5 vanwege sessie hijacking?

Ik ben overigens helemaal met je eens dat het erg fijn zou zijn als iedereen zich eens ging houden aan de best practices en bestaande informatie systemen (whois etc) ging invullen en bijhouden.

@Loserenzo,

Niet helemaal muggenziften, ik struikelde toch even over 'overheden die eigen AS neerleggen voor inwoners' , want dat is niet echt hoe het werkt.

Anyway, qua crypto, als je zegt 'signen' zeg je ook crypto; Niet alleen versleuteling maar ook authenticatie en integriteit vallen onder het vakgebied cryptografie.
En de diverse voorstellen richting secure BGP gaan onder andere dus uit van het signen (meestal met een heel PKI framework) van prefix/AS relaties.
Op moment lijkt het onderwerp nogal dood te zijn, de meeste voorstellen en presentaties zijn van rond 2003-2005.
(Oa. s-bgp (secure BGP), so-BGP (secure origin BGP), en zo te zien nog een paar drafts).
Maar goed, omdat de diverse voorstellen toch leunen op het controleren van BGP updates tegen een bepaalde bron (zoals een routing registry) ben ik dus wat skeptisch over het rendement daarvan wanneer controles die nu al gedaan kunnen worden , dat vaak niet worden.
Ook al moet ik zeggen dat sommige ideeen waar nog aan gewerkt wordt me wel zinvol lijken, al was het puur omdat ze (zelfs zonder de crypto en signing) het operationeel makkelijker maken om bepaalde controles of checks netwerk breed uit te voeren, die op dit moment wel gedaan zouden kunnen worden maar verspreid over de configs van veel routers.