Tcpdump의 옵션들


-a : Network & Broadcast 주소들을 이름들로 바꾼다.

-c Number : 제시된 수의 패킷을 받은 후 종료한다.

-d : comile된 packet-matching code를 사람이 읽을 수 있도록 바꾸어 표준 출력으로 출력하고, 종료한다.

-dd : packet-matching code를 C program의 일부로 출력한다.

-ddd : packet-matching code를 숫자로 출력한다.

-e : 출력되는 각각의 행에 대해서 link-level 헤더를 출력한다.

-f : 외부의 internet address를 가급적 심볼로 출력한다(Sun의 yp server와의 사용은 가급적 피하자).

-F file : filter 표현의 입력으로 파일을 받아들인다. 커맨드라인에 주어진 추가의 표현들은 모두 무시된다.

-i device : 어느 인터페이스를 경유하는 패킷들을 잡을지 지정한다. 지저되지 않으면 시스템의 인터페이스 리스트를 뒤져서 가장 낮은 번호를 가진 인터페이스를 선택한다(이 때 loopback은 제외된다).

-l : 표준 출력으로 나가는 데이터들을 line buffering한다. 다른 프로그램에서 tcpdump로부터 데이터를 받고자 할 때, 유용하다.

-n : 모든 주소들을 번역하지 않는다(port,host address 등등)

-N : 호스트 이름을 출력할 때, 도메인을 찍지 않는다.

-O : packet-matching code optimizer를 실행하지 않는다. 이 옵션은 optimizer에 있는 버그를 찾을 때나 쓰인다.

-p : 인터페이스를 promiscuous mode로 두지 않는다.

-q : 프로토콜에 대한 정보를 덜 출력한다. 따라서 출력되는 라인이 좀 더 짧아진다.

-r file : 패킷들을 '-w'옵션으로 만들어진 파일로 부터 읽어 들인다. 파일에 "-" 가 사용되면 표준 입력을 통해서 받아들인다.

-s length: 패킷들로부터 추출하는 샘플을 default값인 68Byte외의 값으로 설정할 때 사용한다(SunOS의 NIT에서는 최소가 96Byte이다). 68Byte는 IP,ICMP, TCP, UDP등에 적절한 값이지만 Name Server나 NFS 패킷들의 경우에는 프로토콜의 정보들을 Truncation할 우려가 있다. 이 옵션을 수정할 때는 신중해야만 한다. 이유는 샘플 사이즈를 크게 잡으면 곧 패킷 하나하나를 처리하는데 시간이 더 걸릴 뿐만아니라 패킷 버퍼의 사이즈도 자연히 작아지게 되어 손실되는 패킷들이 발생할 수 있기 때문이다. 또, 작게 잡으면 그만큼의 정보를 잃게되는 것이다. 따라서 가급적 캡춰하고자 하는 프로토콜의 헤더 사이즈에 가깝게 잡아주어야 한다.

-T type : 조건식에 의해 선택된 패킷들을 명시된 형식으로 표시한다. type에는 다음과 같은 것들이 올 수 있다. rpc(Remote Procedure Call), rtp(Real-Time Applications protocol), rtcp(Real-Time Application control protocal), vat(Visual Audio Tool), wb(distributed White Board)

-S : TCP sequence번호를 상대적인 번호가 아닌 절대적인 번호로 출력한다.

-t : 출력되는 각각의 라인에 시간을 출력하지 않는다.

-tt : 출력되는 각각의 라인에 형식이 없는 시간들을 출력한다.

-v : 좀 더 많은 정보들을 출력한다.

-vv : '-v'보다 좀 더 많은 정보들을 출력한다.

-w : 캡춰한 패킷들을 분석해서 출력하는 대신에 그대로 파일에 저장한다.

-x : 각각의 패킷을 헥사코드로 출력한다.


사용 가능한 Primitive들

  • dst host HOST
    packet의 IP destination 항목이 HOST일때 참이 된다.
  • src host HOST
    packet의 IP source 항목이 HOST일때 참이 된다.
  • host HOST
    IP source, IP destination 항목 중 어느 하나라도 HOST이면 참이다.
  • ether dst ehost
    ethernet destination 주소가 ehost일 때 참이다.
  • ether src ehost
    ethernet source 주소가 ehost일 때 참이다.
  • ether host ehost
    ethernet source, destination 항목들 중 어느 하나라도 ehost이면 참이다.
  • gateway host
    패킷이 host를 게이트웨이로 사용하면 참이다. 이 말의 의미는 ethernet sour ce나 destination 항목은 host이지만, IP source와 destination은 host가 아닐 때를 말한다.
  • dst net NET
    패킷의 IP destination 주소가 NET의 network number를 가지고 있을 때 참이 다.
  • src net NET
    패킷의 IP source 주소가 NET의 network number를 가지고 있을 때 참이다.
  • net NET
    패킷의 IP source 주소 혹은 destination 주소가 NET의 network number를 가 지고 있을 때 참이다.
  • net netmask mask
    IP 어드레스가 지정된 netmask를 통해서 net과 매칭되면 참이다.
  • net net/len
    IP 어드레스가 netmask와 len 비트만큼 매치되면 참이다.
  • dst port PORT
    패킷이 ip/tcp, ip/udp 프로토콜의 패킷이고 destination port의 값이 PORT일 때 참이다. port는 /etc/services에 명시된 이름일 수도 있고 그냥 숫자일 수도 있다. 만약 이름이 사용됐다면 port 번호와 프로토콜이 같이 체크될 것이다. 만약 숫자나 불 확실한 이름이 사용됐을 경우에는 port 번호만이 체크될 것이다.
  • src port PORT
    패킷의 source port의 값으로 PORT를 가지면 참이다.
  • port PORT
    패킷의 source, destination port 중에 하나라도 PORT이면 참이다.
  • less length
    패킷이 length보다 짧거나 같으면 참이다.(len <= length)
  • greater length
    패킷이 length보다 짧거나 같으면 참이다.(len >= length)
  • ip proto protocol
    패킷이 지정된 종류의 프로토콜의 ip패킷이면 참이다. Protocol은 icmp, igrp, udp, nd, tcp 중의 하나 혹은 몇 개가 될 수 있다. 주의할 점은 tcp, udp, icmp들은 '\'로 escape되어야 한다.
  • ehter broadcast
    패킷이 ethernet broadcast 패킷이라면 참이다. ehter는 생략 가능하다.
  • ip broadcast
    패킷이 IP broadcast 패킷이라면 참이다.
  • ether multicast
    패킷이 IP multicast 패킷이라면 참이다.
  • ether proto protocol
    패킷이 ether type의 protocol이라면 참이다. protocol은 ip, arp, rarp 중에 하나 혹은 몇개가 될 수 있다. ip proto protocol에서와 마찬가지로 ip, arp, rarp는 escape 되어야 한다.
  • decnet src host
    만약 DECNET의 source address가 host이면 참이다. 이 어드레스는 '10.123'이 나 DECNET의 host name일 수 있다. DECNET host name은 DECNET에서 돌아가도록 설정된 Ultrix 시스템에서만 사용 가능하다.
  • decnet dst host
    DECNET destination address가 host이면 참이다.
  • decnet host HOST
    DECNET source, destination address중의 하나라도 HOST이면 참이다.
  • ip, arp, rarp, decnet
    ether proto [ip|arp|rarp|decnet]의 약어
  • lat, moprc, mopdl
    ether proto [lat|moprc|mopdl]의 약어
  • tcp, udp, icmp
    ip proto [tcp|udp|icmp]의 약어
  • expr relop expr
    • EXPR
      proto [expr:size]의 형식을 띤다. proto, expr, size에 올 수 있는 것들은 다음과 같다.
      • proto : ether, fddi, ip, arp, rarp, tcp, udp, icmp
      • expr : indicate Byte offset of packet of proto
      • size : optional. indicate the size of bytes in field of interest
      • default is one, and can be two or four
    • RELOP
      !=, =, <=, >=, etc.

    이 조건식을 사용하기 위해서는 먼저 해당하는 Protocol(proto)의 헤더에 관련된 것들을 자세히 알아야만 한다. proto에는 대상이 될 프로토콜을 지정한다. expr에는 프로토콜 헤더의 처음부터의 Byte Offset을 지정하는 식이 들어가게 된다. Size는 Option이며 지정이 안 되어 있을 경우에는 자동으로 1byte를 지칭한다. 따라서 이 조건식을 사용하게 되면 헤더에 포함된 정보를 Bitmask를 사용하여 직 접 원하는 패킷인지를 가려낼 수 있기 때문에, 보다 정밀한 사용이 가능하게 된다.


Tcpdump의 사용 예제들

security라는 호스트로부터 날아오고, 날아가는 패킷들을 출력
# tcpdump host security

security와 mazinga, getarobo 사이에 날아다니고 있는 패킷들을 출력
# tcpdump host security and \( mazinga or getarobo \)

security에서 elgaim을 제외한 모든 호스트로 날아다니는 IP 패킷들을 출력
# tcpdump ip host security and not elgaim

gateway amurorei를 거치는 ftp에 관련된 패킷들을 출력
# tcpdump 'gateway amurorei and ( port ftp or ftp-data )'

local호스트가 아닌 호스트와 로컬호스트가 맺는 TCP 커넥션의 시작과 마지막 패 킷들을 출력한다(SYN, FIN 패킷).
# tcpdump 'tcp[13] & 3 != 0 and not src and dst net non-local'

gateway amurorei를 지나는 576Byte보다 큰 패킷들을 출력한다
# tcpdump 'gateway amurorei and ip[2:2] > 576'

Ethernet boradcast 혹은 multicast를 통해서 보내진 것이 아닌, IP broadcast 혹 은 multicast 패킷들을 출력한다.
# tcpdump 'ehter[0] & 1 = 0 and ip[16] >= 224'

Echo request/reply가 아닌 ICMP 패킷들을 모두 출력한다.
# tcpdump 'icmp[0] != 8 and icmp[0] != 0'



참고 : http://coffeenix.net/doc/misc/tcpdump.html


'Dev > Network' 카테고리의 다른 글

TCP Connection Establishment Procedure & Connection Termination Procedure  (0) 2012.03.30
SSL Protocol  (0) 2007.09.08
network protocol  (0) 2007.07.23


1) TCP “Three-Way Handshake” Connection Establishment Procedure



2) TCP Connection Termination Procedure



'Dev > Network' 카테고리의 다른 글

tcpdump 옵션  (0) 2013.04.08
SSL Protocol  (0) 2007.09.08
network protocol  (0) 2007.07.23

출처 : http://blog.naver.com/arternis74/150016954638



SSL Protocol


웹을 이용한 전자 상거래, 인터넷 뱅킹 등이 더욱더 증대되면서 이제 인터넷은 정보의 바다가 아니라 하나의 커다란 시장이라 부를 수도 있는 상황이다. 온라인 입금이나 최근에는 소액의 경우 휴대폰 결재를 선택하기도 하지만 뭐니뭐니 해도 국내 인터넷 쇼핑 이용자들이 가장 선호하는 수단은 신용 카드다. 그런데 바로 이점이 보안적인 허점을 가져오는 주 원인이 될 수 있다.


실제로 신용카드로 결제하는 경우 인터넷이라는 공용망을 타고 서버에 전송되는 고객의 신용카드 정보는 신용카드 번호, 유효기간 등을 포함하고 있기 때문에 실제 전자 상거래 시 필요한 대부분의 데이터가 언제 어떻게 도용될지도 모르는 위험에 노출되어 있는 것이다. 그렇다면 개인의 금융정보를 공용망인 인터넷상에서 보호할 것인가?


이 질문에 대한 답으로 현재 가장 많이 사용되는 방법이 SSL(Secure Socket Layer)이다.


1. SSL(Secure Socket Layer) 개념


SSL은 Netsape에서 개발된 프로토콜로서 1995년 히크만(Hickman)에 의해서 개발되었으며 현재 인터넷 사용자들에게 안전한 개인 정보를 교환하기 위한 사실상의 표준 프로토콜로 인정되어 많은 온라인 상거래에 사용되고 있다. SSL은 실제로 다양한 장점을 지닌 암호화 기법들을 사용해 세계 각국에서 사용되는 대부분의 암호화 기법들을 지원할 수 있다.


SSL은 버전 3.0 이후 IETF(Internet Engineering Task Force)에서 표준화되어 TLS(Transport Layer Security)로 명명되었지만 실제 그 내용은 SSL 3.과 TLSv1.0이 같으며 MS Explorer나 Netscape 등 대부분의 브라우저에서 지원하고 있다. SSL 프로토콜에서 사용되어질 수 있는 다양한 애플리케이션 프로토콜이 있지만 주로 사용되는 부분은 WEB(HTTP)이라고 볼 수 있다.


SSL 은 크게 3가지 기능들을 제공함으로 공개되어 있는 인터넷상에서 일어나는 트랜잭션의 기밀성(Privacy)을 보장한다.


○ Site Authentication

User가 선택한 상대편 Web Site를 인증한다는 의미다. 우리가 인터넷 뱅킹이나 인터넷 쇼핑몰을 사용할 때 상대편이 실제 신뢰할 수 있는 은행이나 쇼핑몰의 웹서버 인지를 인증한다는 것으로, 상대 사이트에 대한 신뢰성 있는 인증이 없다면 우리는 불확실한 누군가에게 우리의 금융정보를 넘기는 위험에 처하게 된다.


○ Data Privacy(기밀성)

전달되는 데이터가 도중에 누군가에 의해 판돈되지 않는 다는 것을 보장한다. SSL은 다양한 암호화 알고리즘을 사용하여 인터넷을 통해 전송되는 개인의 사적인 정보를 외부로부터 불법적인 판독을 막는다.


○ Data Integrity(무결성)

사용자의 브라우저로부터 상대방 웹서버까지 전달되는 동안 데이터가 도중에 누군가에 의해 변경되지 않도록 보장한다.


SSL은 위와 같은 요소들을 보장하여 보다 안전한 커뮤니케이션을 할 수 있도록 도와주며 또한 MS 익스플로러나 넷스케이프 등과 같이 널리 보급된 대부분의 웹브라우저와 웹서버들에서 지원된다. 웹브라우저가 SSL 통신을 하는지 여부는 브라우저 오른쪽 하단의 잠금쇠 표시를 가지고 판별할 수 있는데 경우에 따라서는 브라우저 대신에 다른 보안 애플리케이션이 대신하기도 한다.


HTTPS 는 SSL상에서 HTTP 를 구현한 형태로 실제 HTTP 가 기본 포트 80 을 사용하는 대신 HTTPS 는 433 포트를 사용한다.


SSL은 다양한 어플리케이션들을 지원하기 위해 각각의 응용된 어플리케이션 프로토콜을 가지고 있는데, 이는 SSL의 구조를 보면 이해하기 쉽다. SSL은 OSI 7 계층에서 5 계층인 Session Layer에 속하며, 지원 가능한 프로토콜은 어플리케이션 레이어 상에 위한 하부 프로토콜로 한정될 수 밖에 없는데 HTTP, IMAP, FTP, NNTP 등이다.


2. SSL 동작 원리



SSL이 수행되는 단계는 총 3가지로 분류된다.


○ SSL Server Authentication

사용자의 웹브라우저가 상대방의 웹서버를 인증하는 단계이다.

SSL을 지원하는 웹브라우저는 표준 공용키 암호화 기법을 사용하여 서버의 인증서와 공용 ID를 실제로 브라우져가 신뢰하는 인증기관(Trusted CA)으로부터 발급받았는지 여부를 인증하는 기능을 내장하고 있다.


○ SSL Client Authentication

웹서버가 자신에게 요청한 클라이언트를 인증하는 단계이다.

서버 인증 시에 사용했던 동일한 기법으로 인증하는데 서버에 내장된 SSL 지원 소프트웨어나 서버 앞에 배치된 SSL 하드웨어는 클라이언트의 인증서와 공용 ID 를 실제로 서버가 신뢰하는 인증기관(Trusted CA)으로부터 발급 받았는지 여부를 인증하는 기능을 내장하고 있다.


○ Encrypt Connection

서로에 대한 인증단계 이후 정상적으로 종결되면 클라이언트와 서버사이에 교환되는 모든 데이터는 사적인 내용을 보호하기 위한 암호화를 요구받는다. 또한 SSL커넥션을 통해 암호화된 데이터 역시 전송 중 변경을 방지(Message Integrity)하기 위해 Hash 알고리즘이라고 불리는 기술에 의해 보호된다.


위의 3가지 단계를 기반으로 실제로 구현되는 순서는 다음과 같으며, 다음 순서를 진행하기에 앞서 SSL 또한 TCP 프로토콜에 기반을 두고 있으므로 반드시 TCP 3 Handshake는 이루어져 있어만 한다.


A. 클라이언트는 서버에게 Client Hello Message를 전송


일반적으로 브라우저를 통해 서버에게 SSL 연결 요청을 하기 위한 초기 단계이다.


B. 서버는 클라이언트로 Server Hello Message와 서버 인증서를 전송하며, 만약 클라이언트 인증서가 필요한 경우에 인증서 요청도 함께 전송


서버는 클라이언트가 자신이 적합한 서버인지를 인증할 수 있도록 공신력 있는 기관으로부터 발급받은 자신의 공인 인증서를 발송한다. 이때 일반적으로 서버 인증서와 함께 서버의 공용키가 클라이언트측에 전달된다. 만약 클라이언트에 대한 인증을 필요로 하는 트랜잭션이라면 이에 대한 요청도 함께 발송한다.


C. 클라이언트는 암호화에 사용되는 세션 키와 함께 클라이언트에서 지원하는 Cipher Suite를 서버로 전송하며, 서버가 인증서를 요청한 경우에는 클라이언트의 인증서도 함께 전송


서버의 인증서에 대해 클라이언트는 브라우저내에 저장되어 있는 신뢰기관으로부터의 발급여부를 확인하고 암호화에 사용될 Session Key를 생성해 서버 공용키로 Session Key를 암호화 하여 서버에게 전달한다. 또한 암호화된 Session Key와 함께 브라우저가 지원할 수 있는 Chiper Suite, 즉 암호화 기법 리스트와 함께 서버측에서 클라이언트의 인증서를 요청한 경우 스스로의 인증서를 발송한다.


D. 서버는 Chiper Suite를 받아들이고(또는 거부하고) Finished message를 클라이언트로 전송한 후 데이터 전송단계로 이동


서버는 클라이언트로부터 클라이언트 브라우저가 지원하는 암호화 기법 리스트를 받고 클라이언트에게 종결 메시지를 보내고 데이터 전송단계로 돌입한다. 여기까지 정상적으로 완료가 되면 클라이언트가 생성한 Session Key를 클라이언트와 서버가 모두 공유하게 된다.


E. 클라이언트는 최종메시지를 서버로 전송하고 데이터 전송단계로 이동


위 단계까지 정상적으로 완료되면 클라이언트는 종결 메시지를 서버에 보내고 실제 데이터를 전송하기 위한 단계로 돌입한다.


F. 상호 합의한 사이퍼 수트에 의해서 암호화된 메시지를 교환


앞 단계에서 서로 나누어 가진 Session Key로 암호화 된 데이터를 교환하게 된다.


3. SSL 암호화


SSL이 수행되는 단계에 보면 Session Key라는 것이 등장한다. Session Key는 한마디로 클라이언트 측에서 생성하여 서버로 전달된 하나의 키로, 하나의 동일한 키를 클라이언트와 서버가 각각 보관함으로 이후 전달되는 암호화된 데이터를 복호화 할 수 있도록 한다. 이 Session Key의 생성 및 전달 과정에 대한 보다 깊은 이해는 사실상 암호화 기법에 대한 이해를 그 바탕으로 한다.


이번에는 주로 SSL에 대한 개략적인 부분만 다루고 있기 때문에 암호화에 대한 부분은 간단하게만 살펴보도록 하겠다.


SSL 수행단계에서 교환되는 Session Key는 비밀키 암호화(Secret key cryptography). 즉, 대칭적 암호화에서 사용되는 키로서 하나의 키를 양쪽 상대방이 각기 나누어 가짐으로써 하나의 키로 암호화한 데이터를 송신측에서 전송하면 수신측에서 암호화 시 사용한 동일한 키로 복호화하는 단순한 구조를 가진다.


비밀키 암호화 기법은 그 사용이 간단하고 속도가 빠른 반면 크게 두 가지 문제를 가지고 있다.

첫번째는 어떻게 동일한 키를 서버와 클라이언트가 서로 공유하여 가질 것인가이며,

두번째는 서버측에서 볼 때 하나의 클라이언트당 각기 다른 세션키가 필요하기 때문에 어떻게 키를 관리할 것인가다.


위와 같은 문제 때문에 등장한 것이 공개키 암호화 즉 비대칭키 암호화 기법이다. 이 암호화 기법은 비밀키와 공개키라고 불리는 각기 다른 키로 구성된 한 쌍의 키를 클라이언트와 서버가 나누어 가지고 비밀키로 암호화된 데이터는 그와 같은 쌍이 공개키로만 복호화되는 알고리즘을 제공하고 있다.  이 암호화 기법은 비밀키 암호화 시 발생하는 키 교환의 문제를 해결해 주었다. 그러나 각기 나누어 갖은 한 쌍의 키를 가진 상대방에 대한 인증에 대한 문제와 암호화/복호화 과정에 많은 부하가 걸리는 단점을 가지고 있다. 따라서 실제로 SSL 수행의 경우 이 두 가지 암호화 기법과 PKI 기반의 디지털 인증서를 사용한 인증을 혼합하여 사용할 수 있다.


먼저 디지털 인증서(Digital Certificate) 교환을 통해 상대방을 인증, 공개키 암호화의 약점을 줄였으며 서버에서 클라이언트로 전달된 서버의 공개키로 클라이언트에서 생성된 세션키를 암호화하여 서버로 전달하는 공개키 암호화 기법을 사용하여 비밀키 암호화의 키 교환 문제를 없앴고 세션키가 전달된 후 세션키를 통해 실제 데이터를 암호화/복호화함으로 공개키 암호화 시 발생하는 부하로 인한 서비스 지연현상을 방지할 수 있다.


참고로 SSL에서 세션키를 통해 암호화하는 암호화 기법으로는 DES, 3DES, RC2, RC4등이 있고 40비트부터 168비트까지 사용된다. 메시지 무결성(Message Integrity) 보장을 위해 사용되는 Hash 알고리즘으로는 MD5나 SHA1.등이 주로 사용 된다.

'Dev > Network' 카테고리의 다른 글

tcpdump 옵션  (0) 2013.04.08
TCP Connection Establishment Procedure & Connection Termination Procedure  (0) 2012.03.30
network protocol  (0) 2007.07.23

IP Header

Octet Bits Len Name Notes
0 0-3 - Version 4 bits. IP version number. Current version is 4.
0 4-7 - Hdr length 4 bits. Length of IP header in 32 bit words (4 octets). Minimum valid is 5 (20 octets).
1 - 1 ToS 1 octet. Type of Service. Rarely used, often misused or abused.
bit 0-2: Precedence
bit 3: Delay 0 = normal 1 = low
bit 4: Throughtput 0 = normal 1 = high
bit 5: Reliability 0 = normal 1 = high
bit 6-7: Reserved
Precedence
111 Network Control
110 Internetwork Control
101 CRITIC/ECP
100 Flash override
011 Flash
010 Immediate
001 Priority
000 Routine
When used with Explicit Congestion Notification (ECN) (RFC 3168) may take values defined here and here.
2-3 - 2 Total Length 2 Octets. Total length in octets of this packet starting from octet 0 of this header.
4-5 - 2 Identification 2 Octets. Sequence number used when fragmenting IP packets for a given media type.
6 0-3 - Flags 3 bits. Usage
bit 0 - not used = 0
bit 1 (DF) = 1 do not fragment
bit 2 (MF) = 1 more fragments to come
6-7 4-15 - Version 13 bits. Fragment start offset measured in 8 octet (64 bit) units. First fragment is zero.
8 - 1 TTL 1 octet. Time to Live. See notes.
9 - 1 Protocol 1 octet. Protocol. Some common values:
0 (0x00) IPv6 Hop-by-Hop Option
1 (0x01) ICMP protocol
2 (0x02) IGMP protocol
4 (0x04) IP over IP
6 (0x06) TCP protocol
17 (0x11) UDP protocol
41 (0x29) IPv6 protocol
Definitive list is here
10-11 - 1 Checksum 2 octets. See RFCs 1141 & 1624. Covers IP header ONLY.
12-15 - 4 Source 4 octets. Source IP address.
16-19 - 4 Destination 4 octets. Destination IP address.
20+ - ? IP Options Optional. If present must be padded to 32 bit multiples. Definitive list of options is here.
Notes:
  1. Time to Live originally involved a sense of time. It is now used as a simple, but very effective, count to prevent routing errors and loops. Every router that handles the packet decrements the TTL value and if it reaches zero the packet is returned with a ICMP Time Exceeded message. A trace route comand (tracert) is usually a series of ping commands with increasing values of the TTL parameter such that the packet will be returned from each successive router. Called a hop limit in IPv6 to clarify its use.


 

ICMP Header

Internet Control Message Protocol (ICMP) is used to perform many network 'housekeeping' tasks. Each ICMP message has a slightly different format but the first 4 bytes are ALWAYS the same.

Octet Len Name Notes
0 1 ICMP Type ICMP Message Type
0 = echo reply(ping)
3 = destination unreachable
4 = source quench
5 = redirect (route change)
8 = echo request(ping)
11 = time exceeded
12 = Parameter problem
13 = timestamp request
14 = timestamp reply
17 = address mask request
18 = address mask reply
1 1 Code Code values are message specific.
2-3 2 Checksum -

Notes:

  1. Checksum is IP one's complement standard (RFCs 1141 and 1624).

ICMP Echo Request/Response (Ping)

In a ping operation the entire packet is echo'd (or pinged as in ping-pong) back to the sender. A trace route comand (tracert) is usually a series of ping commands with increasing values of the TTL parameter (in IP header) such that it will be returned from each successive router.

Octet Len Name Notes
0 1 ICMP Type Message Type
8 = Echo request
0 = echo reply
1 1 Code Code = 0
2-3 2 Checksum -
4-5 2 Identifier Used by sender to identify operation.
6-7 2 Sequence Used by sender to identify operation.
8+ ? Data Optional Data field.

ICMP Unreachable

The code field specifies the type of error.

Octet Len Name Notes
0 1 ICMP Type Message Type
1 = Host unreachable
1 1 Code 0 = Network unreachable
1 = Host unreachable
2 = Protocol unreachable
3 = Port unreachable
4 = Frag needed but DF set
5 = Source route failed
6 = Destination network unknown
7 = Destination host unknown
8 = Source host isolated
9 = Network access prohibited
10 = Host access prohibited
11 = Network unreachable for ToS
12 = Host unreachable for ToS
2-3 2 Checksum -
4-5 2 Not used Must be zero
6-7 2 Not used Must be zero
8+ ? User Packet IP header plus first 64 bits (8 octets) of failing datagram.

ICMP Source Quench

Great idea but most implementations seem to ignore this polite request to stop sending so much data.

Octet Len Name Notes
0 1 ICMP Type Message Type
4 = Source Quench
1 1 Code Always 0
2-3 2 Checksum -
4-5 2 Not used Must be zero
6-7 2 Not used Must be zero
8+ ? User Packet IP header plus first 64 bits (8 octets) of last datagram.

ICMP Redirect

Indicates the host should use the specified gateway to reach the IP address contained in the returned message.

Octet Len Name Notes
0 1 ICMP Type Message Type
5 = ICMP redirect
1 1 Code May take one of the following values 0 = redirect datagrams for net (obsolete)
1 = redirect datagrams for host
2 = redirect datagrams for ToS and net
3 = redirect datagrams for Tos and host
2-3 2 Checksum -
4-7 4 Gateway IP Specifies that, for the destination host in the returned datagram, this gateway should be used.
8+ ? User Packet IP header plus first 64 bits (8 octets) of failing datagram.

ICMP Time Exceeded

Message returned by the discovering router when the TTL count reaches 0 in the IP header or timeout problem with fragmentation.

Octet Len Name Notes
0 1 ICMP Type Message Type
11 = ICMP Time Exceeded
1 1 Code May take one of the following values 0 = Time to Live count = 0 (exceeded)
1 = fragment reassembly time exceeded
2-3 2 Checksum -
4-7 4 Unused must be zero.
8+ ? User Packet IP header plus first 64 bits (8 octets) of failing datagram.


 

UDP Header

UDP (User Datagram Protocol) is a connectionless protocol and represents a lightweight method of sending and receiving data.

Octet Len Name Notes
0-1 2 Source port -
2-3 2 Destination Port Reserved (well-known) port numbers are here
4-5 2 UDP Length Length of UDP packet starting from Octet 0.
6-7 2 Checksum Optional. 0 = no checksum. The value 0xFFFFFFFF is a computed checksum of 0. See also UDP pseudo header
Notes
  1. UDP Checksum. If a UDP checksum is present (optional for IPv4, mandatory for IPv6) it is assumed to have a 'psuedo header' field of the following format prepended to the data:
    Octet Len Name Notes
    0-3 4 Source Source IP address
    4-7 4 Destination Destination IP address
    8 1 Zero Always zero
    9 1 Protocol Always 17 for UDP
    10-11 2 Length Length of UDP packet (excluding this psuedo header)

    The UDP checksum is computed by including the above 'pseudo header' plus the total UDP packet including the 'real' UDP header.

  2. Checksum is IP one's complement standard (RFCs 1141 and 1624).


 

TCP Header

TCP (Transmission Control Protocol) is a connection-oriented protocol (it has opens and closes and stuff) and provides secure data transfer (the protocol includes ACKs and stuff). You can get the same level of service using UDP but you have to 'hand-carve' the opening, closing and ACK processes. TCP is incredibly efficient and its windowing mechanism especially provides very fast network performance adaptive feedback.

Octet Bits Len Name Notes
0-1 - 2 Source port -
2-3 - 2 Destination Port -
4-7 - 4 Sequence number position of last octet we sent.
8-11 - 4 Acknowledge Number Next octet number we expect from the peer.
12 0-3 - HLEN 4 bits. The number of 32 bit multiples (4 octets) in the TCP header including any 'options' fields.
12 4-7 - Reserved should be zero
13 - 1 Code bits 8 bits (6 used) valid if 1
bit 0 (URG) Urgent
bit 1 (ACK) Acknowledgement
bit 2 (PSH) Requests PUSH
bit 3 (RST) Reset connection
bit 4 (SYN) Sync sequence numbers
bit 5 (FIN) sender finished
14-15 - 2 Window Specifies the amount of data we can accept.
16-17 - 2 Checksum Standard IP checksum. Includes a TCP pseudo header.
18-19 - 2 Urgent pointer Points to end of urgent data.
TCP Options
TCP data
NOTES:
  1. The TCP checksum is assumed to have a 'psuedo header' field of the following format prepended to the data:
    Octet Len Name Notes
    0-3 4 Source Source IP address
    4-7 4 Destination Destination IP address
    8 1 Zero Always zero
    9 1 Protocol Always 6 for TCP
    10-11 2 Length Length of TCP packet (excluding this psuedo header)

    The TCP checksum is computed by including the above pseudo header plus the total TCP packet including the real TCP header.

  2. Checksum is IP one's complement standard (RFCs 1141 and 1624).

TCP Options

TCP allows a number of options sent with the SYN command. Option list MUST be padded with zeros (end of list option) to a multiple of 32 bits. Options may be one byte or multiple bytes (TLD format) in this case octet 2 is always the length value, octet 3+ contains data.

Currently defined options are (exhaustive list is here):

Octet 0 Type Len Data Name
0 One byte 1 - End of option list
1 One byte 1 - Padding (MAY be used to align data)
2 TLD 4 max segment size Segment size option


 

'Dev > Network' 카테고리의 다른 글

tcpdump 옵션  (0) 2013.04.08
TCP Connection Establishment Procedure & Connection Termination Procedure  (0) 2012.03.30
SSL Protocol  (0) 2007.09.08

+ Recent posts