of 54 /54
TÀI LIU THÍ NGHIM MÔN HC KTHUT TRUYN SLIU (Phiên bn cp nht ngày 3/12/2009. Tài liu phc vmôn hc. Lưu hành ni b) Biên son: PGS-TS Trn Xuân Nam Bmôn Thông tin, Khoa Vô tuyến Đin tHc vin Kthut Quân sHÀ NI 2007

Wireshark Labs

Embed Size (px)

Text of Wireshark Labs

TI LIU TH NGHIM MN HC

K THUT TRUYN S LIU(Phin bn cp nht ngy 3/12/2009. Ti liu phc v mn hc. Lu hnh ni b)

Bin son: PGS-TS Trn Xun Nam B mn Thng tin, Khoa V tuyn in t Hc vin K thut Qun s

H NI 2007

MC LCGII THIU ............................................................................................................................ 1 1.1 Mc ch................................................................................................................ 1 1.2 Ci t Wireshark.................................................................................................. 3 1.3 Khi ng Wireshark ............................................................................................ 3 1.4 Chy th Wireshark .............................................................................................. 5 1.5 Ni dung th nghim cn bo co.......................................................................... 8 GIAO THC TCP .................................................................................................................. 9 2.1 Mc ch................................................................................................................ 9 2.2 Phng php.......................................................................................................... 9 2.3 Chun b bi th nghim ........................................................................................ 9 2.4 2.5 Ni dung th nghim............................................................................................ 11 Ni dung kt qu th nghim cn np ................................................................. 22

GIAO THC IP .................................................................................................................... 24 Ti liu tham kho ............................................................................................................... 34 The Transmission Control Protocol.................................................................................. 35 Abstract ............................................................................................................................ 35 A1.1. Introduction ............................................................................................................ 35 A1.2. Connection Establishment and Termination .......................................................... 40 A1.2.1 Three-Way Handshake ..................................................................................... 41 A1.2.2 Data Transfer.................................................................................................... 42 A1.2.3 Connection Termination................................................................................... 42 A1.3. Sliding Window and Flow Control ........................................................................ 43 A1.4. Congestion Control................................................................................................. 44 A1.4.1 Slow Start ......................................................................................................... 44 A1.4.2 Congestion Avoidance ..................................................................................... 45 A1.4.3 Fast Retransmit................................................................................................. 46 A1.4.4 Fast Recovery ................................................................................................... 46 A1.5. Conclusions ............................................................................................................ 46 Abbreviations ............................................................................................................... 47 References .................................................................................................................... 48 IP Fragment............................................................................................................................ 49 A2.1 Introduction ................................................................................................................. 49 A2.2 IP Fragmentation and Reassembly .............................................................................. 49 A2.3 Issues with IP Fragmentation .................................................................................. 51

Bi 1: Gii thiu

Trang 1

Bi 1

GII THIU

1.1

Mc ch

Mc ch ca tp bi th nghim phn tch giao thc mng ny l gip cho hc vin nm vng qu trnh trao i d liu din ra gia cc giao thc thuc cc lp mng tng ng ca b giao thc TCP/IP s dng trong Internet. Cc bi th nghim phn tch giao thc mng s gip cho sinh vin trc tip thc hin thit lp cu hnh, thu kt d liu v phn tch kt qu, quan st chui cc bn tin trao i gia hai thc th (entities) giao thc, o su vo chi tit ca hot ng giao thc, v iu khin cc giao thc thc hin mt s hot ng nht nh ri quan st cc hot ng v hiu qu ca chng. Cc ni dung ny c th c thc hin theo hai phng php: m phng hoc phn tch mi trng mng thc. Trong phm vi bi th nghim ny chng ta s s dng phng php th hai nh s dng gi phn mm phn tch giao thc mng Wireshark. y l gi phn mm m m c s dng ph bin nhiu trng i hc v cc vin nghin cu trn th gii.1

Hc vin s chy mt s ng dng mng trong cc tnh hung khc nhau s dng my tnh trng hoc nh. Quan st cc giao thc mng s dng my tnh ca mnh hc vin c th trc tip tng tc v trao i bn tin vi cc thc th giao thc trn Internet. V vy, hc vin v my tnh s ng vai tr l mt phn tch hp ca cc bi th nghim thc ny. Thng qua bi th nghim hc vin s nm bt c kin thc nh qu trnh hc i i vi hnh. Cng c c bn quan st cc bn tin trao i gia cc thc th giao thc ang chp hnh c gi l packet sniffer. Mt chng trnh packet sniffer bt bn tin ang c pht/thu t/bi my tnh ca hc vin; n cng cho php lu gi v/hoc hin th ni dung ca cc trng giao thc ca cc bn tin bt c. Bn thn packet sniffer l mt chngNi dung cc bi th nghim trong ti liu ny c bin son li t ti liu do J.F.Kurose and Keith W. Ross bin son. xem ton b cc bi th nghim chi tit bng ting Anh, xin truy nhp a ch sau y: http://gaia.cs.umass.edu/ethereal-labs/(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s1

Bi 1: Gii thiu

Trang 2

trnh th ng vi ngha l n ch quan st cc bn tin ang c pht v thu bi cc ng dng v giao thc ang chy trn my tnh ch khng t pht i cc gi tin. Mt cch tng t, cc bn tin cng khng bao gi c nh a ch n packet sniffer mt cch r rng (trc tip). Thay bng, mt packet sniffer nhn mt bn sao ca cc packet c pht/thu t/bi ng dng hay cc giao chc chy ang trn my tnh. Hnh 1.1 ch ra cu trc ca mt packet sniffer. bn phi ca Hnh 1.1 l cc giao thc (trong trng hp ny l cc giao thc Internet) v cc ng dng (v d nh trnh duyt web hay mt ftp client) thng chy trn my tnh. Packet sniffer c m t bn trong hnh ch nht t nt l mt phn chng trnh c ci t vo my tnh, v gm hai phn. Phn th vin bt gi tin (packet capture library) thu cc bn sao ca cc frame ca lp lin kt (link layer) c pht i hoc thu t my tnh. Theo l thuyt bi ging th cc bn tin trao i bi cc giao thc lp pha trn nh HTTP, FTP, TCP, UDP, DNS, hay IP u c ng gi vo cc frame ca lp lin kt c pht i qua mi trng vt l nh cp trong mng Ethernet chng hn. s Hnh 1.1, mi trng gi thit l Ethernet, v v vy, cc giao thc lp trn c ng gi vo trong mt Ethernet frame. Vic bt tt c cc frame ca lp lin kt cho php thu c tt c cc bn tin pht/thu t/bi tt c cc giao thc v ng dng ang chy trn my tnh.

Hnh 1.1: Cu trc packet sniffer Thnh phn th hai ca mt packet sniffer l b phn tch gi tin (packet analyzer), cho php hin th ni dung ca tt c cc trng trong mt bn tin giao thc. lm c iu ny, packet analyzer cn phi hiu cu trc ca tt c cc bn tin trao i gia cc giao thc. V d, gi s chng ta quan tm n vic hin th cc trng trong cc bn tin trao i bi giao(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 3

thc HTTP nh Hnh 1.1. Packet analyzer hiu cu trc ca nh dng Ethernet frame, v v vy c th xc nh c IP datagram bn trong Ethernet frame. Packet analyzer cng hiu nh dng ca IP datagram, v c th tch c TCP segment bn trong IP datagram. Tng t, packet analyzer cng bi t cu trc ca TCP segment v, v vy, cho php tch c bn tin HTTP cha trong TCP segment. Cui cng, packet analyzer hiu giao thc HTTP v, v vy, bit c, byte u tin trong mt bn tin HTTP c cha cc lnh iu khin nh cc t GET, POST, hoc HEAD. Trong phm vi cc bi th nghim ny, chng ta s s dng Wireshark packet sniffer hin th ni dung ca cc bn tin ang pht/thu t/bi cc giao thc cc lp khc nhau ca chng giao thc TCP/IP. Chng trnh ny hot ng trn cc my tnh c s dng Ethernet hay ADSL kt ni ti Internet, cng nh cc giao thc im-ni-im nh PPP (Point-to-Point Protocol). Wireshark l tn gi ca chng trnh Ethereal trc , bt ngun t giao thc lp lin kt d liu Ethernet nh hc trong bi ging. 1.2 Ci t Wireshark

chy Wireshark, my tnh cn phi c ci t c hai phn mm packet sniffer Wireshark v th vin bt gi tin libpcap. Nu phn mm libpcap cha c ci t vo trong h iu hnh ca my, cn phi ci t libpcap. bit a ch download, xem thm ti a ch http://www.wireshark.org/download.html. Download v ci gi phn mm Wireshark: truy nhp n a ch

http://www.wireshark.org, truy nhp vo mc Download, chn mt server gn download Wireshark. Phin bn hin ti ca Wireshark l Wireshark 0.99.7. Download v ci t libpcap2: vi Windows, phn mm libpcap thng c bit n vi tn gi WinPCap. download WinPCap truy nhp vo a ch http://www.winpcap.org/, truy nhp n menu Get WinPCap, v download t mc Installer for Windows. Phin bn hin ti ca WinPCap l WinPCap 4.0.2. 1.3 Khi ng Wireshark

Sau khi khi ng Wireshark, giao din ha ngi dng ca Wireshark s c hin th nh Hnh 1.2. Ban u khng c d liu c hin th cc ca s. Giao din Wireshark c nm thnh phn chnh:2

Cc phin bn mi ca Wireshark c th bao gm WinPCap nn cn kim tra li trc khi ci t

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 4

Menu cu lnh (command menus) l cc menu ko xung t pha trn u ca ca s. Hai menu ng quan tm nht l menu File v Capture. Menu File cho php lu gi d liu gi tn bt c v m mt tp cha d liu gi bt c, v thot khi ng dng Wireshark. Menu Capture cho php bt u bt gi tin.

command menusCa s lc filter specification

Captured packet list

Thng tin header ca mt captured packet header c chn Ni dung packet dng hexadecimal v ASCII

Hnh 1.2. Giao din ngi dng Wireshark

Ca s lit k gi tin (packet-listing window) hin th mt dng tm tt v mi gi tin bt c, bao gm c s th t gi do Wireshark gn, thi gian bt c gi tin, a ch ngun v a ch ch ca gi tin, kiu giao thc, v thng tin v giao thc cha trong gi tin. Phn lit k gi tin c th c xp xp phn loi theo bt k loi no nh bm vo mt tn ct. Trng kiu giao thc (protocol) lit k giao thc mc cao nht thc hin pht hoc thu gi tin ny, tc l, giao thc ngun hay ch ca gi tin ny. Ca s chi tit v packet header (packet-header details window) cung cp chi tit v gi tin c chn (highlighted) trong ca s lit k gi tin. ( chn mt gi tin trong ca s lit k gi tin, t con tr vo dng tm tt v gi tin trong ca s lit k gi tin v click bng phm chut tri). Cc chi tit ny bao gm thng tin v Ethernet frame v IP datagram cha gi tin ny. Lng thng tin ca Ethernet v lp IP c th c m rng hay thu hp li bng cch clicking vo mi tn ch

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 5

sang phi hay xung di v pha tri ca dng Ethernet frame hay IP datagram ca s chi tit v gi tin. Nu cc gi tin c mang bi TCP hay UDP, chi tit v TCP hay UDP s c hin th. Cui cng, chi tit v giao thc lp cao nht pht hay thu gi tin ny cng c cung cp.

Ca s ni dung gi tin (packet-contents window) hin th ton b ni dung ca frame bt c, c dng ASCII v c s 16 (hexadecimal). Trng lc hin th gi (packet display filter field) pha trn ca giao din ha ngi s dng Wireshark cho php nhp tn hay cc thng tin khc v giao thc lc thng tin hin th ca s lit k gi tin (v v vy, u gi tin v ca s ni dung gi tin). v d di y chng ta s dng trng lc hin th gi lc cc gi Ethernet n, ngoi tr cc gi tng ng vi cc bn tin HTTP.

1.4

Chy th Wireshark

chy th Wireshark thc hin cc bc sau y 1. 2. Bc 1: Khi ng web browser (V d: Internet Explorer hay Firefox), nhp vo trang website la chn. Bc 2: Khi ng phn mm Wireshark. S thy c mt ca s tng t Hnh 1.2, ngoi tr khng c gi d liu hin th cc ca s packet-listing, packet-header, hay packet-contents, do Wireshark cha bt u bt gi. 3. 4. Bc 3: bt u bt gi, chn menu ko xung Capture v chn Start. Thao tc ny s lm cho ca s Wireshark: Capture Options hin th nh Hnh 1.3. Bc 4: Sinh vin c th s dng tt c gi tr default trong ca s values . Cc giao din mng (tc l, cc kt ni vt l) m my tnh c ni n mng s c hin th menu ko xung Interface pha trn ca ca s Capture Options. Trong trng hp my tnh c nhiu giao din mng (v d, nu my tnh c c kt ni mng hu tuyn Ethernet v kt ni v tuyn), bn s cn chn mt giao tip s s dng thu v pht packets (thng thng l giao din hu tuyn Ethernet). Sau khi chn xong giao din mng (hoc s dng giao din default ca Wireshark), click OK. Chng trnh bt u bt packet, tc l, tt c cc packet c pht/thu t/bi my tnh ca bn s c chng trnh Wireshark bt. 5. Bc 5: Khi bt u bt packet, mt ca s thng tin vn tt v bt packet s xut hin nh Hnh 1.4. Ca s ny cho thng tin tm tt v s packets thuc cc kiu

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 6

khc nhau ang b bt, v mt phm Stop cho php dng bt packet.

Hnh 1.3: Ca s ty chn ca Wireshark

Hnh 1.4: Ca s captured packet ca Wireshark 6. Bc 6: Trong khi Wireshark ang chy, nhp vo mt a ch URL, v d: http://www.lqdtu.edu.vn/index.htm hin th ni dung trang web browser. hin(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 7

th ni dung trang web ny, browser s lin h vi HTTP server ti http://www.lqdtu.edu.vn/index.htm v trao i cc bn tin HTTP vi server download trang. Cc Ethernet frames cha cc bn tin HTTP ny s b Wireshark bt phn tch. 7. Bc 7: Sau khi browser hin th ni dung trang index.html, dng qu trnh bt packet ca Wireshark bng cch chn Stop ca s Wireshark Capture, hin th tt c cc packets bt c t khi bt u bt packet. Ca s chnh ca Wireshark s c dng tng t nh ca s trn Hnh 1.2. Lc ny chng ta c d liu gi thc (live) cha tt c cc bn tin trao i gia my tnh v cc thc th khc ca mng. Bn tin HTTP trao i vi server ca www.lqdtu.edu.vn s c hin th trong danh sch cc gi bt c. Tuy nhin, cng c nhiu loi gi khc cng s c hin th. iu ny c ngha l mc d bn ch thc hin thao thc download mt trang web, nhng c nhiu giao thc khc chy ngm trong my tnh ca bn 8. Bc 8: Nhp vo http (khng c du ngoc kp v dng ch in thng Wireshark th tt c cc tn protocol u dng ch in thng) vo trong ca s lc hin th u ca s Wireshark chnh. Sau chn Apply. Thao tc ny s lc hin th ring bn tin HTTP ca s packet-listing.

Hnh 1.5: Ca s hin th thng tin ca Wireshark sau bc 8(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 1: Gii thiu

Trang 8

9.

Bc 9: Chn bn tin http u tin trong ca s packet-listing. phi l bn tin HTTP GET c gi i t my ca bn ti HTTP server ca trang www.lqdtu.edu.vn. Khi bn chn bn tin HTTP GET, thng tin u khung ca Ethernet frame, IP datagram, TCP segment, v bn tin HTTP s c hin th ca s packet-header. Bng cch click vo u mi tn sang phi v xung di pha bn tri ca ca s chi tit v packet, c th lc bt hin th thng tin ca Ethernet frame, IP, v TCP. Maximize lng thng tin hin th v giao thc HTTP. Wireshark ca bn s trng gn ging nh Hnh 1.5.

10. Bc 10: Thot Wireshark bng cch vo File n y bn hon thnh xong bi tp u tin. 1.5 Ni dung th nghim cn bo co

Quit

Mc ch ca bi th nghim u tin ny l gii thiu v gip hc vin lm quen vi Wireshark. Da trn 10 bc th nghim va thc hin, tr li cc cu hi sau: 1. Lit k cc giao thc xut hin trn ct giao thc ca s packet-listing cha c filter Bc 7. 2. Thi gian t khi bn tin HTTP GET c gi i n khi bn tin phc p HTTP OK c nhn l bao lu? (Theo mc nh, gi tr ca ct Time ca s packet-listing window l lng thi gian tnh theo giy t khi Wireshark bt u bt. hin th trng Time dng thi gian time-of-day, chn menu ko xung View, sau chn Time Display Format, sau chn tip Time-of-day.) 3. Xc a ch Internet ca www.lqdtu.edu.vn? Xc nh a ch Internet ca my tnh ca bn? 4. In hai bn tin HTTP hin th Bc 9 ni trn. in chn Print t menu cu lnh File, v chn Selected Packet Only v Displayed v click OK.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 9

Bi 2

GIAO THC TCP

2.1

Mc ch

Mc ch ca bi th nghim ny l gip cho hc vin quan st v phn tch mt qu trnh trao i d liu thc din ra gia hai thc th giao thc hai u kt ni, gip hc vin cng c c kin thc l thuyt hc trn lp. Trong bi th nghim ny, hc vin s s dng gi phn mm packet sniffer Wireshark gim st v nghin cu hot ng thc ca giao thc truyn dn tin cy TCP (Transmission Control Protocol) cung cp dch v hng kt ni (connection-oriented service) trn Internet. Sau khi kt thc bi th nghim yu cu hc vin nm vng c qu trnh hot ng ca giao thc truyn ti tin cy TCP v bit cch s dng mt cng c packet sniffer gim st v phn tch qu trnh trao i bn tin trn cc giao thc. 2.2 Phng php

phn tch hot ng ca TCP chng ta c th s dng bt k mt ng dng yu cu dch v truyn dn tin cy nh: HTTP, Telnet, FTP, hay SMTP gi giao thc TCP thc hin kt ni, trao i d liu, v ngt kt ni. Trong bi th nghim ny thun tin chng ta s s dng ng dng HTTP POST mt file t local client l my ca hc vin ln trn mt remote server. My tnh local client c ci t v kch hot Wireshark bt mt trace ca cc packet t khi thit lp kt ni, trao i d liu, cho n khi ngt kt ni. 2.3 Chun b bi th nghim

chun b tin hnh th nghim, cn chun b cc yu t sau y: My tnh c kt ni n Internet thng qua mng LAN hay ADSL ng vai tr local

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 10

client v c ci t sn gi phn mm packet sniffer Wireshark. To mt th mc s dng cho bi th nghim. V d: D:/Wireshark-Labs Mt file text c kch thc tng i ln upload ln remote server. thng nht chng ta chn mt file vn bn c thit k cho bi th nghim c kch thc v ni dung ph hp cho bi th nghim Wireshark ti a ch:http://gaia.cs.umass.edu/ethereal-labs/alice.txt

Sau khi nhp vo a ch trn vo thanh a ch ca web browser, s c ni dung cu chuyn ALICE'S ADVENTURES IN WONDERLAND (Alix x s diu k) dng ASCII hin th trn web browser. Vo menu File Save page as ca browser lu li file cu chuyn vi tn file alice.text vo th mc th nghim ti th mc D:/Wireshark-Labs. Mt account trong remote server cho php post d liu ln. Trong trng hp khng c account cho php post file, chng ta c th s dng remote server h tr cho cc bi th nghim Wireshark t ti trng i hc Massachuset ti a ch:http://gaia.cs.umass.edu/ethereal-labs/TCP-ethereal-file1.html

Uncheck xem ring cc packets n v i t my.

Ty chn giao tip mng (NIC). Thng thung l Ethernet card

Hnh 2.2 Ca s ty chn Capture Options

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 11

2.4

Ni dung th nghim

tin hnh bt packet, to trace v phn tch hoa t ng ca TCP, thc hin tun t cc bc th nghim sau y: 2.4.1 t Capture Options

1. Bc 1: Khi ng Wireshark bng cch nhp p vo biu tng ca Wireshark trn desktop. 2. Bc 2: Trn thanh menu ko xung, chn Capture Options.... Trn dng menu ty

chn Interface, chn giao tip NIC kt ni ti Internet bt gi d liu. Thng thng la chn Ethernet nu my tnh c ni ti mng LAN hay modem ADSL. Nu thc hin kt ni v tuyn n Internet qua mng WiFi, th chn wireless card. Tip theo uncheck Capture packets in promiscous mode bt ring cc gi n v i qua my tnh. V d m t la chn cc Capture Options c minh ha Hnh 2.2. 2.4.2 Chun b capture cc gi 3. Bc 3: Khi ng mt trnh duyt web brower nh Internet Explorer hoc Firefox. 4. Bc 4: Khi ng bt packet: bng cch truy nhp vo menu Capture u qu trnh bt gi. 2.4.3 Thit lp kt ni TCP 5. Bc 5: thc hin thit lp mt kt ni TCP, chng ta s thc hin upload filealice.text lu li phn chun b ln server h tr bi th nghim ti a ch http://gaia.cs.umass.edu/ethereal-labs/TCP-ethereal-file1.html

Start bt

Thng qua vic upload file, giao thc HTTP s dng phng php POST truyn ti file d liu t my tnh client ca hc vin ln remote server. upload file, nhp a ch sau:http://gaia.cs.umass.edu/ethereal-labs/TCP-ethereal-file1.html

vo thanh a ch ca web-browser. Trn mn hnh s xut hin trang web c cha phm Browse cho php upload file nh Hnh 2.3. Sau khi chn c file cn upload alice.txt trong th mc D:/Wireshark-Labs, bm phm Upload POST file ln server. Sau khi file c upload ln server, s c thng bo file c upload thnh cng, yu cu bn Stop capture bt u phn tch d liu nh Hnh 2.4.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 12

Phm Browse cho php nhp vo file alice.txt

Phm Upload cho php upload file alice.txt

Hnh 2.3 Trang web cho php upload file d liu th nghim

Hnh 2.4 Mn hnh thng bo kt qu upload file alice.txt(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 13

Quan st trn ca s Capture Window ca Wireshark s thy c thng tin v cc gi ang c bt nh Hnh 2.5. Tuy nhin, lc ny cha nn bm phm Stop vi m nn chuyn n bc Ngt kt ni mc sau Wireshark bt thm cc gi trao i trong qu trnh ngt kt ni.

Cc giao thc c PDU ang b Wireshark bt

Hnh 2.5 Ca s Capture Window hin th cc packet thuc cc giao thc khc nhau ang b bt 2.4.4 Ngt kt ni 6. Bc 6: ngt kt ni TCP va thit lp trong qu trnh upload file, thc hin ng trnh duyt web brower (nh Internet Explorer hoc Firefox) bng cch vo menu File Close.

2.4.5 Kt thc capture 7. Bc 7: kt thc bt gi tin, bm vo phm Stop trn Capture Window ca Wireshark. Sau khi ca s Capture ng trn mn hnh ca Wireshark s xut hin cc thng tin v qu trnh trao i d liu ca giao thc TCP nh Hnh 2.6. Cc kt qu capture ny c th lu tr li c phc v cho vic phn tch sau ny. lu tr kt qu capture, vo menu File Save as ca Wireshark, chn th mc th nghimD:/Wireshark-Labs v t tn file mong mun (v d Alice_Capture_file) ri

bm Save. Ch l sau khi lu tr file d liu capture c, bn vn c th s dng ca s ca file lu tr thc hin phn tch giao thc bc 8. Ch : trong trng hp my tnh ni n mng ni b Intranet ca Hc vin khng

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 14

truy nhp c n mng Internet, hc vin c th thit lp mt kt ni TCP thng qua giao thc HTTP bng cch thc hin c trang ch ca Hc vin ti a chhttp://www.mta.edu.vn

Cc thao tc thc hin tip theo tng t nh trng hp upload file alice.txt thc hin trn. Giao thc HTTP s thc hin gi giao thc TCP v yu cu thit lp mt kt ni TCP t client l my tnh ca hc vin n web-server lu tr trang ch ca website Hc vin. Trng hp khng thy c cc gi hin th trn ca s Capture cn bm nt Refresh hoc Reload trn web browser ca bn cng bc qu trnh trao i d liuLc quan st ring cc TCP segment

Hnh 2.6: Ca s cha thng tin v qu trnh trao i d liu ca giao thc TCP

2.4.6

Phn tch qu trnh trao i d liu

tin hnh phn tch qu trnh trao i d liu, s dng ca s Wireshark cha cc thng tin capture c nh Hnh 2.6. Trng hp s dng li d liu lu tr cn load li file lu tr bng cch vo menu File Open ca Wireshark v chn file lu tr. quan st qu trnh trao i d liu ca giao thc TCP, trn ca s lc quan st ca Wireshark nhp vo tcp (tt c ch thng) v bm Enter lc quan st ring cc TCP segments. Minh ha qu(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 15

trnh ny c ch ra Hnh 2.6. a/ Qu trnh thit lp kt ni kiu three-way handshake 8. Bc 8: Qu trnh thit lp kt ni kiu three-way handshake: trn ca s Wireshark, da trn cc TCP segment [SYN] chng ta c th theo di qu trnh thit lp kt ni din ra gia my tnh local client ca hc vin v remote webserver theo hai hng Client Server v Server Client nh m t trn Hnh 2.7.

Thit lp kt ni kiu three-way handshake

Bm vo [+] Transmission Control Protocol hin th chi tit v TCP segment

Hnh 2.7 Qu trnh thit lp kt ni TCP quan st chi tit hn cc thng v cc TCP segment, bm vo du [+] TransmissionControl Protocol nh minh ha trn Hnh 2.7. Cc thng tin chi tit nh Source port,

Destination port, Sequence number, Header length, Flags, Window size, Checksum s c hin th. hin th thm cc thng tin chi tit v cc bit trn cc trng u khung tng ng vi segment iu khin, bm vo du [+] Flags. Lc ny chng ta c y cc thng tin chi tit v cc TCP segment. Minh ha v cc thng tin chi tit ny c ch ra Hnh 2.8.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 16

b/ Trao i d liu cc TCP segment 9. Bc 9: La chn s th t ban u cho hng thu v hng pht: mt c im ca TCP l cho php tha thun s th t ca segment trong qu trnh thit lp kt ni nhm hn ch thu nhm cc gi n b tr t kt ni trc . Trong trng hp minh ha Hnh 2.8, s th t (sequence number) tha thun ban u Seq=15890431. Trng hp s th t tha thun ban u hin thSeq=0

biu th s th t tng i ca cc khung

Wireshark bt c. chuyn hin th v s th t thc (tuyt i), vo Edit Preference Protocol TCP, uncheck Relative sequence number andwindow scaling.

S th t ca TCP segment

Thng tin chi tit v cc TCP segment

Hnh 2.8 Thng tin chi tit v TCP segment 10. Bc 10: Phc p cho segment thu c: m bo cung cp dch v truyn dn tin cy, TCP thc hin phc p cc gi thu c khng c li bng cch gi cc ACK tr li cho my pht. bit mt TCP segment c b li hay khng, my thu thc hin kim tra checksum ca TCP header. Trng hp checksum tha mn iu kin kim tra, s c ch th checksum correct nh Hnh 2.9.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 17

c/ Qu trnh iu khin li Qu trnh iu khin li din ra theo cc bc sau y. bc th nht, checksum c kim tra xem c tha mn iu kin kim tra hay khng. Nu tha mn, s c thng bo checksum correct. Trng hp checksum chnh xc, s th t ca khung s c kim tra bc th hai xem c segment b mt hay khng? Trng hp nu c segment b mt hoc checksum khng chnh xc (Hnh 2.9) my thu s yu cu my pht pht li segment theo phng thc Selective Repeat ARQ. 11. Bc 11: Kim tra checksum: sau khi nhn c mt TCP segment t lp IP chuyn ln, giao thc TCP pha thu s kim tra tnh chnh xc ca checksum. Trung hp checksum b sai tng ng vi segment b li, TCP pha thu s gi mt ACK yu cu pht li segment b li nh Hnh 2.9. Trn ca s packet list v packet detail ca Wireshark s thy c thng bo tng ng l Checksum incorrect v [TCP CHECKSUM INCORRECT].

S th t ACK S th t ca TCP segment.

Kim tra li thng qua Checksum

Hnh 2.9 Qu trnh trao i TCP segment 12. Bc 12: T ng pht li mt segment c li hoc b mt s dng Selective Repeat ARQ: khi c mt segment b mt hoc khng tha mn iu kin checksum, nhn c(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 18

ACK yu cu pht li segment li, TCP pht s pht li segment li nh Hnh 2.10. xc nh chi tit v segment c pht li click chut vo dng c thng tin c cha segment v quan st ca s packet details.

Checksum khng tha mn iu kin kim tra, yu cu pht li segment Seq=3823459061

Hnh 2.10 Kim tra checksum ca TCP segment Ly v d cho s kin 055321 trng hp Hnh 2.10 chng ta thy ct packet info c thng tin [TCP Retransmission] cho bit y l segment c pht li. bit thm nguyn nhn pht li chng ta click con tr vo dng cha thng tin v segment ny (xem Hnh 2.11). ca s packet details chng ta thy segment pht li c s th t Sequence_number 698443725. Click con tr vo dng cha segment pht trc v quan st ca s packet details chng ta thy segment 698443725 c pht vo thi im 755650 nh Hnh 2.12. tm ra nguyn nhn gy nn pht li, click vo s kin 881147 di tng ng vi [ACK] cho segment 698443725, v xem xt thng tin ca s packet details, chng ta thy nguyn nhn gy pht li l do ACK cho segment 698443725 b li checksum nn b coi l c li (Hnh 2.13). V vy, my pht TCP t ng pht li segment 698443725.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 19

Segment pht li

S th t tng ng vi ACK trc cho bit segment c pht li

Hnh 2.11 Thng tin v segment b pht li

S th t cho bit segment 698443725 uc pht vo thi im 755650

Hnh 2.12 Xc nh segment pht i b li

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 20

Nguyn nhn pht li do li Checksum ca ACK

Hnh 2.13 Li checksum ca ACK gy pht li Vi cch phn tch tng t chng ta c th tm ra cc nguyn nhn pht li do mt gi khi thy c segment thu c km theo thng bo [TCP Retransmission] v cc s kin trc vi thng bo [Previous segment lost]. c/ iu khin lung thc hin iu khin lung, giao thc TCP my thu iu khin giao thc TCP my pht sao cho my pht khng pht c qu s lng segment cho php trnh lm trn b nh m my thu, gy nn mt gi khng cn thit. lm c vic ny my thu s dng mt ca s qung co (advertise window) Wa da trn tc x l v b nh m my thu. Ca s qung co Wa c tnh bi cng thc: Wa=WR - (Rnew - Rlast). My pht c trch nhim duy tr iu kin: (Srecent - Slast) Wa. Thng qua qu trnh iu khin ny m tc d liu truyn t my pht sang my thu c th iu khin c. 13. Bc 13: Ca s qung co Wa do my thu cung cp: quan st trn cc dng cha thng tin ca cc ACK gi t my thu n my pht, chng ta c th xc nh c ca s qung co Wa . Trn v d Hnh 2.14, ca s qung co Wa=8712 bytes, ln ACK trc Wa=6432 bytes, v ln ACK tip theo l 11616.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 21

Ca s qung co Wa TCP my thu gi cho my thu

Hnh 2.14: Ca s qung co my thu TCP gi n cho my pht

Graceful close

Hnh 2.15: Ngt kt ni kiu graceful close ca TCP

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 22

2.4.7 Ngt kt ni graceful close TCP thc hin ngt kt ni kiu graceful close, tc l ngt kt ni ring cho mi hng. 14. Bc 14: Ngt kt ni kiu graceful close: qu trnh ngt kt ni din ra cho c hai hng t Client Server v t Server Client nh trn Hnh 2.15. Qu trnh din ra theo 3 bc do yu cu ngt kt ni t Server Client thc hin cng AKC theo phng php piggyback. 2.5 Ni dung th nghim cn bo co Hon thnh 14 bc th nghim ni trn, ghi li mn hnh v kt qu phn tch cho tng bc Tr li cc cu hi sau y: 1. a ch IP v s TCP port s dng bi my tnh client (ngun) ang truyn ti file ti gaia.cs.umass.edu? tr li cu hi ny, th cch tt nht l chn mt bn tin HTTP v xem xt chi tit TCP packet c s dng mang bn tin HTTP ny, s dng details of the selected packet header window. 2. a ch IP ca gaia.cs.umass.edu? Server ang gi v nhn cc TCP segment bng cng no cho kt ni ny? 3. S th t ca TCP SYN segment c s dng khi to kt ni TCP gia my tnh client v gaia.cs.umass.edu? Phn no trong segment xc nh segment l mt SYN segment? 4. S th t ca SYNACK segment gi bi gaia.cs.umass.edu n my tnh khi phc p li SYN segment? Gi tr ca trng ACKnowledgement SYNACK segment? gaia.cs.umass.edu xc nh gi tr nh th no? Phn no xc nh segment l mt SYNACK segment? 5. S th t ca TCP segment cha cu lnh HTTP POST? Ch rng tm c lnh POST, bn cn tm hiu k trng ni dung packet pha di ca ca s Wireshark window, tm mt segment vi POST trong trng DATA ca n. 6. Coi TCP segment cha HTTP POST nh l segment u tin kt ni TCP. Xc nh s th t ca 6 segments u tin kt ni TCP (bao gm c segment cha HTTP POST)? Mi segment c gi ti nhng thi im no? ACK c nhn khi

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 2: Giao thc TCP

Trang 23

no cho mi segment? 7. 8. 9. Xc nh di ca tng segment trong s 6 TCP segment u tin? Xc nh kch thc buffer qung co Wa my thu cho 6 TCP segment u tin? C segment pht li no trong trace file khng? Lm cch no kim tra trace tr li cu hi ny? 10. My thu thng s dng bao nhiu d liu trong mt ACK? Bn c th xc nh cc trng hp my thu xc nhn tng segment thu c. 11. Vo Statistics TCP Stream Graph Throughput Graph, v th throughput v phn tch kt qu

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 24

Bi 3

GIAO THC IP

3.1

Mc ch

Trong bi th nghim ny hc vin s nghin cu giao thc lp mng IP (Internet Protocol) s dng trong Internet. Hc vin s tin hnh qu trnh bt cc IP datagram trao i gia my tnh client ca hc vin v mt my tnh khc trn Internet. Sau khi bt c mt trace (vt) cc IP datagrams, hc vin s tin hnh phn tch cc trng d liu trong IP datagram, v nghin cu chi tit thao tc phn on trong giao thc IP. Kt thc bi th nghim hc vin s nm chc hot ng ca giao thc IP, cng c thm kin thc hc trn lp. 3.2 Phng php

phn tch hot ng ca giao thc IP, chng ta s s dng chng trnh traceroute pht i cc packet [i vi Unix v Linux l cc UDP datagram vi cc port ch trong khong 33434 to 33534, cn vi Windows l cc ICMP (Internet Control Message Protocol) echo request] n mt a ch ch nh trc trn mng IP v nhn li cc packet phn hi t cc router, v nh bit c route i t host ch n host ngun. theo di qu trnh trao i thng tin gia trm ngun, cc router v a ch ch, chng ta s dng chng trnh network protocol analyzer Wireshark bt v lu li mt trace ca cc IP datagram v packet pht v thu. 3.3 Bt cc gi nh chng trnh traceroute

to mt trace ca cc IP datagrams cho th nghim, chng ta s s dng chng trnhtraceroute gi i cc packet c kch thc khc nhau ti mt a ch X no trn

Internet. Nguyn tc lm vic ca chng trnh traceroute, da trn chng trnh ping, thc hin trc tin gi i mt hoc nhiu packet c ng gi vo trong IP datagram vi trng TTL (Time to Live) trong header c t bng 1; sau gi tip mt lot cc

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 25

packet v pha cng a ch vi gi tr TTL bng 2; ri bng 3 v tng t. Ch rng mi khi nhn c mt IP datagram, mi router s gim gi tr trng TTL IP datagram thu c i 1. Khi gi tr ca TTL bng 0, router s nhn bit y l mt IP datagram li do thi gian tn ti ht v s t ng gi tr li host ngun thng bo li bng mt bn tin ICMP (type 11 Time-to-live exceeded). Kt qu l mt IP datagram vi TTL bng 1 do chng trnh traceroute gi s lm cho router cch host ngun mt hop t ng gi mt bn tin ICMP Time-to-live exceeded ngc tr v pha host ngun; IP datagram c gi vi TTL bng 2 s lm cho router cch 2 hop gi mt bn tin ICMP ngc v pha ngun; v tng t. Da vo a ch ngun cha trong cc bn tin ICMP vt qu TTL, chng ta c th xc nh c a ch ca router gi bn tin ICMP. V nh vy, bng cch ny, host chy chng trnhtraceroute c th xc nh c cc routers t gia n v ch X.

s dng traceroute trong Windows, chng ta c th s dng chng trnhtracert c sn t command window. Tuy nhin, do chng trnh tracert trong Windows

khng cho php thay i kch thc ca bn in yu cu ting vng ICMP (ping) do chng trnh tracert gi, nn khng th s dng n nghin cu qu trnh phn on trong giao thc IP. V vy, trong bi th nghim ny chng ta s s dng mt chng trnh shareware h trtraceroute l PingPlotter.

3.4

Chun b bi th nghim

phc v cho bi th nghim, hc vin cn chun b cc bc sau y: Chng trnh tracert c s dng ph bin cho windows l PingPlotter. c PingPlotter, c th download t a ch http://www.pingplotter.com/download.html. a ch ca trang PingPlotter, c 3 chng trnh l Freeware, Standard v Pro. Phin bn Freeware hin ti (version 3.20.1) khng cho php thay i kch thc ca gi, trong khi phin bn Pro li khng cho chy th, nn ch c bn Standard c th s dng c dng shareware vi 30 ngy dng th, cho thi gian lm th nghim ca hc vin. Sau khi download c chng trnh PingPlotter phin bn Standard, hc vin cn ci t vo trong my tnh phc v cho th nghim sau ny. My tnh c ni ti mng Internet (qua mng LAN hay ADSL). Chng trnh network protocol anlyzer Wireshark hay phin bn c ca n l Ethereal, c ci t vo trong my tnh. 3.5 Ni dung bi th nghim

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 26

Ni dung bi th nghim gm cc bc chnh sau y:

3.5.1

Thit lp tham s trace

1. Bc 1: Khi ng Wireshark v bt u bt gi (Capture Start), sau bm OK trn mn hnh Packet Capture Options ca ca s. Xem hng dn chi tit Bi 2. 2. Bc 2: Chn mt a ch Internet chng trnh tracert (PingPlotter) to ra mt trace n host c a ch . V d: a ch www.uts.edu.au ca trng i hc University of Technology Sydney (UTS). 3. Bc 3: Khi ng PingPlotter. Sau khi khi ng xong trn mn hnh s xut hin ca s chng trnh nh trn Hnh 3.1.

Thanh nhp a ch Internet ca host cn trace

t s ln mun trace Thi gian gia cc ln trace

Hnh 3.1 Ca s chng trnh PingPlotter Mt s im ng ch trn ca s l thanh nhp a ch host cn trace Address to Trace, phn ci t Sampling vi cc trng thit lp s ln trace # of times to trace, v khong thi gian gia cc ln trace Trace Interval. Trong phm vi bi th nghim ny chng ta t 3 cho # of times to trace. 3.5.2 Bt u trace

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 27

4. Bc

4:

trn

thanh

menu

ca

PingPlotter,

chn

menu

Edit Advanced

Options Packet Options v nhp vo gi tr 56 trng Packet Size v bm OK nh m t trn Hnh 3.2. Sau bm phm Trace. Thao tc ny cho php chng ta gi i cc ICMP echo request packet c kch thc bng 56bytes v host ch l www.uts.edu.au v nhn v cc bn tin ICMP Time-to-live exceeded. Bn s thy c ca s PingPlotter tng t Hnh 3.1 di y.

t kch thc packet

Hnh 3.2 t kch thc packet

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 28

a ch ca cc router trn route t host ngun n ch

Hnh 3.3 Ca s trace ca PingPlotter Tip theo, gi mt tp hp cc packet c di ln hn bng cch chn Edit Advanced Options Packet Options v nhp vo gi tr 2000 (bytes) trng Packet Size v bm OK. Sau bm phm Resume. Cui cng, gi mt tp cc packet vi di ln hn bng cch chn Edit Advanced Options Packet Options v nhp vo gi tr 3500 (bytes) trng Packet Size v sau bm OK. Sau bm phm Resume. 3.5.3 Kt thc trace

5. Bc 5: kt thc trace, dng chng trnh Wireshark bng cch bm Stop ca s Capture ca Wireshark. 3.5.4 Phn tch trace bt c

trong trace do Wireshark thu c, bn s thy mt lot cc packet ICMP Echo Request gi bi host ngun l my tnh ca bn v cc packet cha bn tin ICMP Time-to-Live exceeded do cc router trn tuyn gi ngc tr li v my tnh ca bn. 6. Bc 6: Bn tin ICMP Echo Request. Trn ca s phn tch ca Wireshark chn bn tin bt c u tin nh Hnh 3.4

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 29

a ch IP host ngun

a ch IP ca router cch host mt hop

Kch thc packet = 56 bytes Gi tr Time-to-Live ca IP datagram cha bn tin ICMP

Hnh 3.4 Ca s Wireshark hin th thng tin ca packet u tin Trong phn hin th thng tin v header ca cc packet, chn [+] Internet Protocol xem cc thng tin v header ca IP datagram cha ICMP echo (ping) request packet. Da trn thng tin hin th trn ca s (xem Hnh 3.4) chng ta c th xc nh c a ch IP ca host ngun l 192.168.1.44, a ch host ch l 138.25.16.22, v gi tr trng TLL ca IP datagram bng 1. iu ny cho chng ta bit host www.uts.edu.au c a ch IP l 138.25.16.22. 7. Bc 7: Bn tin ICMP Time-to-Live exceeded. Trn ca s phn tch ca Wireshark, chn bn tin bt c th hai. Nh thy trn ca s y l packet cha bn tin ICMP Time-to-Live exceeded.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 30

Thng tin v ICMP packet IP header length Trng TTL=0

Hnh 3.5 Ca s Wireshark hin th thng tin ca packet ICMP Time-to-Live exceeded phn hin th thng tin v packet chng ta c th thy a ch ngun (a ch ca router gi ICMP packet) l 192.168.1.1 v a ch ch [a ch ca host gi ICMP echo (ping) request] l 192.168.1.44. iu ny c ngha l host (router) 192.168.1.1 l router u tin trn tuyn n host www.uts.edu.au m chng ta ang trace. Khi thu c IP datagram cha ICMP echo (ping) request packet, router 192.168.1.1 gim gi tr TTL i 1. Do TTL=0, nn router 192.168.1.1 loi b IP datagram v t ng gi v host ngun cha bn tin ICMP Time-to-Live exceeded. Trn ca s thng tin chi tit ca Wireshark chn [+] Internet Control Message Protocol, ri chn tip [+] Internet Protocol hin th cc thng tin v ICMP packet v header ca IP datagram nh Hnh 3.5. Trn Hnh 3.5, phn hin th thng tin header ca packet,[-] Internet Control Message Protocol [-] Internet Protocol, chng ta c th thy a ch

ngun l 192.168.1.44 v a ch ch l 138.25.16.22. Hai a ch ngun v ich ny l hai a ch ngun v ch cha trong IP datagram ca packet ICMP echo (ping) request trc . 8. Bc 8: Kch thc IP header. Trn ca s chi tit v header ca packet, phn[-]

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 31

Internet Protocol (xem Hnh 3.5) chng ta thy c thng tin Header length: 20 bytes, cho bit

di header ca IP datagram. T kch thc ca IP datagram v IP header chng ta c th bit c di ca phn payload trong IP datagram. 9. Bc 9: Phn on IP (IP fragment). Theo l thuyt chng ta bit mng Ethernet l lp cung cp dch v cho lp mng IP ch cho php truyn i cc frame vi di ti a 1500 bytes. V vy, cc IP datagram c di ln hn 1500 bytes s b phn on v truyn trn cc Ethernet frame khc nhau. Trong trng hp bi th nghim ang tin hnh, khi gi i cc packet c kch thc 2000 bytes v 3500 bytes, Ethernet s phn on cc packet thnh cc fragment v gi i trn cc Ethernet frame lin tip nhau. Xt v d trng hp packet c kch thc 2000bytes. Do kch thc packet (chnh l kch thc IP datagram) t l 2000 bytes nn tr i 20 bytes header, phn payload cn cha 1980 bytes. Phn d liu ny c chia thnh 2 hai on: mt c kch thc 1480 bytes ng khung va vo 1500 bytes ca Ethernet frame, v mt on th hai cha phn payload cn li, tc l, 500bytes. Trn ca s Captured packet list ca Wireshark, chn dng s kin c cha Fragmented IPprotocolnh Hnh 3.6(a). Trn ca s cha thng tin header chi tit ca packet, phn

pha di ca [-] Internet Prototocol c thng tin Reassembled IP in frame:106 cho bit packet hin ti l mt phn on (fragement) ca mt IP datagram v phn on cn li ca IP datagram c cha trong frame s 106 tng ng vi dng s kin th 106. Chn tip dng tip theo (106 trong v d ny) s thy ca s tng t Hnh 3.6(b). Dng ny cha m t ni dung Echo (ping) request cho bit ton b ni dung ca IP datagram gi trong phn on trc v phn on ny cha bn tin Echo (ping) request. phn thng tin chi tit ca packet header chng ta thy cc thng tin:

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP

Trang 32

IP datagram b phn on

Trng More fragment = 1 cho bit cn phn on tip theo ca cng IP datagram Ch s frame cha phn don tip theo ca cng IP datagram

(a) on th nht ca mt IP datagram

Trng More fragment = 0 cho bit y l phn on cui ca IP datagram

Thng tin v cc phn on ca IP datagram

Hnh 3.6 Phn on IP. (b) on th hai ca mt IP datagram

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Bi 3: Giao thc IP[-] [IP fragments (1980) bytes: #105(1480), #106(500)] [Frame: 105, payload: 0-1479 (1480 bytes)] [Frame: 105, payload: 1480-1979 (500 bytes)]

Trang 33

Thng tin ny, ging nh phn tch trn, c ngha l tng s payload trong IP datagram l 1980bytes, c phn thnh 2 on. on th nht cha 1480bytes, bao gm cc byte t s 0 n 1479 trong IP datagram gc, c truyn i bi frame s 105. on th hai cha 500 bytes cn li, t byte s 1480 n byte 1979, v c truyn i bi frame s 106. 10. Bc 10: Bn tin ICMP Echo Request. Trn ca s phn tch ca Wireshark chn bn tin bt c u tin nh Hnh 3.4 3.6 Ni dung kt qu cn np Lp li 10 bc th nghim trn, phn tch phn on IP cho trng hp gi packet vi kch thc 3500. In kt qu mn hnh v gn vo bo co. Thc hin cc ni dung phn tch tip theo v tr li cc cu hi sau y: Sp xp cc gi traced c theo a ch IP ngun bng cch bm vo Source column header; s c mt mi tn ch xung di (v) bn cnh t Source. Nu mi tn quay ln trn, click li vo Source column header. Chn bn tin ICMP Echo Request u tin do my tnh gi, v m rng phn Internet Protocol ca s chi tit ca packet header. phn ca s lit k cc packet capture c, s thy tt c cc bn tin ICMP k tip pha di bn tin u ICMP tin. S dng mi tn xung di chuyn qua cc bn tin ICMP gi bi my tnh ca bn. 1. Xc nh cc trng trong IP datagram thay i gia cc datagram trong lot cc bn tin ICMP gi t my tnh ca bn? 2. Cc trng no khng thay i? Cc trng no phi c nh? Cc trng no cn thay i? Gii thch ti sao? 3. Xc nh gi tr trng Identification v trng TTL? 4. Cc gi tr ny c c nh vi tt c cc phc p ICMP TTL-exceeded gi ti my tnh ca bn t router gn nht? Ti sao?

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 34

Ti liu tham kho1. A. Leon-Garcia and I. Widjaja, Communication Networks: Fundamental Concepts and Key Architectures, McGraw-Hill, 1999. 2. F. Kurose and K.W. Ross, Ethereal Labs, www-net.cs.umass.edu/ethereal-labs/ 3. www.wireshark.org

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 35

Ph lc 1

The Transmission Control Protocol3

Abstract It is important to understand TCP if one is to understand the historic, current and future architecture of the Internet protocols. Most applications on the Internet make use of TCP, relying upon its mechanisms that ensure safe delivery of data across an unreliable IP layer below. In this paper we explore the fundamental concepts behind TCP and how it is used to transport data between two endpoints. A1.1. Introduction The Transmission Control Protocol (TCP) standard is defined in the Request For Comment (RFC) standards document number 793 [10] by the Internet Engineering Task Force (IETF). The original specification written in 1981 was based on earlier research and experimentation in the original ARPANET. The design of TCP was heavily influenced by what has come to be known as the "end-to-end argument" [3]. As it applies to the Internet, the end-to-end argument says that by putting excessive intelligence in physical and link layers to handle error control, encryption or flow control you unnecessarily complicate the system. This is because these functions will usually need to be done at the endpoints anyway, so why duplicate the effort along the way? The result of an end-to-end network then, is to provide minimal functionality on a hop-by-hop basis and maximal control between end-to-end communicating systems. The end-to-end argument helped determine how two characteristics of TCP operate; performance and error handling. TCP performance is often dependent on a subset of algorithms and techniques such as flow control and congestion control. Flow control determines the rate at which data is transmitted between a sender and receiver. Congestion3

Ngun: http://condor.depaul.edu/~jkristof/technotes/tcp.html

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 36

control defines the methods for implicitly interpreting signals from the network in order for a sender to adjust its rate of transmission. The term congestion control is a bit of a misnomer. Congestion avoidance would be a better term since TCP cannot control congestion per se. Ultimately intermediate devices, such as IP routers would only be able to control congestion. Congestion control is currently a large area of research and concern in the network community. A companion study on congestion control examines the current state of activity in that area [9]. Timeouts and retransmissions handle error control in TCP. Although delay could be substantial, particularly if you were to implement real-time applications, the use of both techniques offer error detection and error correction thereby guaranteeing that data will eventually be sent successfully. The nature of TCP and the underlying packet switched network provide formidable challenges for managers, designers and researchers of networks. Once regulated to low speed data communication applications, the Internet and in part TCP are being used to support very high speed communications of voice, video and data. It is unlikely that the Internet protocols will remain static as the applications change and expand. Understanding the current state of affairs will assist us in understanding protocol changes made to support future applications. a/ Transmission Control Protocol TCP is often described as a byte stream, connection-oriented, reliable delivery transport layer protocol. In turn, we will discuss the meaning for each of these descriptive terms. b/ Byte Stream Delivery TCP interfaces between the application layer above and the network layer below. When an application sends data to TCP, it does so in 8-bit byte streams. It is then up to the sending TCP to segment or delineate the byte stream in order to transmit data in manageable pieces to the receiver1. It is this lack of 'record boundaries" which give it the name "byte stream delivery service". c/ Connection-Oriented Before two communicating TCPs can exchange data, they must first agree upon the willingness to communicate. Analogous to a telephone call, a connection must first be made before two parties exchange information.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 37

d/ Reliability A number of mechanisms help provide the reliability TCP guarantees. Each of these is described briefly below. Checksums. All TCP segments carry a checksum, which is used by the receiver to detect errors with either the TCP header or data. Duplicate data detection. It is possible for packets to be duplicated in packet switched network; therefore TCP keeps track of bytes received in order to discard duplicate copies of data that has already been received.2 Retransmissions. In order to guarantee delivery of data, TCP must implement retransmission schemes for data that may be lost or damaged. The use of positive acknowledgements by the receiver to the sender confirms successful reception of data. The lack of positive acknowledgements, coupled with a timeout period (see timers below) calls for a retransmission. Sequencing. In packet switched networks, it is possible for packets to be delivered out of order. It is TCP's job to properly sequence segments it receives so it can deliver the byte stream data to an application in order. Timers. TCP maintains various static and dynamic timers on data sent. The sending TCP waits for the receiver to reply with an acknowledgement within a bounded length of time. If the timer expires before receiving an acknowledgement, the sender can retransmit the segment. e/ TCP Header Format Remember that the combination of TCP header and TCP in one packet is called a TCP segment. Figure 1 depicts the format of all valid TCP segments. The size of the header without options is 20 bytes. We will briefly define each field of the TCP header below.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 38

Figure 1 - TCP Header Format f/ Source Port A 16-bit number identifying the application the TCP segment originated from within the sending host. The port numbers are divided into three ranges, well-known ports (0 through 1023), registered ports (1024 through 49151) and private ports (49152 through 65535). Port assignments are used by TCP as an interface to the application layer. For example, the TELNET server is always assigned to the well-known port 23 by default on TCP hosts. A complete pair of IP addresses (source and destination) plus a complete pair of TCP ports (source and destination) define a single TCP connection that is globally unique. See [5] for further details. g/ Destination Port A 16-bit number identifying the application the TCP segment is destined for on a receiving host. Destination ports use the same port number assignments as those set aside for source ports [5]. h/ Sequence Number A 32-bit number identifying the current position of the first data byte in the segment within the entire byte stream for the TCP connection. After reaching 232 -1, this number will wrap around to 0. i/ Acknowledgement Number A 32-bit number identifying the next data byte the sender expects from the receiver. Therefore, the number will be one greater than the most recently received data byte. This field is only used when the ACK control bit is turned on (see below). k/ Header Length(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 39

A 4-bit field that specifies the total TCP header length in 32-bit words (or in multiples of 4 bytes if you prefer). Without options, a TCP header is always 20 bytes in length. The largest a TCP header may be is 60 bytes. This field is required because the size of the options field(s) cannot be determined in advance. Note that this field is called "data offset" in the official TCP standard, but header length is more commonly used. l/ Reserved A 6-bit field currently unused and reserved for future use. m/ Control Bits Urgent Pointer (URG). If this bit field is set, the receiving TCP should interpret the urgent pointer field (see below). Acknowledgement (ACK). If this bit field is set, the acknowledgement field described earlier is valid. Push Function (PSH). If this bit field is set, the receiver should deliver this segment to the receiving application as soon as possible. An example of its use may be to send a Control-BREAK request to an application, which can jump ahead of queued data. Reset the Connection (RST). If this bit is present, it signals the receiver that the sender is aborting the connection and all queued data and allocated buffers for the connection can be freely relinquished. Synchronize (SYN). When present, this bit field signifies that sender is attempting to "synchronize" sequence numbers. This bit is used during the initial stages of connection establishment between a sender and receiver. No More Data from Sender (FIN). If set, this bit field tells the receiver that the sender has reached the end of its byte stream for the current TCP connection. n/ Window A 16-bit integer used by TCP for flow control in the form of a data transmission window size. This number tells the sender how much data the receiver is willing to accept. The maximum value for this field would limit the window size to 65,535 bytes, however a "window scale" option can be used to make use of even larger windows. o/ Checksum

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 40

A TCP sender computes a value based on the contents of the TCP header and data fields. This 16-bit value will be compared with the value the receiver generates using the same computation. If the values match, the receiver can be very confident that the segment arrived intact. p/ Urgent Pointer In certain circumstances, it may be necessary for a TCP sender to notify the receiver of urgent data that should be processed by the receiving application as soon as possible. This 16-bit field tells the receiver when the last byte of urgent data in the segment ends. q/ Options In order to provide additional functionality, several optional parameters may be used between a TCP sender and receiver. Depending on the option(s) used, the length of this field will vary in size, but it cannot be larger than 40 bytes due to the size of the header length field (4 bits). The most common option is the maximum segment size (MSS) option. A TCP receiver tells the TCP sender the maximum segment size it is willing to accept through the use of this option. Other options are often used for various flow control and congestion control techniques. r/ Padding Because options may vary in size, it may be necessary to "pad" the TCP header with zeroes so that the segment ends on a 32-bit word boundary as defined by the standard [10]. s/ Data Although not used in some circumstances (e.g. acknowledgement segments with no data in the reverse direction), this variable length field carries the application data from TCP sender to receiver. This field coupled with the TCP header fields constitutes a TCP segment. A1.2. Connection Establishment and Termination TCP provides a connection-oriented service over packet switched networks. Connection-oriented implies that there is a virtual connection between two endpoints.3 There are three phases in any virtual connection. These are the connection establishment, data transfer and connection termination phases.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 41

A1.2.1 Three-Way Handshake In order for two hosts to communicate using TCP they must first establish a connection by exchanging messages in what is known as the three-way handshake. The diagram below depicts the process of the three-way handshake.

Figure 2 - TCP Connection Establishment From figure 2, it can be seen that there are three TCP segments exchanged between two hosts, Host A and Host B. Reading down the diagram depicts events in time. To start, Host A initiates the connection by sending a TCP segment with the SYN control bit set and an initial sequence number (ISN) we represent as the variable x in the sequence number field. At some moment later in time, Host B receives this SYN segment, processes it and responds with a TCP segment of its own. The response from Host B contains the SYN control bit set and its own ISN represented as variable y. Host B also sets the ACK control bit to indicate the next expected byte from Host A should contain data starting with sequence number x+1. When Host A receives Host B's ISN and ACK, it finishes the connection establishment phase by sending a final acknowledgement segment to Host B. In this case, Host A sets the ACK control bit and indicates the next expected byte from Host B by placing acknowledgement number y+1 in the acknowledgement field. In addition to the information shown in the diagram above, an exchange of source and destination ports to use for this connection are also included in each senders' segments.4

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 42

A1.2.2 Data Transfer Once ISNs have been exchanged, communicating applications can transmit data between each other. Most of the discussion surrounding data transfer requires us to look at flow control and congestion control techniques which we discuss later in this document and refer to other texts [9]. A few key ideas will be briefly made here, while leaving the technical details aside. A simple TCP implementation will place segments into the network for a receiver as long as there is data to send and as long as the sender does not exceed the window advertised by the receiver. As the receiver accepts and processes TCP segments, it sends back positive acknowledgements, indicating where in the byte stream it is. These acknowledgements also contain the "window" which determines how many bytes the receiver is currently willing to accept. If data is duplicated or lost, a "hole" may exist in the byte stream. A receiver will continue to acknowledge the most current contiguous place in the byte stream it has accepted. If there is no data to send, the sending TCP will simply sit idly by waiting for the application to put data into the byte stream or to receive data from the other end of the connection. If data queued by the sender reaches a point where data sent will exceed the receiver's advertised window size, the sender must halt transmission and wait for further acknowledgements and an advertised window size that is greater than zero before resuming. Timers are used to avoid deadlock and unresponsive connections. Delayed transmissions are used to make more efficient use of network bandwidth by sending larger "chunks" of data at once rather than in smaller individual pieces.5 A1.2.3 Connection Termination In order for a connection to be released, four segments are required to completely close a connection. Four segments are necessary due to the fact that TCP is a full-duplex protocol, meaning that each end must shut down independently.6 The connection termination phase is shown in figure 3 below.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 43

Figure 3 - TCP Connection Termination Notice that instead of SYN control bit fields, the connection termination phase uses the FIN control bit fields to signal the close of a connection. To terminate the connection in our example, the application running on Host A signals TCP to close the connection. This generates the first FIN segment from Host A to Host B. When Host B receives the initial FIN segment, it immediately acknowledges the segment and notifies its destination application of the termination request. Once the application on Host B also decides to shut down the connection, it then sends its own FIN segment, which Host A will process and respond with an acknowledgement. A1.3. Sliding Window and Flow Control Flow control is a technique whose primary purpose is to properly match the transmission rate of sender to that of the receiver and the network. It is important for the transmission to be at a high enough rate to ensure good performance, but also to protect against overwhelming the network or receiving host. In [8], we note that flow control is not the same as congestion control. Congestion control is primarily concerned with a sustained overload of network intermediate devices such as IP routers.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 44

TCP uses the window field, briefly described previously, as the primary means for flow control. During the data transfer phase, the window field is used to adjust the rate of flow of the byte stream between communicating TCPs. Figure 4 below illustrates the concept of the sliding window.

Figure 4 - Sliding Window In this simple example, there is a 4-byte sliding window. Moving from left to right, the window "slides" as bytes in the stream are sent and acknowledged.7 The size of the window and how fast to increase or decrease the window size is an area of great research. We again refer to other documents for further detail [9]. A1.4. Congestion Control TCP congestion control and Internet traffic management issues in general is an active area of research and experimentation. This final section is a very brief summary of the standard congestion control algorithms widely used in TCP implementations today. These algorithms are defined in [6] and [7]. Their use with TCP was standardized in [1]. A1.4.1 Slow Start Slow Start, a requirement for TCP software implementations is a mechanism used by the sender to control the transmission rate, otherwise known as sender-based flow control. This is accomplished through the return rate of acknowledgements from the receiver. In other words,

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 45

the rate of acknowledgements returned by the receiver determine the rate at which the sender can transmit data. When a TCP connection first begins, the Slow Start algorithm initializes a congestion window to one segment, which is the maximum segment size (MSS) initialized by the receiver during the connection establishment phase. When acknowledgements are returned by the receiver, the congestion window increases by one segment for each acknowledgement returned. Thus, the sender can transmit the minimum of the congestion window and the advertised window of the receiver, which is simply called the transmission window. Slow Start is actually not very slow when the network is not congested and network response time is good. For example, the first successful transmission and acknowledgement of a TCP segment increases the window to two segments. After successful transmission of these two segments and acknowledgements completes, the window is increased to four segments. Then eight segments, then sixteen segments and so on, doubling from there on out up to the maximum window size advertised by the receiver or until congestion finally does occur. A1.4.2 Congestion Avoidance During the initial data transfer phase of a TCP connection the Slow Start algorithm is used. However, there may be a point during Slow Start that the network is forced to drop one or more packets due to overload or congestion. If this happens, Congestion Avoidance is used to slow the transmission rate. However, Slow Start is used in conjunction with Congestion Avoidance as the means to get the data transfer going again so it doesn't slow down and stay slow. In the Congestion Avoidance algorithm a retransmission timer expiring or the reception of duplicate ACKs can implicitly signal the sender that a network congestion situation is occurring. The sender immediately sets its transmission window to one half of the current window size (the minimum of the congestion window and the receiver's advertised window size), but to at least two segments. If congestion was indicated by a timeout, the congestion window is reset to one segment, which automatically puts the sender into Slow Start mode. If congestion was indicated by duplicate ACKs, the Fast Retransmit and Fast Recovery algorithms are invoked (see below). As data is received during Congestion Avoidance, the congestion window is increased. However, Slow Start is only used up to the halfway point where congestion originally occurred. This halfway point was recorded earlier as the new transmission window. After this halfway point, the congestion window is increased by one segment for all segments in the transmission window that are acknowledged. This mechanism will force the sender to more

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 46

slowly grow its transmission rate, as it will approach the point where congestion had previously been detected. A1.4.3 Fast Retransmit When a duplicate ACK is received, the sender does not know if it is because a TCP segment was lost or simply that a segment was delayed and received out of order at the receiver. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Typically no more than one or two duplicate ACKs should be received when simple out of order conditions exist. If however more than two duplicate ACKs are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate ACKs. When three or more duplicate ACKs are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment (as indicated by the position of the duplicate ACK in the byte stream). This process is called the Fast Retransmit algorithm and was first defined in [7]. Immediately following Fast Retransmit is the Fast Recovery algorithm. A1.4.4 Fast Recovery Since the Fast Retransmit algorithm is used when duplicate ACKs are being received, the TCP sender has implicit knowledge that there is data still flowing to the receiver. Why? The reason is because duplicate ACKs can only be generated when a segment is received. This is a strong indication that serious network congestion may not exist and that the lost segment was a rare event. So instead of reducing the flow of data abruptly by going all the way into Slow Start, the sender only enters Congestion Avoidance mode. Rather than start at a window of one segment as in Slow Start mode, the sender resumes transmission with a larger window, incrementing as if in Congestion Avoidance mode. This allows for higher throughput under the condition of only moderate congestion [23]. A1.5. Conclusions TCP is a fairly complex protocol that handles the brunt of functionality in a packet switched network such as the Internet. Supporting the reliable delivery of data on a packet switched network is not a trivial task. This document only scratches the surface of the TCP internals, but hopefully provided the reader with an appreciation and starting point for further interest in TCP. Even after almost 20 years of standardization, the amount of work that goes into supporting and designing reliable packet switched networks has not slowed. It is an area of(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 47

great activity and there are many problems to be solved. As the Internet continues to grow, our reliance on TCP will become increasingly important. It is therefore imperative for network engineers, designers and researchers to be as well versed in the technology as possible.

1. The word "segment" is the term used to describe TCP's data unit size transmitted to a receiver. TCP determines the appropriate use of this segment size rather than leaving it up to higher layer protocols and applications. 2. Duplicate packets are typically caused by retransmissions, where the first packet may have been delayed and the second sent due to the lack of an acknowledgement. The receiver may then receive two identical packets. 3. As opposed to a connectionless-oriented protocol such as that used by the user datagram protocol (UDP). 4. There are additional details of the connection establishment, data transfer and termination phases that are beyond the scope of this document. For curious readers, I recommend consulting a more complete reference such as [4], [11] and of course the official standard RFC 793 [10]. 5. It was discovered early on that some implementations of TCP performed poorly due to this scenario. It has been termed the silly window syndrome and documented in [2]. 6. Although it is possible, it is not very common for TCP to be operating in the "half-close state". See [11] for further details. 7. We assume in this example that bytes are immediately acknowledged so that the window can move forward. In practice the sender's window shrinks and grows dynamically as acknowledgements arrive in time. Abbreviations ACK bit IETF IP ISN RFC TCP Acknowledgement binary digit Internet Engineering Task Force Internet Protocol Initial Sequence Number Request For Comments Transmission Control Protocol

TCP/IP Transmission Control Protocol/Internet Protocol

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 48

UDP

User Datagram Protocol

References[1] Robert Braden. Requirements for Internet Hosts - Communication Layers, October 1989, RFC 1122. [2] David D. Clark. Window Acknowledgement and Strategy in TCP, July 1982, RFC 813. [3] David D. Clark. The Design Philosophy of the DARPA Internet Protocols. In Proceedings SIGCOMM '88, Computer Communications Review Vol. 18, No. 4, August 1988, pp. 106-114). [4] Douglas E. Comer. Internetworking with TCP/IP, Volume I: Principles, Protocols and Architecture. Prentice Hall, ISBN: 0-13-216987-8. March 24, 1995. [5] Internet Assigned Numbers Authority. Port Number Assignment, February 2000. [6] Van Jacobson. Congestion Avoidance and Control. Computer Communications Review, Volume 18 number 4, pp. 314-329, August 1988. [7] Van Jacobson. Modified TCP Congestion Control Avoidance Algorithm. end-2-end-interest mailing list, April 30, 1990. [8] S. Keshav. An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network. Addison Wesley, ISBN: 0-201-63442-2. July, 1997. [9] John Kristoff. TCP Congestion Control, March 2000. [10] Jon Postel. Transmission Control Protocol, September 1981, RFC 793. [11] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison Wesley, ISBN: 0-201-63346-9. January 1994.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 49

Ph lc 2

IP Fragment4

A2.1 Introduction The purpose of this document is to present how IP Fragmentation and Path Maximum Transmission Unit Discovery (PMTUD) work and to discuss some scenarios involving the behavior of PMTUD when combined with different combinations of IP tunnels. The current widespread use of IP tunnels in the Internet has brought the problems involving IP Fragmentation and PMTUD to the forefront. A2.2 IP Fragmentation and Reassembly The IP protocol was designed for use on a wide variety of transmission links. Although the maximum length of an IP datagram is 64K, most transmission links enforce a smaller maximum packet length limit, called a MTU. The value of the MTU depends on the type of the transmission link. The design of IP accommodates MTU differences by allowing routers to fragment IP datagrams as necessary. The receiving station is responsible for reassembling the fragments back into the original full size IP datagram. IP fragmentation involves breaking a datagram into a number of pieces that can be reassembled later. The IP source, destination, identification, total length, and fragment offset fields, along with the "more fragments" and "don't fragment" flags in the IP header, are used for IP fragmentation and reassembly. For more information about the mechanics of IP fragmentation and reassembly, please see RFC 791. The image below depicts the layout of an IP header.

4

Ngun: http://www.cisco.com/warp/public/105/pmtud_ipfrag.html

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 50

Figure 1. IP datagram header The identification is 16 bits and is a value assigned by the sender of an IP datagram to aid in reassembling the fragments of a datagram. The fragment offset is 13 bits and indicates where a fragment belongs in the original IP datagram. This value is a multiple of eight bytes. In the flags field of the IP header, there are three bits for control flags. It is important to note that the "don't fragment" (DF) bit plays a central role in PMTUD because it determines whether or not a packet is allowed to be fragmented. Bit 0 is reserved, and is always set to 0. Bit 1 is the DF bit (0 = "may fragment," 1 = "don't fragment"). Bit 2 is the MF bit (0 = "last fragment," 1 = "more fragments"). Value 0 1 0 0 Bit 0 Reserved Bit 1 DF May Do not Bit 2 MF Last More

The graphic below shows an example of fragmentation. If you add up all the lengths of the IP fragments, the value exceeds the original IP datagram length by 60. The reason that the overall length is increased by 60 is because three additional IP headers were created, one for each fragment after the first fragment. The first fragment has an offset of 0, the length of this fragment is 1500; this includes 20 bytes for the slightly modified original IP header. The second fragment has an offset of 185 (185 x 8 = 1480), which means that the data portion of this fragment starts 1480 bytes into the original IP datagram. The length of this fragment is 1500; this includes the additional IP header created for this fragment.(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 51

The third fragment has an offset of 370 (370 x 8 = 2960), which means that the data portion of this fragment starts 2960 bytes into the original IP datagram. The length of this fragment is 1500; this includes the additional IP header created for this fragment. The fourth fragment has an offset of 555 (555 x 8 = 4440), which means that the data portion of this fragment starts 4440 bytes into the original IP datagram. The length of this fragment is 700 bytes; this includes the additional IP header created for this fragment. It is only when the last fragment is received that the size of the original IP datagram can be determined. The fragment offset in the last fragment (555) gives a data offset of 4440 bytes into the original IP datagram. If you then add the data bytes from the last fragment (680 = 700 - 20), that gives you 5120 bytes, which is the data portion of the original IP datagram. Then, adding 20 bytes for an IP header equals the size of the original IP datagram (4440 + 680 + 20 = 5140).

A2.3 Issues with IP Fragmentation There are several issues that make IP fragmentation undesirable. There is a small increase in CPU and memory overhead to fragment an IP datagram. This holds true for the sender as well as for a router in the path between a sender and a receiver. Creating fragments simply involves creating fragment headers and copying the original datagram into the fragments. This can be done fairly efficiently because all the information needed to create the fragments is immediately available. Fragmentation causes more overhead for the receiver when reassembling the fragments because the receiver must allocate memory for the arriving fragments and coalesce them back into one datagram after all of the fragments are received. Reassembly on a host is not

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s

Ti liu tham kho

Trang 52

considered a problem because the host has the time and memory resources to devote to this task. But, reassembly is very inefficient on a router whose primary job is to forward packets as quickly as possible. A router is not designed to hold on to packets for any length of time. Also a router doing reassembly chooses the largest buffer available (18K) with which to work because it has no way of knowing the size of the original IP packet until the last fragment is received. Another fragmentation issue involves handling dropped fragments. If one fragment of an IP datagram is dropped, then the entire original IP datagram must be resent, and it will also be fragmented. You see an example of this with Network File System (NFS). NFS, by default, has a read and write block size of 8192, so a NFS IP/UDP datagram will be approximately 8500 bytes (including NFS, UDP, and IP headers). A sending station connected to an Ethernet (MTU 1500) will have to fragment the 8500 byte datagram into six pieces; five 1500 byte fragments and one 1100 byte fragment. If any of the six fragments is dropped because of a congested link, the complete original datagram will have to be retransmitted, which means that six more fragments will have to be created. If this link drops one in six packets, then the odds are low that any NFS data can be transferred over this link, since at least one IP fragment would be dropped from each NFS 8500 byte original IP datagram. Firewalls that filter or manipulate packets based on Layer 4 (L4) through Layer 7 (L7) information in the packet may have trouble processing IP fragments correctly. If the IP fragments are out of order, a firewall may block the non-initial fragments because they do not carry the information that would match the packet filter. This would mean that the original IP datagram could not be reassembled by the receiving host. If the firewall is configured to allow non-initial fragments with insufficient information to properly match the filter, then a non-initial fragment attack through the firewall could occur. Also, some network devices (such as Content Switch Engines) direct packets based on L4 through L7 information, and if a packet spans multiple fragments, then the device may have trouble enforcing its policies.

(C)2007 Trn Xun Nam, Khoa V tuyn in t, Hc vin K thut Qun s