Your SlideShare is downloading. ×
  • Like
Network Packet Analysis - using WireShark
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Network Packet Analysis - using WireShark

  • 812 views
Published

네크워크 패킷 분석 - TCP, IP, UDP, ICMP …

네크워크 패킷 분석 - TCP, IP, UDP, ICMP
2013.06.13

Published in Engineering
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
812
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 컴퓨터 네트워크 : 팀 프로젝트 Network Packet Analysis - Using WireShark 2013. 6. 3. 이 오 준
  • 2. 1. 네트워크 패킷의 일반적인 형태 - Ethernet/IP 헤더의 기본 구조 - TCP/UDP/ICMP 헤더의 기본 구조 2. 패킷의 종류에 따른 형태 - SYN Packet - TCP Packet with Payload - UDP Packet - Error reporting ICMP Packet - Echo request ICMP Packet 3. 결론 CONTENTS
  • 3. 1. 네트워크 패킷의 일반적인 형태
  • 4. 1-1 Ethernet/IP Header의 기본 구조 04 1. 네트워크 패킷의 일반적인 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 Des. Mac add. 2 Des. Mac add. Source Mac add. 3 Source Mac add. 4 type 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 version h. len. type of service total length 2 Identification flag fragment offset 3 time to live protocol header checksum 4 Source IP Address 5 Destination IP Address 6 Option
  • 5. 1-2 TCP/UDP/ICMP Header의 기본 구조 05 1. 네트워크 패킷의 일반적인 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 Source Port Destination Port 2 Total Length Checksum 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 Type Code Checksum 2 Other Message-Specific Information 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 Source Port Destination Port 2 Sequence Number 3 Acknowledgement number 4 h. len. Reversed C W R E C E U R G A C K P S H R S T S Y N F I N Window Size 5 Checksum Urgent pointer 6 Option 7
  • 6. 2. 패킷 종류에 따른 형태 2-1. SYN Packet 2-2. TCP Packet with payload 2-3. UDP Packet 2-4. Error reporting ICMP Packet 2-5. Echo request ICMP Packet
  • 7. 2-1. SYN Packet 07 2. 패킷 종류에 따른 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 00:1b:0d:60:c0:00 2 e8:03:9a:1e:45:71 3 4 0800 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 ver.4 20 bytes 0x00 52 bytes 2 0x7b96 (31638) 0x02 0 3 128 TCP (6) 0x0000 4 172.25.235.50 5 120.50.129.110 6 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 49942 (49942) http (80) 2 0 (relative sequence number) 3 0 4 32 byte 00000 0 0 0 0 0 0 1 0 8192 5 0x9113 0 6 Maximum Segment Size: 1464 bytes 7 NOP Window Scale: 2 (multiply by 4) 8 NOP NOP TCP SACK Permitted Option: True
  • 8. 2-1. SYN Packet 08 2. 패킷 종류에 따른 형태 전체 패킷의 hex 코드 Ethernet 프레임의 기본 정보
  • 9. 2-1. SYN Packet 09 2. 패킷 종류에 따른 형태 Ethernet 헤더 분석 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 00:1b:0d:60:c0:00 2 e8:03:9a:1e:45:71 3 4 0800 -수신자의 Mac 주소 : 00:1b:0d:60:c0:00 -송신자의 Mac 주소 : e8:03:9a:1e:45:71 -상위 프로토콜의 Type : 0x0800 (IP를 의미)
  • 10. 2-1. SYN Packet 010 2. 패킷 종류에 따른 형태 IP 헤더 분석 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 ver.4 20 bytes 0x00 52 bytes 2 0x7b96 (31638) 0x02 0 3 128 TCP (6) 0x0000 4 172.25.235.50 5 120.50.129.110
  • 11. 2-1. SYN Packet 011 2. 패킷 종류에 따른 형태 IP 헤더 분석 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 ver.4 20 bytes 0x00 52 bytes 2 0x7b96 (31638) 0x02 0 3 128 TCP (6) 0x0000 4 172.25.235.50 5 120.50.129.110 -IP 프로토콜의 버전 : 4 -IP 헤더의 길이 : 20bytes (header option 없음) -Type of Service : 0x00 (default) - 우선순위, 지연시간, 처리능력, 신뢰성에 관한 QoS 표기. -전체 IP Datagram의 길이 : 52bytes -Datagram 식별 번호 : 0x7b96 (31638) - 단편마다 고유하게 설정하여 datagram 재조립시 사용. -Flags : 0x02 (단편화 일어나지 않음) -Fragment Offset : 0 (단편화가 일어나지 않았음) - 단편화시 단편의 시작 바이트 값을 8로 나누어 저장. -Time To Live : 128 -상위 프로토콜의 종류 : TCP (6) -Header Checksum : 0x0000 -송신자 주소 : 172.25.235.50 -수신자 주소 : 120.50.129.110
  • 12. 2-1. SYN Packet 012 2. 패킷 종류에 따른 형태 TCP 헤더 분석 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 2 2 2 3 2 4 2 5 2 6 2 7 2 8 2 9 3 0 3 1 3 2 1 49942 (49942) http (80) 2 0 (relative sequence number) 3 0 4 32 byte 00000 0 0 0 0 0 0 1 0 8192 5 0x9113 0 6 Maximum Segment Size: 1464 bytes 7 NOP Window Scale: 2 (multiply by 4) 8 NOP NOP TCP SACK Permitted Option: True-송신자의 포트 번호 : 49942 (49942) -수신자의 포트 번호 : http (80) -Sequence Number : 0 (relative sequence number) -Acknowledge Number : 0 - 연결을 요청하는 SYN 세그먼트이므로 이전에 보낸 세그먼트가 없음. -TCP 헤더의 길이 : 32bytes (option -> 12bytes) -사용되지 않는 영역 : 00000 -Code bit (제어 패킷 설정) : 0x002 (SYN 패킷) -Window 크기 : 8192 -송신자의 수신 윈도우의 크기. -Checksum : 0x9113 -Urgent Pointer : 0 -URG 제어 비트가 활성화 된 경우 체크하는 부분 -Maximum Segment Size (option) : 1464 bytes -Window Scale (option) : 2 (multiply by 4) -Window 크기 영역의 값에 4를 곱한 것이 실제 윈도우 크기. -TCP SACK Permitted Option (option) : True -SYN Segment에서 발견되는 연속보내기를 허용하는 옵션.
  • 13. 2-1. SYN Packet 013 2. 패킷 종류에 따른 형태 TCP 헤더 분석
  • 14. 2-2. TCP Packet with Payload 014 2. 패킷 종류에 따른 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 1500 2 0x794e (31054) 0x02 0 3 54 TCP (6) 0xb0ad 4 108.162.206.211 5 192.168.25.2 6 No Options 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 http (80) 56222 2 954841 (Relative) 3 906 (Relative) 4 20 000 0 0 0 0 1 0 0 0 0 17 5 0x414b Urgent not set 6 No Options 7
  • 15. 015 2. 패킷 종류에 따른 형태 전체 패킷의 hex 코드 Ethernet 프레임의 기본 정보 2-2. TCP Packet with Payload
  • 16. 016 2. 패킷 종류에 따른 형태 Ethernet 헤더 분석 -수신자의 Mac 주소 : bc:5f:f4:21:a8:d4 -송신자의 Mac 주소 : 00:01:36:eb:36:80 -상위 프로토콜의 Type : 0x0800 (IP를 의미) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800 2-2. TCP Packet with Payload
  • 17. 017 2. 패킷 종류에 따른 형태 IP 헤더 분석 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 1500 2 0x794e (31054) 0x02 0 3 54 TCP (6) 0xb0ad 4 108.162.206.211 5 192.168.25.2 2-2. TCP Packet with Payload
  • 18. 018 2. 패킷 종류에 따른 형태 IP 헤더 분석 -IP 프로토콜의 버전 : 4 -IP 헤더의 길이 : 20bytes (header option 없음) -Type of Service : 0x00 (default) - 우선순위, 지연시간, 처리능력, 신뢰성에 관한 QoS 표기. -전체 IP Datagram의 길이 : 1500 bytes -Datagram 식별 번호 : 0x794e (31054) -단편마다 고유하게 설정하여 datagram 재조립시 사용. -Flags : 0x02 (단편화 일어나지 않음) -Fragment Offset : 0 (단편화가 일어나지 않았음) - 단편화시 단편의 시작 바이트 값을 8로 나누어 저장. -Time To Live : 54 -상위 프로토콜의 종류 : TCP (6) -Header Checksum : 0xb0ad -송신자 주소 : 108.162.206.211 -수신자 주소 : 192.168.25.2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 1500 2 0x794e (31054) 0x02 0 3 54 TCP (6) 0xb0ad 4 108.162.206.211 5 192.168.25.2 2-2. TCP Packet with Payload
  • 19. 019 2. 패킷 종류에 따른 형태 TCP 헤더 분석 -송신자의 포트 번호 : 56222 (56222) -수신자의 포트 번호 : http (80) -Sequence Number : 954841 (relative sequence number) -Acknowledge Number : 906 (relative) -TCP 헤더의 길이 : 20bytes -사용되지 않는 영역 : 00000 -Code bit (제어 패킷 설정) : 0x010 (ACK 패킷) -Window 크기 : 17 -Checksum : 0x414b -Urgent Pointer : 0 -URG 제어 비트가 활성화 된 경우 체크하는 부분 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 http (80) 56222 2 954841 (Relative) 3 906 (Relative) 4 20 000 0 0 0 0 1 0 0 0 0 17 5 0x414b Urgent not set 6 No Options 7 2-2. TCP Packet with Payload
  • 20. 020 2. 패킷 종류에 따른 형태 TCP 헤더 분석 2-2. TCP Packet with Payload
  • 21. 2-3. UDP Packet 021 2. 패킷 종류에 따른 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 bytes 0x00 48 bytes 2 0x43bc (17340) 0x00 0 3 108 UDP (17) 0x5d4c 4 81.233.130.33 5 192.168.25.2 6 No Option 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 44682 29279 2 28 0xe96d
  • 22. 022 2. 패킷 종류에 따른 형태 전체 패킷의 hex 코드 Ethernet 프레임의 기본 정보 2-3. UDP Packet
  • 23. 023 2. 패킷 종류에 따른 형태 Ethernet 헤더 분석 -수신자의 Mac 주소 : bc:5f:f4:21:a8:d4 -송신자의 Mac 주소 : 00:01:36:eb:36:80 -상위 프로토콜의 Type : 0x0800 (IP를 의미) 2-3. UDP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800
  • 24. 024 2. 패킷 종류에 따른 형태 IP 헤더 분석 2-3. UDP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 bytes 0x00 48 bytes 2 0x43bc (17340) 0x00 0 3 108 UDP (17) 0x5d4c 4 81.233.130.33 5 192.168.25.2
  • 25. 025 2. 패킷 종류에 따른 형태 IP 헤더 분석 -IP 프로토콜의 버전 : 4 -IP 헤더의 길이 : 20 bytes (header option 없음) -Type of Service : 0x00 (default) - 우선순위, 지연시간, 처리능력, 신뢰성에 관한 QoS 표기. -전체 IP Datagram의 길이 : 48 bytes -Datagram 식별 번호 : 0x43bc (17340) - 단편마다 고유하게 설정하여 datagram 재조립시 사용. -Flags : 0x00 (단편화 일어나지 않음) -Fragment Offset : 0 (단편화가 일어나지 않았음) - 단편화시 단편의 시작 바이트 값을 8로 나누어 저장. -Time To Live : 108 -상위 프로토콜의 종류 : UDP (17) -Header Checksum : 0x5d4c -송신자 주소 : 81.233.130.33 -수신자 주소 : 192.168.25.2 2-3. UDP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 bytes 0x00 48 bytes 2 0x43bc (17340) 0x00 0 3 108 UDP (17) 0x5d4c 4 81.233.130.33 5 192.168.25.2
  • 26. 026 2. 패킷 종류에 따른 형태 UDP 헤더 분석 -송신자의 포트 번호 : 44682 (44682) -수신자의 포트 번호 : http (80) -Segment 길이 : 28 bytes -Checksum : 0xe96d 2-3. UDP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 44682 29279 2 28 0xe96d
  • 27. 2-4. Error reporting ICMP Packet 027 2. 패킷 종류에 따른 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 IP (0x0800) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 123 2 0xdbb4 (56244) 0x00 0 3 44 ICMP (1) 0x0cd1 4 41.136.162.10 5 192.168.25.2 6 No Options 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 3 3 0xa296 2 Zero padding
  • 28. 028 2. 패킷 종류에 따른 형태 전체 패킷의 hex 코드 Ethernet 프레임의 기본 정보 2-4. Error reporting ICMP Packet
  • 29. 029 2. 패킷 종류에 따른 형태 Ethernet 헤더 분석 -수신자의 Mac 주소 : bc:5f:f4:21:a8:d4 -송신자의 Mac 주소 : 00:01:36:eb:36:80 -상위 프로토콜의 Type : 0x0800 (IP를 의미) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800 2-4. Error reporting ICMP Packet
  • 30. 030 2. 패킷 종류에 따른 형태 IP 헤더 분석 2-4. Error reporting ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 123 2 0xdbb4 (56244) 0x00 0 3 44 ICMP (1) 0x0cd1 4 41.136.162.10 5 192.168.25.2
  • 31. 031 2. 패킷 종류에 따른 형태 IP 헤더 분석 -IP 프로토콜의 버전 : 4 -IP 헤더의 길이 : 20bytes (header option 없음) -Type of Service : 0x00 (default) - 우선순위, 지연시간, 처리능력, 신뢰성에 관한 QoS 표기. -전체 IP Datagram의 길이 : 123 bytes -Datagram 식별 번호 : 0xdbb4 (56244) - 단편마다 고유하게 설정하여 datagram 재조립시 사용. -Flags : 0x00 (단편화 일어나지 않음) -Fragment Offset : 0 (단편화가 일어나지 않았음) - 단편화시 단편의 시작 바이트 값을 8로 나누어 저장. -Time To Live : 44 -상위 프로토콜의 종류 : ICMP (1) -Header Checksum : 0x0cd1 -송신자 주소 : 41.136.162.10 -수신자 주소 : 192.168.25.2 2-4. Error reporting ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 123 2 0xdbb4 (56244) 0x00 0 3 44 ICMP (1) 0x0cd1 4 41.136.162.10 5 192.168.25.2
  • 32. 032 2. 패킷 종류에 따른 형태 UDP 헤더 분석 -에러 타입 : 3 (목적지 도달 불가) -에러 코드 : 3 (포트 도달 불가) -Checksum : 0xa296 2-4. Error reporting ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 3 3 0xa296 2 Zero padding
  • 33. 2-5. Echo Request ICMP Packet 033 2. 패킷 종류에 따른 형태 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 00:01:36:eb:36:80 bc:5f:f4:21:a8:d4 IP (0x0800) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 60 2 0x3dc4 0x00 0 3 128 ICMP (1) 0x0000 4 192.168.25.2 5 173.194.38.81 6 No Option 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 8 0 0x4d1c 2 Identifier (Little Endian) = 0x0100 Sequence number (Little Endian) = 0x3f00
  • 34. 034 2. 패킷 종류에 따른 형태 전체 패킷의 hex 코드 Ethernet 프레임의 기본 정보 2-5. Echo Request ICMP Packet
  • 35. 035 2. 패킷 종류에 따른 형태 Ethernet 헤더 분석 -수신자의 Mac 주소 : bc:5f:f4:21:a8:d4 -송신자의 Mac 주소 : 00:01:36:eb:36:80 -상위 프로토콜의 Type : 0x0800 (IP를 의미) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 bc:5f:f4:21:a8:d4 2 00:01:36:eb:36:80 3 4 0x0800 2-5. Echo Request ICMP Packet
  • 36. 036 2. 패킷 종류에 따른 형태 IP 헤더 분석 2-5. Echo Request ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 60 2 0x3dc4 0x00 0 3 128 ICMP (1) 0x0000 4 192.168.25.2 5 173.194.38.81 6 No Option
  • 37. 037 2. 패킷 종류에 따른 형태 IP 헤더 분석 -IP 프로토콜의 버전 : 4 -IP 헤더의 길이 : 20bytes (header option 없음) -Type of Service : 0x00 (default) - 우선순위, 지연시간, 처리능력, 신뢰성에 관한 QoS 표기. -전체 IP Datagram의 길이 : 60bytes -Datagram 식별 번호 : 0x3dc4 - 단편마다 고유하게 설정하여 datagram 재조립시 사용. -Flags : 0x00 (단편화 일어나지 않음) -Fragment Offset : 0 (단편화가 일어나지 않았음) - 단편화시 단편의 시작 바이트 값을 8로 나누어 저장. -Time To Live : 128 -상위 프로토콜의 종류 : ICMP (1) -Header Checksum : 0x0000 -송신자 주소 : 192.168.25.2 -수신자 주소 : 173.194.38.81 2-5. Echo Request ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 4 20 0x00 60 2 0x3dc4 0x00 0 3 128 ICMP (1) 0x0000 4 192.168.25.2 5 173.194.38.81 6 No Option
  • 38. 038 2. 패킷 종류에 따른 형태 UDP 헤더 분석 2-5. Echo Request ICMP Packet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 8 0 0x4d1c 2 Identifier (Little Endian) = 0x0100 Sequence number (Little Endian) = 0x3f00 -에러 타입 : 8 (echo 요청) -에러 코드 : 0 -Checksum : 0x4d1c -식별자 (BE) : 1 -식별자 (LE) : 256 -Sequence Num (BE) : 63 -Sequence Num (LE) : 16128
  • 39. 3. TCP Options
  • 40. 3. TCP Options 40 3. TCP Options Maximum Segment Size (MSS) The Maximum Segment Size is used to define the maximum segment that will be used during a connection between two hosts. As such, you should only see this option used during the SYN and SYN/ACK phase of the 3-way-handshake. The MSS TCP Option occupies 4 bytes (32 bits) of length. If you have previously come across the term "MTU" which stands for Maximum Transfer Unit, you will be pleased to know that the MSS helps define the MTU used on the network. If your scratching your head because the MSS and MTU field doesn't make any sense to you, or it is not quite clear, don't worry, the following diagram will help you get the big picture: You can see the Maximum Segment Size consists of the Data segment, while the Maximum Transfer Unit includes the TCP Header, MSS and the IP Header. It would also benefit us to recognise the correct terminology that corresponds to each level of the OSI Model: The TCP Header and Data is called a Segment (Layer 4), while the IP Header and the Segment is called an IP Datagram (Layer 3). Furthermore, regardless of the size the MTU will have, there is an additional 18 bytes overhead placed by the Datalink layer. This overhead includes the Source and Destination MAC Address, the Protocol type, followed by the Frame Check Sequence placed at the end of the frame. This is also the reason why we can only have a maximum MTU of 1500 bytes. Since the maximum size of an Ethernet II frame is 1518 bytes, subtracting 18 bytes (Datalink overhead) leaves us with 1500 bytes to play with.
  • 41. 3. TCP Options 41 TCP usually computes the Maximum Segment Size (MSS) that results in IP Datagrams that match the network MTU. In practice, this means the MSS will have such a value that if we add the IP Header as well, the IP Datagram (IP Header+TCP Header+DATA) would be equal to the network MTU. If the MSS option is omitted by one or both ends of the connection, then the value of 536 bytes will be used. The MSS value of 536 bytes is defined by RFC 1122 and is calculated by taking the default value of an IP Datagram, 576 bytes, minus the standard length of the IP and TCP Header (40 bytes), which gives us 536 bytes. In general, it is very important to use the best possible MSS value for your network because your network performance could be extremely poor if this value is too large or too small. To help you understand why, lets look at a simple example: If you wanted to transfer 1 byte of data through the network, you would need to create a datagram with 40 bytes of overhead, 20 for the IP Header and 20 for the TCP Header. This means that your using 1/41 of your available network bandwidth for data. The rest is nothing but overhead! On the other hand, if the MSS is very large, your IP Datagrams will also be very large, meaning that they will most probably fail to fit into one packet should the MTU be too small. Therefore they will require to be fragmented, increasing the overhead by a factor of 2. 3. TCP Options
  • 42. 3. TCP Options 42 Window Scaling We briefly mentioned Window Scaling in the previous section of the TCP analysis, though you will soon discover that this topic is quite broad and requires a great deal of attention. After gaining a sound understanding of what the Window size flag is used for, Window Scaling is, in essence, an extention to the Window size flag. Because the largest possible value in the Window size flag is only 65,535 bytes (64 kb), it was clear that a larger field was required in order to increase the value to a whopping 1 Gig! Thus, Window Scaling was born. The Window Scaling option can be a maximum of 30 bits in size, which includes the original 16 bit Window size field covered in the previous section. So that's 16 (original window field) + 14 (TCP Options 'Window Scaling') = 30 bits in total. If you're wondering where on earth would someone use such an extremely large Window size, think again. Window Scaling was created for high-latency, high-bandwidth WAN links where a limited Window size can cause severe performance problems. To consolidate all these technological terms and numbers, an example would prove to be beneficial: The above example assumes we are using the maximum Window size of 64 kbs and because the WAN link has very high latency, the packets take some time to arrive to their destination, that is, Host B. Due to the high latency, Host A has stopped transmitting data since there are 64 kbs of data sent and they have not yet been acknowledged. 3. TCP Options
  • 43. 3. TCP Options 43 When the Time = 4, Host B has received the data and sends the long awaited acknowledgement to Host A so it can continue to send data, but the acknowledgement will not arrive until somewhere around Time = 6. So, from Time = 1 up until Time = 6, Host A is sitting and waiting. You can imagine how poor the performance of this transfer would be in this situation. If we were to transfer a 10 Mb file, it would take hours! Let's now consider the same example, using Window Scaling: As you can see, with the use of Window Scaling, the window size has increased to256 kb! Since the value is quite large, which translates to more data during transit, Host B has already received the first few packets, while Host A is still sending the first 256 kb window. On Time = 2, Host B sends an Acknowledgement to Host A, which is still busy sending data. Host A will receive the Acknowledgement before it finishes the 256 kb window and will therefore continue sending data without pause since it will soon receive another Acknowledgement from Host B. Clearly the difference that a large window size has made is evident, increasing the network performance and minimising the ideal time for the sending host. The Window Scale option is defined in RFC 1072, which lets a system advertise 30-bit (16 from the original window + 14 from the TCP Options) Window size values, with a maximum buffer size of 1 GB. This option has been clarified and redefined in RFC 1323, which is the specification that all implementations employ today. Lastly, for those who deal with Cisco routers, it may benefit you to know that you are also able to configure the Window size on Cisco routers running the Cisco IOS v9 and greater. Also, routers with versions 12.2(8)T and above support Window Scaling, which is automatically enabled for Window sizes above 65,535 bytes (64 kb), with a maximum value of 1,073,741,823 bytes (1 GByte)! 3. TCP Options
  • 44. 3. TCP Options 44 Selective Acknowledgments (SACK) TCP has been designed to be a fairly robust protocol though, despite this, it still has several disadvantages, one of which concerns Acknowledgements, which also happens to be the reason Selective Acknowledgement were introduced with RFC 1072. The problem with the good old plain Acknowledgements is that there are no mechanisms for a receiver to state "I'm still waiting for bytes 20 through 25, but have received bytes 30 through 35". And if your wondering whether this is possible, then the answer is 'yes' it is! If segments arrive out of order and there is a hole in the receiver's queue, then using the 'classical' Acknowledgements supported by TCP, can only say "I've received everything up to byte 20". The sender then needs to recognise that something has gone wrong and continue sending from that point onwards (byte 20). As you may have concluded, the above situation is totally unacceptable, so a more robust service had to be created, hence Selective Acknowledgments! Firstly, when a virtual connection is established using the classic 3-way-handshake the hosts must send a "Selective Acknowledgments Permitted" in the TCP Options to indicate that they are able to use SACK's. From this point onwards, the SACK option is sent whenever a selective acknowledgment is required. 3. TCP Options
  • 45. 3. TCP Options 45 For example, if we have a Windows98 client that is waiting for byte 4,268, but the SACK option shows that the Windows98 client has also received bytes 7,080 through 8,486, it is obvious that it is missing bytes 4,268 through 7,079, so the server should only resend the missing 2,810 bytes, rather than restarting the entire transfer at byte number 4,268. Lastly, we should note that the SACK field in the TCP Options uses two 16 bit fields, a total of 32 bits together. The reason there are two fields is because the receiver must be able to specify the range of bytes it has received, just like the example we used. In the case where Window Scaling is also used, these 2 x 16 bit fields can be expanded to two 24 or 32 bit fields. 3. TCP Options
  • 46. 3. TCP Options 46 Timestamps Another aspect of TCP's flow-control and reliability services is the round-trip delivery times that a virtual circuit is experiencing. The round-trip delivery time will accurately determine how long TCP will wait before attempting to retransmit a segment that has not been acknowledged. Because every network has unique latency characteristics, TCP has to understand these characteristics in order to set accurate acknowledgment timer threshold values. LANs typically have very low latency times, and as such TCP can use low values for the acknowledgment timers. If a segment is not acknowledged quickly, a sender can retransmit the questionable data quickly, thus minimizing any lost bandwidth and delay. On the other hand, using a low threshold value on a WAN is sure to cause problems simply because the acknowledgment timers will expire before the data ever reaches the destination. Therefore, in order for TCP to accurately set the timer threshold value for a virtual circuit, it has to measure the round-trip delivery times for various segments. Finally, it has to monitor additional segments throughout the connection's lifetime to keep up with the changes in the network. This is where the Timestamp option comes into the picture. Similarly to the majority of the other TCP Options covered here, the Timestamp option must be sent during the 3-way-handshake in order to enable its use during any subsequent segments. The Timestamp field consists of a Timestamp Echo and Timestamp Reply field, both of which the reply field is always set to zero by the sender and completed by the receiver after which it is sent back to the original sender. Both timestamp fields are 4 bytes long! 3. TCP Options
  • 47. 3. TCP Options 47 Nop The nop TCP Option means "No Option" and is used to separate the different options used within the TCP Option field. The implementation of the nop field depends on the operating system used. For example, if options MSS and SACK are used, Windows XP will usually place two nop's between them, as was indicated in the first picture on this page. Lastly, we should note that the nop option occupies 1 byte. In our example at the beggining of the page, it would occupy 2 bytes since it's used twice. You should also be aware that this field is usually checked by hackers when trying to determine the remote host's operating system. 3. TCP Options
  • 48. Thank you!