SCTP

SCTP란 2000년도에 No.7 Signaling 메시지를 IP NW을 사용하여 전송하기 위해 만들어진 전송 프로토콜로

표준문서 RFC2960 으로 정의되어 있다.

나는 06년 모 통신회사에서 SG라고 부르는 Signaling Gateway 장비를 구축하면서 처음 접하게 되었다.

SCTP는 Stream Control Transmission Protocol의 약자이다. 기존의 TCP와 비슷한데 한가지 차이점은

Stream 이라는 단어가 들어가 있다는 점이다. 여기에 뭔가 중요한 의미가 있을것 같지 않은가?

그렇다면 기존에 TCP 라는 전송 프로토콜을 잘 사용하다가 왜 굳이 SCTP 라는 프로토콜을 새로 만들었는지 살펴보자.

 

No.7 Signaling 메시지는 오래전부터 Circuit Switching 일명 전화망에서 사용하던 control 메시지였는데 아시다시피

전화망은 IP NW망에 비해 상당히 폐쇄적이고, 견고하게 구성되어 있다. 근데 이 No.7 메시지를 TCP를 사용하여

전송하기에는 TCP의 단점들이 너무 많았으며 따라서 TCP를 보완하여 SCTP라는 신규 프로토콜을 생성하게 된 것이다.

 

TCP의 대표적인 단점을 먼저 살펴보고 SCTP의 특징에 대해 알아보자.

 

■ TCP 단점

1. Head of Line Blocking

TCP는 신뢰성 있는 전송을 위하여 패킷을 송신 후 ack를 기다린다. 바로 여기서 TCP의 어쩔수 없는 단점이 나타난다.

어떤 연구결과에 따르면 TCP에서 1% packet loss 발생시 총 소요시간 중 9% delay를 유발한다고 나와있다.

쉽게 얘기하면 100개의 패킷을 전송하는데 한 패킷 당 1초가 소요된다고 치면 총 100초가 걸린다. 근데

전송 중에 한개의 패킷이 유실될 경우 재전송 등으로 인해 총 109초가 걸린다는 의미이다.

Head of Line Blocking을 풀어보면 라인의 머리가 어떠한 이유로 막혀있다는 의미인데 이는 패킷을 전송 후

상대방으로 부터 ack를 수신하지 못하면 그 이후에 보내야 할 패킷들이 전송되지 못하고 모두 대기한다.

TCP의 단점글을 찾아보면 어김없이 나오는 이 단어를 SCTP에서는 어떻게 해결했는지 잠시 후 알아보자.

 

2. 보안에 취약

TCP는 개발된지 상당히 오래된 프로토콜로 TCP의 여러가지 취약점을 이용한 해킹기법이 상당히 많이 존재한다.

대표적으로 TCP에서 동작하는 3 way handshake 방식을 살펴보자.

Client 와 Server 간에 3 way handshake 를 시도한다고 할때 Client 에서 최초로 syn 을 전송한다.

이때 Server는 backlog queue에 서비스 제공을 위한 메모리 자원을 할당 후 ack/syn을 전송한다.

근데 여기서 Client 가 악의적인 목적으로 패킷을 조작하여 처음 syn을 보낼때 소스IP를 잘못된 IP로

변경하여 (혹은 존재하지 않는 IP) 전송한다고 하면 Server는 아무것도 모르고 해당 소스IP를 목적지IP로

변경하여 ack/syn을 전송하려고 할 것이다. 당연히 이는 실패될 것이고, 정해진 시간이 만료되면 Server에서

해당 자원을 해제할 것이다. Client에서 Server의 timeout 시간보다 훨씬 빠른 속도로 대량의 syn을 보낸다면?

Server에서 계속해서 리소스를 할당하다 결국 시스템이 다운될 것이다.

이게 바로 그 유명한 DOS 공격유형 중 대표적인 Syn Flooding 이라는 공격방법이다.

이처럼 TCP 구조적인 문제점을 이용한 해킹공격들이 SCTP를 개발하는데 충분한 이유가 되었던 것이다.

 

그럼 다음 시간에 SCTP의 본격적인 특징에 대해 알아보도록 하겠다.

 

 

 

 

 

 

 

 

 

 

 

'Protocol' 카테고리의 다른 글

Gratuitous ARP  (0) 2013.09.13
Proxy ARP  (4) 2013.09.12

Gratuitous ARP

오늘은 Gratuitous ARP에 대해 알아보도록 하자.

Gratuitous ARP는 줄여서 그냥 GARP 라고 부른다.

우선 gratuitous 의 사전적인 의미를 찾오보면 '불필요한', '쓸모없는' 이란 뜻이다.

과연 GARP는 불필요하고 쓸모없는 프로토콜일까? 

절대 그렇지 않다!!!

 

일반 ARP는 Request를 전송하고, Response를 기다리는 방식이지만 GARP는 Response가 없으며, GARP가 사용되는 사례는 아래와 같다.

1. IP 설정시 동일한 네트웍에 중복된 IP가 있는지 확인

2. 이중화 절체시 인근 스위치 및 Host 들이 경로를 절체시킬 수 있도록 자신의 MAC 주소를 알려줌

 

먼저 첫번째 예를 확인해보자.

테스트는 윈도우에서 IP를 세팅하던, 라우터 인터페이스에서 IP를 세팅하던 동일하다.

IP를 입력하는 순간 동일한 IP를 사용하는지 체크하기 위해 GARP가 Broadcast 된다. 

 

위의 그림은 라우터 인터페이스의 IP를 1.1.12.1로 설정한 후 no shutdown 한 직후 발생한 GARP의 패킷을 잡아보았다.

패킷을 보면 Sender IP와 Target IP가 동일하다. 동일 네트웍에 있는 모든 노드들은 이 패킷을 수신하여 자신의 IP와 비교후 다르면 무시하고, 같으면 GARP를 Broadcast 하여 중복되었음을 알려준다.

 

아래 그림은 중복된 IP 가 존재할 경우 발생한 GARP 패킷이다.

 

그리고 라우터에서는 아래 화면과 같이 Duplicate address 로그가 계속해서 발생한다.

만약 윈도우 OS라면 중복된 IP가 존재한다는 창이 팝업될 것이다. 

 

여기서 한가지 생각해볼 부분은 IP가 중복되어 발생하는 GARP도 Broadcast 방식이라는 점이다.

다시말해 Host A가 1.1.1.1 이라는 IP를 기존에 사용중이였는데 Host B에서 IP를 1.1.1.1로 세팅하면

Host B에서 먼저 중복된 IP를 검색하는 GARP를 Broadcast 하고, Host A에서는 중복이 발생했다는 의미로

GARP를 다시 Broadcast 한다.

두번째 발생하는 GARP가 Unicast를 사용하는게 아니라 굳이 Broadcast 하는 이유는 왜일까?

이는 동일 네트웍 상의 다른 모든 노드들의 ARP 테이블을 정상적으로 다시 Refresh 시켜주기 위함이다.

처음 Host B에서 Host A로 GARP를 Broadcast 하면 이를 수신한 모든 노드들은 자신의 ARP 테이블에 해당 IP의

MAC 주소는 Host B의 MAC 주소로 등록시켜 버린다. 이런 문제점을 보완하기 위해 IP 중복이 발생한 경우에도

GARP는 Broadcast로 모든 노드들에게 전송시켜줘야 한다.

 

두번째 예를 확인해 보자.

아래 그림과 같이 HSRP 로 이중화 되어있는 구성에서 평상시 R1이 Active, R2가 Standby로 동작할 때

스위치의 MAC 테이블을 확인해보면 목적지 0000.0c07.ac01 에 대해서는 F0/1로 포워딩 하도록 저장되어 잇다.

이후 R1에서 R2로 Active가 절체되는 순간 R2는 GARP를 Broadcast 한다. 

GARP를 수신한 스위치에서는 목적지 0000.0c07.ac01 주소에 대한 포워딩 인터페이스를 F0/1에서 F0/2로 변경한다.

 

아래는 Active 절체시 R2에서 발생한 GARP 패킷을 캡쳐한 화면이다.

 

참고로 이중화 절체시 발생하는 GARP는 꼭 네트웍 장비만 발생시키는 것은 아니다. 서버 장비에서도 OS 설정에 따라

발생 가능하다. 실제로 내가 관리하는 사이트에 이중화로 동작하는 Sun 서버가 있었는데 이중화 절체시 IP가 중복되는

문제점을 몇년간 해결하지 못하다가 서버 절체시 GARP를 전송하도록 OS 커널단에서 수정후 문제를 해결할 수 있었다.

 

 

'Protocol' 카테고리의 다른 글

SCTP  (0) 2013.09.14
Proxy ARP  (4) 2013.09.12

Proxy ARP

Proxy 라는 용어는 네트웍에서 자주 사용되는 단어이다.

대표적으로 Proxy Server 등을 들수 있는데 가장 먼저 Proxy 라는 단어의 의미부터 명확히 짚고갈 필요가 있다.

Proxy 의 사전적 의미는 '대리(인)' 이다.

즉, 남을 대신해 자신이 대신 수행해 준다는 의미인데

라우터는 Host 에서 보내온 ARP Request 를 보고 목적지 IP가 자기 자신이 아니더라도 자신이 도달 가능한 경로라고 판단할 경우(라우팅 테이블에 등록되어있는 목적지) 자신의 MAC 주소로 대신 응답해 주는 기능이다.

 

실제 상용망에 있었던 사례를 살펴보자.

 

위의 구성과 완전히 동일하지는 않았으나 대략 비슷하다.

여기서 주의깊게 봐야 할 부분은 PC1에서 GW의 IP를 R1의 IP로 오설정 한 부분이다.

실제 망에서도 이와같이 GW IP가 잘못 설정된 상태로 몇년을 정상적으로 운영중이였으며, 우연한 기회에 발견하였다.

GW IP 설정이 잘못되었는데 어떻게 그동안 운영이 가능했을까!!!

 

바로 R2의 Fa0/1 인터페이스에 Proxy ARP 기능이 enable 되어있었기 때문이다.
※ Cisco 모델은 모든 인터페이스에 Proxy ARP 기능이 디폴트로 enable 되어있음

 

PC1 에서 외부 네트웍과 통신하기 위해 GW IP로 ARP Request를 브로드캐스트 전송하면 R2는 이 패킷을 수신하는데, 비록 목적지 IP가 자신이 아니지만 내가 도달할 수 있는 경로이므로 나에게 보내줘도 된다는 의미로 자신의 MAC 주소 (Fa0/1 인터페이스 MAC 주소)로 ARP Response 응답한다.

당연한 얘기지만 R2에서 10.1.1.1 경로에 대해 라우팅 테이블에 등록되어 있지 않다면 Proxy ARP 가 동작하지 않는다.

 

테스트 환경은 Packet Tracer 6.0 을 사용했는데 GNS3에서는 Host의 GW를 아예 다른 네트웍으로 선언이 불가하므로 Packet Tracer를 선택했으며, Packet Tracer에서도 Proxy ARP 기능은 정상 동작하므로 테스트에 문제없다.

 

우선 R2 fa0/1 MAC Address를 확인하자.

 

PC1에서 그림과 같이 IP/GW 설정을 한 후 PC0으로 ping 테스트를 시도하면 이상없이 잘된다.

그리고, R2가 자신의 MAC 주소로 대신 응답해준 것을 arp 테이블로 확인 가능하다.

 

이번에는 R2의 f0/1 인터페이스에서 no proxy arp로 Proxy ARP를 disable 하고 PC1에서 다시 ping 10.1.1.10을 해보자.

(그전에 PC1에서 arp -d 로 arp 테이블을 clear 시켜야 한다.) 당연히 ping 은 안된다.

 

두번째는 스태틱 라우팅과 Proxy ARP 관계를 알아보자~

테스트 구성도는 아래 그림과 같다.

이 테스트에서 중요한 부분은 R1에서 R2의 10.1.1.1로 ping이 갈 수 있도록 R1에서 static route를 지정해 주는데 이때 next hop을 자신의 output 인터페이스로 지정한다. 

(output 인터페이스가 아닌 상대방 인터페이스 IP를 지정할 경우 Proxy ARP는 발생하지 않음)

 

R1에서 ping 10.1.1.1 을 하면 정상적으로 성공한다.

R1에서 arp 테이블을 확인하면 10.1.1.1에 대해 R2 f0/0 인터페이스의 MAC 주소로 등록되어 있다.

즉, R1에서 목적지 10.1.1.1에 대한 ARP Request 패킷을 송신하면, R2에서는 자신이 10.1.1.1에 도달할 수 있다고 판단하고, 자기 자신의 MAC 주소로 대신 응답해 준 것이다. 

 

이번에도 당연한 얘기지만 R2의 f0/0 인터페이스에서 Proxy ARP를 disable 시키면 R1에서 10.1.1.1로 ping이 실패한다.

즉, 스태틱 라우팅을 사용할 경우에는 Proxy ARP 기능을 disable 되어있으면 절대 안된다는 의미이다!

 

이번에는 조금 다른 테스트를 해보자.

웹에서 Proxy ARP 를 검색하여 찾아보면 이런 설명이 되어있다.

"Proxy ARP를 사용하면 Host에서 GW IP를 설정하지 않더라도 외부 네트웍과 통신이 이루어진다."

과연 이 말이 맞는 말일까?

 

결론부터 얘기하자면 위의 설명은 잘못 되었으나 100% 틀린 말은 아니다!

아래 구성도를 보자. 

 

Host A에 GW IP가 설정되어 있지 않은 상태에서 ping 2.2.2.10 을 입력하면 어떻게 되는가?

목적지 IP가 자신의 네트웍 대역과 틀리므로 GW에게 ARP Request 를 던져야 하는데 GW IP가

설정되어 있지 않기때문에 ARP Request 패킷을 생성할 수가 없다.

 

즉, ARP Request 패킷이 라우터에게 도달할 수 없으며, OS 커널단에서 바로 Drop 된다.

그리고 Host A는 Destination host unreachable 라는 ICMP 메시지를 화면에 던져준다.

 

여기서 키 포인트는 ARP Request 패킷이 라우터까지 도달 할수 있느냐 없느냐의 유무이다.

다시말해 동일한 구성에서 강제로라도 ARP Request 가 라우터까지 갈 수 있다면 라우터의 Proxy ARP 기능을 이용하여 외부 네트웍과 통신이 가능하다는 말이다.

위의 구성도에서 Host A의 서브넷 정보만 수정된 구성도를 다시 보자. 

 

Host A의 서브넷마스크가 라우터와 동일하지가 않다. 상용망에서는 일반적으로 이와같이 구성하는 일은 없으나 테스트를 위해 일단 보자.

 

이 구성도에서는 Host A에서 ping 1.1.2.10 이 성공한다.

Host A의 서브넷마스크는 16bit 이므로 목적지 1.1.2.10 에 대해서도 같은 네트웍이라고 판단한다.

따라서 ARP Request 를 Broadcast 하고 이를 수신한 라우터는 자신의 MAC 주소로 응답을 해주게 된다.

이렇게 강제로 ARP Request 를 라우터까지 도달하게 하여 통신을 할 수는 있지만 일반적인 구성이 아니므로 그냥 참고만 하자.

 

 

'Protocol' 카테고리의 다른 글

SCTP  (0) 2013.09.14
Gratuitous ARP  (0) 2013.09.13