AUTHENTICATED
CREATE URL
NEGOTIATE URL END
success END failure timeout
change_r:url
create failure
connect success
timeout/connect failure
Obr´azek 4.20: Stavov´y model dohadov´an´ı datagramov´eho spojen´ı na serveru Z tˇechto dvou stavov´ych model˚u byl vytvoˇren verifikaˇcn´ı model, kter´y je uveden v pˇr´ıloze na stranˇe 131. D´ıky v´yˇse uveden´ym zjednoduˇsen´ım bylo moˇzn´e zpr´avy mezi procesem klienta a serveru pˇren´aˇset pomoc´ı dvou syn-chronn´ıch kan´al˚u:
mtype = { none , c h a n g e l , c h a n g e r , c o n f i r m l , c o n f i r m r } /∗ cmd type , u r l , cmd type , u r l ∗/
chan q1 = [ 0 ] o f {mtype , byte , mtype , byte } ; chan q2 = [ 0 ] o f {mtype , byte , mtype , byte } ;
Pˇren´aˇsen´a zpr´ava mohla obsahovat bud’ jeden nebo dva pˇr´ıkazy Change L, Change R, Confirm L, Confirm R, kter´e mohly navrhovat nebo potvrzovat
URL vyj´adˇren´y jedn´ım bytem. URL mohlo nab´yvat tˇr´ı hodnot. Hodnota NONE URL byla pouˇzita v kombinaci s pˇr´ıkazy Confirm k zam´ıt´an´ı navr-hovan´ych hodnot. VALID URL vyjadˇrovala platn´e URL a UNVALID URL byla pouˇzita jako n´avrh klienta na URL nov´eho datagramov´eho spojen´ı.
V´ysledky verifikace uveden´e v pˇr´ıloze na stranˇe 135 prok´azaly, ˇze se v t´eto ˇ
c´asti protokolu nenach´az´ı ˇz´adn´y deadlock ani nevyv´ıjej´ıc´ı se cykly.
Bezpeˇcnostn´ı rizika dohadov´an´ı datagramov´eho spojen´ı
Pˇri vlastn´ım dohadov´an´ı nov´eho spojen´ı by nemˇela hrozit nˇejak´a re´aln´a bezpeˇcnostn´ı rizika. Probl´em m˚uˇze ovˇsem nastat v pˇr´ıpadˇe, ˇze server umoˇ z-ˇ
nuje pouˇz´ıt nezabezpeˇcen´e datagramov´e spojen´ı i na link´ach, kter´e nejsou zabezpeˇceny jin´ym zp˚usobem (IPsec, localhost, apod.). ´Utoˇcn´ık m˚uˇze na nezabezpeˇcen´e datagramov´e spojen´ı za´utoˇcit dvˇema zp˚usoby. M˚uˇze se po-kusit uh´adnout ˇc´ıslo port˚u novˇe otevˇren´eho spojen´ı a toto spojen´ı ukr´ast.
Tento zp˚usob by mˇel b´yt pˇredem odsouzen k nezdaru, protoˇze klient by mu-sel uhodnout s ˇc´ıslem portu souˇcasnˇe i hodnotu Cookie a takov´a moˇznost je krajnˇe nepravdˇepodobn´a. Vˇetˇs´ım rizikem je ´utok typu Man-in-the-middle, protoˇze ´utoˇcn´ık m˚uˇze zachytit paket obsahuj´ıc´ı ˇc´ıslo c´ılov´eho portu a Cookie.
Utoˇ´ cn´ık m˚uˇze n´aslednˇe tyto informace pouˇz´ıt k pˇripojen´ı se k serveru. Z to-hoto d˚uvodu se nedoporuˇcuje pouˇz´ıvat nezabezpeˇcen´e datagramov´e spojen´ı na s´ıti Internet.
(1.2.3.4) (5.6.7.8)
| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | V +----+<---+ RESPOND
| | Confirm_R(COOKIE(0DD31jPcZ6st)) | | |
| | | | | . | | Change_L(COOKIE(0DD31jPcZ6st)) . |
. | | . |
Obr´azek 4.21: Pˇr´ıklad kompletn´ıho handshaku
4.6 Datagramov´ e spojen´ı
Protoˇze v se v souˇcasn´em n´avrhu protokolu poˇc´ıt´a na transportn´ı vrstvˇe pouze s protokolem UDP, tak se bude nad´ale uvaˇzovat na datagramov´em spojen´ı pouze protokol UDP. Veˇsker´e pˇr´ıkazy pˇren´aˇsen´e na UDP spojen´ı je potˇreba pˇren´aˇset v paketech, kter´e maj´ı strukturu uvedenou na obr´azku 4.22.
0 0 0 1 1 2 3
Obr´azek 4.22: Struktura Verse paketu
Paket se skl´ad´a z hlaviˇcky za n´ıˇz mus´ı n´asledovat potvrzovac´ı pˇr´ıkazy.
Za potvrzovac´ımi pˇr´ıkazy n´asleduj´ı syst´emov´e pˇr´ıkazy a teprve po nich tzv.
uzlov´e pˇr´ıkazy pˇren´aˇsej´ıc´ı uˇziteˇcn´a data. Mezi potvrzovac´ımi pˇr´ıkazy, syst´ e-mov´ymi pˇr´ıkazy a ani uzlov´ymi pˇr´ıkazy nedoch´az´ı k ˇz´adn´emu vyplˇnov´an´ı.
Na obr´azku 4.22 je zarovn´an´ı na d´elku 4 byt˚u pouze pro lepˇs´ı pˇrehlednost.
Hlaviˇcka paketu zaˇc´ın´a verz´ı protokolu Version. Souˇcasn´a verze protokolu m´a Version = 1. N´asleduj´ı 4 bity, kter´e slouˇz´ı bud’ jako rezerva pro pˇr´ıliˇs velk´a ˇ
c´ısla verze protokolu nebo pˇr´ıpadnˇe pro dalˇs´ı pˇr´ıznaky. Za rezervou n´asleduj´ı pˇr´ıznaky:
• PAY znaˇc´ı, ˇze v paketu jsou pˇren´aˇsena uˇziteˇcn´a data (payload data) a poloˇzka Payload ID obsahuje platnou hodnotu. V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• ACK ud´av´a, ˇze paket obsahuje speci´aln´ı ACK nebo NAK pˇr´ıkazy a poloˇzka ACK ID obsahuje platnou hodnotu. V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• ANK je nastaven´y, kdyˇz poloˇzka ANK ID obsahuje platnou hodnotu.
V opaˇcn´em pˇr´ıpadˇe by mˇela b´yt vyplnˇena nulami.
• SYN se pouˇz´ıv´a bˇehem handshaku
• FIN se pouˇz´ıv´a bˇehem ukonˇcen´ı spojen´ı.
Kdyˇz si klient a server bˇehem handshaku na UDP spojen´ı dohodnou nˇejak´y algoritmus pro Flow Control, tak se pro signalizaci velikosti ok´enka pouˇz´ıv´a poloˇzka Windows Size. Pˇren´aˇsen´a hodnota m˚uˇze ud´avat velikost v bytech nebo jejich n´asobc´ıch podle dohodnut´eho algoritmu.
Payload ID se pouˇz´ıv´a jako jedineˇcn´y identifik´ator payload paket˚u. S kaˇ z-d´ym odeslan´ym payload paketem se inkrementuje pˇr´ısluˇsn´y ˇc´ıtaˇc. Kdyˇz jeho hodnota dos´ahne maxima: 232− 1, tak se hodnota ˇc´ıtaˇce nastav´ı na nulu.
Stejn´e pravidlo plat´ı i pro ACK ID, kter´e funguje jako jedineˇcn´y identifik´ator potvrzovac´ıch paket˚u. Poloˇzka ANK ID obsahuje identifik´ator naposledy po-tvrzen´eho payload paketu.
Pokud pˇr´ıjemce potˇrebuje potvrdit pˇrijet´ı nebo ztr´atu payload paketu, tak za hlaviˇckou vloˇz´ı potvrzovac´ı pˇr´ıkazy, kter´e se od ostatn´ıch pˇr´ıkaz˚u liˇs´ı v tom, ˇze se za jejich Op Code nenach´az´ı d´elka pˇr´ıkazu. Potvrzovac´ı pˇr´ıkazy maj´ı konstantn´ı d´elku a k jejich pˇr´ıpadn´e komprimaci doch´az´ı jin´ym zp˚usobem neˇz u ostatn´ıch pˇr´ıkaz˚u. Struktura potvrzovac´ıch pˇr´ıkaz˚u je uve-dena na obr´azku 4.23. Jejich funkce a pouˇzit´ı budou podrobnˇeji pops´any v n´asleduj´ıc´ıch ˇc´astech.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 2 3 4 5 6 7 8 9 +---+---+---+---+---+
| Op_Code=1 | Received Payload Packet ID | (a)
+---+---+---+---+---+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 2 3 4 5 6 7 8 9 +---+---+---+---+---+
| Op_Code=2 | Lost Payload Packet ID | (b)
+---+---+---+---+---+
Obr´azek 4.23: Struktura pˇr´ıkazu ACK (a) a NAK (b)
4.7 Handshake datagramov´ eho spojen´ı
Neˇz si mohou klient a server vymˇenit prvn´ı data, tak mezi nimi mus´ı probˇehnout ˇctyˇrcestn´y handshake, jehoˇz n´avrh byl inspirov´an handshakem protokolu DCCP. Handshake na datagramov´em spojen´ı umoˇzˇnuje klientovi i serveru provˇeˇrit pr˚uchodnost pˇrenosov´ych cest pˇred t´ım neˇz si alokuj´ı ne-zbytn´e syst´emov´e prostˇredky pro zajiˇstˇen´ı ˇc´asteˇcn´e spolehlivosti datagra-mov´eho spojen´ı. Bˇehem handshaku si tak´e mohou dohodnout dalˇs´ı vlastnosti spojen´ı jako jsou pouˇzit´e algoritmy pro FC a CC.
Klient m˚uˇze zaˇc´ıt handshake aˇz po t´e, co od serveru obdrˇz´ı na TCP spo-jen´ı n´avrh URL datagramov´eho spojen´ı. Vlastn´ımu handshaku mus´ı pˇred-ch´azet DTLS handshake, pokud je sch´ema serverem navrˇzen´eho URL za-konˇceno ˇretˇezcem dtls://. DTLS protokol i jeho handshake jsou detailnˇe pops´any v [31]. DTLS se pˇr´ıliˇs neliˇs´ı od TLS, kter´e bylo pops´ano v ˇc´asti TLS handshake. Hlavn´ı rozd´ıly mezi TLS a DTLS jsou pops´any v ˇcl´anku [28].
Souˇc´ast´ı DTLS handshaku je i objevov´an´ı PMTU, kter´e umoˇzˇnuje zjistit maxim´aln´ı MTU na obou link´ach mezi klientem a serverem. V pˇr´ıpadˇe, ˇze je pouˇzita nezabezpeˇcen´a varianta datagramov´eho spojen´ı, tak je vhodn´e, aby klient i server pouˇzili vlastn´ı PMTU. Na modern´ıch operaˇcn´ıch syst´emech k tomu nen´ı potˇreba m´ıt opr´avnˇen´ı administr´atora, ale je moˇzn´e zjistit PMTU pomoc´ı pˇr´ısluˇsn´ych syst´emov´ych vol´an´ı nad sokety dan´eho spojen´ı. Z´ısk´an´ı PMTU umoˇzˇnuje pos´ıl´an´ı velk´ych paket˚u bez rizika fragmentace paket˚u na dan´e lince. PMTU zabezpeˇcen´eho spojen´ı je vˇzdy menˇs´ı neˇz PMTU neza-bezpeˇcen´eho spojen´ı na stejn´e lince, protoˇze DTLS do vˇsech paket˚u pˇrid´av´a vlastn´ı hlaviˇcku. DTLS pˇrid´av´a do paketu kromˇe hlaviˇcky i MAC a t´ım d´ale zmenˇsuje prostor pro pˇren´aˇsen´a data, coˇz DTLS umoˇzˇnuje kompenzovat po-moc´ı komprese pˇren´aˇsen´ych dat.
Pˇr´ıklad v´ymˇeny paket˚u bˇehem handshaku je uveden na obr´azku 4.24.
V tomto pˇr´ıkladˇe nejsou pro pˇrehlednost uvedeny ˇz´adn´e dalˇs´ı syst´emov´e pˇr´ıkazy pro dohadov´an´ı vlastnosti spojen´ı (Cookie, Flow Control, Conges-tion Control).
4.7.1 Prvn´ı ˇ c´ ast handshaku
Bˇehem handshaku se klient i server nach´azej´ı v nˇekolika stavech. Spojen´ı zahajuje klient ve stavu REQUEST zasl´an´ım paketu, kter´y m´a nastaven pˇr´ıznaky PAY a SYN. Jedn´a se tud´ıˇz o pr´azdn´y payload paket, kter´y m´a poˇc´ateˇcn´ı Payload ID nastaveno na n´ahodnou hodnotu. Pˇr´ıznak SYN ˇr´ık´a, ˇ
ze se jedn´a o paket zahajuj´ıc´ı spojen´ı.
Pokud prvn´ı paket pˇrijat´y serverem obsahuje podporovanou verzi
pro-client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | V +----+<---+ RESPOND
| | |
V | PAY ACK ANK pay_id=42 ack_id=0 ank=41 ack=76 | PARTOPEN +--->+----+
| | |
| PAY ACK ANK pay_id=77 ack_id=1 ank=76 ack=42 | V +----+<---+ OPEN
| | |
V | ACK ANK ack_id=1 ank=42 ack=77 |
OPEN +--->+
| |
. .
Obr´azek 4.24: Pˇr´ıklad handshaku na datagramov´em spojen´ı
tokolu a pˇr´ıznaky PAY a SYN, tak by se mˇel server pˇrepnout ze stavu LISTEN do stavu RESPOND a odpovˇedˇet odesl´an´ım paketu obsahuj´ıc´ıho pˇr´ıznaky PAY, SYN a ACK. Jedn´a se opˇet o payload paket s n´ahodnˇe zvo-len´ym Payload ID, kter´y k sobˇe pˇribaluje i potvrzovac´ı paket s pˇr´ıkazem ACK potvrzuj´ıc´ı pˇrijet´ı prvn´ıho paketu. Poˇc´ateˇcn´ı hodnota ACK ID pˇribalen´eho potvrzovac´ıho paketu by mˇela b´yt nulov´a.
Jelikoˇz je na transportn´ı vrstvˇe pouˇzit nespolehliv´y datagramov´y proto-kol UDP, tak je nezbytn´e, aby klient pˇreposlal ztracen´y paket v nezmˇenˇen´e podobˇe. To znamen´a, ˇze nesm´ı b´yt inkrementov´ana ani jinak zmˇenˇena ˇz´adn´a poloˇzka v hlaviˇcce a dalˇs´ıch pˇr´ıkazech. Ztr´ata paketu je detekov´ana pomoc´ı vyprˇsen´ı ˇcasovaˇce. Poˇc´ateˇcn´ı hodnota ˇcasovaˇce je jedna sekunda. Pˇri kaˇzd´e dalˇs´ı ztr´atˇe paketu (vyj´adˇreno promˇennou step) se hodnota ˇcasovaˇce zvyˇsuje podle n´asleduj´ıc´ıho algoritmu:
else
back of f := M AX BACK OF F ; fi
timout := init timeout + back of f ∗ (rand()/(M AX RAN D + 1));
end
kde rand() je funkce vracej´ıc´ı n´ahodnou hodnotu nebo pseudon´ahodnou hodnotu s n´ahodnou poˇc´ateˇcn´ı hodnotou v rozsahu h0, M AX RAN Di.
V prvn´ıˇc´asti handshaku m˚uˇze doj´ıt pˇri v´ymˇenˇe paket˚u ke ˇctyˇrem moˇzn´ym sc´en´aˇr˚um, kter´e jsou uvedeny na obr´azku 4.25.
client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | |
| X<---+<---+
| PAY SYN pay_id=76 ack_id=0 ack=41 | |
drop +<---+<---+
| |
. .
. .
Obr´azek 4.25: Pˇr´ıklad 4 moˇzn´ych sc´en´aˇr˚u bˇehem prvn´ı ˇc´asti handshaku Z obr´azku je patrn´e, ˇze k dosaˇzen´ı spolehlivosti handshaku je nutn´e, aby server po pˇrepnut´ı do stavu RESPOND st´ale odpov´ıdal i na pakety, kter´e odeslal klient ve stavu REQUEST. Klient nesm´ı bˇehem stavu REQUEST poslat v´ıce jak 10 paket˚u a v tomto stavu se nesm´ı nach´azet d´ele jak 30 sekund. Pokud do t´eto doby neobdrˇz´ı spr´avnou odpovˇed’ od serveru, tak by mˇel klient po TCP spojen´ı poslat serveru pr´azdn´y pˇr´ıkaz Change L(URL)
signalizuj´ıc´ı, ˇze se spojen´ı se serverem na UDP nezdaˇrilo a n´aslednˇe ukonˇcit se serverem komunikaci.
Podobnˇe by mˇel server odpovˇedˇet maxim´alnˇe na 10 paket˚u, kter´e mu poslal klient ve stavu REQUEST. Neobdrˇz´ı-li server paket odeslan´y klien-tem ze stavu PARTOPEN do 30 sekund od doby, kdy se pˇrepnul do stavu RESPOND, tak by mˇel s klientem na UDP spojen´ı ukonˇcit komunikaci.
Server by mˇel z´aroveˇn odpov´ıdat pouze na pakety, kter´e obsahuj´ı pˇr´ıkaz Change L(Cookie) s dohodnutou hodnotu Cookie. Server by mˇel odpov´ıdat i na pakety, kter´e poch´azej´ı z jin´e IP adresy neˇz na kter´e vede s klientem ko-munikaci po TCP, protoˇze klient m˚uˇze m´ıt v´ıce s´ıt’ov´ych rozhran´ı a pˇrestoˇze je to velmi nepravdˇepodobn´e, tak TCP spojen´ı m˚uˇze b´yt smˇerov´ano pˇres jin´e s´ıt’ov´e rozhran´ı klienta neˇz UDP spojen´ı. Z´aroveˇn server mus´ı ve stavu RE-SPOND odpov´ıdat na dotazy z jedn´e kombinace IP adresa port st´ale stejn´ym paketem.
4.7.2 Druh´ a ˇ c´ ast handshaku
Po t´e, co klient obdrˇz´ı od serveru paket s platnou odpovˇed´ı, by se mˇel pˇrepnout do stavu PARTOPEN. Paketem s platnou odpovˇed´ı se rozum´ı pa-ket obsahuj´ıc´ı pˇr´ıznaky PAY, SYN a ACK a syst´emov´y pˇr´ıkaz Ack potvr-zuj´ıc´ı pˇrijet´ı prvn´ıho paketu. V tomto paketu by mˇel server poslat i pˇr´ıkaz Confirm L(Cookie) s potvrzen´ım platnosti Cookie a pˇr´ıpadnˇe i svoji Cookie v pˇr´ıkazu Change L(Cookie), pokud to bylo dohodnuto na TCP spojen´ı. Za pˇredpokladu, ˇze jedna z Cookie neodpov´ıdala tomu, co bylo dohodnuto na TCP spojen´ı, by mˇel klient pˇrijat´y paket ignorovat.
V reˇzimu PARTOPEN by mˇel klient pos´ılat pakety s pˇr´ıznaky PAY, ACK a ANK, kdy hodnota Payload ID je o jedna vˇetˇs´ı neˇz byla u paket˚u zas´ılan´ych ve stavu REQUEST. D´ale by mˇel paket obsahovat pˇr´ıkaz ACK potvrzuj´ıc´ı pˇrijet´ı payload paketu a platnou poloˇzku ANK ID signalizuj´ıc´ı serveru, ˇze uˇz nen´ı nad´ale nutn´e potvrzovat pˇrijet´ı prvn´ıho paketu. Paket by mˇel obsahovat i pˇr´ıkaz Confirm L(Cookie) v pˇr´ıpadˇe, ˇze se server prok´azal platnou Cookie.
Klient m˚uˇze po pˇrepnut´ı do reˇzimu PARTOPEN obdrˇzet odpovˇedi na pakety odeslan´e jeˇstˇe ve stavu REQUEST. Takov´e pakety by mˇel klient ig-norovat.
V druh´e ˇc´asti handshaku by se mˇel server pˇrepnout do stavu OPEN, pokud pˇrijme paket poch´azej´ı ze stejn´e kombinace IP adresa:port jako byly pakety pˇrijat´e ve stavech LISTEN a RESPOND. Z´aroveˇn mus´ı pˇrijat´y paket obsahovat potvrzen´ı payload paketu, kter´y server poslal klientovi v prvn´ı ˇ
c´asti handshaku. Server by mˇel odpovˇedˇet payload paketem, kter´y bude z´aroveˇn potvrzovat pˇrijat´y payload paket. Server by mˇel alokovat syst´emov´e prostˇredky potˇrebn´e pro resend mechanismus teprve ve stavu OPEN, protoˇze
tehdy m´a server jistotu, ˇze komunikace s dan´ym klientem je moˇzn´a. Klient se pˇrepne do stavu OPEN po obdrˇzen´ı v´yˇse zm´ınˇen´eho potvrzovac´ıho paketu.
Vˇsechny moˇzn´e sc´en´aˇre v´ymˇeny paket˚u bˇehem druh´e ˇc´asti handshaku jsou uvedeny na obr´azku 4.26.
client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | |
PARTOPEN +<---+<---+
| | |
| | PAY ACK ANK pay_id=42 ack_id=0 ank_id=41 ack=76 | +--->+--->X |
| |
| |
| PAY ACK ANK pay_id=42 ack_id=0 ank_id=41 ack=76 | timeout +--->+ OPEN
| | |
| PAY ACK ANK pay_id=77 ack_id=1 ank_id=76 ack=42 | |
| X<---+<---+
| |
| PAY ACK ANK pay_id=42 ack_id=0 ank_id=41 ack=76 | timeout +--->+----+
| | |
| | |
| PAY ACK ANK pay_id=42 ack_id=0 ank_id=41 ack=76 | | timeout +--->+----+----+
| | | |
| PAY ACK ANK pay_id=77 ack_id=1 ank_id=76 ack=42 | | | OPEN +<---+<---+ |
| | |
| PAY ACK ANK pay_id=77 ack_id=1 ank_id=76 ack=42 | | drop +<---+<---+
| |
. .
Obr´azek 4.26: Pˇr´ıklad 4 moˇzn´ych sc´en´aˇr˚u bˇehem druh´e ˇc´asti handshaku Z obr´azku je patrn´e, ˇze klient opˇet m˚uˇze obdrˇzet duplikovan´e pakety po pˇrepnut´ı do stavu OPEN. Takov´e pakety by mˇel klient ignorovat.
4.7.3 Dohadov´ an´ı na datagramov´ em spojen´ı
Vlastnosti datagramov´eho spojen´ı (Congestion Control, Flow Control, apod.) nen´ı moˇzn´e dohadovat na p˚uvodn´ım TCP spojen´ı, protoˇze by to velmi komplikovalo delegaci datagramov´eho spojen´ı na jin´y server, jak to bylo pops´ano v kapitole 4.5.3. Kaˇzd´y server by mˇel m´ıt moˇznost si s klien-tem dohadovat vlastnosti spojen´ı podle vlastn´ıho nastaven´ı.
Dohadov´an´ı vlastnost´ı na datagramov´em spojen´ı se liˇs´ı od dohadov´an´ı na TCP spojen´ı v tom, ˇze nen´ı zaruˇcena spolehlivost doruˇcen´ı dat. Z toho d˚uvodu je nutn´e zajistit pˇrepos´ıl´an´ı dohadovac´ıch pˇr´ıkaz˚u. Bˇehem handshaku detekuje ztr´atu paketu pouze klient na z´akladˇe vyprˇsen´ı ˇcasovaˇce a klient ztracen´y paket pˇrepos´ıl´a v nezmˇenˇen´e podobˇe. Ve stavu OPEN se pouˇz´ıv´a jin´y mechanismus detekce ztr´aty paketu.
Aby se odes´ılatel s pˇr´ıjemcem dohodli na vlastnostech pomoc´ı dohado-vac´ıch pˇr´ıkaz˚u, tak mus´ı dodrˇzovat nˇekolik pravidel. Pˇr´ıjemce mus´ı na doha-dovac´ı pˇr´ıkazy odpovˇedˇet ihned. Kdyˇz odes´ılatel detekuje ztr´atu paketu obsa-huj´ıc´ıho dohadovac´ı pˇr´ıkazy, tak by mˇel pˇreposlat pouze pˇr´ıkazy Change L a Change R. Nav´ıc by mˇel odes´ılatel zopakovat odesl´an´ı dohadovac´ıch pˇr´ıkaz˚u Change L, Change R, kdyˇz na nˇe neobdrˇz´ı odpovˇed’ do doby, kter´a je rovna dvojn´asobku SRTT.
4.7.4 Dohadov´ an´ı o Flow Control
Bˇehem handshaku si obˇe strany dohodnou jak´y budou pouˇz´ıvat algorit-mus pro Flow Control (FC) neboli kontrolu zahlcen´ı pˇr´ıjemce. Zahlcen´ım je v´ıce ohroˇzen´y server, takˇze klient sice m˚uˇze navrhnout pouˇzit´y algoritmus, ale urˇcuj´ıc´ı slovo pˇri nastaven´ı pouˇz´ıvan´eho algoritmu by mˇel m´ıt server.
Pro spr´avn´e fungov´an´ı FC je nezbytn´e, aby obˇe strany pouˇz´ıvaly totoˇzn´e algoritmy. Na obr´azku 4.27 je uveden pˇr´ıklad dohadov´an´ı.
Na obr´azku 4.27 je vidˇet, ˇze klient m˚uˇze postal n´avrhy na FC, ale ty jsou v tomto pˇr´ıpadˇe serverem zam´ıtnuty. Server n´aslednˇe pos´ıl´a sv´e n´avrhy na algoritmu FC, kter´e mus´ı klient potvrdit. Server m˚uˇze navrhnout pouˇzit´ı v´ıce algoritm˚u, ale oba pˇr´ıkazy Change L(FC ID) i Change R(FC ID) by mˇely obsazovat totoˇzn´y seznam navrhovan´ych hodnot. Vˇzdy by mˇelo doj´ıt k navrˇzen´ı a potvrzen´ı FC pro pˇr´ıjemce i odes´ılatele, aby nevznikly nejasnosti, jak´y algoritmus bude dan´a strana pouˇz´ıvat.
Pokud klient navrhovan´e algoritmy nepotvrd´ı (poˇsle serveru pr´azdn´e pˇr´ı-kazy Change L(FC ID) a Change R(FC ID)), protoˇze je napˇr´ıklad neim-plementuje, tak by se server nemˇel pˇrepnout do stavu OPEN, ale mˇel by se pˇrepnout do stavu CLOSEREQ a spojen´ı s klientem pˇr´atelsky ukonˇcit.
Pˇr´ıklad pˇr´atelsk´eho nedohodnut´ı je uveden na obr´azku 4.28.
Pokud se klient se serverem nedohodnou na jin´e vlastnosti spojen´ı bˇehem handshaku, kter´a je nezbytn´a pro spr´avn´e fungov´an´ı datagramov´eho spojen´ı, je potˇreba spojen´ı ukonˇcit stejn´ym zp˚usobem jako v pˇr´ıpadˇe nedohodnut´ı se na Flow Control. Ukonˇcen´ı spojen´ı bude podrobnˇeji vysvˇetleno v ˇc´asti 4.9.
client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | V
+----+<---+ RESPOND
| | Confirm_L(FC_ID()) Confirm_R(FC_ID()) |
| | Change_L(FC_ID(FC_NONE)) Change_R(FC_ID(FC_NONE)) |
| | |
V | PAY ACK ANK pay_id=42 ack_id=0 ank=41 ack=76 | PARTOPEN +--->+----+
| Confirm_L(FC_ID(FC_NONE)) Confirm_R(FC_ID(FC_NONE)) | |
| | |
| PAY ACK ANK pay_id=77 ack_id=1 ank=76 ack=42 | V +----+<---+ OPEN
| | |
V | ACK ANK ack_id=1 ank=42 ack=77 |
OPEN +--->+
| |
. .
Obr´azek 4.27: Pˇr´ıklad dohadov´an´ı o Flow Control
4.7.5 Dohadov´ an´ı o Congestion Control
Congestion Control (CC) by mˇel b´yt urˇcov´an pˇredevˇs´ım klientem, proto-ˇ
ze se pˇredpokl´ad´a, ˇze autor aplikace dok´aˇze urˇcit, jak´y algoritmus CC bude nejl´epe vyhovovat povaze pˇren´aˇsen´ych dat. Koneˇcn´e slovo pˇri urˇcov´an´ı vlast-nosti spojen´ı m´a ovˇsem zase server. Pˇr´ıklad dohadov´an´ı o algoritmu pro CC je uveden na obr´azku 4.29.
Dohadov´an´ı o CC zaˇcne klient zasl´an´ım pˇr´ıkazu Change L(CC ID) se se-znamem navrhovan´ych algoritm˚u pro linku klient-server. Server by mˇel ze seznamu vybrat nˇejak´y algoritmus a potvrdit jeho pouˇzit´ı zasl´an´ım pˇr´ıkazu Confirm L(CC ID). Z´aroveˇn by mˇel server stejn´y algoritmus navrhnout pro linku server-klient. Klient by mˇel tuto volbu potvrdit. Kdyˇz se klient a server nedohodnou na pouˇzit´em algoritmu pro CC, tak by mˇel server ukonˇcit komu-nikaci s klientem stejn´ym zp˚usobem jako je ukonˇceno spojen´ı po ne´uspˇeˇsn´em dohadov´an´ı o Flow Control.
Dohadov´an´ı o Flow a Congestion Control je moˇzn´e prov´est pouze bˇehem handshaku. Ve stavu OPEN jiˇz nen´ı moˇzn´e pouˇz´ıvan´e algoritmy mˇenit.
Flow ani Congestion Control nen´ı moˇzn´e nastavovat na TCP spojen´ı pˇred zah´ajen´ım vlastn´ıho datagramov´eho handshaku, protoˇze se poˇc´ıt´a s budouc´ı moˇznost´ı delegovat datagramov´e spojen´ı na jin´y server a kaˇzd´y server by mˇel m´ıt moˇznost si zvolit vlastn´ı algoritmy.
client server
| PAY SYN pay_id=76 ack_id=0 ack=41 | V
+----+<---+ RESPOND
| | Change_L(FC_ID(FC_TCP_LIKE)) Change_R(FC_ID(FC_TCP_LIKE)) |
| | |
V | PAY ACK ANK pay_id=42 ack_id=0 ank=41 ack=76 | PARTOPEN +--->+----+
| Confirm_L(FC_ID()) Confirm_R(FC_ID()) | |
| | |
| PAY ACK FIN ANK pay_id=77 ack_id=1 ank=76 ack=42 | V +----+<---+ CLOSEREQ
| | |
V | PAY ACK FIN ANK pay_id=43 ack_id=1 ank=42 ack=77 | CLOSING +--->+----+
| | |
| PAY ACK FIN ANK pay_id=78 ack_id=2 ank=77 ack=43 | V CLOSED +<---+ CLOSED
| |
. .
Obr´azek 4.28: Pˇr´ıklad nedohodnut´ı algoritmu Flow Control
4.7.6 Bezpeˇ cnostn´ı rizika handshaku
Na handshake datagramov´eho spojen´ı se m˚uˇze ´utoˇcn´ık pokusit prov´est DoS/DDoS ´utok. Pˇr´ıpadn´y ´utok je zt´ıˇzen´y skuteˇcnost´ı, ˇze server otv´ır´a n´ a-hodn´y UDP port. Pˇr´ıstup k tomuto portu m˚uˇze samotn´y server omezit na konkr´etn´ı IP adresu, pˇrestoˇze bylo uk´az´ano, ˇze to m˚uˇze nˇekter´ym klient˚um
Na handshake datagramov´eho spojen´ı se m˚uˇze ´utoˇcn´ık pokusit prov´est DoS/DDoS ´utok. Pˇr´ıpadn´y ´utok je zt´ıˇzen´y skuteˇcnost´ı, ˇze server otv´ır´a n´ a-hodn´y UDP port. Pˇr´ıstup k tomuto portu m˚uˇze samotn´y server omezit na konkr´etn´ı IP adresu, pˇrestoˇze bylo uk´az´ano, ˇze to m˚uˇze nˇekter´ym klient˚um