Panama sluit UDP-poorten vanwege VoIP

De site Linux and Main heeft een zeer opmerkelijk verhaal geplaatst over de praktijken die in Panama gaande zijn. De regering aldaar heeft alle internetproviders opgedragen om 46 UDP-poorten te blokkeren. De reden hiervoor is het afnemende gebruik van het POTS (plain old telephone system) vanwege de opkomst van Voice-over-IP technologie. Bellen via internet met programma's als NetMeeting, Dialpad en Net2phone zou de oorzaak zijn van de dalende inkomsten van het telefoon-bedrijf, iets wat de overheid blijkbaar wil voorkomen. De gevolgen van de beslissing zijn tot ver buiten de grenzen van het land zelf te merken. Vanwege de geografische ligging - Panama vormt een brug tussen Noord- en Zuid-Amerika - komen een aantal belangrijke onderzeese glasvezelbundels bij elkaar op Panamees grondgebied. Veel internationaal internetverkeer stroomt dus door de backbones van de in dat land gevestigde providers. Wereldwijd kunnen mensen die contacten op een ander continent onderhouden er dus last van ondervinden:

The decree is apparently rooted in complaints by Cable & Wireless Panama (Motto: "If you're worried about your data, voice, or Internet service provider, we're here to help"), which says it is losing money due to users employing the Internet to make otherwise expensive internetional telephone calls -- calls that would otherwise be listed on Cable & Wireless bills.

The UDP ports involved include: 1034, 1035, 2090, 2091, 5000, 6801, 6802, 6803, 9900, 9901, 12080, 12120, 12122, 22555, 26133, 30582, 35061, 38000, 38100, 38200, 47563, 48310, 51200, and 51201.

De providers zouden inmiddels bezig zijn met een protestactie.

Reacties (57)

[siebrand]

Dit soort initiatieven zijn een grote bedreiging voor de continuiteit van Internet en de verdere ontwikkeling van diensten daarop, in dit geval in het bijzonder VoIP technologie. Dit is censuur met een internationale uitstraling. Het zou in, mijn ogen, diplomatieke druk op de regering van Panama rechvaardigen met als doel de huidige blocks ongedaan te maken en vrije doorgang van TCP/IP verkeer over de verbindingen te herstellen.

[curry684]

vrije doorgang van TCP/IP verkeer over de verbindingen te herstellen.

TCP is even net heel wat anders dan UDP. VoIP werkt nou net zo mooi over UDP omdat dat veel minder overhead en network traffic genereert, en bij spraak maakt het niet uit als je, zoals gebruikelijk bij UDP, hier en daar een datapakketje kwijtraakt. Je bedoelt dus dat ze UDP/IP traffic moeten herstellen.

[Anoniem: 28557]

TCP is even net heel wat anders dan UDP.
[...]
Je bedoelt dus dat ze UDP/IP traffic moeten herstellen.

TCP/IP is een verzamelnaam voor een hele ris protocollen, waaronder UDP. Het is genoemd naar de 2 belangrijkste protocollen, nl. TCP en IP.
De volledige naam van TCP/IP is "The TCP/IP protocol suite".
Andere protocollen zijn bv. ARP, DNS, HTTP, SMTP, ICMP.

[Anoniem: 28557]

Lees nou gewoon wat ik schrijf. Ik weet heus wel wat het verschil is tussen TCP en UDP. Alleen de naam "TCP/IP" (wat kort is voor "The TCP/IP protocol suite"), beschrijft meer dan alleen TCP en IP. De TCP/IP protocol suite is een hele groep protocollen, waaronder TCP en IP, maar ook UDP, ICMP, ARP, etc.

[edit]reactie op edit van GameCom:
Nogmaals: lees nou wat ik schrijf. Ik zeg niet dat UDP onder TCP valt, ik zeg dat UDP onder TCP/IP valt.

TCP/IP is een groep protocollen, waar onder andere TCP, UDP en IP onder vallen. TCP/IP is gewoon een naampje voor een protocol suite...

[edit2]
http://www.protocols.com/pbook/tcpip.htm
http://www.networksorcery.com/enp/topic/ipsuite.htm
http://www.acm.org/crossroads/xrds1-1/tcpjmy.html
http://www.geocities.com/SiliconValley/Vista/8672/network/
http://www.webopedia.com/TERM/T/TCP_IP.html

[Turtle]

GameCon, Jeroenr heeft het helemaal niet mis, ga nau niet van iemand zitten zeggen dat ie ut fout heeft als je het verhaal zelf niet helemaal snapt.
Hij heeft het over TCP/IP als in de hele groep protocollen, niet over het woordje TCP of IP appart. En jah, bij die protocollen suite horen meer protocollen dan alleen die die in de naam worden gebruikt. Als jij in windows het protocol TCP/IP toevoegd beschik jij toch ook spontaan over UDP?
En als we aan het mierenneuken zijn, UDP/IP wat moet dat dan zijn? UDP bestaat en IP bestaat, maar die combinatie staat officieel toch helemaal nergens voor.
Dus mensen haal alsjeblieft mensen die wat zinnigs zeggen zoals jeroenr van die troll af.

Edit op Edit van GameCon.. god wat een verhaal wordt dit zeg, nau mijn laatste reactie:
jij hebt in windows (of linux, of Mac) TCP/IP geinstalleerd en alleen TCP/IP.. en toch blijkt dat je over UDP beschikt... rare hoe kan dat????

[Inferno]

Dat heb je toch echt mis.

TCP heeft namelijk een zogenaamde throttle, en is dientengevolge een "sociaal protocol" en heeft een foutcorrectiesysteem, terwijl UDP deze niet heeft en alles maar gewoon erdoor spuit, geen rekening houdende met ander dataverkeer en aan foutcorrectie geen aandacht besteedt.

Ik denk dat jij het over IP hebt, waarvan zowel TCP als UDP gebruik van maken, maar dit protocol zit op een totaal andere network-layer.

De protocollen HTTP, FTP, SMTP, etc liggen allemaal op de Application level, terwijl TCP op de Transport layer ligt. De protocollen maken dus wel gebruik van TCP, maar kunnen eigenlijk net zo goed van een ander transport layer protocol gebruik maken die dezelfde garanties heeft als TCP. IP ligt overigens op zijn beurt weer op de Network layer, waar zowel UDP als TCP gebruik van maken.
Internet telefonie (waar het hier toch eigenlijk om gaat) en streaming media maken daarentegen gebruik van UDP, vanwege de kleine hoeveelheid overhead (geen foutcorrectie) en de hogere snelheid (niet-sociaal + geen foutcorrectie).

edit: reaktie op 2e post van Jeroenr:
Je zegt dat UDP onder TCP valt. Dat klopt dus gewoon niet, want ze zitten op dezelfde layer, de andere die je noemt zitten op een andere layer dan TCP en maken dus gebruik van TCP, maar vallen niet onder TCP. Daarnaast heeft TCP zelfs zijn naam te danken aan Transmission Control, iets dat UDP niet heeft, dus... trek je eigen conclusie...

edit 2: reaktie op edit van jeroenr ( )
Zweer... daar heb ik echt nog nooit van gehoord. Wel heel onlogisch trouwens dat ze dat allemaal in 1 suite flikkeren terwijl ze totaal verschillende garanties bieden.

edit 3: reaktie op Turtle
Kerel, Troll? Waar slaat dat nou weer op man? Ik had echt nog nooit gehoord dat UDP onder TCP/IP zou vallen, iets dat in mijn ogen ook totaal onlogisch is en ik ook nooit geleerd heb (ja, ik studeer informatica ja, dus ik zou zeggen dat ik geen n00b ben op dat gebied). UDP/IP zou het in mijn ogen inderdaad moeten zijn, dat is gewoon 10x logischer.

[Rembert]

Dit soort initiatieven zouden aan moeten tonen dat Internet een dergelijke nationale beslissing zonder problemen moet kunnen overleven. Was Internet niet oorspronkelijk ontworpen als koude oorlog wapen dat ook in een werkelijke oorlog gewoon blijft functioneren ondanks het feit dat wapens sommige delen van het netwerk uit zouden schakelen? Zie Panama als een uitgeschakeld deel. Het verkeer moet dan feitelijk gewoon worden gererouteerd. Meer niet. Als het initiatief van Panama ernstige gevolgen gaat hebben dan is er een duidelijke zwakheid van Internet aan het licht gekomen, een zwakheid waar mensen als Osama Bin Laden misschien ook wel heel erg geinteresseerd in zijn.

[siebrand]

Je hebt hier niet te maken met een routeringsprobleem, maar met een port block (hogere laag in het OSI model). Dat packet gaat geen andere route zoeken, want er IS al een route voor dat packet, maar daar wordt het gedropt.

Internet overleeft het uitvallen van routers maar heeft grote problemen met het filteren van onderdelen.

Daarnaast is het UDP en daar komt geen ACK op. Niemand die ooit gaat uitvinden waarom dit niet werkt...

[epoman]

Dit is niet alleen naïef (men vind hier toch binnen no-time weer een oplossing voor), maar ook reden tot nadenken. In wezen is dit een vorm van het begrenzen van de ontwikkelingen van een medium. Internet is ongekend belangrijk voor de communicatie wereldwijd, en de mogelijkheden groeien met de dag.

Wanneer een regering meent dat het internet er voor zorgt dat een bedrijf inkomsten misloopt, waar ligt dan het probleem? Volgens mij toch echt bij het bedrijf in kwestie. En welke regering gaat er nu over tot zulke radicale stappen als een bedrijfje wat loopt te jammeren?

Ik zie drie mogelijkheden: de regering loopt belastinggeld mis door lagere inkomsten C&W; C&W geeft de regering veel geld om deze poorten dicht te gooien; of een combinatie hiervan. Indien er mensen zijn die wel weten hoe de vork in de steel zit, gaarne uitleg.

Er zit een luchtje aan dit bericht. Ik weet niet wat precies, maar het stinkt wel.

[hufkes]

Ik weet niet hoe goed je spaans is, maar anders kun je originele bericht hier nalezen: http://www.ersp.gob.pa/busqueda/show_resol.asp?id=JD-3576&idsector=1

Via Babelfish is trouwens wel een redelijke vertaling te realiseren volgens mij

[itsme]

Zo onlogisch als dit op het eerste oog lijkt is dit niet, in noodgevallen moet er een netwerk zijn dat onafhankelijk van internet kan opereren voor de communicatie met nooddiensten etc, dit netwerk is veel te duur als t niet gebruikt word behalve in noodsituaties, om behoud van het netwerk mogelijk te maken moet men de exploitatie ervan aantrekkelijk maken, een goedkope oplossing is dus de concurentie verbieden.

[Raafz0r]

Dus je wilt een oud netwerk behouden, voor nooddiensten, terwijl er voor gewone gebruikers al veel betere mogelijkheden zijn?

Concurrentie verbieden mag dan wel goedkoop zijn, maar in dit geval zeker geen goede oplossing. Laat dat C&W maar zorgen dat ze hun product aanscherpen als mensen het niet meer willen.

[howbizar]

In Panama is het aantal aanvragen voor een telefoonaansluiting 5 keer zo hoog als het aantal gerealiseerde telefoonaansluitingen. Als het volk niet kan bellen met een telefoon, dan maar via het internet. C&W kan gewoon niet op tegen VoIP dus dan gaan ze huilen.

[boner]

nou als panama dat doet met de routers en infra-structuren van andere partijen zou dat wel eens een handelsoorlogje worden.

Maar ach. C&W zal toch heus wel gaan tunnelen dan? zo moeilijk is het niet om dit te omzeilen. Wel jammer voor de bandbreedte overigens. UDP is toch iets handiger mbt bandbreedte verbruik dan tcp.

[SilentStorm]

Het idee is juist dat tcp wordt gebruikt voor bestandsoverdracht, waarbij het belangrijk is dat het bestand in precies dezelfde staat aankomt als het verzonden is. (bij fouten wordt het hele pakket opnieuw verzonden). Voor udp (er staat trouwens foutief upd in het bericht) is dat anders: daar wordt constant data verzonden zonder te kijken of het goed is aangekomen. ideaal voor bv online games, shoutcast, online video en ook voice over ip.

Qua snelheid zul je er niets van merken omdat de bandbreedte gelijk blijft. Alleen een aantal poorten zijn niet meer toegankelijk. (belachelijke actie trouwens..). Overigens is dit voor de makers van deze programma's zo te wijzigen door in het protocol de poort te veranderen in een vrije poort die niet wordt geblokt, en daar een patch van uit te brengen. Ik verwacht dat dit de komende dagen dan ook vaak zal gebeuren.

[jvo]

Om iets preciezer te zijn. TCP brengt een verbinding tot stand. UDP werkt met losse pakketjes. (Ideaal voor DNS dus)

In principe was het de bedoeling dat voice over ip met TCP ging werken. Probleem is dat bijna alle router software de volledige TPC/IP standaard niet ondersteunt.

[Anoniem: 28557]

In principe was het de bedoeling dat voice over ip met TCP ging werken.

Is dat zo? Het lijkt mij nl. niet logisch om dit met TCP te doen, aangezien het in de praktijk nutteloos is om een verdwenen pakketje opnieuw te sturen. Voorbeeld: (hier ga ik er even vanuit dat elke letter van een gesproken zin een apart pakketje is, wat natuurlijk onzin is)
D-I-T-I-S-E-E-N-T-E-S-T
Dit wordt verzonden, elk 5e pakketje raakt verloren:
D-I-T-I-E-E-N-T-S-T
Nu gaan we de verloren pakketjes resenden, uiteraard met een latency, laten we zeggen, 2 pakketjes later:
D-I-T-I-E-E-S-N-T-S-T-E-T
Zie je dat, ondanks dat het bericht nu compleet aangekomen is, dit een stuk minder duidelijk "hoorbaar" is dan een incompleet bericht?

Met een normale bestandsoverdracht is dit geen probleem; je kunt immers de losse stukjes later weer in de juiste volgorde zetten. Met voice kan dat niet, omdat je -wil je een beetje normale latency hebben- de voice direct gaat afspelen als het binnenkomt. Als je zou moeten wachten tot de verloren pakketjes ook binnen zijn, zou het spraaksignaal met horten en stoten binnenkomen.

Probleem is dat bijna alle router software de volledige TPC/IP standaard niet ondersteunt.

Deze begrijp ik niet helemaal... wat ontbreekt er aan een router waardoor VoIP mbv TCP (met uitzondering van wat ik hierboven beschrijf) niet zou werken?

[jiriw]

Reactie op KePZ:

Een probleempje dan nog dat heet: DELAY ... je wil absoluut niet anderhalve seconde willen w8ten omdat er nog pakketjes gesorteerd moeten worden want audioblokje 2 tot 8 kunnen dan echt pas beluisterd worden als herzonden blokje 1 binnen is.
*oeps stond ook al bij jeroenr*

[Maartenr]

De meeste routers ondersteunen IP en niet TCP. TCP zit te hoog in het osi-model. Omdfat ze dit niet ondersteunen moet een verloren pakket over de gehele lengte herzonden worden ipv tussen routers onderling, hierdoor onstaat te veel delay.

ISN is het Initial Sequence Number. Dit is het getal wat als startnummer wordt gebruikt (wordt elke 4 ms met 1 verhoogd). TCP gebruikt daarna gewoon een 32 bits sequence nummer wat verhoogd wort met elke verzonden byte. Zowel de zendende als de ontvangende partij hebben een sequence nummer.

[Anoniem: 53946]

Precies voor dit probleem heeft TCP (of juist IP) een "ISN" I... Sequence Number. Hiermee kunnen pakketjes, voordat ze samen gevoegd worden, gesorteerd worden en zo ontstaat de juiste data dus.

-- edit: *kuch* niet helemaal goed gelezen

[boner]

het voordeel van UDP boven TCP voor dit soort verkeer is dat voor elk TCP pakketje dat wordt verstuurd er ook een retourpacketje met een ACK komt. Voor de zender maakt dit allemaal geen klap uit. inderdaad. maar voor mensen aan de andere kant van de kabel wel. Die zitten dan namelijk met heel veel pakketjes die moeten wachten op de ack's. vandaar dat voor dit soort verkeer, waarbij de inhoud wel eens een pakketje mag wegraken of verkeerd gaan, het beter is om UDP te gebruiken.

[jiriw]

Qua snelheid zul je er niets van merken omdat de bandbreedte gelijk blijft.

Helaas heb je niet helemaal gelijk. De headers van een UDP pakketje zijn kleiner dan dat van een TCP pakketje met de zelfde effectieve inhoud.
Dus kan je meer bytes/sec verzenden over UDP dan dat je zou kunnen doen over TCP.
Nadeel is idd wel dat UDP niet "secure" is wat betreft of alle data aankomt, maar dat is met VoIP niet nodig (en soms zelfs niet wenselijk)

Overigens is dit voor de makers van deze programma's zo te wijzigen door in het protocol de poort te veranderen in een vrije poort die niet wordt geblokt, en daar een patch van uit te brengen. Ik verwacht dat dit de komende dagen dan ook vaak zal gebeuren.

Helaas denk ik van niet. Tunnelen kan een idee zijn, maar poorten veranderen niet. Aangezien je dan bij alle mensen over de wereld die VoIP software gebruiken (b.v. PhoneFree gebruikt de UDP poorten 1034 - 1035 en 9900 - 9901 voor INCOMMING data) die poort moet veranderen.

[Anoniem: 2141]

dat bandbreedte verhaal ga je echt niet merken..d'r ligt zo ontzettend veel overcapaciteit op de zeebodem..

[witchdoc]

Die wel netjes betaald wordt per verbuikte bandbreedte

Leuk vinden ze't dus zeker niet.

[Wouter Tinus]

C&W is de Panamese KPN, geen internetprovider.

[boner]

nee hoor. C&W is een oer engels bedrijf. doet al 130 jaar aan telecom. Is samen met worldcom en AT&T een van de grootste telecom aanbieders ter wereld.

zie http://www.cw.com/resources/17/17989.pdf voor company info...

[Wouter Tinus]

Maar ze runnen het telefoonnet in Panama, en dus zijn ze te vergelijken met de KPN, en zeker niet met een internetprovider die het zaakje wel zal proberen te omzeilen, zoals je hierboven vraagt.

[Anoniem: 23081]

Eindelijk een staat met lef, dat kan je niet van de meeste Westerse staten zeggen. Heil bush the cowboy. De meeste Westerse staten doen alles wat usa goed vind. Zie EU-versie van DMCA, amerikaanse kernwapens die in belgie liggen,...

[GarBaGe]

Vanwege de geografische ligging - Panama vormt een brug tussen Noord- en Zuid-Amerika - komen een aantal belangrijke onderzeese glasvezelbundels bij elkaar op Panamees grondgebied. Veel internationaal internetverkeer stroomt dus door de backbones van de in dat land gevestigde providers.

Gewoon de knooppunten voorzien van hardware die niet verder kijkt dan alleen de hardware laag (ik meen layer 1 in het OSI-model). Op dat niveau zijn er geen poorten, maar alleen bits.
Kan je toch alleen blijven routen
En anders kan je nog Panama-VPN tunnels aanleggen om het verkeer voor en na Panama ff over een ander poortnummer (en bij voorkeur TCP) te mikken

Met TCP/IP vallen meer dan genoeg trucs uit te halen om dit te omzeilen

[Swinnio]

Gewoon de knooppunten voorzien van hardware die niet verder kijkt dan alleen de hardware laag (ik meen layer 1 in het OSI-model). Op dat niveau zijn er geen poorten, maar alleen bits. Kan je toch alleen blijven routen

Dat is dus grote onzin. Je kunt nooit routen op de fysieke laag, omdat pas in de hogere lagen de doeladressen en eventuele routing headers staan. Of wou je soms op de fysieke laag elk bit gaan interpreteren en zondigen tegen een van de belangrijkste elementen van het OSI-model (elke laag hoeft niet te weten wat er in de bovenliggende laag gebeurt)?

En anders kan je nog Panama-VPN tunnels aanleggen om het verkeer voor en na Panama ff over een ander poortnummer (en bij voorkeur TCP) te mikken

Je hebt blijkbaar geen flauw idee waar je het over hebt. VoIP werkt juist relatief goed omdat het van UDP gebruikmaakt. Het grote verschil tussen UDP en TCP is dat bij UDP een snelle aflevering veel belangrijker is dan een accurate bezorging. Ideaal voor spraak dus. VoIP over TCP zal dus veel minder goed werken. Laat staan de extra delay en overhead door de tunneling.

Met TCP/IP vallen meer dan genoeg trucs uit te halen om dit te omzeilen

Inderdaad, maar niet degene die jij in je hoofd hebt.

[Anoniem: 45514]

Je kunt nooit routen op de fysieke laag, omdat pas in de hogere lagen de doeladressen en eventuele routing headers staan. Of wou je soms op de fysieke laag elk bit gaan interpreteren en zondigen tegen een van de belangrijkste elementen van het OSI-model (elke laag hoeft niet te weten wat er in de bovenliggende laag gebeurt)?

Ip en tcp zijn twee verschillende lagen, waar voor routering alleen de IP laag van belang is. Daar staan de destination en source adressen.

Tunnelling is niet eens nodig in zijn volledige vorm. Gewoon een kwestie van de destination poort veranderen voor panama, en weer terug zetten na panama. Natuurlijk omslachtig, maar het filteren op die poorten is dat zowieso.

[Anoniem: 19339]

Als je alleen naar de bitjes kijkt, en niet naar wat de bitjes betekenen, weet je niet wat erin staat, en dus niet wat de destination is, en dus valt er niks te routen.

[dmeij]

Omgekeerde wereld dit laten die eikels gewoon aandelen nemen in de internetproviders in plaats terug in de tijd te gaan met pots op lange termijn gaat dit tegen ze werken.

[Olaf van der Spek]

Waarom zouden die poorten op de doorgaande routes geblokkeerd moeten worden?
Het is toch voldoende deze poorten alleen te blokkeren op de gateways van de ISPs zodat alleen lokale klanten er last van hebben?

[SirBlade]

En waren er niet een hoop mensen die dachten dat het een goed idee zou zijn als de overheid de kabel en telefoon bedrijven weer zou opkopen. Ziehier de mogelijke resultaten

[itsme]

Net niet, omdat het commerciel is moet het product kunnen concureren met andere diensten, als het een overheidsproduct was is het doel niet om winst te maken maar om een netwerk te hebben. Er hoeft dus niet geconcureerd te worden.

[Anoniem: 3994]

...om 46 UPD-poorten te blokkeren.

Nieuw protocol zeker...

[Tikfout ondertussen gewijzigd]