1. 왜 의사헤더를 추가하나? 1 / 32 UDP 데이터그램이 목적지에 제대로 전송됐는지 확인하기 위해

Presentation on theme: "1. 왜 의사헤더를 추가하나? 1 / 32 UDP 데이터그램이 목적지에 제대로 전송됐는지 확인하기 위해"— Presentation transcript:

1 1. 왜 의사헤더를 추가하나? 1 / 32 UDP 데이터그램이 목적지에 제대로 전송됐는지 확인하기 위해
=> UDP 헤더는 포트번호만 명시하기 때문에 목적지를 검증 하려면 IP 주소가 필요함. 2018년 11월 11일 오전 8시 7분 1 / 32

2 2. 윈도우 기반 흐름제어 2 / 32 Window기반 전송
ACK 프레임을 수신하지 않더라도 여러 개의 프레임을 연속적으로 전송하도록 하여 전송효율을 높이는 방법 호스트들이 각각 2개의 window를 가지고 있음 송신 window : 송신 가능한 프레임 수 수신 window : 수신 가능한 프레임 수 슬라이딩 윈도우에 적용 됨 2018년 11월 11일 오전 8시 7분 2 / 32

3 2. 윈도우 기반 흐름제어 슬라이딩 윈도우 2018년 11월 11일 오전 8시 7분 3 / 32

4 2. 윈도우 기반 흐름제어 Window 광고 수신기가 송신기에게 얼마나 큰 윈도우를 사용할 수 있는지 전달하는 것. Window 광고를 통해 window size 동기화 윈도우 기반 흐름제어 Window 광고를 통해 송신기의 윈도우 크기를 조정하여 전송률을 조절 하게 됨. 2018년 11월 11일 오전 8시 7분 4 / 32

5 13. TCP 연결 관리 김 진 홍

6 contents 개요 TCP 연결 설정과 종료 TCP 옵션 TCP의 경로 MTU 발견 TCP 상태 천이 재설정 세그먼트
정리

7 1. 개요 7 / 32 13장 개요 – TCP 연결 TCP 연결이 무엇인지 TCP 연결이 어떻게 설정되는지
2018년 11월 11일 오전 8시 7분 7 / 32

8 2. TCP 연결 설정과 종료 8 / 32 TCP 연결 설정과 종료 3 way handshake 4 way handshake
2018년 11월 11일 오전 8시 7분 8 / 32

9 2. TCP 연결 설정과 종료 - 계속 9 / 32 TCP 절반 폐쇄
소켓 API에서 응용이 close를 호출하지 않고 shutdown을 호출하여 절반 폐쇄를 수행할 수 있음. 일반적인 응용에서의 종료는 close를 이용하여 양방향 종료를 수행 함. 클라이언트 서버 응용 shutdown 응용에 EOF 전달 응용에 close 응용에 read 응용에 write FIN의 ack FIN 데이터 데이터 ack 2018년 11월 11일 오전 8시 7분 9 / 32

10 2. TCP 연결 설정과 종료 - 계속 동시 개방 각 종단은 SYN을 전송하고 2개의 SYN이 네트워크를 통해 상대방에 전송 각 종단은 상대편 종단에 대해서 잘 알려진 로컬 포트 번호를 갖음. 능동적개방 SYN_SENT SYN_RCVD SYN J SYN K ESTABLISHED SYN J, ack K+1 SYN K, ack J +1 동시 개방에 따른 세그먼트 교환 2018년 11월 11일 오전 8시 7분 10 / 32

11 2. TCP 연결 설정과 종료 - 계속 11 / 32 동시 폐쇄 양쪽 종단으로부터 능동적 종료를 수행
동시폐쇄는 일반적인 종료와 같은 수의 세그먼트 교환 능동적종료 FIN_WAIT_1 CLOSING FIN J FIN K TIME_WAIT ack K+1 ack J +1 동시 종료 중의 세그먼트 교환 2018년 11월 11일 오전 8시 7분 11 / 32

12 2. TCP 연결 설정과 종료 - 계속 12 / 32 초기 순서 번호 SYN을 전송하기 전에 연결을 위한 ISN을 선택 함.
2018년 11월 11일 오전 8시 7분 12 / 32

13 2. TCP 연결 설정과 종료 - 계속 예제 2018년 11월 11일 오전 8시 7분 13 / 32

14 2. TCP 연결 설정과 종료 - 계속 14 / 32 연결 설정의 타임아웃 지수형 백오프 재시도 횟수
1초 -> 2초 -> 4초 -> 8초 -> 16초 -> 32초 각 백오프가 이전 백오프의 2배 재시도 횟수 2018년 11월 11일 오전 8시 7분 14 / 32

15 3. TCP 옵션 15 / 32 종류 길이 이름 참고 설명 32 bits 1 EOL RFC0793 옵션 목록의 끝 NOP 2
1 EOL RFC0793 옵션 목록의 끝 NOP 동작 없음(padding에 사용) 2 4 MSS 최대 세그먼트 크기 3 WSOPT RFC1323 윈도우 스케일링 팩터 SACK-허용 RFC2018 전송기가 SACK 지원 5 가변 SACK SACK 블록 8 10 TSOPT 타임스탬프 옵션 28 UTO RFC5482 유저 타임아웃 29 TCP-AO RFC5925 인증 옵션(기타알고리즘) 253 실험적 RFC4727 실험적 사용을 위한 유보 254 Kind=2 Len=4 MSS Kind=1 Kind=3 Len=3 Shift count kind=8 Len=10 Timestamp value Timestamp echo reply 32 bits Kind=0 Window Scale Option 이란? : TCP 윈도우 크기는 기본적으로 16비트 변수를 이용하기 때문에 65535바이트 이상으로 커질 수 없다. 이는 요즘 같은 시대에는 상당히 작은 값이다. 그래서 헤더에 있는 16비트 윈도우 크기는 무시하고, 따로 32비트의 윈도우 크기를 사용하는 기능을 window scale option이라고 한다. 32비트 변수를 어디다 두는지는 잘 모르겠지만, 아마 데이터 부분에다 두겠지. 어쨌든 이 옵션을 켜고, 송수신 측이 서로 SYN을 주고받으면, 좀 더 큰 크기의 윈도우를 사용할 수 있게 된다." 2018년 11월 11일 오전 8시 7분 15 / 32

16 4. TCP의 경로 MTU 발견 16 / 32 경로 MTU 호스트 사이 경로에 있는 네트워크 세그먼트의 최소 MTU
PMTUD(Path MTU Discovery) TCP가 연결이 설정되면 자신의 송신 최대 세그먼트 크기를 선택. 연결이 설정되면 각 종단은 MSS를 통지 송신 인터페이스의 minimum MTU나 수신된 MSS를 사용 2018년 11월 11일 오전 8시 7분 16 / 32

17 4. TCP의 경로 MTU 발견 - 계속 17 / 32 PMTUD 사용을 보여주기 위해 MTU를 288byte로 설정
(교재 참고) Client Server GW 모뎀 인터넷 eth0: eth0: MTU=1492 => 288 2018년 11월 11일 오전 8시 7분 17 / 32

18 5. TCP 상태 천이 정상적인 server 정상적인 client 18 / 32

19 5. TCP 상태 천이 - 계속 19 / 32 일반적인 연결 확립과 종료에 대한 TCP 상태
2018년 11월 11일 오전 8시 7분 19 / 32

20 5. TCP 상태 천이 - 계속 20 / 32 TIME_WAIT 상태
2MSL(Maximum Segment Lifetime) 대기 상태 TCP가 ACK를 잃어버린 경우에 ACK 재전송 하기 위해서 2MSL 대기 상태에 있는 동안, socket pair 재사용 X TCP가 능동적 폐쇄를 수행하고 마지막 ACK를 전송하면 이 연결은 MSL의 2배동안 TIME_WAIT 상태에서 대기해야함. 마지막 ACK가 손실 되는 경우 TCP가 마지막 ACK를 재전송 하게 한다. 수동 폐쇄쪽에서는 마지막 ACK를 수신 할때까지 FIN을 전송함. 2018년 11월 11일 오전 8시 7분 20 / 32

21 5. TCP 상태 천이 - 계속 21 / 32 FIN_WAIT_2 상태 폐쇄가 FIN을 보내는 것부터 시작 됨.
net.ipv4.tcp_fin_timeout 타이머를 설정하여 타이머 종료 후 강제로 CLOSED 상태로 이동 시킴. 2018년 11월 11일 오전 8시 7분 21 / 32

22 6. 재설정 세그먼트 재설정 세그먼트 TCP헤더의 RST 비트필드가 on으로 설정된 세그먼트를 재설정 세그먼트라고 함. 일반적으로 정확하지 않은 세그먼트가 도착할 때 TCP에 의해 보내짐. 2018년 11월 11일 오전 8시 7분 22 / 32

23 6. 재설정 세그먼트 - 계속 23 / 32 존재하지 않는 포트에 대한 연결 요구
연결 요구가 도착할 때 목적지 포트상에 프로세스가 대기하지 않을 때 RST 전송 telnet 2018년 11월 11일 오전 8시 7분 23 / 32

24 6. 재설정 세그먼트 - 계속 24 / 32 연결 중단 일반적인 종료 : 큐의 데이터를 모두 전송 한 후 FIN 전송
연결 중단 : 데이터를 폐기하고 FIN대신 RST를 보내 종료. e.g. ftp를 통해 파일 리스트를 불러오는 중 ^C로 중단시킴. 2018년 11월 11일 오전 8시 7분 24 / 32

25 7. TCP 서버 동작 25 / 32 수신 연결 큐와 TCP 연결 애플리케이션은 커널로 부터 전체 연결의 수를 제한 받음.
SYN이 도착하면 net.ipv4.tcp_max_syn_backlog가 검사됨. backlog가 초과되면 SYN_RCVD 상태에서 연결이 거절됨. 각 종단은 TCP에 의해 연결이 됐으나 애플리케이션 계층에서는 연결되지는 않은 고정 길이 큐를 가짐.(backlog) Backlog는 0과 net.core.somaxconn에 정의된 최대값 사이 값을 가짐 연결에 대한 큐에 공간이 있다면 SYN/ACK를 보냄. ACK가 수신되고 새로운 연결이 성립 된다면 애플리케이션에게 연결 성립이 전달됨 서버가 연결성립을 인식하여 데이터를 수신 할 준비가 되지 않은 상태에 데이터가 들어온다면 TCP는 데이터를 큐에 넣음. 새로운 연결을 위한 큐의 공간이 없으면 TCP는 수신된 SYN을 무시함. 아무것도 되돌려 보내지 않으며, 클라이언트는 결국 타임아웃 됨. 2018년 11월 11일 오전 8시 7분 25 / 32

26 7. TCP 서버 동작 - 계속 26 / 32 수신 연결 큐와 TCP 연결
sock –s –v –q1 -O (-s : 서버, -v : verbose, -q1 : backlog 큐를 1로, -O30000 : 첫 번째 클라이언트를 받아들이기 전에 30000초 대기, 6666 : 포트번호) Syn 을 받고 synack을 재전송. 2018년 11월 11일 오전 8시 7분 26 / 32

27 8. TCP 연결 관리를 포함하는 공격 27 / 32 공격1 : SYN flood
한 대 이상의 클라이언트가 spoofed ip 주소를 가지고 TCP 연결시도를 연속으로 생성시키는 DoS 공격 서버가 모든 SYN 패킷에 대해 세션을 생성하고 응답을 기다림. flash crowd와 구별이 쉽지 않음. 2018년 11월 11일 오전 8시 7분 27 / 32

28 8. TCP 연결 관리를 포함하는 공격 - 계속 28 / 32 방어1: SYN 쿠키
SYN 쿠키가 사용되면 L4에서 응답하고 세션테이블을 생성하지 않음. 정상적인 사용자로 판단 시 Server의 세션을 생성. 공격자는 SYN/ACK에 대한 반응을 하지 않기 때문에 L4는 SYN/ACK 응답만 지속 함. 2018년 11월 11일 오전 8시 7분 28 / 32

29 8. TCP 연결 관리를 포함하는 공격 - 계속 29 / 32 방어: SYN 쿠키
Cookie value는 TCP 헤더의 Option 중 3bit를 제외한 나머지 공간을 활용함. Sequence number를 인코딩하여 이 공간에 적재. 정상적인 사용자라면 해당 정보를 잘 분석해서 재응답 패킷을 전송 2018년 11월 11일 오전 8시 7분 29 / 32

30 8. TCP 연결 관리를 포함하는 공격 - 계속 30 / 32 공격2 : PMTUD를 이용한 공격
매우 작은 MTU 값을 가진 ICMP PTB 메세지 전송. TCP에게 데이터를 매우 작은 패킷으로 만들게 해 성능을 감소 시킴. 2018년 11월 11일 오전 8시 7분 30 / 32

31 8. TCP 연결 관리를 포함하는 공격 - 계속 31 / 32 방어: 1. 호스트의 PMTUD를 비활성화
2. PMTUD를 576bytes 이하의 사이즈로 설정하는 내용을 갖는 ICMP PTB 메시지를 수신한다면 폐기. 3. 최소 패킷 크기를 항상 동일한 값으로 고정시킴. 2018년 11월 11일 오전 8시 7분 31 / 32

32 9. 정리 32 / 32 연결확립 3way hand-shaking 데이터 교환 전 연결확립이 되어야 함. 상태천이도
TCP 동작의 이해를 도와주는 그림 TCP의 TIME_WAIT 종단이 MSL을 두 배로 설정하고 FIN 신호에 대해 ACK 응답을 대기 함. 2018년 11월 11일 오전 8시 7분 32 / 32

33 Qna

34