1
3. přenáška
Protokoly přenosu dat
Osnova přednášky
2
1. Protokoly RTP
2. Protokol RTCP
3. Protokoly cRTP, SRTP a ZRTP
4. Protokol SCTP
3
1. Protokol RTP
4
Hlas je vzorkován kodekem a pak
vkládán do rámců RTP
kodek
hlas
Protokol RTP
5
RTP (Real-time Transport Protokol) je aplikační protokol, který byl navržen
pro přenos audio/video dat přes Internet. Postaven je na protokolu UDP a
jsou mu přidány některé vlastnosti pro zajištění lepšího přenosu mediálních dat.
Zajišťuje seřazení jednotlivých paketů (sequence number), jejich časové značkování
(timestamp – vzorkovací značka prvního oktetu v paketu) a multiplexování
a demultiplexování. Záhlaví je velké obvykle 12 byte.
RTP nezajišťuje rezervaci kanálu a negarantuje QoS (Quality of Service).
Verze: 1996 – RFC 1889 a 1890 (verze 2),
2003 – RFC 3550 a 3551 (vylepšují především dohled nad RTP),
2004 – RFC 3711 (SRTP).
Doporučený zdroj:
Wiki Wireshark http://wiki.wireshark.org/SampleCaptures#SIP_and_RTP
K čemu RTP slouží
6
Poskytuje mechanizmy pro koncové multimediální přenosy v reálném čase.
Protokol podporuje přenos dat mezi dvěma i více účastníky.
- Identifikace rámce – Identifikuje začátek a konec rámce
- Rekonstrukce správného pořadí paketů na základě sekvenčních čísel
- Synchronizace: Určuje správný okamžik přehrávání dat na základě
časových razítek, a to
- Intermedia – Synchronizace více médií (audio-video-text)
- Identifikace toku – Identifikuje typ médií a jeho kódování
RTP v RFC 3550
7
RTP v RFC 3551
8
Hrubá struktura RTP paketu
9
Záhlaví rozšířené pro DTMF
10
Formát záhlaví
11
 Ver označuje verzi protokolu (dnes se používá verze 2),
 P (padding field) v případě P=1 označuje vycpávku v posledním paketu toku na dorovnání
jednotné délky. Poslední oktet obsahuje informaci o tom, kolik oktetů bylo celkem přidáno,
 X (extension bit) v případě X=1 označuje, že za záhlavím následuje rozšíření paketu s CSRC
 CC (Contributing Source Identifier Counter) – počet zdrojů
význam M (marker bit) počatek spřadani hovoru (talkspurt) → uprava zpožděni je dána
aplikačním profilem (např. konec paketu v toku rámců).
RTP na rozdíl od UDP zavádí následující služby:
 PT – payload type, metoda kódování, může se během přenosu měnit;
 doručení ve správném pořadí, kontrola ztráty paketu (sequence number);
 zavedení časového razítka (timestamp);
 rozlišení synchronizačního zdroje – při přenosu více kanálů audio/video (SSRC –
indikace synchronizačního zdroje, CSRC – identifikace příspěvkového (contribution) zdroje,
Marker po klidovém úseku
(volitelný)
12
Typy zátěže (PT) audio
13
Typ kódování médium taktovací počet kanálů
kmitočet
Typy zátěže (PT) video
14
Dynamické porty je třeba předem
dohodnout
15
Číslo paketu a časové razítko
16
16
číslo paketu
časové razítko
Číslování paketů
První číslo je náhodně zvolené
Polycom
Časové razítko
18
20 ms rámec G.711 obsahuje 160 vzorků
Synchronizace pro playback
19
Jak se mění zdroj, mění se
i adresa synchronizačního zdroje
20
Skyping s web kamerou a
mikrofonem (stejný zdroj)
21
Agregace dat
22
Pro 24 kanálů je využití
pásma 89 %
Jaké je časování odesílání paketů ze zdroje?
23
∆t = (1400 – 1240)/8 kHz = 160/8000 = 20 ms
Neboli 50 paketů za sekundu
Přenosu DTMF a jiných tónů řeší RFC 2833
24
Co zde z přenášených údajů o přenosu tónu
DTMF podle RFC 2833 vyčteme?
25
Co se dovídáme:
- bylo voleno číslo 911
- první číslice „9“ je tón o délce trvání 200 ms
(1 600/8 kHz) a začíná v čase 0 ms
- druhé číslice „1“ je tón o délce trvání 250 ms
(2 000/8 kHz) a začíná v čase 800 ms
(6 400/8 kHz) časových jednotek, timetamps)
- třetí číslice „1“ je tón o délce trvání 50 ms
(400/8 kHz) a bylo stisknuto v čase1,4 s
(11 200/8 kHz) časových jednotek, timetamps)
První generace Cisco IP telefonů (7902, 7905,
7910, 7912, 7940, 7960) RFC 2833 nepodporovala,
druhá (7906, 7911, 7941, 7942, 7945,
7961, 7962, 7965, 7970, 7971, 7975) a další
už ano. U Cisco Unified Call Manager a je
RFC 2833 podporováno od verze 5.0. Je dobré
DTMF na branách řešit in-band pomocí Named
Telephone Events, které RFC 2811
znají, např. out-of-band SIP signalizace ne.
Identifikace volajícího (DTMF):
- out-of-band (mimo hovorové pásmo): čísla, kmitočet…
- in-band: PCM, tóny v pásmu 300-3400 Hz digitalizované dle G.711.
Obsah paketu (zátěž) v příkladu
26
Příklad – RTP pro GSM
27
Záhlaví RTP
K čemu může být užitečné doplnění na násobky 8?
28
2. Protokol RTCP
RCTP a RTP mají sousedící čísla portů
a jsou přenášeny s frekvencí 5 paketů/s
29
Protokol RTCP
30
RTP podporuje sloučení několika mediálních toků do jedné relace (session) za účelem
podpory aplikací ,jako je pořádání konferenčních hovorů. Chybí mu však zpětná kontrola
o tom, zda a v jakém stavu dorazily pakety k příjemci.
Z tohoto důvodu je pro protokol RTP implementován doplňkový protokol Real-time
Transport Control Protocol (RTCP) zajišťuje odezvu od příjemce k odesílateli.
Odesílatel tak může získávat informace o tom, v jaké kvalitě je signál přijímán, kolik
paketů se cestou ztratilo nebo jaký byl rozkmit zpoždění (jitter) doručených paketů.
Lze tedy s jeho pomocí sledovat úroveň kvality služby.
Periodické posílání mezi účastníky komunikace (na jiném portu než RTP – o jedna větší).
Šířka pásma pro RTCP nesmí přesáhnout 5 % šířky pásma pro RTP spojení.
Typy paketů RTCP
31
 SR – sender report: počet poslaných slabik → odhad rychlosti,
časové značky → synchronizace
 RR – receiver report: Počet poslaných a očekávaných paketů →
ztráty, jiter během přijmu, zpožděni oběhu
 BYE – explicitní ukončení – navíc (kromě timeoutu)
 SDES – source description: CNAME (canonical end-point identifier) –
reálné jméno použité pro popis zdroje, EMAIL, PHONE, LOC (geografické
umístění), TOOL (aplikace nebo jméno prostředku), NOTE – poznámka
nebo stav – popisuje aktuální stav zdroje.
 APP – rozšíření – závislé na aplikaci
Zpráva od zdroje – Send Report
(soubor statistik o přijímaných a vysílaných datech)
32
identifikace zdroje dat
čas odeslání
odpovídající čas příjmu →synchronizace
čítač paketů odesílatele: celkový počet
odeslaných paketů
čítač oktetů odesílatele: celkový počet
odeslaných oktetů
Synchronizace
33
 Synchronizujeme různé streamy audio, video, snímky, …
 Časové značky jsou často umístěny v náhodných
intervalech
 Nemusí tikat nominální rychlosti
 SR slouží ke korelaci reálného času za pomoci časových
značek RTP
Příklad
34
Synchronization Source ID
Počet přenesených paketů
Typ paketu
Zpráva od příjemce – Received Report
35
LSR – čas posledního přijmu SR
DLSR – zpoždění od posledního SR
vyhlazené „chvění“ mezi pakety
pro porovnání ztrát, přerušení spojení
dlouhodobé ztráty
krátkodobé ztráty
identifikuje původce záznamu
Rozbalené pakety RR a BYE
36
Vizitky odesilatelů – Source DEScription
(vlastnosti odesilatelů RTP komunikace)
37
Příklad paketu SDES
38
Typy SDES
39
Kolize
40
 dva zdroje mají stejné SSRC: pro 1000 členů relace
souběžně spojených je pravděpodobnost asi 10-4
 Řešení kolize: poslání BYE, získání nového identifikátoru
Packet RTCP s vizitkou SDES
odchycený Wiresharkem
41
Verze 2
Zasílání rozšířených zpráv
dohledu dle RTCP XR
42
pakety zahozené sítí
pakety zahozené uživatelem
shluky mezery mezi shluky
tam zpět [ms]
mezi konci [ms]
Residual Echo Return Loss
(vzniká ve 4/2 vidlici)
MOS-LQ – listening quality, MOS-CQ – conversational quality
jitter buffer
(adaptive – nonadaptive)
Rozšíření RTCP XR (Extended Reports) v RFC 3611 z roku 2003 umožňuje zasílání informace o kvalitě hovoru v MOS.
K výměně těchto zpráv se používají tzv. bloky oznámení (Report Blocks), např.:
Naměřen údaje lze použít pro vylepšování
vlastností přenosu
43
Příklad: Použití Gilbert-Elliotova modelu pro vylepšování vlastností algoritmu PLC
( Packet Loss Concealment) použitého v kodeku G.729A.
Zdroj:
Jinsul Kim, Seung Ho Han, Hyun-Woo Lee, Won Ryu, and Minsoo Hahn: „QoS-Factor
Transmission Control Mechanism for Voice over IP Network based on RTCP-XR Scheme“
Individuální výpadky Výpadky celých skupin paketů
Naměřen údaje lze použít pro vylepšování
vlastností přenosu
44
Příklad: Použití Gilbert-Elliotova modelu pro vylepšování vlastností algoritmu PLC
( Packet Loss Concealment) použitého v kodeku G.729A.
Zdroj:
Jinsul Kim, Seung Ho Han, Hyun-Woo Lee, Won Ryu, and Minsoo Hahn: „QoS-Factor
Transmission Control Mechanism for Voice over IP Network based on RTCP-XR Scheme“
Individuální výpadky Výpadky celých skupin paketů
45
3. Protokoly cRTP, SRTP
a ZRTP
cRTP
46
RFC 2508 – komprese záhlaví IP, UDP, RTP pro nízkorychlostní sériová připojení.
RFC 2509 – komprese záhlaví IP přes protokol PPP.
RFC 3545 – protokol ECRTP pro připojení s vysokým zpožděním, ztrátou paketů zpřeházenými pakety.
Podstata: nepřenáší se opakující se stejné údaje. Nevýhoda: Zátěž procesorů na směrovačích. Kalkulace:
G.711 - 160 B
IP/UDP/RTP 40 B, FR 4 B
Celkem 204 B * 50 p/s * 8b = 81 600 kb/s
G.711 - 160 B
IP/UDP/cRTP 5 B, FR 4 B
Celkem 169 B * 50 p/s * 8b = 67 600 kb/s
G.729 - 20 B
IP/UDP/RTP 40 B, FR 4 B
Celkem 64 B * 50 p/s * 8b = 25 600 kb/s
G.729 - 20 B
IP/UDP/cRTP 5 B, FR 4 B
Celkem 29 B * 50 p/s * 8b = 11 600 kb/s
Enhanced Compressed RTP v RFC 3545
47
Nástroje pro odposlech
(VOIPSA – The Voice over IP Security Alliance)
48
http://www.voipsa.org/Resources/tools.php
Protokol SRTP
(Secure Real-time Transport Protocol)
49
Formát SRTP paketu
(zdroj http://realtimesecure.asp2.cz/srtp.aspx)
50
Pole, která jsou navíc oproti RTP: MKI a Authentication tag.
Pole, která jsou navíc oproti RTP
51
Master Key Identifier (MKI) – nepovinné a identifikuje master key, od
kterého jsou odvozeny tajné symetrické klíče session keys (klíče
relace). Klíče relace jsou dohodnuty mezi uživateli hned po navázání
spojení a po zbytek celé relace se jimi šifrují přenášená multimediální
data. Nejdřív si ovšem komunikující strany musí vyměnit master key,
pomocí kterého si pak vygenerují všechny potřebné klíče sezení.
K výměně master key se může použít protokol SDP (protokol pro
inicializaci relací). Ten ale neposkytuje žádnou formu zabezpečení a tak
je třeba navíc použít protokoly TLS nebo IPSec.
Authentication tag je šifrovaný kontrolní součet záhlaví a těla RTP
paketu. Je doporučený a chrání pakety od neautorizované změny
obsahu.
Záhlaví protokolu SRTCP
52
53
Porovnání IPSec a SRTP
G.711, 50 p/s
HDLC MPLS IP IPSec UDP RTP G.711
6 4 20 40–80 8 12 160
HDLC MPLS IP UDP SRTP G.711
6 4 20 8 12+4
(aut.)
160
54
Porovnání IPSec a SRTP
G.729, 50 p/s
HDLC MPLS IP IPSec UDP RTP G.729
6 4 20 60 8 12 20
HDLC MPLS IP UDP SRTP G.729
6 4 20 8 12+4 20
režie 85 %
režie 73 %
Formát paketu SRTCP
55
SRTCP paket je chráněný obdobně jako SRTP paket, ale na rozdíl od SRTP je zde pole Authentication
tag povinné. Jinak by bylo například možné ukončit spojení, kdyby útočník poslal paket BYE. Navíc je
zde ještě pole SRTCP index, který se používá jako čítač pořadí SRTCP paketů a slouží k zabránění
opakovaným útokům. První bit v tomto poli E se používá jako šifrovací značka (Encryption flag), která
značí, jestli bylo tělo SRTCP paketu šifrováno.
AES je v counter nebo F8 módu
56
1. counter mód E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128)...
povinný pro šifrování a vyvozování klíčů relace z master key
Algoritmus umožňuje příjemci zpracovat přijaté pakety v nestanoveném pořadí, což je požadováno
při použití real-time aplikací, kde pakety nemusí být vždy spolehlivě doručeny.
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
Inicializační vektor IV’, který se skládá z kontrolního součtu salt_key k_s, SSRC (náhodné číslo jednoznačně
identifikující zdroj) a indexu paketu i.
2. F8 mód (varianta OFB – Output Feedback Block
S(j) = E(k_e, IV' XOR j XOR S(j-1))
volitelný pro šifrování (určen pro pro UMTS 3G mobilní sítě)
57
Generování dodatku pomocí hash funkce
58
Zajištění autenticity a integrity v SRTP
HMAC – Hash Message Authentication Code
Jde o hash funkci nad zprávou m kombinovanou s klíčem k
HMAC(k,m) = H[(k  opad)||H[k  ipad)||m]]
ipad = 00110110 opakované 64x
opad = 01011100 opakované 64x
Je popsána v RFC 2104
V TLS a IP Sec se používá
HMAC-MD5 i HMAC-SHA-1,
V SRTP jen HMAC-SHA-1
2006: Úspěšný plný útok na MD4
a částečný na MD5
Vzhledem k tomu, že je při přenosu kladen důraz na co nejmenší
šířku přenosového pásma, je výsledný kontrolní součet zkrácen
na 80 nebo 32 bitů.
Generování klíčů relace pomocí
jednoho master key
59
Pro distribuci je použit protokol nechráněný protokol SDP (viz RFC 4566).
ZRTP jako nástavba SRTP
(Zimmermann Real-Time Transport Protocol)
60
Pro výměnu klíčů používá mechanismus Diffie-Hellmana
(D-H hodnoty 3072 a 4096) a pak přepne do režimu SRTP.
Pro zamezení útoku typu MITM používá metody
- SAS (Short Authentication Key) – porovnávají se hashe
sdíleného symetrického klíče
M. Abdall: A Simple Threshold Authenticated Key Exchange from Short. ASIACRYPT 2005.
S. Pasini and S. Vaudenay: SAS-Based Authenticated Key Agreement. http://lasecwww.epfl.ch/pub/lasec/doc/PV06b.pdf
Pro WiFi patentováno v USA v roce 2009 (Luciana Costa (It))
- Retained secrets – porovnávají se hashe vytvořené z předchozího
hashe a z nového sdíleného symetrického klíče.
Blíže viz http://realtimesecure.asp2.cz/zrtp.aspx (2010, Vošec - Petr Otoupalík, pěkné)
Příklad použití algoritmu D-H
61
1. Dohoda g = 11, n = 347, 1 < g < 347
2. Tajné klíče jsou x = 240, y = 39
3. A počítá X = gx mod n = 11240 mod 347 = 49
B počítá Y = gy mod n = 1139 mod 347 = 285
4. A pošle B 49, B pošle A 285
5. A počítá Yx mod n = 285240 mod 347 = 268
B počítá Xy mod n = 4939 mod 347 = 268
A a B mají dohodnut společný klíč rovný 268, aniž by byl přenášen.
Řešení problému s nechráněným přenosem
master key v SDP použitím DTLS
62
Příklady řešení bezpečnosti RTP
u softphonů
63Na téma penetračnícjh testů doporučuji http://www.cesnet.cz/akce/2010/vzdalena-spoluprace/p/voznak-penetracni-testy.pdf
64
4. Protokol SCTP
Protokol SCTP
65
Protokol SCTP (Stream Control Transmission Protocol), je protokol, který se ve VoIP
zatím ještě příliš neprosadil. Primárně byl navržen pro přenos PSTN signalizace přes
sítě IP, lze jej však použít i pro přenos signalizačních protokolů. Jedná se
o nespojovaný protokol, podobně jako UDP, ale na rozdíl od UDP je spolehlivý,
doručuje pakety ve správném pořadí a má ochranu proti zahlcení.
Protokol rovněž zavádí podporu multihoming, kde se jeden (nebo oba) koncové body,
mohou skládat z více IP adres.
Data jsou zde přenášena v dávkách zvaných chunk. Každý chunk je identifikován svým
typem, osmibitové pole umožňuje definovat 255 typů, RFC 4960 jich zatím definovalo 15.
Chunky v SCTP (Wireshark)
66
Pěr dotazů
67
1. Pravda nebo lež: většina komunikačních
systémů používá RTP při přenosu hlasu a videa.
2. Pravda nebo lež: RTP má stavět v kvalitě
služeb mechanismu.
3. Pravda nebo lež: porty pro RTP a RTCP jsou
náhodné.
4. Pravda nebo lež: RTCP je vázán na RTP
stream s použitím stejného ID synchronizace
zdroje.
Odpovědi
68
1. Pravda nebo lež: většina komunikačních
systémů používá RTP při přenosu hlasu a videa. T
2. Pravda nebo lež: RTP byl vytvořen s ohledem
na QoS.
3. Pravda nebo lež: Porty pro RTP a RTCP jsou
náhodné.
4. Pravda nebo lež: RTCP je vázán na RTP stream
s použitím stejného ID synchronizace zdroje.
Odpovědi
69
1. Pravda nebo lež: většina komunikačních
systémů používá RTP při přenosu hlasu a videa. T
2. Pravda nebo lež: RTP byl vytvořen s ohledem
na QoS. F
3. Pravda nebo lež: Porty pro RTP a RTCP jsou
náhodné.
4. Pravda nebo lež: RTCP je vázán na RTP stream
s použitím stejného ID synchronizace zdroje.
Odpovědi
70
1. Pravda nebo lež: většina komunikačních
systémů používá RTP při přenosu hlasu a videa. T
2. Pravda nebo lež: RTP byl vytvořen s ohledem
na QoS. F
3. Pravda nebo lež: Porty pro RTP a RTCP jsou
náhodné. Platí to jen pro RTP.
4. Pravda nebo lež: RTCP je vázán na RTP stream
s použitím stejného ID synchronizace zdroje.
Odpovědi
71
1. Pravda nebo lež: většina komunikačních
systémů používá RTP při přenosu hlasu a videa. T
2. Pravda nebo lež: RTP byl vytvořen s ohledem
na QoS. F
3. Pravda nebo lež: Porty pro RTP a RTCP jsou
náhodné. Platí to jen pro RTP.
4. Pravda nebo lež: RTCP je vázán na RTP stream
s použitím stejného ID synchronizace zdroje. F
Jak lze RTP streamy odlišit od
sebe?
72
Jak lze RTP streamy odlišit od sebe?
73
Použitím synchronization source identifier.
K čemu slouží protokol RTCP?
74
K čemu slouží protokol RTCP?
75
Poskytuje zpětnou vazbu pro sledování
výkonu toků RTP.
Uveďte pět typů zpráv RTCP
76
Uveďte pět typů zpráv RTCP
77
 Source Report
 Receiver Report
 Source Description
 Bye
 APP
S jakou frekvencí jsou přenášeny
toky RTCP?
78
S jakou frekvencí jsou přenášeny
toky RTCP?
79
5 paketů/s
Ve kterém paketu naleznete
kanonické jméno?
80
Ve kterém paketu naleznete
kanonické jméno?
81
Source Description
Zdroje
82
Wiki Wireshark http://wiki.wireshark.org/SampleCaptures#SIP_and_RTP