Sadržaj

QUIC protokol

Sažetak

Živimo u vremenu kada smo sve više mobilni i u svakom koraku te mobilnosti koristimo svoje pametne uređaje kako bi obavljali sve više zadataka. Ta mobilnost zahtijeva od naših uređaja da se konstanto moraju izmjenjivati točke pristupa Internetu. Samim time je vrijeme koje je potrebno da se dostavi informacija do našeg uređaja presudna. Većina razmjena tih informacija se odvija preko TCP protokola koji svakim mjenjanjem mrežnih informacija uređaja mora ponovno stvarati konekciju i time izmjeniti veliki broj paketa da bi se to i dogodilo. Sve te probleme TCP-a se pokušava riješiti novim protokolom naziva QUIC koji uz rješavanje tih problema uvodi i sigurnosne aspekte kao što su autentifikacija i enkripcija paketa i sve to uz povećanje performansi i smanjenje latencije.

Keywords: QUIC, Internet, protokol, TCP, TLS

Uvod

QUIC je siguran konekcijski transportni protokol za generalnu upotrebu. Protokol kreira komunikaciju temeljenu na stanjima između klijenta i poslužitelja.
Iako se protokol nalazi na transportnom sloju kao bazu za komunikaciju koristi UDP protokol. UDP za razliku od TCP-a nema mogućnost oporavka od gubitka paketa te se za taj aspekt brine QUIC. Na sljedećoj slici se vidi usporedba TCP i QUIC na IP stogu:
Protokol je nastao 2012. godine od strane Jim Roskinda u Googleu. Iako je protokol još u fazi nacrta koristi se u više od pola konekcija od Chrome web preglednika prema Googleovim poslužiteljima[1]. Ostali preglednici podržavaju protokol, ali nije omogućen po početnim postavkama.

Ideja protokola je da objedini značajke TLS i TCP protokola u jedinstven protokol kako bi smanjio latenciju, unaprijedio TCP svojstvo oporavka od gubitka paketa te uključio enkripciju podataka automatski. Objedinjujući svojstva ta dva protokola QUIC rukovanje se može odvesti već i u jednom povratnom putovanju, a u slučaju da je postojala komunikacija između klijenta i poslužitelja i prije enkriptirani podaci se mogu slati bez potrebe da je prije obavljeno rukovanje.

Krajnje točke komunikacije izmjenjuju pakete od kojih većina sadrži okvire koji nose kontrolne informacije i aplikacijske podatke. QUIC autentificira cijele pakete i enkriptira potrebne dijelove . QUIC paketi se prenose u UDP datagramima što dozvoljava brzu integraciju u postojeće sustave i mreže.

Aplikacijski protokoli izmjenjuju informacije preko QUIC konekcije putem tokova podataka koji su poredani sljedovi bajtova. Postoje dva tipa toka podataka: dvosmjerni i jednosmjerni. Dvosmjerni dozvoljava objema krajnjim točkama da šalju podatke dok jednosmjerni dozvoljava samo jednoj krajnjoj točci. Ograničavanje stvaranja tokova podataka i količinu poslanih podataka se ostvaruje na sistemu kredita.

QUIC pruža potrebne povratne informacije kako bi implementirao pouzdano dostavljanje i ostvario kontrolu nad zagušenjem paketa. QUIC konekcije nisu strogo vezane uz jedan mrežni put. Migracija konekcija se ostvaruje koristeći konekcijske identifikatore kako bi se konekcija preselila na novi mrežni put. Samo klijent može migrirati konekciju kod promjene mrežne topologije ili adrese klijenta te se na taj način očuvaju sve prije uspostavljene konekcije bez potrebe stvaranja novih.[2]

QUIC rukovanje

QUIC za razliku od TCP-a po dizajnu nudi enkripciju kao dio protokola. QUIC to postiže pružanjem sigurnosnih značajki poput autentifikacije i enkripcije koje inače obrađuje protokol na višem sloju poput TLS-a dok se to kod QUIC-a odrađuje na samom transportnom sloju.
Inicijalno QUIC rukovanje spaja TCP trosmjerno rukovanje s TLS/1.3 rukovanjem, koji osigurava autentifikaciju krajnjih točaka kao i pregovor oko kriptografskih parametara. Na sljedećoj slici je prikazana komunikacija koristeći TCP i TLS protokole kako bi se uspostavila konekcija.
QUIC protokol osigurava da konekcija bude uvijek autentificirana i kriptirana, ali i osigurava da se inicijalno stvaranje konekcije odvija brže. Za tipično QUIC rukovanje potreban je jedno povratno putovanje između klijenta i poslužitelja kako bi se uspostavila konekcija za razliku od 2 povratna putovanja potrebna za TCP i TLS/1.3 rukovanja zajedno. Na sljedećoj slici je prikazana komunikacija koristeći QUIC kako bi se uspostavila konekcija. QUIC također kriptira i dodatne konekcijske metapodatke koje bi mogle biti zloupotrebljene od posrednika. Na primjer brojevi paketa bi mogli biti korišteni od napadača da korelira korisničke aktivnosti preko više mrežnih puteva kada konekcijska migracija je upotrebljena. Kriptirajući paketne brojeve osigurava se da se ne može korelirati aktivnosti od nikog osim krajnjih točaka konekcije.[4]

QUIC format paketa

QUIC paketi sadrže dva tipa zaglavlja: kratke i duge. Duga zaglavlja se koriste za pakete koji su poslani prije razmjene kriptografskih ključeva, tj. prije prvobitnog rukovanja. Nakon toga se sva komunikacija prebacuje na pakete s kratkim zaglavljem.
Duga zaglavlja se koriste kako bi se lakše uspostavila komunikacija i ispregovarale neke pojedinosti poput verzije protokola. U sljedećem bloku je prikazana struktura dugog zaglavlja.

Long Header Packet {
     Header Form (1) = 1,
     Fixed Bit (1) = 1,
     Long Packet Type (2),
     Type-Specific Bits (4),
     Version (32),
     Destination Connection ID Length (8),
     Destination Connection ID (0..160),
     Source Connection ID Length (8),
     Source Connection ID (0..160),
     Type-Specific Payload (..),
   }

Postoje četiri tipa dugih zaglavlja koja se definiraju u “Long Packet Type” zaglavlju i to su sljedeći tipovi:

Tip Ime Upotreba
0x0 Inicijalni Koristi se kod inicijalne razmjene kripto okvira kako bi se izvela razmjena ključeva.
0x1 0-RTT Koristi se za prijenos ranih podataka s klijenta na poslužitelj prije nego se izvršilo rukovanje.
0x2 Rukovanje Koristi se za prijenos kriptografskih poruka rukovanja i potvrda s poslužitelja i klijenta.
0x3 Ponovni pokušaj Šalje se ponovno klijentu kako bi se potvrdila adresa klijenta koristeći token. Taj token mora biti vraćen od strane klijenta u svim inicijalnim paketima.

Kratka zaglavlja definiraju samo jedan tip paketa naziva 1-RTT paket te se koriste nakon dogovora oko kriptografskih ključeva. Struktura zaglavlja je prikazana u sljedećem bloku.

1-RTT Packet {
     Header Form (1) = 0,
     Fixed Bit (1) = 1,
     Spin Bit (1),
     Reserved Bits (2),
     Key Phase (1),
     Packet Number Length (2),
     Destination Connection ID (0..160),
     Packet Number (8..32),
     Packet Payload (8..),
   }

Preusmjeravanje paketa i migracija konekcija

Tipični NAT usmjerivači mogu voditi računa o TCP konekcijama koje prolaze kroz njih koristeći 4 vrijednosti: izvorišna IP adresa i port te odredišna IP adresa i port. Promatranjem TCP SYN, ACK i FIN paketa koji se prenose kroz mrežu mogu utvrditi stvaranje novih konekcija i prekidanje istih. To im dozvoljava da precizno upravljaju NAT poveznicama između unutarnjih i vanjskih adresa.
Sa QUIC protokolom to još nije moguće jer većina NAT usmjerivača ne razumije QUIC protokol te mora baratati arbitrarnim prevođenjem adresa kod UDP datagrama što uključuje kratak istek vremena praćenja konekcije. Na taj način dolazi do prekidanja dugotrajnih konekcija.
Kada se dogodi ponovno NAT prevođenje, krajnji točka konekcije izvan NAT mreže će vidjeti da paketi dolaze od drugog izvorišnog porta nego od onog koji se koristio kada je konekcija bila prvobitno uspostavljena, što čini vođenje računa o konekcijama nemoguće korištenjem samo 4 vrijednosti. Na sljedećoj slici je demonstriran problem koji se veže uz nemogućnost NAT usmjerivača da dobro upravlja QUIC konekcijama. Jedno od svojstva QUIC protokola je migracija konekcija. To dozvoljava QUIC krajnjim točkama da migriraju konekciju na druge IP adrese i mrežne puteve po volji, Na primjer mobilni klijent će moći migrirati QUIC konekciju s mobilne mreže na WiFi mrežu. Migracija konekcija se postiže konceptom konekcijskih ID-a koji se prenose u QUIC paketima te služe za identifikaciju konekcije. Krajnje točke na taj način koriste ID kako bi upravljale konekcijama za koje su odgovorne bez upotrebe prije navedenih 4 vrijednosti. Kod rubnih usmjerivača može se desiti da jedna IP adresa definira puno poslužitelja te zbog nepoznavanja protokola i zbog promjene NAT vrijednosti ili migracije same konekcije će paketi biti usmjereni na krivi poslužitelj.

Ispravljanje pogrešaka unaprijed

Ispravljanje pogrešaka (eng. Forward Error Correction) je svojstvo QUIC protokola da svaki paket koji se šalje također sadrži podatke drugih paketa te se na taj način paket koji se izgubio u transportu može rekonstruirati bez potrebe da se ponovno šalje. Zbog tog svojstva protokola svaki paket sadrži više korisnog tereta nego je to potrebno jer se uzima u obzir potencijal izgubljenih paketa koji se lakše ponovno stvore na ovaj način.
Trenutni omjer je deset paketa. Za svakih 10 paketa koji se šalju nalazi se dovoljno podataka da se rekonstruira jedan izgubljeni paket. Slanjem više podataka nego je potrebno se žrtvuje količina poslanih podataka u zamjenu za potrebu da se ponovno šalje paket što bi moglo potrajati duže vrijeme.

Zaključak

QUIC protokol donosi puno poboljšanja kao zamjena za TCP. Enkripcija svih podataka pod podrazumijevano, korekcija pogrešaka unaprijed i smanjivanje potrebnih povratnih putovanja samo su neki od tih poboljšanja. Također cilj QUIC protokola je da bude temelj nove verzije HTTP-a, verzije 3. Trenutno što koči bržu implementaciju u trenutne sustave je da se treba uložiti puno sredstava da se protokol implementira na mrežnoj opremi jer se HTTP promet odvija na standardnim TCP portovima dok je UDP promet na tim istim portovima blokiran u vatrozidu. S obzirom na to da je protokol još u fazi Internet nacrta znači da je vrijeme koje će biti potrebno da bude široko zastupljen i finaliziran jako ovisi o tome kako će biti implementiran u trenutno korištenim Internet aplikacijama. Ako je trenutni trend da više od pola konekcija putem Chrome preglednika prema Googleovim uslugama se odvija putem QUIC protokola. Zastupljenost u ostatku Internet prometa bi trebala biti visoka u narednim godinama te bi se na kraju moglo desiti da bude zastupljeniji od TCP-a.

Literatura

[1] Frederic Lardinois. Google Wants To Speed Up The Web With Its QUIC Protocol

[2] QUIC: A UDP-Based Multiplexed and Secure Transport draft-ietf-quic-transport-34

[3] Mattias Geniar. Google’s QUIC protocol: moving the web from TCP to UDP

[4] Alessandro Ghedini. The Road to QUIC