hvordan er Telenor's "Music Freedom" implementert?

[Hans_Henrik]

det lar deg streame musikk via 4g uten å bruke av datakvoten din, men hvordan gjøres dette? 

først antok jeg at de bare hadde ip-whitelists, men de støtter "Spotify, Tidal, Apple Music, Deezer, Beat, og Google Music" , og spesielt med Google Music, så er det så mange cache-servere som brukes til så mange ting at jeg tror det ville vært nesten umulig å ha en fullstendig liste over streaming/cache servere for en whitelist-løsning (hvis ikke Google Music gir ut en slik liste selv, og jeg googlet det, ser ikke ut som de gjør det), samt at de sannsynligvis ville ubevisst inkludert youtube-servere samtidig.


det er usannsynlig at de bruker såkalt `deep-packet-inspection` for å se om http-headers inneholder `Content-Type: audio/mpeg` (eller noe i den duren), for 2 årsaker: de fleste (inkl. Google Music) streaming tjenester bruker kryptering som gjør at Telenor ikke kan smug-kikke på headers uansett, og: en slik løsning ville brukt masse cpu kraft (og hvis systemet ble overbelastet så ville all 4g trafikk bli tregere)

så tenkte jeg på dns-poisoning, men det hadde ikke fungert det heller (kryptering + ugyldig / fake ssl-sertifikat , streaming hadde ikke fungert i det hele tatt hos de fleste)

 

 

noen ide / noen som vet? 

Endret 29. juli 2018 av Hans_Henrik

[simen929]

Jeg har alltid trodd at det er ip-whitelist som har vært tilfellet.

Jeg vet at i google sin FCM tjeneste for push notifikasjoner så lister de opp alle nett man evt må åpne opp i brannmur o.l for å få tjenesten til å virke. Jeg antar at de i Google Music sitt tilfelle ikke vil offentliggjøre noe slikt da det ikke gir noe mening, men kanskje Telenor har fått disse listene direkte fra Google? De er tross alt en stor aktør med mye kunder. Dette er også en "gode" for Google at telenors kunder kan lytte på deres tjeneste uten å bruke sin inkluderte data.

 

Deep-packet inspection er vel litt på kanten ift personvern også, med mindre det står noe særskilt i avtalen på mobilabonnementet angående dette.

[Merko]

Er nok DNS.

[MariusJS]

De forskjellige aktørene må kontakte telenor/telia for å få 0-takstert streamingen

[MegaMann2]

Er nok DNS.

 

 

DNS?

 

Du finner ikke noe DNS i en IP-pakke i en TCP strøm hvor datamengden faktisk går.

 

 

 

Men til saken:

 

De får lister av ip-adresser fra levrandørene som er med på produktet. Dette er lister de forskjellige streamingtjenestene har lett tilgengelig.

[Merko]

DNS? 

Du finner ikke noe DNS

Har ikke noe erfaring på det området, men du kan hvertfall fint finne ut om en IP hører til under google domenene.

 

Hvordan operatørene gjør det vet jeg nå ikke men morsomt om noen vet.

[MegaMann2]

Har ikke noe erfaring på det området, men du kan hvertfall fint finne ut om en IP hører til under google domenene.

 

Hvordan operatørene gjør det vet jeg nå ikke men morsomt om noen vet.

 

 

Det er ikke noe enkel sammenheng mellom DNS oppføringen og kommunikasjonen som senere tar plass på TCP for å overføre data.

 

Det blir som å slå opp i en telefonbok, for deretter å gjennomføre en telefonsamtale ved bruk av nummeret du fant i katalogen.

Jeg tror at det å matche alle mulige DNS svar en klient får med alle sine TCP strømmer krever for mye arbeid til at det er en fornuftig måte å løse dette på.

 

Man kan slå opp reverse DNS på IP adresser man finner i en TCP strøm, men reverse DNS er ikke perfekt - og i slike store CDN er det ikke ofte de matcher den faktiske DNS adressen som er konfigurert i appene, mange ganger er ikke en reverse konfiguriert en gang.

 

Å se om en IP hører til google domenet gir ikke så mye mening i seg selv, på internett så har vi noe som heter public subnet som er tildelt til et AS. Google og mange andre CDN levrandører har et eller fler AS nummer som sine IP-adresser er knyttet til. Problemet er at disse CDNene også brukes til video (og masse annet) i mange tilfeller, og dette ønsker operatørene ikke (enda) å gi fri streaming på. Så å matche på om adressen tilhører Google i seg selv blir for dårlig.

 

Derfor må musikk streaming tilbyrderene gi nok informasjon til operatøren slik at de på en enkel måte kan matche trafikk fra et CDN som musikk streaming. Det kan være en kombinasjon av IP addresser og andre attributter som er synlig for operatøren i en TCP/IP strøm. Kanskje musikk bare streames fra spesifikke IP-adresser i CDNet som bare hoster musikk (?).

 

Dersom HTTPS benyttes så kan man ikke se noe innhold i HTTP meldingen (ikke en gang hostname), man kan kun se IP adressen som brukes av TCP/IP, men reverse adressen til den kan være så mangt, eller ingenting.

[MariusJS]

Tok forøvrig kontakt med YouTube Premium support i Norge

 

 

Hei Marius!

Takk for at du kontakter YouTube og Google Play Musikk! Mitt navn er Julie og jeg jobber her med brukerstøtte.

Så hyggelig å høre at du er interessert i YouTube Musikk! Jeg forstår at du ønsker at vi skal kontakte Telia og Telenor for å få YouTube Musikk inkludert i Music Freedom tilbudet deres.

Vi setter stor pris på å høre fra brukerne våre om hvordan vi kan forbedre våre produkter. Takk for forespørselen din, jeg skal selvfølgelig sørge for at den blir sendt direkte videre til vårt produktteam. Jeg setter også stor pris på at du har gjort research selv og lagt ved e-postadressene til både Telia og Telenor.

Jeg har dessverre ikke mulighet til å kontakte Telia og Telenor selv, men jeg kan forsikre deg om at jeg hadde gjort det med en gang hvis jeg hadde hatt anledning til det. Jeg har selv Music Freedom, og er en ivrig bruker av YouTube Musikk, så jeg ønsker selvsagt selv at dette skal bli inkludert!

Takk igjen for forespørselen din, og ikke nøl med å gi meg en lyd om du har flere spørsmål om denne saken eller noe annet, jeg hjelper deg gjerne!

Vennlig hilsen, xxx

Ser jo ut til at det er håp

[Merko]

Det er ikke noe enkel sammenheng mellom DNS oppføringen og kommunikasjonen som senere tar plass på TCP for å overføre data.

 

Det blir som å slå opp i en telefonbok, for deretter å gjennomføre en telefonsamtale ved bruk av nummeret du fant i katalogen.

Jeg tror at det å matche alle mulige DNS svar en klient får med alle sine TCP strømmer krever for mye arbeid til at det er en fornuftig måte å løse dette på.

 

Man kan slå opp reverse DNS på IP adresser man finner i en TCP strøm, men reverse DNS er ikke perfekt - og i slike store CDN er det ikke ofte de matcher den faktiske DNS adressen som er konfigurert i appene, mange ganger er ikke en reverse konfiguriert en gang.

 

Å se om en IP hører til google domenet gir ikke så mye mening i seg selv, på internett så har vi noe som heter public subnet som er tildelt til et AS. Google og mange andre CDN levrandører har et eller fler AS nummer som sine IP-adresser er knyttet til. Problemet er at disse CDNene også brukes til video (og masse annet) i mange tilfeller, og dette ønsker operatørene ikke (enda) å gi fri streaming på. Så å matche på om adressen tilhører Google i seg selv blir for dårlig.

 

Derfor må musikk streaming tilbyrderene gi nok informasjon til operatøren slik at de på en enkel måte kan matche trafikk fra et CDN som musikk streaming. Det kan være en kombinasjon av IP addresser og andre attributter som er synlig for operatøren i en TCP/IP strøm. Kanskje musikk bare streames fra spesifikke IP-adresser i CDNet som bare hoster musikk (?).

 

Dersom HTTPS benyttes så kan man ikke se noe innhold i HTTP meldingen (ikke en gang hostname), man kan kun se IP adressen som brukes av TCP/IP, men reverse adressen til den kan være så mangt, eller ingenting.

Interessant lesing

 

Skal se om jeg kan få tak i noen riktige folk i Telia, så høre hvordan de filtrerer trafikken 

[Merko]

Tok forøvrig kontakt med YouTube Premium support i Norge

 

 

Ser jo ut til at det er håp

Absolutt.

Skal se om jeg kan finne ut hvilken person i produktavdelingen i Telia som har ansvaret så kan jeg jo videreformidle

[Øystein H]

Apple benytter blant annet *.cdn-apple.com for CDN servere (i praksis Akamai) i tillegg til flere andre faste domener. Så det bør ikke være vanskelig for en operatør å lage en IP-liste over «gratis trafikk» som tilhører de enkelte tjenestene.

[MegaMann2]

Apple benytter blant annet *.cdn-apple.com for CDN servere (i praksis Akamai) i tillegg til flere andre faste domener. Så det bør ikke være vanskelig for en operatør å lage en IP-liste over «gratis trafikk» som tilhører de enkelte tjenestene.

 

 

Problemet er jo fort at disse CDNene også hoster bilder, video eller annet statisk innhold som man ikke ønsker å zero-rate.

[MariusJS]

Problemet er jo fort at disse CDNene også hoster bilder, video eller annet statisk innhold som man ikke ønsker å zero-rate.

Det finnes jo mer eller mindre samme system i USA, så tror de fleste internasjonale leverandører har en plan på hvordan man løser det, helt hvordan det funker derimot... Hadde jo vært interessant å vite hva den faktiske løsningen var

[Øystein H]

Problemet er jo fort at disse CDNene også hoster bilder, video eller annet statisk innhold som man ikke ønsker å zero-rate.

 

 

Selvsagt gjør de det men disse tjenestene går på andre IP adresser og porter.   En kan også benytte innholdskontroll for å sjekke f.eks. initiell web-header eller tilsvarende, men det tror jeg vil kreve for mye av mobiloperatøren og jeg tror ikke de ønsker å benytte dette. 

 

En CDN-server fra Akamai kan håndtere et stort antall forskjellige tjenester men alle disse må ha en dedikert IP eller port.  Hvis forskjellige tjenester skal tilbys over samme IP må en benytte forskjellige porter for å skille dem.  Alternativt kan en, dersom tjenesten leveres på lag 7 i OSI-modellen (som f.eks. http), benytte innholdsinspeksjon for å skille mellom tjenestene under initiell oppkobling.

 

Den enkleste måten for 0-taksering er å skille på IP alene eller IP sammen med port.  

 

Edit: Siste linje skal være "Den enkleste måten for 0-taksering er å benytte DNS oppslag (som igjen vil peke på IP/port til CDN server)".  Ser av kommentar at min forrige setning kunne misforståes.  

Endret 1. august 2018 av Øystein H

[MegaMann2]

Selvsagt gjør de det men disse tjenestene går på andre IP adresser og porter.   En kan også benytte innholdskontroll for å sjekke f.eks. initiell web-header eller tilsvarende, men det tror jeg vil kreve for mye av mobiloperatøren og jeg tror ikke de ønsker å benytte dette. 

 

En CDN-server fra Akamai kan håndtere et stort antall forskjellige tjenester men alle disse må ha en dedikert IP eller port.  Hvis forskjellige tjenester skal tilbys over samme IP må en benytte forskjellige porter for å skille dem.  Alternativt kan en, dersom tjenesten leveres på lag 7 i OSI-modellen (som f.eks. http), benytte innholdsinspeksjon for å skille mellom tjenestene under initiell oppkobling.

 

Den enkleste måten for 0-taksering er å skille på IP alene eller IP sammen med port.  

 

 

Det kan absolutt være slik du sier, men det er ingen regler eller standarder som sikrer at det er slik at et stk CDN med en stk IP har unikt innhold. Jeg syntes også det er litt rart om en stor innholdslevrandør må tilpasse CDNene sine etter hva alle verdens operatører trenger for å zero-rate innhold av type X, Y eller Z i sine abbenomenter.

 

Jeg kjenner ikke til Akamai sitt CDN, men på jobb benytter vi oss av AWS CloudFront, og det er ingenting som hindrer meg i å hoste både video, lyd eller bilder, eller hva som helst på et og samme CDN endepunkt med en spesifikk IP og port. Jeg kan hvis jeg vil, hoste alt av statiske filer fra en nettside på et CDN. Hvis operatøren baserer seg utelukkende på IP og port ville alt på dette CDNet blitt nulltaksert.

 

Jeg har forøvrig aldri sett noen benytte noe annet enn default port på et CDN, det høres veldig rart ut å gjøre da det rundt om kring i verden er mange nettverk som har strenge brannmurregler for HTTP trafikk. Sjansen for at netttjenesten til de som benytter seg av CDNet ikke virker blir for stort til at man ikke gjør det.

 

 

Hos oss benytter vi oss av https på CDNet vårt, og det ser jeg mange andre også gjør. Da er det umulig for operatøren selv med DPI å kunne se hva slags innhold som sendes over HTTP. Selv den initielle web-headeren som du nevner er kryptert. Alt på lag 7 i OSI modellen vil kunne være kryptert, og det blir da umulig å kunne se hva slags innhold som sendes.

 

Jeg tror heller ikke at de store CDNene garanterer en unik IP adresse per CDN endepunkt til hver av kundene sine - det skalerer rett og slett ikke i ipv4 verden.

 

Jeg vet at det er skrevet artikler om såkalte nettverks-coockies som er klartekst pakker som tagger hva en kryptert forbindelse inneholder. Disse har vært eksperimentert med i forbindelse med zero-rating. Jeg vet ikke om dette brukes i produksjon noe steder.

 

Alt i alt tror jeg ikke det holder for en operatør å basere seg på lister av IP adresser og porter alene for å identifisere innholdet i forbindelse med zero-rating.

[MegaMann2]

Etter å ha lest litt dypere og fler forskningsartikler om temaet ser det ut til at man normalt baserer zero-rating på følgende 2 metoder:

 

Hvis HTTP: DPI benyttes for å lese ut host feltet i HTTP requester og responser..

 

Hvis HTTPS: DPI benyttes for å lese ut SNI i TLS handshake.

 

Operatører får altså lister av hostnames som benyttes av innholdslevrandører for å peke mot CDNer. Hostnames er relativt stabile i forhold til IPadresser som også mye mindre nøyaktig.

 

Forøvirg er disse to metodene relativt greie å sproofe for å lure operatør til å zero-rate annen type trafikk

Endret 31. juli 2018 av MegaMann2

[Øystein H]

Tok en liten test for å finne ut hvordan noen løsninger benytter CDN-servere.  Sjekket Apple Music og Spotify (web).  Testen er gjort fra en MacBook Pro og trafikk logget via Wireshark for OSX.

 

 

Apple Music.

Testet oppkobling via Altibox, Telia 4G og jobbens eget nettverk.

Uansett valg så benyttet Apple Music CDN server med navn e673.dsce9.akamaiedge.net.  Den startet med et oppslag mot init.itunes.apple.com -> init-cdn.itunes-apple-com.akadns.net -> itunes.apple.com.edgekey.net -> e673.dsce9.akamaiedge.net.

Oppkoblet via Altibox og Telia fikk jeg samme IP adresse for e673….. men fra jobbens nettverk eller jobbens gjestenett så fikk jeg forskjellige IP-er (på helt andre subnet).   Klarte også å få forskjellig IP på samme DNS oppslag mot Altibox noe som tyder på en round-robin-type algoritme for å flytte trafikken mellom forskjellige servere.

 

Så det virker som Apple Music streamer sin musikk via CDN server “e673.dsce9.akamaiedge.net” og det viser også Wireshark.  Hvilken IP adresse som et DNS-oppslag mot e673.dsce9.akamaiedge.net gir, vil være avhengig av hvilken ISP du benytter og hvor i verden du befinner deg. 

 

 

Spotify

Samme type oppkobling testet.  Her fikk jeg opp p.scdn.co som CDN server.  IP adressen var forskjellig avhengig av fra hvilken region jeg koblet meg opp.  Fikk samme IP i Norge og Sverige men en annen i Frankrike og en 3. i USA.   Spotify benytter Google CDN servere for å tilby musikken sin så det virker fornuftig.

 

 

Og for å sitere Telenor om hva som er nødvendig fra tjenestetilbyderne.

For at en ny tilbyder skal kunne inkluderes i Music Freedom, må Telenor kunne gjenkjenne datatrafikken i vårt mobilnett. Dette må konfigureres og testes før lansering. I den forbindelse vil det være behov for informasjon om for eksempel hvilke IP-adresser, vertsnavn og protokoller som tilbyderen benytter for å levere innholdet til brukernes mobiltelefoner. 

 

 

 

[Hans_Henrik]

kan noen med "telenor music freedom" kjøre denne php-scripten, å se om 10 megabytes faktisk blir trukket fra abonnement eller ikke? (ps, du kan bytte ut 10 megabytes med å bytte det første 10-tallet i koden,)

 

php -r '$max_dl=10*1024*1024;$dl=0;$requests=0;$ch=curl_init("https://e673.dsce9.akamaiedge.net");curl_setopt_array($ch,[CURLOPT_SSL_VERIFYHOST=>0,CURLOPT_VERBOSE=>0,CURLOPT_RETURNTRANSFER=>1,CURLOPT_HEADER=>1,CURLINFO_HEADER_OUT=>1]);while($dl<$max_dl){curl_exec($ch);$info=curl_getinfo($ch);$dl+=$info["header_size"]+$info["request_size"]+$info["size_download"];++$requests;echo "\r$requests: $dl/$max_dl (".(($dl/$max_dl)*100)."%)";}' 

koden vil laste ned 10 megabytes fra https://e673.dsce9.akamaiedge.net , 
men det tar noen minutter (rundt 20 minutter her iallefall), da roundtrips er litt tregt, og den kun laster ned ~300 bytes per roundtrip, og den sender/laster kun 1 request om gangen 

 

- hvis du ikke har php (som de fleste sikkert ikke har): hvis du er på en android telefon, så kan du skaffe php ved å laste ned Termux, https://play.google.com/store/apps/details?id=com.termux&hl=en
og skrive "pkg install php" i Termux, deretter kopiere inn koden ovenfor

hvis du er på Windows, kan du laste ned php her https://windows.php.net/download/ , pakke det ut til C:\php
og så skrive "C:\php\php.exe -r" isteden for "php -r" i cmd, og så lime inn resten av koden ovenfor

hvis du er på MacOS, da er php ferdiginstallert fra Apple, bare kjør koden i en terminal

hvis du er på iOS (iPhone/iPad/etc)... da vet jeg ikke hvordan du kan kjøre php-cli =/ 

 

 

Etter å ha lest litt dypere og fler forskningsartikler om temaet ser det ut til at man normalt baserer zero-rating på følgende 2 metoder:

 

Hvis HTTP: DPI benyttes for å lese ut host feltet i HTTP requester og responser..

 

Hvis HTTPS: DPI benyttes for å lese ut SNI i TLS handshake.

 

Operatører får altså lister av hostnames som benyttes av innholdslevrandører for å peke mot CDNer. Hostnames er relativt stabile i forhold til IPadresser som også mye mindre nøyaktig.

 

Forøvirg er disse to metodene relativt greie å sproofe for å lure operatør til å zero-rate annen type trafikk

takker, for TLS/SNI, ja det ser ut som det kan spoofes ja,

 

 

Tok en liten test for å finne ut hvordan noen løsninger benytter CDN-servere.  Sjekket Apple Music og Spotify (web).  Testen er gjort fra en MacBook Pro og trafikk logget via Wireshark for OSX.

 

 

Apple Music.

Testet oppkobling via Altibox, Telia 4G og jobbens eget nettverk.

Uansett valg så benyttet Apple Music CDN server med navn e673.dsce9.akamaiedge.net.  Den startet med et oppslag mot init.itunes.apple.com -> init-

Spotify

Samme type oppkobling testet.  Her fikk jeg opp p.scdn.co som CDN server.  IP adressen var forskjellig avhengig av fra hvilken region jeg koblet meg 

takker 

Endret 11. august 2018 av Hans_Henrik

[Hans_Henrik]

av en eller annen grunn får denne URLen (NSFW*2!!) en gjennomsnittshastighet på 270kbps, når alt skulle vært nede på 128kbps... 

$ wget https://vip-video33000.fc2.com/up/flv/201504/10/W/20150410Wsee7BWu.free.mp4?mid=4a15e342585768abc7c61c4550536103 -q -O- | dd of=/dev/null status=progress

23379968 bytes (23 MB, 22 MiB) copied, 87.0672 s, 269 kB/s
45734+3 records in
45735+1 records out
23416375 bytes (23 MB, 22 MiB) copied, 87.2492 s, 268 kB/s

   kan det være relatert? lurer på om den trekker fra datamengde med Music Freedom-greine (som jeg ikke har)  (PS: NSFW!)

Endret 19. august 2018 av Hans_Henrik

[MegaMann2]

av en eller annen grunn får denne URLen (NSFW*2!!) en gjennomsnittshastighet på 270kbps, når alt skulle vært nede på 128kbps... 

$ wget https://vip-video33000.fc2.com/up/flv/201504/10/W/20150410Wsee7BWu.free.mp4?mid=4a15e342585768abc7c61c4550536103 -q -O- | dd of=/dev/null status=progress

23379968 bytes (23 MB, 22 MiB) copied, 87.0672 s, 269 kB/s
45734+3 records in
45735+1 records out
23416375 bytes (23 MB, 22 MiB) copied, 87.2492 s, 268 kB/s

   kan det være relatert? lurer på om den trekker fra datamengde med Music Freedom-greine (som jeg ikke har)  (PS: NSFW!)

 

Hvorfor _skal_ den være 128 kBps?

Og hva mener du det kan være relatert til?