KR101406556B1 - 호스트 시스템 간 접속 확립 방법 - Google Patents

Abstract

본 발명은 방화벽 후방에 있는 호스트와의 접속을 안전하게 확립하기 위한, 본 명세서에서 KOP(Knock-On Protocol)로 지칭되는 호스트 간 시그널링 프로토콜에 대한 것이다. 본 발명의 몇몇 실시예들은 중간의 방화벽(FW) 또는 네트워크 어드레스 변환기(NAT)에 의해서 사용되어서 이 FW 또는 NAT를 통한 이 FW 또는 NAT 후방에 있는 호스트들로의 접속 확립을 구현하는 KOF(Knock-On Feature)에 관한 것이다. 유리하게는, KOF는 메시지 대량 공격에서 사용되는 어드레스 도용으로부터 보호할 수 있는 프리픽스 기반 보호 특징을 포함한다.

Description

호스트 시스템 간 접속 확립 방법{SECURE CONNECTION INITIATION HOSTS BEHIND FIREWALLS}

본 발명은 패킷 데이터 네트워크에 관한 것이며, 특히 2 개의 호스트 시스템들(이들 시스템 중 어느 하나는 방화벽을 통해서 패킷 데이터 네트워크에 접속됨) 간의 보안 접속을 개시하는 바에 관한 것이다. 이후부터는, 이러한 호스트 시스템의 패킷 데이터 네트워크로의 접속은 호스트 시스템이 방화벽의 후방에 놓인 것으로 지칭된다.

방화벽(FW) 및 네트워크 어드레스 변환기(NAT)는 다음의 같은 보안 특징을 이용한다. 즉, FW는 오직 방화벽 전방으로 나간 아웃바운드(outbound) 패킷들에 응답하여서 들어오는 인바운드(inbound) 패킷들만을 허용한다. FW은 이 인바운드 패킷들이 이전의 아웃바운드 패킷들과 프로토콜 타입, 소스 IP 어드레스, 소스 포트, 수신지 IP 어드레스 및 수신지 포트의 튜플(tuple)이 일치할 것을 요구한다.

이러한 방화벽 보안 특징에서는 추가 필터링 특징이 사용되지 않으면 내부 호스트(방화벽 후방에 있는 호스트 시스템)가 임의의 외부 호스트(동일한 방화벽 후방에 있지 않은 호스트 시스템)와의 접속을 개시한다. 그러나, 외부 호스트들은 내부 호스트와의 접속을 구할 수 없다.

공교롭게도, 이 FW 보안 특징에서는 외부 호스트의 내부 호스트로의 접속이 바람직한 상황에서도 이 외부 호스트에 의해서 개시되는 접속은 확립되지 않는다. 2 개의 호스트가 서로 상이한 방화벽들 후방에 있으며 서로 접속을 확립하기를 원할 때에 완벽한 교착 상태가 발생한다. 이 경우에, 이 두 호스트들은 서로 직접적으로 통신할 수 없다.

이 FW 보안 특징은 또한 본 명세서에서 간단하게 NAT로 지칭되는 대부분의 네트워크 어드레스 변환기 또는 네트워크 어드레스 및 포트 변환기 내로 구축될 수 있다. 따라서, 이후부터는, FW에 대하여 기술되는 모든 것들은 또한 일반적으로 NAT에도 적용될 수 있다.

또한, FW 보안 특징은 모바일 IPv6(IETF RFC 3775)와 같은 호스트 기반 이동성을 지원하는 기술들에서는 문제를 발생시킨다. 이러한 기술들에서는 호스트는 진행 중인 전송 접속을 방해하지 않고서 이동하면서 그의 IP 어드레스를 변경할 수 있다. 이 이동하는 호스트는 바인딩 업데이트(binding update)를 사용하여서 그의 새로운 IP 어드레스에 대한 그의 CN(correspondent node)를 업데이트해야 한다. 그러나, 이 바인딩 업데이트는 새로운 IP 어드레스로부터 도달하기 때문에, 이러한 FW 보안 특징에서는 FW가 이 바인딩 업데이트를 차단시켜 버린다.

이러한 FW 보안 특징에 의해서 유발되는 바람직하지 않은 부작용을 극복하기 위한 다음과 같은 2 가지 주요한 방식이 있다. (1) FW는 내부 호스트와 접촉하고자 하는 외부 호스트를 위해서 포트를 개방한다. (2) 내부 호스트는 임의의 외부 호스트에 의해서 접촉될 수 있는 외부 릴레이 서버(RS)로의 시그널링 접속(signaling connection)을 유지한다. 가령, 두 번째 방식은 TURN 법(draft-ietf-behave-turn-04.txt)에 의해서 제안된다. 이 TURN 법은 나아가 IETF가 제안한 ICE(Interactive Connection Establishment) 방식(draft-ieft-mmusic-ice-tcp-07)의 중요한 일부이다.

그러나, 이 두 방식 모두는 FW에 의한 보안을 위험하게 할 수 있는데 그 이유는 내부 호스트가 FW 또는 RS 상의 개방된 포트를 통해 이루어지는 공격의 대상이 될 수 있기 때문이다. 두 번째 방식의 몇몇 변형예는 내부 호스트와 RS 간의 링크 상에 추가적인 보안을 제공할 수 있다. 그러나, 이러한 변형예들은 내부 호스트들이 원칙적으로 받을 수밖에 없는 공격에는 어떠한 영향도 주지 못한다. 이렇게 내부 호스트들이 받을 수밖에 없는 공격 때문에, 상기 TURN 법 및 ICE 방식은 시장에서 크게 수용되지 않고 있다. 방화벽 관리자들은 이러한 방식들을 선호하지 않으며 동일한 이유로 인해서 다른 RS 기반 방식들을 선호하지 않는다.

이러한 점을 감안하면, 방화벽의 유리한 보안 기능을 유지하면서 동시에 외부 호스트가 내부 호스트와의 접속 확립을 개시하게 할 수 있는 것이 바람직하다. 나아가, 외부 호스트가 새로운 IP 어드레스로 이동한 경우에, 그 내부 호스트와 확립된 접속이 계속 유지되게 하는 것이 바람직할 것이다.

본 발명의 실시예들은 방화벽 후방에 있는 호스트와의 접속을 확립하기 위한, 본 명세서에서 KOP(Knock-On Protocol)로 지칭되는 호스트 간 시그널링 프로토콜에 대한 것이다.

본 발명의 몇몇 실시예들은 중간의 방화벽(FW) 또는 네트워크 어드레스 변환기(NAT)에 의해서 사용되어서 이 FW 또는 NAT를 통한 이 FW 또는 NAT 후방에 있는 호스트들로의 접속 확립을 구현하는 KOF(Knock-On Feature)에 관한 것이다.

본 발명의 몇몇 실시예들은 외부 호스트와 내부 호스트와의 접속 확립을 시도하는 빈도를 한정함으로써 보안을 제공한다.

KOF가 FW 또는 NAT에 통합된 본 발명의 실시예들 및 KOF가 FW 또는 NAT에 직렬로 접속되어서 구현되는 실시예들에서, 대응하는 접속들이 종료된 후에 개방된 5 튜플 엔트리들을 "플러깅(즉, 폐쇄 또는 삭제)"함으로써 추가 보안이 유리하게 제공될 수 있다.

본 발명의 몇몇 실시예들에서, KOF는 유리하게는 메시지 대량 공격에서 사용되는 어드레스 도용으로부터 호스트 시스템을 보호하기 위해서 프리픽스 기반형(prefix-based) 보호 특징을 포함한다.

유리하게는, 본 발명의 실시예들에 따른 KOF의 통상적인 프로세싱 및 메모리 요구 사항들은 FW 또는 NAT의 요구 사항들에 비해서 적다.

본 발명의 일 측면에 따라서, 제 2 호스트 시스템에 대해 보안 보호를 제공하는 방화벽을 통해서 제 1 호스트 시스템과 상기 제 2 호스트 시스템 간의 접속을 확립하는 방법이 제공된다. 이 방법은 KOF(knock-on-feature) 장치에 의해서, 상기 제 1 호스트 시스템이 전송한 제 1 메시지를 수신하는 단계와, 상기 제 1 메시지가 상기 제 1 호스트 시스템과 제 2 호스트 시스템 간의 접속을 확립하기 위한 제 1 타입이라고 판정하는 단계와, 상기 제 1 메시지로부터 상기 제 1 호스트 시스템과 제 2 호스트 시스템의 각각의 어드레스를 판정하는 단계와, 상기 제 1 호스트 시스템과 제 2 호스트 시스템의 어드레스에 대응하는 2 튜플(2 tuple)에 대한 임의의 상태 정보가 상기 KOF 장치상에 존재하는지의 여부를 판정하는 단계와, 상기 2 튜플에 대한 어떠한 상태 정보도 상기 KOF 장치상에 존재하지 않으면 상기 제 1 메시지를 상기 제 1 호스트 시스템으로 전송하는 단계를 수행한다.

유리하게는, 이 방법은 상기 제 2 호스트 시스템에 대하여 상기 KOF 장치상에 존재하는 상태 정보의 양을 판정하는 단계와, 상기 양이 사전 결정된 최대치를 초과하면, 2 개의 호스트 시스템 쌍━각 쌍은 상기 제 2 호스트 시스템과 다른 호스트 시스템을 포함하며, 상기 다른 호스트 시스템은 각 쌍에서 상이함━의 상태 정보를 하나의 호스트 시스템 쌍에 대한 상태 정보로 결합하는 단계━상기 하나의 호스트 시스템 쌍에 대한 상태 정보는 상기 제 2 호스트 시스템의 어드레스 및 상기 2 개의 호스트 시스템 쌍의 나머지 호스트 시스템들의 각각의 어드레스들에 공통적인 어드레스 프리픽스를 포함함━를 더 포함한다.

본 발명의 전술한 목적, 특징 및 장점과 다른 목적, 특징 및 장점은 첨부된 도면에서 예시된 바와 같은 바람직한 실시예들의 다음의 보다 자세한 설명으로부터 명백해질 것이다.
도 1은 통상적인 종래의 방화벽 아키텍처의 5 튜플과 연관된 상태 및 상태 전환을 나타내고 있다.
도 2는 통상적인 종래의 방화벽 아키텍처의 인바운드 패킷(상부) 및 아웃바운드 패킷(하부)에 대한 FSM(finite state machine)을 나타내고 있다. 이 흐름도는 타이머 만료로부터 기인되는 도 1에 도시된 5 튜플 상태 전환을 포함하지 않고 있다.
도 3은 본 발명의 실시예들에 따른, 통합형 KOF 방화벽에 대한 네트워크 아키텍처(a), 레거시 FW에 직렬로 부가된 KOF에 대한 네트워크 아키텍처(b) 및 외부 릴레이 서버(RS) 상의 KOF에 대한 네트워크 아키텍처(c)를 나타내고 있다.
도 4는 도 3의 (a)에 도시된 실시예에 따른 통합형 KOF FW 아키텍처의 KOP 메시지 호 흐름을 나타내고 있다.
도 5는 도 3의 (a)에 도시된 실시예에 따른 통합형 KOF FW 아키텍처의 5 튜플 및 2 튜플과 관련된 상태 및 상태 전환을 나타내고 있다.
도 6은 도 3의 (b)에 도시된 실시예에 따른, 레거시 FW에 직렬로 부가된 KOF의 5 튜플 및 2 튜플과 관련된 상태 및 상태 전환을 나타내고 있다.
도 7은 도 3의 (c)에 도시된 실시예에 따른, 외부 RS 아키텍처 내에 제공된 KOF의 KOP 메시지 호 흐름을 나타내고 있다.
도 8은 도 3의 제 1 아키텍처 네트워크(a)에서 도시된 실시예에 따른 통합형 KOF FW에 의해서 수행되는 인바운드 패킷을 다루는 방법을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 5에 도시된 상태 전환을 포함하지 않는다.
도 9는 도 3의 제 1 아키텍처 네트워크(a)에서 도시된 실시예에 따른 통합형 KOF FW에 의해서 수행되는 아웃바운드 패킷을 다루는 방법을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 5에 도시된 상태 전환을 포함하지 않는다.
도 10은 도 3의 제 2 아키텍처 네트워크(b)에서 도시된 실시예에 따른 방화벽에 직렬로 부가된 KOF에 의해서 수행되는 인바운드 패킷을 다루는 방법을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 6에 도시된 상태 전환을 포함하지 않는다.
도 11은 도 3의 제 2 아키텍처 네트워크(b)에서 도시된 실시예에 따른 방화벽에 직렬로 부가된 KOF에 의해서 수행되는 아웃바운드 패킷을 다루는 방법을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 6에 도시된 상태 전환을 포함하지 않는다.
전체 도면에서, 유사한 구성 요소에는 유사한 참조 부호가 부여된다.

도 1에서, 방화벽(FW) 상에서, 실제로 또는 잠재적으로 존재하는 접속과 관련된 모든 5 튜플(5-tuple)은 2 개의 상태 중 어느 하나, 즉 통과 상태(1) 또는 차단 상태(2)와 관련된다. 여기서, 해당 통과 기능 또는 차단 기능은 인바운드 패킷(inbound packet)에 적용된다. 5 튜플을 구비한 아웃바운드 패킷(outbound packet)이 통과할 때에 각 5 튜플은 차단 상태(2)에서 통과 상태(1)로 변한다. 통과 상태(1)는 활성 시간(life time)과 연관된다. 활성 시간 만료 후에, 5 튜플은 차단 상태(2)로 돌아간다. 통과 상태(1)에서, 타이머는 모든 아웃바운드 패킷 또는 인바운드 패킷이 대응하는 5 튜플을 보유할 시에 리프레시될 수 있다.

통상적인 FW 구현예에서, 오직 통과 상태(1)에서의 5 튜플만이 캐시 메모리의 할당을 요구한다. 차단 상태(2)는 디폴트 상태이며 시간에 민감한 정보를 반송하지 않기 때문에, 차단 상태(2)는 캐시 메모리 할당을 요구하지 않는다. 5 튜플 및 만료 시간과 같은 데이터는 통상적으로 통과 상태(1)에서 5 튜플을 위해서 방화벽 상에 유지된다.

도 2에서, FW 기능은 2 개의 FSM(finite state machines)를 통해서 표현될 수 있다. 일 FSM(한정 상태 머신)(4)은 인바운드 패킷을 다루고 다른 FSM(5)은 아웃바운드 패킷을 다룬다. 도 2에서 FSM 도면은 상태 만료로 인해서 상태 전환을 생략하고 있다.

도 3에서, KOP(Knock-On Protocol)는 호스트 간 접속 관리를 구성 및 개발하기 위한 커티시 프로시저(courtesy procedure)로서 최종 호스트들에 의해서 사용되어야 한다. 가령 인증과 같은 추가 기능은 이러한 메시지 내에 내장될 수 있다.

KOP 메시지들은 FW 상의 KOF에 의해서 인터셉트, 평가 및 동작될 수 있다. 몇몇 조건적 규칙 세트에 근거하여서, (내부 호스트를 향하는) 인바운드 KOP 메시지들은 FW 상의 KOF에 의해서 내부 호스트로 전달될 수 있다. KOP 메시지 및 KOF 규칙 세트를 신중하게 규정함으로써, FW를 통한 접속이 매우 안전한 방식으로 확립될 수 있다. 다음 부분들은 KOF가 방화벽 보안 기능을 저해하지 않도록 KOF가 설계되는 방식을 개략하고 있다.

KOP 메시지는 5 튜플에 의해서 주어지는 전송 접속에 기초한다. 따라서, KOP 메시지들은 대응하는 5 튜플 정보를 반송한다. KOP는 다음과 같은 메시지들을 지원한다.

- KOP REQ: 특정 5 튜플 대신에 접속 확립을 요청함

- KOP ACK: KOP REQ 메시지에 응답하여서 접속 확립을 허용함

- KOP NAK: KOP REQ 메시지에 응답하여서 접속 확립을 거부함

- KOP RSP: KOP REQ 메시지에 응답하여서 더 많은 정보를 요청함(이 메시지에 대한 응답은 다른 KOP REQ 메시지일 것임)

- KOP FIN: 5 튜플 접속을 종료함

위의 처음의 4 개의 메시지들은 접속 확립 이전에 또는 접속 확립 시점에 사용되고 마지막 메시지는 접속 종료 시점에 또는 그 이후에 사용된다. 접속의 활성 시간 동안에, 호스트 상의 KOP 클라이언트는 임의의 상태 정보를 유지할 필요가 없다.

5 튜플과는 별로도, KOP 메시지들은 주로 임의의 추가 정보를 반송할 수 있다. 가령, KOP REQ 메시지는 가령 전송 호스트의 인증 자격과 같은, 피어 호스트가 접속에 참여하도록 설득하는 내장 정보를 반송할 수 있다. KOP RSP 메시지는 피어 호스트가 추가 정보를 요청하도록 할 수 있다. KOP REQ/RSP 메시지 쌍들을 이용하여서, 보다 복잡한 핸드쉐이크가 확립될 수 있다.

KOP 메시지들은 정보를 유지하기 위해 Type-Length-Value 포맷을 사용할 수 있다. KOP 메시지들은 다음과 같은 전송 포맷들을 사용할 수 있다.

- KOP 메시지들은 특정 포트 넘버를 갖는 UDP를 사용할 수 있다. 다음에서, 이 방식은 달리 언급되지 않는 한 KOP를 위해서 사용된다.

- KOP 메시지들은 그들 자신의 프로토콜 타입을 반송할 수 있다.

- KOP 메시지들은 ICMP를 사용할 수 있다.

- KOP 정보는 IP-옵션 헤더(IPv4) 또는 IP-확장 헤더(IPv6) 내에 내장될 수 있다. 이는 IPv6의 경우에 특히 우수한 방식일 것이다.

- KOP 메시지들은 특정 전송 프로토콜로 구현될 수 있다. 가령, TCP의 경우에, TCP 옵션 헤더가 KOP 메시지들을 플래그(flag)하기 위해서 사용될 수 있다. KOP REQ 메시지는 가령 TCP SYN 메시지 상으로 피기 백(piggy-back)될 수 있다.

- KOP 정보는 가령 IKEv2(IETF RFC 4306)와 같은 기존의 시그널링 프로토콜 내에 포함될 수 있다.

KOP 가능한 호스트는 KOP 메시지들을 사용하여서 다른 호스트와의 접속을 확립 또는 종료하거나 다른 호스트로부터의 접속 개시 요청을 거부하기 위해서 KOP 메시지들을 생성, 전송, 수신 및 해석하고 이에 응답할 수 있는 호스트 시스템이다. 바람직하게는, KOP 가능한 호스트들은 레거시 호스트와 상호작용할 수 있다. 예를 들어, KOP 가능한 호스트들이 접속을 확립하기 위해서 레거시 호스트(legacy host)에 KOP REQ 메시지를 전송할 때에, 어떠한 응답도 일어나지 않을 수 있다. 이 경우에, KOP 가능한 호스트는 몇몇의 재전송 후에 이를 간단히 포기하고 이 레거시 호스트와의 접속을 통상적인 방식으로 확립하고자 시도할 수 있다.

KOP의 목적은 FW와 NAT와 같은 중간 박스들을 극복하는 것이기 때문에, 접속 개시 호스트는 KOP REQ 메시지를 전송하는 것과 병행하거나 통상적인 접속 확립이 실패한 후에 접속 확립을 시도할 수 있다. 오직 KOF를 갖는 FW만이 KOP REQ 메시지들이 통과되게 할 수 있다. 수신 호스트(즉, KOP REQ 메시지가 향하는 호스트)가 KOP 가능할 때에, 이 호스트는 접속 개시 호스트와의 접속에 참여하지 않고서 KOP NAK 메시지 또는 KOP RSP 메시지로 KOP REQ 메시지에 응답할 기회를 갖는다. 이 수신 호스트가 레거시 호스트이지만 방화벽 후방에 있지 않으면, 해당 접속은 지연 없이 개시될 수 있다. 이는 통상적인 호 확립 절차들은 호스트들 중 하나가 KOP 구현 가능하지 않을지라도 적합하게 동작할 수 있음을 의미한다.

KOP 정보가 트래픽 접속의 TCP SYN 패킷과 멀티플렉싱된 IP 옵션 헤더, IP 확장 헤더 또는 TCP 옵션 헤더 상에서 반송될 때에 주의가 요구된다. 가령, 중간 FW 상의 KOF는 그 패킷의 KOP 부분에 반응할 수 있는 반면에, 즉 그것이 통과되도록 하는 반면에, 수신 레거시 호스트는 그 메시지의 KOP 부분을 간단히 폐기하고 TCP SYNACK으로 TCP SYN 패킷에 응답할 수 있다. 이는 필수적으로 방화벽의 보안 기능을 무력화시킨다.

KOP 구현 가능한 수신 호스트는 간단히 주도권을 잡고 KOP REQ 메시지에 응답하여서 접속을 개시할 수 있기 때문에 KOP ACK 메시지는 원칙적으로 불필요하다. 이러한 바를 수용하기 위해서, KOP REQ 메시지 송신기는 그의 단부에서 병렬로 접속을 개시할 수 있다. 이는 그 자신의 방화벽 상에 5 튜플을 생성할 것이며 이로써 수신 호스트가 전송한 인바운드 트래픽 패킷은 통과할 수 있게 된다.

도 3에서, KOF는 각각의 네트워크 아키텍처(10a, 10b, 10c)에서 도시된 바와 같은 3 가지 방식으로 제공될 수 있으며, 이 아키텍처들에서 내부 호스트 Hi는 방화벽 FW 후방에 있는 내부 네트워크(14) 및 방화벽의 다른 측 상에 있는 외부 네트워크(16)를 통해서 외부 호스트 Ho에 통신 가능하게 접속된다. 따라서, KOF는 (a) 통합된 KOF 방화벽(12)으로 도시된 바와 같은 제 1 방식과, (b) 레거시 방화벽일 수 있는 방화벽(20)에 직렬로 부가된 KOF(18)으로서 도시된 바와 같은 제 2 방식과, (c) 공중 릴레이 서버(RS)(22) 상에 제공된 KOF로서 도시된 바와 같은 제 3 방식으로 제공될 수 있다.

도 4는 제 1 네트워크 아키텍처(10a)에 따른 통합형 KOF 방화벽(12)의 경우에 대한 접속 확립 및 종료에 대한 예시적인 호 흐름을 나타내고 있다. 이 호 흐름은 또한 KOF(18)가 FW(20)에 대해서 직렬로 부가된 제 2 네트워크 아키텍처(10b)에 대해서도 적용될 수 있다.

도 4에서, 외부 호스트 Ho는 KOP REQ 메시지를 내부 호스트 Hi에 전송함으로써 내부 호스트 Hi와의 접속을 개시하기를 시도한다. 통합형 KOF 방화벽(12)은 KOP REQ 메시지를 수신하고 이를 KOP 메시지로서 인식하고 이 메시지를 내부 호스트 Hi에 전송한다(32). 내부 호스트 Hi는 KOP NAK 메시지를 외부 호스트 Ho에 전송(34)함으로써 KOP REQ 메시지에 응답할 수 있다. 이 통합형 KOF 방화벽(12)은 KOP NAK 메시지를 수신하여서 이를 KOP 메시지로서 인식하고 이 메시지를 내부 호스트 Ho에 전송한다(36). KOP NAK 메시지는 내부 호스트 Hi가 요청된 접속 확립을 거부하는 것을 나타내기 때문에, 이 메시지를 수신하면, 외부 호스트 Ho는 요청된 접속을 확립하지 않는다. KOP NAK 대신에, 내부 호스트 Hi는 KOP ACK 메시지를 외부 호스트 Ho에 전송(38)할 수 있는데 이 KOP ACK 메시지는 내부 호스트 Hi가 요청된 접속 확립을 수락함을 의미한다. 통합형 KOF 방화벽(12)은 KOP ACK 메시지를 수신하여서 이를 KOP 메시지로서 인식하고 이를 외부 호스트 Ho에 전송한다(40). 이 KOP ACK 메시지를 수신하면, 외부 호스트 Ho는 요청된 접속을 확립하기 시작한다.

KOP ACK 메시지 또는 KOP NAK 메시지를 전송하는 대신에, 내부 호스트 Hi는 추가 정보를 요청하기 위해서 KOP RSP 메시지를 외부 호스트 Ho에 전송할 수 있다(42). 이 통합형 KOF 방화벽(12)은 KOP RSP 메시지를 외부 호스트 Ho에 전달(44)할 뿐만 아니라 이 KOP RSP 메시지에 응답하여서 외부 호스트 Ho가 내부 호스트 Hi에 전송(46)하는 제 2 KOP REQ 메시지를 전달한다(48). 제 2 KOP REQ 메시지를 수신하면, 내부 호스트 Hi는 제 1 KOP REQ 메시지가 수신되기 이전에서와 같은 동일한 옵션을 갖는다. 내부 호스트 Hi가 접속을 확립한 상태에서 이 접속을 종료하기 원하는 경우에, 내부 호스트 Hi는 통합형 KOF 방화벽(12)를 통해서 외부 호스트 Ho에 KOP FIN 메시지를 전송(50)함으로써 현 접속이 종료될 예정임을 외부 호스트 Ho에게 알리며, 이러한, 상기 통합형 KOF 방화벽(12)은 상기 KOP FIN 메시지를 수신받아서 외부 호스트 Ho에 전달한다(52).

도 5에서, 통합형 KOF 방화벽(12) 기능은 인바운드 트래픽 패킷과 관련된 5 튜플(60) 및 인바운드 KOP REQ 패킷과 관련된 2 튜플(62)과 연관될 수 있다. 5 튜플(60) 상태는 인바운드 트래픽 패킷이 통과되어야 하는지 차단되어야 하는지를 판정한다. 2 튜플(62) 상태는 인바운드 KOP REQ 메시지가 통과되어야 하는지 차단되어야 하는지를 판정한다. 2 튜플은 {Hi, Ho} IP 어드레스 쌍을 지칭하며 여기서 Hi는 내부 호스트를 나타내며 Ho는 외부 호스트를 나타낸다. 외부 호스트 Ho는 그 자신의 FW 후방에 상주할 수 있다.

일반적으로, KOP 메시지들은 통과 상태에 있는 대응하는 2 튜플 엔트리가 존재할 때에만 통과된다. 이러한 엔트리가 존재하지 않으면, KOF는 이러한 엔트리를 생성하여서 이를 통과 상태로 설정할 것이다. 대응하는 2 튜플 엔트리가 차단 상태에 있으면 KOF는 KOP REQ 메시지를 통과시키지 않을 것이다. 이러한 2 튜플의 2 중 모드 동작은 다음과 같은 기능을 제공한다. 즉, 통과 상태는 KOP REQ 메시지의 도달 레이트가 임계 레벨보다 작은지의 여부를 체크하고 만일 그렇다면 KOP REQ 메시지는 통과되도록 허용될 것이고, 그렇지 않는다면, 차단 상태가 발동되어서 내부 호스트 Hi에 다른 KOP REQ 메시지가 도달하는 것이 방지될 것이다.

각 5 튜플이 통과 상태(68)와 차단 상태(66) 중 어느 하나의 상태로 존재하는 동안에, 각 2 튜플은 유휴 상태(74), 통과 상태(86) 및 차단 상태(78) 중 어느 하나의 상태로 존재할 수 있다. KOF 통합형 FW는 5 튜플 차단 상태(66) 또는 2 튜플 유휴 상태(78)에 대해서는 어떠한 캐시 메모리도 보유하지 않는데 그 이유는 이러한 상태들이 디폴트 상태이며 어떠한 시간 민감형 정보도 반송하지 않기 때문이다. 5 튜플 통과 상태(68)에 대해서는, KOF 통합형 FW는 5 튜플 및 만료 시간을 캐싱한다. 2 튜플 통과 상태(86)에 대해서는, KOF 통합형 FW는 2 튜플, 만료 타이머 및 메시지 카운터를 캐싱한다. 2 튜플 차단 상태(78)에 대해서는, KOF 통합형 FW는 2 튜플 및 만료 타이머를 캐싱한다.

KOF 통합형 FW(12)는 내부 호스트 Hi 및 외부 호스트 Ho 간의 기존의 접속을 유지하거나 내부 호스트 Hi에 의한 접속 확립 시도를 유지하기 위해서 5 튜플 통과 상태(68) 엔트리를 유지한다(72). KOF 통합형 FW(12)는 외부 호스트 Ho가 내부 호스트 Hi와의 접속 확립을 시도할 때에 인바운드 KOP REQ 메시지의 레이트를 제어하기 위해서 2 튜플 통과 상태 엔트리{Hi, Ho}를 유지한다(86). 후속 KOP REQ 메시지들이 내부 호스트 Hi에 의해서 요구되지 않거나 외부 호스트 Ho가 내부 호스트 Hi에 전송한 KOP REQ 메시지의 허용 가능한 레이트를 초과한 경우에는 외부 호스트 Ho에 의한 이러한 후속 KOP REQ 메시지가 내부 호스트 Hi로 도달되는 것을 방지하기 위해서 KOF 통합형 FW(12)는 2 튜플 차단 상태(78) 엔트리를 유지한다.

5 튜플(60)에 기초한 기능은 몇몇 예외 사항을 제외하고 통상적인 FW에 의해서 제공되는 바와 유사하다. 먼저, 그의 차단 기능은 인바운드 KOP REQ 메시지에 적용되지 않는다. 대신에, 인바운드 KOP REQ 메시지는 이들의 연관된 2 튜플(62)의 상태에 영향을 받는다. 둘째로, 5 튜플(60) 엔트리는 아웃바운드 KOP REQ 메시지, 아웃바운드 KOP RSP 메시지 또는 아웃바운드 KOP FIN 메시지의 이동 시에는 생성되지 않는다.

통상적인 FW 기능에 추가하여셔, 5 튜플(60)은 이 5 튜플에 대응하는 아웃바운드(즉, 내부 호스트 Hi로부터 전송되는) KOP ACK 메시지가 통합형 KOP 방화벽(12)을 통과할 때에 차단 상태(66)에서 통과 상태(68)로 전환된다(64). 이러한 전환(64)은 통상적인 패킷(KOP 메시지들을 반송하지 않는 패킷)이 이 통합형 KOP 방화벽(12)을 통과할 때에도 발생할 수 있다.

통상적인 FW 기능 이외에, 5 튜플(60)은 이 5 튜플(60)에 대응하는 아웃바운드 KOP FIN 메시지가 통합형 KOP 방화벽(12)을 통과할 때에 통과 상태(68)에서 차단 상태(66)로 전환된다(70). 이러한 특징으로 인해서, 내부 호스트 Hi는 종료된 접속에 대해서는 방화벽 상의 5 튜플 엔트리를 막아 버림으로써, 내부 호스트 Hi에 대해서 실질적인 보안이 이루어지고, 만일에 그렇지 않다면 보안상의 구멍(보안상 공격에 취약한 부분)이 되어 버릴 수 있는 상기 5 튜플 엔트리가 내부 호스트 Hi에 의해서 차단되는 것이다.

통합형 KOP 방화벽(12)은 각 5 튜플의 통과 상태(68)에 대한 타이머를 포함하는데 이 타이머가 만료되면 이 타이머는 통과 상태(68)에서 차단 상태(66)로의 전환이 이루어지게 한다. 이와 달리, 5 튜플(60)은 5 튜플(60)에 대응하는 인바운드 패킷 또는 아웃바운드 패킷이 통합형 KOP 방화벽(12)을 통과함에 있어서는 방화벽 상태를 통과 상태(68)로 유지한다(60). 통과 상태(68) 뿐만 아니라 통과 상태(68)에서 차단 상태(66)로의 전환(70)과 관련하여서 타이머와 연관된 기능은 통상적인 방화벽에 대한 바와 동일하다.

모든 2 튜플(62)는 내부 호스트 Hi와 외부 호스트 Ho 간의 KOP 메시지 내에 포함된 {Hi IP 어드레스, Ho IP 어드레스} 쌍에 기초한다. KOF 통합형 FW(12)는 2 튜플(62)을 유휴 상태(74), 통과 상태(76) 및 차단 상태(78) 중 어느 하나의 상태로 유지한다. KOF 통합형 FW(12)은 다음과 같은 방식으로 동작한다. 유휴 상태(74)에 있어서 인바운드 KOP REQ 메시지가 대응하는 내부 호스트 Hi를 향해서 도달하면, 2 튜플(62)은 통과 상태(76)로 전환(80)되어 KOP REQ 메시지가 KOF 통합형 FW(12)를 통과하게 한다. 통과 상태(76)는 활성 시간 속성 및 최대 카운트 속성을 갖는다. 활성 시간 속성 값에 의해서 결정되는 통과 상태(76)의 활성 시간 동안, 최대 카운트 속성 값과 동일한 최대 개수의 KOP REQ 메시지들이 이 2 튜플에 대해서 전송될 수 있다. 이 최대 개수의 KOP REQ 메시지들이 도달하기 전에 통과 상태(76)의 활성 시간이 만료되면, 2 튜플(62)은 유휴 상태(74)로 전환된다(82). 통과 상태(76)의 활성 시간이 만료되기 이전에 최대 개수의 KOP REQ 메시지들이 도달되면, 2 튜플(62)은 차단 상태(78)로 전환된다(84). 이와 달리, 통과 상태(76)에 있는 2 튜플은 이 2 튜플의 아웃바운드 KOP REQ 메시지 및 아웃바운드 KOP RSP 메시지가 통합형 KOF 방화벽(12)을 통과할 시에 이 통과 상태를 리프레시한다(86). 이러한 리프레시(86)는 통과 상태 타이머 및 통과 상태(76)의 통과 상태 카운터를 리셋한다. 차단 상태(78)에서는, 외부 호스트 Ho에서 내부 호스트 Hi로의 후속 인바운드 KOP 메시지들은 통합형 KOF FW(12)에 의해서 거절된다. 차단 상태(78)는 자신의 활성 시간 속성을 가지며 이 활성 시간 값이 차단 상태(78)의 활성 시간을 결정한다. 차단 상태(78)의 활성 시간이 만료되면, 2 튜플(62)은 유휴 상태(74)로 전이된다(88).

내부 호스트 Hi가 KOP REQ 메시지를 수신하고 요청된 접속을 확립하는데 관심이 없으면, 내부 호스트 Hi는 KOP NAK 메시지를 사용하여서 이 접속을 개시한 외부 호스트 Ho에 응답할 수 있다. 이 KOP NAK 메시지는 KOF 통합형 FW(12) 상의 2 튜플(62)이 통과 상태(76)에서 차단 상태(78)로 바로 전환(84)됨으로써, 통합형 KOF 방화벽(12)은 외부 호스트 Ho에서 전송된 후속 KOP REQ 메시지들이 내부 호스트 Hi로 도달되지 못하게 한다.

KOF 상태가 통과 상태(76)에 있고 대응하는 내부 호스트 Hi가 대응하는 외부 호스트 Ho로부터의 추가 정보를 요청하는 아웃바운드 KOP RSP 메시지를 전송하는 경우에, KOF 통합형 FW(12)은 2 튜플(62)에 대한 통과 상태 타이머 및 통과 상태 카운터를 리셋한다. 이 KOF 통합형 FW(12)은 이 통과 상태 타이머 및 통과 상태 카운터를 사용하여서 대응하는 통과 상태 활성 시간이 이 2 튜플(62)에 대해서 만료되었는지의 여부 또는 통과 상태(76)에 있는 동안에 허용된 최대 개수의 메시지들이 도달하였는지의 여부를 판정한다. 이러한 리셋 기능은 필요할 수 있는 임의의 재전송을 포함하여서 KOP REQ 메시지를 사용하여서 KOP RSP 메시지에 응답할 수 있는 기회를 외부 호스트 Ho에게 제공한다.

내부 호스트 Hi에 의해서 전송된 KOP RSP 메시지 및 KOP ACK 메시지는 외부 호스트 Ho가 FW 후방에 상주하는 경우에 KOP REQ 메시지 역할을 할 수도 있다. 따라서, KOP REQ/RSP 메시지 핸드쉐이크 또는 KOP REQ/ACK 메시지 핸드쉐이크는 양 방화벽 상의 경로를 허용한다. 이러한 핸드쉐이크는 양 호스트들이 방화벽 후방에 있을 때에 확실한 방식으로 접속이 확립되게 한다.

이러한 여러 특징으로 인해서, KOF는 통합형 KOF 방화벽(12)을 통해서 다음과 같은 보호 기능을 제공한다. 즉, 소정 타입의 제어 메시지를 내부 호스트 Hi에 전달하기 위해서 방화벽을 개방하는 동안에, 이러한 메시지의 인바운드 패킷 흐름을 통과 상태(76) 활성 시간당 최대 카운터로 한정할 수 있다. (통과 상태(76) 활성 기간 값 및 최대 카운트 값에 의해서 결정되는) 이러한 레이트가 내부 호스트 Ho에 의해서 초과되게 되면, 차단 상태(78)가 활성화되어서 몇몇 연장된 시간 동안에 추가적인 KOP REQ 메시지가 내부 호스트 Hi에 전달되지 못하게 한다. 통과 상태(76) 활성 시간 속성 값은 유리하게는 다수의 KOP REQ 메시지 재전송이 수용될 수 있도록 몇 초로 설정된다. 차단 상태(78) 활성 시간 속성 값은 통과 상태 활성 시간 속성 값보다 길며 이로써 차단 상태(78)는 KOP REQ 메시지가 내부 호스트 Hi를 대량으로 공격하지 못하게 한다(가령, 차단 상태(78) 활성 시간 속성 값은 수 분 또는 수 시간일 수 있다).

통합형 KOF 방화벽(12)에서 KOF에서 제공되는 상술한 바와 같은 보호 기능을 개선하기 위해서, KOP 메시지들의 패킷 길이가 특정 최대 길이로 한정될 수 있다. 총 메시지 길이를 576 옥텟(octet)보다 작게 유지시키는 것이 바람직하며, 이것은 패킷 단편화가 사용되지 않음을 의미한다. 따라서, KOF는 KOP 메시지에 영향을 주기 이전에 KOP 메시지를 반송하는 패킷의 길이를 평가하여서 이 길이가 특정 최대 길이를 초과하면 이 패킷을 버린다.

KOF에 의해서 제공되는 보호 기능을 더 개선하기 위해서, 특정 TLV 포맷이 KOP 메시지에 도입될 수 있다. 이 포맷은 타입 규정 및 값 길이에 있어서 유연성이 있으므로, 통합형 KOF 방화벽(12) 및 호스트들이 인식하지 못하는 타입 규정을 갖는 KOP 메시지를 폐기할 수 있도록 함으로써 추가적인 호스트 보호 기능을 제공한다.

KOF는 내부 호스트가 거절한 KOP REQ 메시지를 갖는 외부 호스트와의 접속을 확립하는 것을 막지 않는다. 이러한 기능은 대응하는 호스트 쌍의 2 튜플(62)이 차단 상태(78)를 유지하고 있을지라도 KOF 통합형 FW(12)가 5 튜플(60)을 통과 상태(68)로 유지할 수 있음을 의미한다. 이러한 특성은 통합형 KOF FW(12)가 레거시 FW 기능에 순응하도록 하기 때문에 중요하다.

2 튜플(62)의 상태는 보다 간단한 방식으로 구현될 수 있다. 유휴 상태(74)는 어떠한 시간 민감형 정보도 가지지 않기 때문에, 메모리 할당을 필요로 하지 않는다. 따라서, 통과 상태(76) 또는 차단 상태(78)에 있는 2 튜플만이 메모리 내에서 유지된다. 이를 위해서, 다음과 같은 데이터 구조들이 메모리 내에서 유지된다.

KOF 통과 상태:

- 2 튜플

- 만료 시간(통과 상태 활성 시간이 만료되는 시간)

- 카운터(최대 카운트 속성 값에 이르거나 그 아래인 KOP 메시지의 카운트 개수)

KOF 통과 상태 만료 시간은 전술한 통과 상태 타이머를 구현하고 KOF 통과 상태 카운터는 전술한 통과 상태 카운터를 구현한다.

KOF 차단 상태:

- 2 튜플

- 만료 시간(차단 상태 활성 시간이 만료되는 시간)

정상적인 동작 하에서, 메모리 내에서 유지되는 KOF 상태의 수는 무시될 수 있다. 그러나, 이러한 수는 메시지가 대량으로 공격하는 동안에는 실질적으로 증가할 수 있다. 이러한 상황 하에서, 다음에서 기술되는 프리픽스 기반형 보호(prefix-based protection)가 유익할 것이다.

프리픽스 기반형 보호

KOF 통합형 FW(12)은 각 내부 호스트 Hi에 도달하는 KOP REQ 메시지의 레이트를 한정하면서, KOP REQ 메시지가 대량으로 내부 호스트를 대량으로 공격하는 것을 막을 수 있다. 이러한 공격은 KOF 자체의 오버헤드를 낳을 수 있는 공격을 포함한다. 이러한 상황 하에서, KOF는 그의 기능을 일시 중지하고 통합형 KOF 방화벽(12) 기능은 통상적인 FW 기능으로 복귀한다.

KOF는 대량의 도용된 IP 어드레스들로부터 발생하여서 일 내부 호스트 Hi를 향하는 대량의 KOF REQ 메시지들의 공격을 받을 수 있다. 이는 KOF가 모든 도용된 IP 어드레스로부터 발생하는 KOF REQ 메시지들의 결과적인 모든 결과적인 2 튜플에 대하여 하나의 엔트리(62)를 유지하며 이로써 통합형 KOF 방화벽(12)이 대량의 전체 메시지를 통과시키도록 허용할 것이기 때문이다.

원칙적으로, IP 어드레스 도용은 중간의 라우터들에 의한 인그레스 필터링(ingress filtering)을 통해서 약화된다. 그러나, 인그레스 필터링이 언제나 효과적인 것은 아니다. 또한, 공격자들이 동일한 L2 네트워크, 즉 일 L3 서브넷과 연관된 IP 어드레스를 도용할 수 있다.

KOF는 상술한 바와 같은 기본 2 튜플(Hi IP 어드레스, Ho IP 어드레스)을 다음과 같은 프리픽스 기반 형태 {Hi IP 어드레스, Ho IP 프리픽스)로 확장함으로써 상기와 같은 대량의 공격을 막을 수 있다. 이 프리픽스 기반 형태에서, 외부 호스트의 Ho 프리픽스에 순응하는 내부 호스트 Hi에 대한 모든 인바운드 KOP REQ 메시지들은 동일한 KOF 상태를 사용하여서 동일한 2 튜플(62)에 의해서 처리될 수 있다.

이렇게 기본 2 튜플을 프리픽스 기반 형태로 확장하는 바는 점진적으로 수행될 필요가 있는데 그 이유는 IP 프리픽스에 기초하는 차단으로 인해서 큰 수의 친화적인 호스트들에 대한 액세스 가능성이 저감될 수 있기 때문이다. 이를 위해서 다양한 알고리즘들이 도입될 수 있다. 하나의 간단하고 매우 효과적인 방법은 다음과 같다.

- 각 내부 호스트 Hi에 대해서, KOF는 통과 상태(76) 또는 차단 상태(78)가 메모리 할당을 요구하기 때문에 이 두 개의 상태 중 어느 하나의 상태에 있는 소정의 최대 N 개의 2 튜플들만을 유지할 수 있다. 이러한 두 상태 중 어느 하나의 상태를 유지하는 2 튜플들은 2 튜플 엔트리로서 지칭된다.

- 내부 호스트 Hi에 대한 2 튜플 엔트리들의 개수가 N에 도달하고 새로운 인바운드 KOF REQ 메시지가 내부 호스트 Hi에 대해서 도달하여서 통과 상태(76)에 있는 새로운 2 튜플 엔트리가 생성되면, 내부 호스트의 2 튜플 엔트리들 중 2 개는 단일 2 튜플 엔트리로 결합되어야 한다. 이 결합된 2 튜플 엔트리는 각각이 전술한 2 개의 2 튜플 엔트리들 각각에 대응하는, 외부 호스트들 Ho의 IP 어드레스들의 인터섹션(intersection)을 "프리픽스"로서 사용한다. 이 용어 프리픽스는 본 명세서에서는 서브넷 할당의 차원에서 사용되지 않는다.

- 양 2 튜플 엔트리들이 동일한 상태(통과 상태(76) 또는 차단 상태(78))를 가지면, 이 상태는 결합된 2 튜플 엔트리에 전달된다. 이 상태가 통과 상태(76)이면, 결합된 2 튜플 엔트리의 카운터는 선행하는 2 튜플 엔트리들의 최대 카운터로 설정되고 결합된 만료 시간은 선행하는 2 튜플 엔트리들의 최소 만료 시간으로 설정된다. 이 상태가 차단 상태(78)이면, 결합된 2 튜플 엔트리의 만료 시간은 선행하는 2 튜플 엔트리들의 최대 만료 시간으로 설정된다.

- 양 2 튜플 엔트리들이 서로 다른 상태를 갖는다면(하나는 통과 상태(76)에 있고 다른 하나는 차단 상태(78)에 있다면), 결합된 2 튜플 엔트리는 차단 상태(78)로 설정되고 만료 시간은 리셋된다.

- 결합 절차에서 사용되는 2 튜플 엔트리를 선택하는 바는 결합된 2 튜플에 대한 가장 긴 프리픽스에 기초할 수 있다. 이 프리픽스가 길수록 외부 호스트들의 IP 어드레스들 간의 토폴러지 상의 거리가 짧아진다. 이러한 선택 프로세스를 위한 컴퓨팅 작업은 소량인데 그 이유는 개수 N이 작게 선택될 수 있기 때문이다.

가령 N = 3으로 선택될 수 있다. 이 경우에 새로운 KOF REQ 메시지가 내부 호스트 Hi에 대해서 도달할 때에 내부 호스트 Hi는 이미 N = 3 개의 2 튜플 엔트리들을 갖는다.

2 튜플 엔트리 1 & 3이 결합되는데 그 이유는 이들이 가장 큰 공통 프리픽스를 구비하기 때문이며 그 결과는 다음과 같다.

- 상태 1로서 도시된 바와 같은 결합된 KOF 상태는 IP 어드레스의 최하위의 2 개의 옥텟(octet)에서 사용된 'X.X'로 인해서 이른바 프리픽스 기반 형태로 되어 있는 외부 호스트 Ho IP 어드레스 200.1.X.X를 갖는다. 'X.X'는 외부 호스트들의 IP 어드레스들의 대응하는 옥텟들에 대해서 모든 값들을 매치시킨다. 또한, 결합된 KOF 상태의 통과 상태 카운터(메시지 카운터)는 3으로 설정되며, 이는 선행하는 KOF 상태 1 및 상태 3의 통과 상태 카운터의 값들보다 크다. 새로운 KOF 상태의 통과 상태 타이머(만료 시간)는 '현재 + 3120 msec'로 설정되며, 이는 선행하는 KOF 상태 1 및 상태 3의 통과 상태 타이머보다 짧다.

KOF는 2 튜플 엔트리 결합 이력에 대한 어떠한 정보도 유지할 필요가 없다. 상태 전환이 통상적인 IP 어드레스 기반 상태에서와 동일한 방식으로 프리픽스 기반 상태에도 적용된다. 유휴 상태(74)에 이르면, 상태 번들링(bundling) 정보는 손실되는데 그 이유는 유휴 상태(74)에서는 어떠한 메모리도 유지되지 않기 때문이다. 이 메카니즘은 상태 번들링을 순조롭게 반전시키며 KOF가 그의 정상적인 동작 모드로 릴렉스(relax)하도록 한다.

상술한 결합 프로세스는 내부 호스트 Hi에 대한 최대 2 튜플 엔트리 개수 N에 기초한다. 이 개수는 동적으로 조절될 수 있다. 또는, 고정된 N 값이 각 내부 호스트 Hi에 할당되거나 이와 달리 하나의 공통 2 튜플 엔트리 풀(pool)이 모든 내부 호스트 Hi 대신에 할당될 수 있다. 이 풀이 채워지고 새로운 2 튜플 엔트리들이 부가되어야 한다면, 가장 많은 개수의 2 튜플들을 갖는 내부 호스트 Hi가 선택될 수 있다. 이 풀이 내부 호스트들 Hi의 개수보다 작으면, 모든 내부 호스트 Hi가 2 개 이상의 2 튜플 엔트리를 유지하지 않은 채로 이 풀이 채워지게 된다. 이 경우에, 동일한 결합 절차가 Hi IP 어드레스에 대해서 적용될 수 있다. 이 경우에, 2 튜플 엔트리들은 역시 내부 호스트 Hi 대신에 프리픽스를 유지할 수 있다.

프리픽스 기반형 보호에 있어서, 소스 IP 어드레스 풀을 사용하여서 내부 호스트 Hi에 대하여 KOF REQ 메시지들을 대량으로 공격하면 이 공격자의 서브넷과 관련된 내부 호스트 Ho IP 어드레스 프리픽스를 갖는 하나의 2 튜플 엔트리는 차단 상태(78)에 놓이게 된다. 이 공격자로부터의 내부 호스트 Hi로의 모든 추가 KOP REQ 메시지들은 통합형 KOP 방화벽(12)에 의해서 차단될 것이다. 이와 동시에, 통합형 KOP 방화벽(12)은 이 내부 호스트 Hi와 접속을 확립하고자 시도하는 다른 서브넷으로부터의 외부 호스트에 대해서는 정상적으로 동작할 것이다.

이러한 대량 공격은 통상적으로 일 서브넷과 관련된 IP 어드레스로 한정되는데 그 이유는 중간 라우터의 인그레스 필터링이 출처가 불명확한 패킷들을 폐기하기 때문이다. 확률이 적지만 공격자가 전체 인터넷으로부터 IP 어드레스를 도용한 경우에도, 프리픽스 기반형 보호는 모든 인바운드 KOF REQ 메시지들을 차단할 것이다. 이러한 경우에, 통합형 KOF 방화벽(12)은 통상적인 방화벽과 동일한 보호 기능을 제공한다.

내부 호스트 Hi를 KOP REQ 메시지의 대량 공격으로부터 보호하는 것 이외에, 프리픽스 기반형 보호는 유리하게는 2 튜플 엔트리에 대해 필요한 메모리의 양을 한정한다. 더 유리하게는, 프리픽스 기반형 보호는 새로운 KOP REQ 메시지가 내부 호스트 Hi에 대해서 도달할 때에 컴퓨팅 작업을 저감시키는데 그 이유는 오직 작은 개수의 KOF 상태만이 각 호스트에 대해서 유지되기 때문이다.

레거시 방화벽에 직렬로 부가된 KOF( Knock - On Feature )

다시 도 2를 참조하면, 구체적으로 제 2 네트워크 아키텍처(10b)를 참조하면, KOF(18)는 별도의 기능으로서 방화벽(20)에 직렬로 부가될 수 있다. 이는 UDP 기반 KOP 메시지들이 사용되는 경우에 달성하기에 특이 용이하다. 이 경우에, 대응하는 UDP 포트는 방화벽 상에서 개방될 것이다.

도 6은 KOF(18)가 방화벽(20)에 직렬로 되어 있는 제 2 네트워크 아키텍처(10b)의 KOF(18) 및 방화벽(20)의 5 튜플 상태 및 2 튜플 상태 및 상태 전환을 나타내고 있다. 이 경우에 방화벽(20)은 통상적인 방화벽 기능을 제공하는 5 튜플(100)을 지원하는 레거시 방화벽이다. KOF(18)은 통합형 KOF 방화벽(12)을 참조하여서 전술한 바와 같은 2 튜플(62)과 동일한 방식으로 동작하는 2 튜플(102) 및 5 튜플(104)을 지원한다.

5 튜플(100)은 내부 호스트 Hi와 외부 호스트 Ho 간의 접속과 연관된 대응하는 5 튜플에 대한 상태를 유지한다. FW(20)는 특정 5 튜플이 통과 상태(106) 또는 차단 상태(108)로 유지되어야 하는지의 여부를 제어하거나 통과 상태(106)에서 차단 상태(108)로 전환되거나 차단 상태(108)에서 통과 상태(106)로 전환되어야 하는지의 여부를 제어한다. 통과 상태(106)에 있는 동안에 통과 타이머가 갱신되고 통과 타이머가 만료되면 5 튜플(100) 상태는 통과 상태(106)에서 차단 상태(108)로 전환된다(110). 이와 달리, 대응하는 5 튜플의 인바운드 패킷 또는 아웃바운드 패킷이 방화벽(20)을 통과하는 한 FW 상태는 통과 상태로 유지된다(112). 통과 상태(106)로 유지되는 때에, 통과 상태(106)와 연관된 타이머가 리셋된다. 차단 상태(108)에 있는 동안에, 대응하는 5 튜플의 아웃바운드 패킷이 방화벽(20)을 통과하는 경우에는 방화벽 상태는 차단 상태(108)에서 통과 상태(106)로 전환될 것이다(114).

KOF(18)는 내부 호스트 Hi와 외부 호스트 Ho 간의 인바운드 KOP REQ 메시지와 연관된 2 튜플을 유지한다. 방화벽(20)이 KOP 메시지들을 브리지(bridge)하기 때문에, KOF(18)는 KOF 통합형 FW(12)가 2 튜플(62)을 운용한 바와 동일한 방식으로 제 2 네트워크 아키텍처(10b)에서도 2 튜플(102)을 운용한다. 본 실시예에 대한 전술한 설명을 간략하게 하기 위해서, KOF(18)가 2 튜플(102)을 다루는 바는 KOF 통합형 FW(12)에서 2 튜플(62)에 대해서 이루어진 바와 동일한 방식으로 구현된다고 이해하면 될 것이다.

제 1 네트워크 아키텍처(10a)의 통합형 방식과 달리, 제 2 네트워크 아키텍처(10b)의 KOF(18)은 5 튜플(100)에 대해서 동작하는 FW(20)에 대하여 직렬로 해서 5 튜플(104)에 대해서 동작한다. KOF(18)에 의해서 유지되는 5 튜플은 내부 호스트 Hi와 외부 호스트 Ho 간의 임의의 실제적 또는 잠재적인 접속에 대응한다. KOF(18)는 5 튜플(104)이 통과 상태(116) 또는 차단 상태(118)로 유지되어야 하는지의 여부를 제어하거나 통과 상태(116)에서 차단 상태(118)로 전환되거나 차단 상태(118)에서 통과 상태(116)로 전환되어야 하는지의 여부를 제어한다. KOF(18)는 KOF FIN 메시지를 지원하는데, 즉 내부 호스트 Hi로부터의 아웃바운드 KOP FIN 메시지에 기초하여서 내부 호스트 Hi로 향하는 5 튜플의 트래픽 패킷을 차단한다. 따라서, KOF 5 튜플(104) 상태가 통과 상태(116)에 있고 이 5 튜플(104)에 대응하는 KOP FIN 메시지가 아웃바운드 방향에서 KOF(18)를 통과할 때에, 통과 상태(116)에 있는 5 튜플(104)은 차단 상태(118)로 전환된다(120). 이와 달리, KOP FIN 메시지가 KOF(18)를 통과할 때에 KOF 5 튜플(104) 상태가 이미지 차단 상태(118)에 있게 되면, KOF 5 튜플(104) 상태는 차단 상태(118)로 유지되고(122) 5 튜플 차단 상태 타이머가 리셋된다. 차단 상태 타이머가 만료되거나 5 튜플에 대응하는 아웃바운드 패킷이 내부 호스트 Hi로부터 KOF(18)을 통과하면, 5 튜플(104)은 차단 상태(118)에서 통과 상태(116)로 전환된다(124). 5 튜플(100)의 통과 상태 타이머가 만료되는데 걸리는 시간과 균등한 시간 후에 차단 상태 타이머가 만료된다.

5 튜플(100)이 이 5 튜플(100)에 대해서 오직 통과 상태(106)만을 구현함으로써 실현되는 반면에, KOF의 5 튜플(104)은 이 5 튜플(104)에 대해서 오직 차단 상태(118)만을 구현함으로써 실현될 수 있다. 따라서, KOF의 5 튜플(104)에 대해서 필요한 메모리 요구 사항은 방화벽의 5 튜플(100)에 대해서 필요한 메모리 요구 사항과 대략 동일하거나 이보다 작을 수 있다. 즉, 방화벽의 5 튜플(100)에 대해서, 통과 상태(106)에 있는 방화벽 상태는 [그의 대응하는 접속 활성 시간 + 통과 상태(106)의 활성 시간] 동안에 메모리를 점유한다. 반면에, KOF의 5 튜플(104)에 대해서는, 차단 상태(118)에 있는 KOF 5 튜플 상태는 각각의 차단 상태 타이머에 의해서 결정되는 차단 상태(118) 활성 시간 동안만 메모리를 점유하고, 전술한 바와 같이, 차단 상태 타이머는 방화벽의 5 튜플(100) 통과 상태(106)의 통과 상태 타이머가 만료되는데 필요한 시간과 균등한 시간 이후에 만료된다.

제 2 네트워크 아키텍처(10b)의 5 튜플(100) 동작 및 KOF 5 튜플(104) 동작의 결합은 통합형 KOF 방화벽(12)에서의 5 튜플(60) 동작과 동일한 기능을 달성한다. 그러나, 제 2 네트워크 아키텍처(10b)의 직렬 방식은 KOF ACK 메시지를 지원하지 않는다. 유리하게는, KOF ACK 메시지의 효과는 정상적인 트래픽 패킷에 의해서 달성될 수 있다.

도 7 및 이에 대응하는 제 3 네트워크 아키텍처(10c)에서, KOF는 레거시 FW(20)를 지원하는 릴레이 서버(RS)(22) 상에 제공된다. RS(22)는 공중 인터넷 내에 있거나 적어도 공중 인터넷으로부터 액세스 가능하다고 가정된다. 또한, 내부 호스트 Hi는 RS(22)로의 시그널링 접속을 갖는다. 내부 호스트 Hi가 DNS(domain name sever)를 사용하여서 가령 자신이 통과하게 되는 RS(22)의 IP 어드레스, 프로토콜 타입 및 포트를 공표한다.

통합형 KOF 방화벽(12)의 보안 수준과 균등한 보안 수준을 제공하기 위해서, 이 제 3 네트워크 아키텍처(10c)에서, 내부 호스트 Hi와 RS(22) 간의 시그널링 접속(signaling connection)을 따르는 트래픽은 무결성 보호된다. 이는 시그널링 트래픽은 공중 인터넷을 통과하고 따라서 무결성 공격에 취약하기 때문에 수행된다.

외부 호스트 Ho가 KOP REQ 메시지를 RS(22)에 전송할 때에, 외부 호스트 Ho는 KOP REQ 메시지의 페이로드 내의 내부 호스트 Hi를 명시적으로 참조할 필요가 있다. 이는 통합형 KOF FW(12)이 KOP REQ 메시지의 IP 헤더로부터 내부 호스트 Hi를 추론하는 제 1 네트워크 아키텍처(10a)에서와 상이하다. 동일한 방식으로, 외부 호스트 Ho는 프로토콜 타입 및 포트 넘버에 대한 정보를 KOP REQ 메시지의 페이로드 내에 부가할 수 있다.

그러나, 이러한 방식은 공격에 더 취약하게 한다. 즉, 내부 호스트 Hi의 IP 어드레스가 라우팅 목적을 위해서 사용되지 않고 오직 KOP REQ 메시지의 페일드 내에서 운반되기 때문에, 이는 임의의 공격자에 의해서 변경될 수 있다. 이러한 공격에 대한 취약성을 극복하기 위해서, 외부 호스트 Ho는 RS(22)로 전송된 KOP REQ 메시지의 무결성을 보호해야 한다.

KOP REQ 메시지의 이러한 무결성 보호는 공중/사설 키 쌍 또는 공유된 키를 통해서 달성될 수 있다. 가령 DH(Diffie-Hellman) 교환을 사용하는 보안 연계는 충분할 수 있다. DH 교환을 기초로 하는 이러한 공유형 키들을 파괴하기 위해서, 각 엔드와의 개별 접속을 유지하는 MitM(man-in-the-middle) 시스템이 요구될 것이다. 이러한 절차에서, MitM 시스템은 중간 라우터에 의한 인그레스 필터링에 의해서 공격을 받지 않으면서 각각의 엔트 포인트의 IP 어드레스를 도용할 필요가 있을 것이다. 만일에 이러한 MitM 시스템이 존재한다면, 이 시스템은 FW(20) 상의 기존의 5 튜플 엔트리들로의 IP 어드레스들을 도용함으로써 방화벽(20)을 직접적으로 극복할 것이다. 따라서, RS(22)와 외부 호스트 Ho 또는 내부 호스트 Hi 간의 KOP 메시지 교환을 위해서 DH 기반형 키들을 사용하는 것은 이러한 교환의 무결성 보호에 있어서 충분할 수 있는데 그 이유는 레거시 FW(20)가 제공하는 바와 같은 동일한 수준의 보호를 최소한 제공할 수 있기 때문이다.

도 7 및 도 3의 제 3 네트워크 아키텍처(10c)를 참조하면, RS(22)와 내부 호스트 및 외부 호스트 Ho/Hi 간의 예시적인 메시지 호 흐름(200)은 다음과 같이 발생한다.

- 내부 호스트 Hi와 RS(22)가 DH 교환을 사용하여서 보안 시그널링 접속을 확립한다(202). 이는 FW(20) 상에 상기 내부 호스트 Hi와 RS(22)에 대응하는 제 1 5 튜플을 생성한다.

- 외부 호스트 Ho가 DH 교환을 사용하여서 RS(22)와 보안 접속을 확립한다.

- 외부 호스트 Ho가 KOP REQ 메시지를 먼저 무결성 보호한 후에 이 메시지를 RS(22)에 전송한다. KOP REQ 메시지의 페이로드는 사전 규정된 파라미터 타입을 사용하여서 내부 호스트 Hi의 데이터를 포함한다. 이 데이터는 제안된 접속을 위해서 사용될 내부 호스트 Hi의 IP 어드레스, 프로토콜 타입 및 포트 넘버를 포함한다.

- RS(22) 상에 상주한 KOF는 KOP REQ 메시지를 평가한다. 이를 위해서, KOF는 제 1 네트워크 아키텍처(10a) 및 제 2 네트워크 아키텍처(10b)를 참조하여서 전술된 바와 동일한 2 튜플(62) 동작을 사용한다.

- 내부 호스트 Hi 및 외부 호스트 Ho의 IP 어드레스들에 대응한 2 튜플에 대한 KOF 상태가 차단 상태(78)에 있지 않으면, RS(22)는 시그널링 링크를 통해서 KOP REQ 메시지를 내부 호스트 Hi로 터널링한다(208). RS(22)는 전술한 바와 같이 KOP REQ 메시지에 대해서 무결성 보호를 제공한다. KOP REQ 메시지는 외부 호스트 Ho의 IP 어드레스를 포함한다.

- 상기 메시지가 반송되는 시그널링 링크가 FW(20) 상의 제 1 5 튜플 엔트리의 생성과 관련하여서 전술한 바와 같이 이미 확립되었기 때문에 FW(20)는 KOP REQ 메시지가 통과되게 한다(210).

- 내부 호스트 Hi는 외부 호스트 Ho를 직접적으로 컨택하기 위해서 KOP REQ 메시지 내의 정보를 사용한다. 이러한 컨택은 내부 호스트 Hi와 외부 호스트 Ho에 대응하는 FW(20) 상의 제 2 5 튜플 엔트리를 생성하며, 이 엔트리는 외부 호스트 Ho가 내부 호스트 Hi로부터의 통신에 직접적으로 응답하게 한다.

- 내부 호스트 Hi가 KOP NAK 메시지를 외부 호스트 Ho에 전송하기를 원할 경우에(212), 내부 호스트 Hi는 RS(22)로의 시그널링 접속을 사용하고 외부 호스트 Ho의 IP 어드레스를 포함하며 상기 메시지를 무결성 보호한다. FW(20)는 무결성 보호된 KOP NAK 메시지를 RS(22)에 전송한다(214). RS(22)는 이 메시지를 입증하고 그 상의 2 튜플(62)은 차단 상태(78)로 전환되고 KOP NAK 메시지를 외부 호스트 Ho에 전송한다(216).

- 내부 호스트 Hi는 또한 KOP REQ 메시지에 응답하여서 KOP ACK 메시지를 외부 호스트 Ho에 전송할 수도 있다(218). FW(20)은 KOP REQ 메시지를 RS로 제공한다. RS(22) 상에 내장된 KOF는 전술한 FW 5 튜플(60)과 동일하면서 내부 호스트 Hi와 외부 호스트 Ho의 5 튜플에 대응하는 FW 상태를 유지하는 5 튜플에 대한 엔트리를 유지한다. 이 5 튜플의 FW 상태는 RS(22)가 KOP ACK 메시지를 외부 호스트 Ho에 전달할 때에(222) 통과 상태(68)로 설정된다. 이 5 튜플의 FW 상태가 통과 상태(68)에 있을 때에, RS(22)는 임의의 정보를 외부 호스트 Ho에서 내부 호스트 Hi로 릴레이하거나 이와 반대로 릴레이할 것이다.

- 또한, 내부 호스트 Hi는 KOP REQ 메시지에 응답하여서 외부 호스트 Ho에 KOP RSP 메시지를 전송할 수도 있다. 이 메시지는 KOP ACK 메시지에 대해서 전술한 바와 동일한 방식으로 외부 호스트 Ho에 통신될 수 있다. 외부 호스트 Ho는 이 KOP REQ 메시지가 요청한 정보를 포함하는 다른 KOP REQ 메시지를 사용하여서 상기 KOP RSP 메시지에 응답할 것이다. 이 제 2 KOP REQ 메시지는 제 1 KOP REQ 메시지에 대해서 전술한 바와 동일한 방식으로 내부 호스트 Hi에 통신될 것이다. 다수의 이러한 KOP RSP 메시지/KOP REQ 메시지 교환(224)이 허용된다.

- 내부 호스트 Hi는 KOP ACK 메시지를 통해 개시된 릴레이 접속을 종료하기 위해서 KOF FIN 메시지를 외부 호스트 Ho에 전송할 수 있다(226). 이 KOF FIN 메시지는 KOP ACK 메시지에 대해서 전술한 바와 동일한 방식으로 외부 호스트 Ho에 릴레이된다. 상기 KOP FIN 메시지 및 KOP ACK 메시지는 RS(22)가 모든 트래픽 데이터를 릴레이하는 경우에 사용된다.

도 8은 도 3의 제 1 아키텍처 네트워크(10a)에서 도시된 실시예에 따른 통합형 KOF FW(12)에 의해서 수행되는 인바운드 패킷을 다루는 방법(400)을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 5에 도시된 상태 전환을 포함하지 않는다.

도 8의 방법(400)은 인바운드 패킷이 통합형 KOF FW(12)에 도달하기를 대기한다(402). 인바운드 패킷이 도달하면, 이 패킷이 KOP REQ 메시지인지의 여부가 판정된다(404). 이 패킷이 KOP REQ 메시지가 아니면, 이 패킷이 통합형 KOF FW(12) 상에 이미 저장된 5 튜플 엔트리와 일치하는지 여부가 판정된다(410). 서로 일치하는 5 튜플 엔트리가 존재하면, 이 5 튜플 엔트리에 대응하는 타이머가 리프레시되고(406) 패킷을 내부 호스트 Hi로 통과시키고(408), 다른 인바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 단계(410)에서, 통합형 KOF FW(12) 상에 어떠한 일치하는 5 튜플 엔트리가 존재하지 않는다고 판정되면, 패킷은 차단되고(412) 이 방법은 다른 인바운드 패킷 도달을 기다리기 시작한다.

단계(400)에서, 상기 패킷이 KOP REQ 메시지라고 판정되면, 단계(414)에서 이 패킷과 일치하는 2 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다. 어떠한 일치하는 2 튜플 엔트리도 존재하지 않는다면, 상기 패킷에 대응하는 2 튜플 엔트리를 생성하고(416) 이 엔트리를 통과 상태로 만든다. 이어서, 이 패킷을 내부 호스트 Hi에 통과시키고(418), 다른 인바운드 패킷 도달을 기다리기 시작한다. 단계(414)에서, 서로 일치하는 2 튜플 엔트리가 존재하면, 이 엔트리가 차단 상태에 있는지의 여부가 판정된다(420). 이 엔트리가 차단 상태에 있다면, 이 방법은 이 패킷을 차단하고(422) 다른 인바운드 패킷 도달을 기다리기 시작한다. 그러나, 단계(420)에서 이 2 튜플 엔트리가 차단 상태에 있지 않다고 판정되면, 이 엔트리에 대응하는 2 튜플 카운터가 증분되고 이어서 이 카운트가 오버로드(overload)되었는지의 여부가 판정된다(428). 이 카운터가 오버로드되었으면, 2 튜플 엔트리가 차단 상태로 설정되고(426) 이 엔트리에 대한 타이머를 리셋한다. 이어서, 이 패킷이 차단되고(422) 이 방법은 다른 인바운드 패킷 도달을 기다리기 시작한다. 그러나, 상기 카운터가 오버로드되지 않았다면, 이 패킷이 내부 호스트 Hi로 전달되고(430) 이 방법은 다른 인바운드 패킷 도달을 기다리기 시작한다.

도 9는 도 3의 제 1 아키텍처 네트워크(10a)에서 도시된 실시예에 따른 통합형 KOF FW(12)에 의해서 수행되는 아웃바운드 패킷을 다루는 방법(500)을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 5에 도시된 상태 전환을 포함하지 않는다.

도 9의 방법(500)은 아웃바운드 패킷이 통합형 KOF FW(12)에 도달하기를 대기한다(502). 아웃바운드 패킷이 도달하면, 이 패킷이 KOP 메시지인지의 여부가 판정된다(504). 이 패킷이 KOP 메시지가 아니면, 이 패킷과 일치하는 5 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다(506). 일치하는 5 튜플 엔트리가 존재하면, 이 5 튜플 엔트리에 대응하는 타이머가 리셋되고(508) 이 패킷을 외부 호스트 Ho로 전달하고(510), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 통합형 KOF FW(12) 상에 어떠한 일치하는 5 튜플 엔트리가 존재하지 않는다고 판정되면, 이 패킷에 대응하는 5 튜플 엔트리가 생성되고(512) 이 패킷을 외부 호스트 Ho로 전달하고(510), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(504)에서, 상기 패킷이 KOP 메시지라고 판정되면, 단계(514)에서 이 패킷이 KOP ACK 메시지인지의 여부가 판정된다. 만일 그러하다면, 단계(516)에서, 일치하는 5 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다. 일치하는 5 튜플 엔트리가 존재한다면, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 어떠한 일치하는 5 튜플 엔트리도 존재하지 않는다면, 상기 패킷에 대응하는 5 튜플 엔트리를 생성하고(518) 이 패킷을 외부 호스트 Ho로 전달하고, 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(514)에서 이 패킷이 KOP ACK 메시지가 아니라고 판정되면, 단계(522)에서 이 패킷이 KOP FIN 메시지인지의 여부가 판정된다. 그러하다면, 단계(524)에서, 일치하는 5 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다. 일치하는 5 튜플 엔트리가 존재하지 않는다면, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 5 튜플 엔트리가 존재한다면, 이 5 튜플 엔트리가 삭제되고(526) 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(522)에서 이 패킷이 KOP FIN 메시지가 아니라고 판정되면, 단계(528)에서 이 패킷이 KOP RSP 메시지인지의 여부가 판정된다. 그러하다면, 단계(530)에서, 이 패킷과 일치하는 2 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다. 일치하는 2 튜플 엔트리가 존재하지 않는다면, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 2 튜플 엔트리가 존재한다면, 단계(532)에서, 이 엔트리가 통과 상태에 있는지의 여부가 판정된다. 그러하다면, 이 2 튜플 엔트리에 대응하는 타이머 및 카운터가 리셋되고(534), 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 단계(532)에서, 2 튜플 엔트리가 통과 상태에 있지 않다고 판정되면, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(528)에서 이 패킷이 KOP RSP 메시지가 아니라고 판정되면, 단계(536)에서 이 패킷이 KOP NAK 메시지인지의 여부가 판정된다. 그러하다면, 단계(538)에서, 이 패킷과 일치하는 2 튜플 엔트리가 통합형 KOF FW(12) 상에 존재하는지의 여부가 판정된다. 일치하는 2 튜플 엔트리가 존재하지 않는다면, 이 패킷에 대응하는 2 튜플 엔트리가 통합형 KOF FW(12) 상에 생성되고(540) 이 엔트리를 차단 상태로 설정한다. 이어서, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 2 튜플 엔트리가 존재한다면, 이 엔트리를 차단 상태로 설정하고(542) 이 엔트리에 대응하는 타이머를 리셋하고, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(536)에서 상기 패킷이 KOP NAK 메시지가 아니라고 판정되면, 이 패킷을 외부 호스트 Ho로 전달하고(520), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

도 10은 도 3의 제 2 아키텍처 네트워크(10b)에서 도시된 실시예에 따른 방화벽(20)에 직렬로 부가된 KOF(18)에 의해서 수행되는 인바운드 패킷을 다루는 방법(600)을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 6에 도시된 상태 전환을 포함하지 않는다.

도 10의 방법(600)은 인바운드 패킷이 KOF(18)에 도달하기를 대기한다(602). 인바운드 패킷이 도달하면, 이 패킷이 KOP REQ 메시지인지의 여부가 판정된다(604). 이 패킷이 KOP REQ 메시지가 아니면, 이 패킷을 FW(20)로 통과시키고(606) 다른 인바운드 패킷 도달을 기다리기 시작한다. 만일 상기 패킷이 KOP REQ 메시지이면, 이 패킷이 KOF(18) 상에 이미 저장된 2 튜플 엔트리와 일치하는지 여부가 판정된다(608). 서로 일치하는 2 튜플 엔트리가 존재하지 않으면, 이 패킷에 대응하는 2 튜플 엔트리가 생성되고(610) 이 엔트리를 통과 상태로 설정한다. 이어서, 이 패킷을 FW(20)로 통과시키고(612) 다른 인바운드 패킷 도달을 기다리기 시작한다. 단계(608)에서, 일치하는 2 튜플 엔트리가 존재한다면, 단계(614)에서, 이 엔트리가 차단 상태에 있는지의 여부가 판정된다. 그러하다면, 이 패킷이 차단되고(616) 다른 인바운드 패킷 도달을 기다리기 시작한다.

단계(614)에서, 이 2 튜플 엔트리가 차단 상태에 있지 않다고 판정되면, 이 통과 상태에 있는 엔트리에 대응하는 2 튜플 카운터가 증분되고, 이어서 단계(622)에서, 카운터가 오버로드되었는지의 여부가 판정된다. 이 카운터가 오버로드되었다면, 2 튜플 엔트리를 차단 상태로 설정하고(620) 이 엔트리에 대응하는 타이머를 리셋한다. 이어서, 이 패킷이 차단되고(616) 다른 인바운드 패킷 도달을 기다리기 시작한다. 그러나, 카운터가 오버로드되지 않았다면, 이 패킷은 FW(20)로 전달되며(624) 다른 인바운드 패킷 도달을 기다리기 시작한다.

도 11은 도 3의 제 2 아키텍처 네트워크(10b)에서 도시된 실시예에 따른 방화벽(20)에 직렬로 부가된 KOF(18)에 의해서 수행되는 아웃바운드 패킷을 다루는 방법(700)을 나타내는 흐름도이다. 이 흐름도는 타이머 만료로 기인되는 도 6에 도시된 상태 전환을 포함하지 않는다.

도 11의 방법(700)은 아웃바운드 패킷이 KOF(18)에 도달하기를 대기한다(702). 아웃바운드 패킷이 도달하면, 이 패킷이 KOP 메시지인지의 여부가 판정된다(704). 이 패킷이 KOP 메시지가 아니면, 이 패킷과 일치하는 5 튜플 엔트리가 KOF(18) 상에 존재하는지의 여부가 판정된다(706). 어떠한 일치하는 5 튜플 엔트리도 존재하지 않는다면, 이 패킷을 외부 호스트 Ho를 향해서 통과시킨다(708). 이어서, 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 일치하는 5 튜플 엔트리가 존재한다면, 차단 상태에 있는 5 튜플 엔트리를 삭제하고(710), 이 패킷을 외부 호스트 Ho를 향해서 통과시킨다(708). 이어서, 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(704)에서, 상기 패킷이 KOP 메시지이면, 단계(712)에서, 이 패킷이 KOP FIN 메시지인지의 여부가 판정된다. 그러하다면, KOF(18) 상에 일치하는 5 튜플 엔트리가 존재하는지의 여부가 판정된다. 어떠한 일치하는 5 튜플 엔트리도 존재하지 않는다면, 이 패킷을 외부 호스트 Ho를 향해서 통과시킨다(708). 이어서, 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 5 튜플 엔트리가 존재한다면, 이 패킷에 대응하는 5 튜플 엔트리가 생성되고(716) 이를 차단 상태로 설정한다. 이어서, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(712)에서, 상기 패킷이 KOP FIN 메시지가 아니라면, 단계(718)에서, 이 패킷이 KOP RSP 메시지인지의 여부가 판정된다. 그러하다면, KOF(18) 상에 일치하는 2 튜플 엔트리가 존재하는지의 여부가 판정된다(720). 어떠한 일치하는 2 튜플 엔트리도 존재하지 않는다면, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 2 튜플 엔트리가 존재한다면, 이 엔트리가 통과 상태에 있는지의 여부가 판정된다(722). 그러하다면, 이 엔트리에 대응하는 타이머 및 카운터가 리셋되고(724) 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 이 일치하는 2 튜플 엔트리가 통과 상태에 있지 않다면, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

단계(718)에서, 상기 패킷이 KOP RSP 메시지가 아니라고 판정되면, 단계(726)에서, 이 패킷이 KOP NAK 메시지인지의 여부가 판정된다. 그러하다면, KOF(18) 상에 이 패킷과 일치하는 2 튜플 엔트리가 존재하는지의 여부가 판정된다(728). 어떠한 일치하는 2 튜플 엔트리도 존재하지 않는다면, 이 패킷에 대응하는 2 튜플 엔트리가 KOF(18) 상에서 생성되고(730) 이 엔트리가 차단 상태로 설정된다. 이어서, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다. 이와 달리, 일치하는 2 튜플 엔트리가 존재한다면, 이 엔트리를 차단 상태로 설정하고(732) 이 엔트리에 대응하는 타이머를 리셋한다. 이어서, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

만일 단계(726)에서, 상기 패킷이 KOP NAK 메시지가 아니라고 판정되면, 이 패킷을 외부 호스트 Ho를 향해서 통과시키고(708), 다른 아웃바운드 패킷 도달을 기다리기 시작한다.

NAT ( Network Address Translator )에 대한 애플리케이션

대부분의 NAT들은 네트워크 어드레스 변환 기능 또는 네트워크 어드레스/포트 변환 기능을 방화벽 기능과 결합시킨다. 이 경우에, 상술한 바와 같은 동일한 KOF 방법들이 적용될 수 있다. 그러나, NAT로 인해서, 내부 호스트 Hi의 내부 어드레스 및 포트 넘버들은 NAT에 의해서 변환되는 그의 공중 어드레스 및 포트 넘버들과 상이하다. 따라서, 외부 호스트 Ho는 내부 호스트 Hi에 도달하는 방식을 알지 못할 수 있다. 나아가, 내부 호스트 Hi는 그의 공중 IP 어드레스를 모를 수 있다. 이러한 상황은 KOP 메시지에 영향을 줄 뿐만 아니라 전송 접속 확립에도 영향을 준다.

KOP 메시지가 통상적인 전송 포트 (UDP 또는 TCP)에 의해서 지원되면, 호스트는 IETF(RFC 5389)가 제안한 STUN(Connection Traversal Utilties for NAT)를 사용하여서 그의 KOP 공중 IP 어드레스 및 포트 넘버를 찾을 수 있다. 내부 호스트 Hi는 DNS 내의 데이터가 공중에서 가용되도록 이 데이터를 공표할 수 있다.

내부 호스트 Hi는 STUN 방법을 사용하여서 자신이 셋업하기를 희망하는 전송 접속을 위한 공중 IP 어드레스 및 포트 넘버를 찾을 수 있다. 이 STUN 방법의 결과는 접속 셋업 시에 KOP REQ 메시지 내에 포함되어서 원격 호스트에 전송된다. 이 원격 호스트가 NAT 후방에 상주하면, 이 호스트는 동일한 STUN 방법을 사용하여서 KOP ACK 메시지 또는 KOP RSP 메시지 내에 포함시켜서 그 자신의 공중 IP 어드레스 및 포트 넘버를 되돌려 전송한다. 내부 호스트 및 외부 호스트가 전송 패킷을 서로에 대해서 전송할 수 있는데 이러한 동작은 각각의 NAT 상에 5 튜플 엔트리를 생성할 것이다. 종종 "홀 펀칭(hole punching)"으로 지칭되는 이러한 기술은 전송 접속이 이 호스트들 간에서 확립되게 한다.

동일한 주요한 방법들이 KOP 메시지들이 가령 IPv6(IP Extension header) 또는 IPv4(IP Option header)를 통해서 전송 접속 상으로 멀티플렉싱되거나 전송 층 내로 내장될 때에 적용될 수 있다. 이러한 방법은 호스트의 DNS 서버 내에 공표될 수 있는 KOP 어드레스 및 포트 넘버가 오직 하나가 아니라는 단점을 갖는다. 이 경우에, RS가 사용될 수 있다. RS는 (양 호스트들이 NAT 후방에 있으면) 이들에 대하여 STUN 서비스를 수행하며 이들을 KOP 메시지 교환 시에 포함시킨다.

마지막으로, 일 NAT 또는 양 NAT가 대칭형 NAT이면, RS의 기능은 KOP 메시지 교환으로부터 전송 데이터 터널링까지 확대될 수 있다.

수많은 변경 및 수정 및 대체가 다음의 청구 범위에서 규정되는 본 발명의 범위를 벗어나지 않고서 상술한 바와 같은 본 발명의 실시예들에 대해서 이루어질 수 있다.

Claims (10)

1. 제 2 호스트 시스템을 보호하는 방화벽을 통해서 제 1 호스트 시스템과 상기 제 2 호스트 시스템 간의 접속을 확립하는 방법으로서,
   KOF(knock-on-feature) 장치에 의해서,
   상기 제 1 호스트 시스템에 의해 전송된 제 1 메시지를 수신하는 단계와,
   상기 제 1 메시지가 상기 제 1 호스트 시스템과 상기 제 2 호스트 시스템 간의 접속을 확립하기 위한 제 1 타입이라고 판정하는 단계와,
   상기 제 1 메시지로부터 상기 제 1 호스트 시스템과 상기 제 2 호스트 시스템 각각의 어드레스를 판정하는 단계와,
   상기 제 1 호스트 시스템과 상기 제 2 호스트 시스템의 어드레스에 대응하는 2 튜플(2 tuple)에 대한 임의의 상태 정보가 상기 KOF 장치상에 존재하는지의 여부를 판정하는 단계와,
   상기 2 튜플에 대한 상기 상태 정보가 상기 KOF 장치상에 존재하지 않으면 상기 제 1 메시지를 상기 제 1 호스트 시스템으로 전송하는 단계를 포함하고,
   하나의 호스트 시스템 쌍에 대해 결합된 타이머를 2 개의 호스트 시스템 쌍의 각각의 제 1 타이머의 최소치로 설정하는 단계와,
   상기 하나의 호스트 시스템 쌍에 대해 결합된 메시지 카운터를 상기 2 개의 호스트 시스템 쌍의 각각의 메시지 카운터의 최대치로 설정하는 단계를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
2. 제 1 항에 있어서,
   상기 2 튜플에 대한 제 1 타이머를 초기화 및 개시하는 단계와,
   상기 2 튜플에 대한 메시지 카운터를 초기화 및 증분하는 단계와,
   상기 제 1 타이머가 만료되었으면 상기 KOF 장치상의 상기 상태 정보를 제거하는 단계와,
   상기 2 튜플에 대한 상태 정보가 상기 KOF 장치상에 존재하면,
   상기 제 1 타이머를 체크하는 단계와,
   상기 메시지 카운터의 카운트를 체크하는 단계와,
   상기 카운트가 사전 결정된 값에 도달되면 상기 제 2 튜플에 대한 제 2 타이머를 개시하고 상기 제 1 메시지를 드랍(drop)하는 단계와,
   상기 카운트가 상기 사전 결정된 값에 도달되지 않으면 상기 제 1 메시지를 상기 제 2 호스트 시스템에 전송하는 단계를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
3. 제 2 항에 있어서,
   상기 2 튜플에 대한 상태 정보가 상기 KOF 장치상에 존재하면,
   상기 제 2 타이머를 체크하는 단계와,
   상기 제 2 타이머가 만료되지 않았으면 상기 제 1 메시지를 드랍하는 단계와,
   상기 제 2 타이머가 만료되었으면 상기 KOF 장치상의 2 튜플에 대한 모든 상기 상태 정보를 제거하는 단계와,
   상기 제 2 호스트 시스템에 의해 전송된 제 2 메시지를 수신하는 단계와,
   상기 제 1 메시지에 응답하여 상기 제 2 메시지가 상기 제 1 호스트 시스템으로부터의 정보를 요청하기 위한 제 2 타입이라고 판정하는 단계와,
   상기 제 2 메시지를 상기 제 1 호스트 시스템에 전송하는 단계를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
4. 제 2 항에 있어서,
   상기 KOF 장치는 상기 방화벽 외부에 있으면서 상기 방화벽에 직렬로 접속되어 있으며,
   상기 방법은,
   상기 제 2 타이머를 체크하는 단계와,
   상기 제 2 타이머가 만료되지 않았으면 상기 제 1 메시지를 드랍하는 단계와,
   상기 제 2 타이머가 만료되었으면, 상기 2 튜플에 대한 5 튜플 상태 정보를 포함하는 상기 2 튜플에 대한 모든 상기 상태 정보를 상기 KOF 장치상에서 제거하는 단계━상기 5 튜플 상태 정보는 상기 2 튜플 이외에 상기 접속에 대해, 프로토콜 타입 표시, 상기 제 1 호스트 시스템의 제 1 포트의 표시 및 상기 제 2 호스트 시스템의 제 2 포트의 표시를 포함함━를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
5. 제 1 항에 있어서,
   상기 제 2 호스트 시스템에 대하여 상기 KOF 장치상에 존재하는 상태 정보의 양을 판정하는 단계와,
   사전 결정된 최대치를 초과하는 양에 응답하여, 상기 2 개의 호스트 시스템 쌍━각 쌍은 상기 제 2 호스트 시스템과 다른 호스트 시스템을 포함하며, 상기 다른 호스트 시스템은 각 쌍에서 상이함━의 상태 정보를 상기 하나의 호스트 시스템 쌍에 대한 상태 정보로 결합하는 단계━상기 하나의 호스트 시스템 쌍에 대한 상태 정보는 상기 제 2 호스트 시스템의 어드레스와, 상기 2 개의 호스트 시스템 쌍의 나머지 호스트 시스템들의 각각의 어드레스들에 공통적인 어드레스 프리픽스를 포함함━를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
6. 제 1 항에 있어서,
   상기 제 2 호스트 시스템에 의해 전송된 제 3 메시지를 수신하는 단계와,
   상기 제 3 메시지가 상기 제 1 호스트 시스템과 제 2 호스트 시스템 간의 접속을 종료하기 위한 제 3 타입이라고 판정하는 단계와,
   상기 제 3 타입의 메시지를 수신하는 것에 응답하여, 상기 2 튜플에 대한 5 튜플 상태 정보를 상기 KOF 장치로부터 제거하는 단계━상기 5 튜플 상태 정보는 상기 2 튜플 이외에 상기 접속에 대해, 프로토콜 타입 표시, 상기 제 1 호스트 시스템의 제 1 포트의 표시 및 상기 제 2 호스트 시스템의 제 2 포트의 표시를 포함함━를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
7. 제 6 항에 있어서,
   상기 KOF 장치는 상기 방화벽의 일부이며,
   상기 방법은,
   상기 제 2 호스트 시스템에 의해 전송된 제 4 메시지를 수신하는 단계와,
   상기 제 4 메시지가 상기 제 1 메시지에 응답하여 상기 접속을 개시하기 위한 제 4 타입이라고 판정하는 단계와,
   상기 5 튜플에 대한 제 3 타이머를 개시하는 단계와,
   상기 제 1 호스트 시스템에 의해 전송되어 상기 제 2 호스트 시스템으로 수신되는 통신 트래픽을 수신하는 단계와,
   상기 제 3 타이머를 체크하는 단계와,
   상기 5 튜플에 대한 상태 정보가 상기 방화벽 상에 존재하는지의 여부를 판정하는 단계와,
   상기 제 3 타이머가 만료되지 않고 상기 5 튜플에 대한 상태 정보가 상기 방화벽 상에 존재한다면 상기 통신 트래픽을 통과시키는 단계를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
8. 제 1 항에 있어서,
   상기 KOF 장치는 상기 방화벽 외부에 있는 릴레이 서버(relay server)의 일부이며,
   상기 수신 단계는 상기 제 1 호스트 시스템과 상기 릴레이 서버 간의 사전 확립된 제 1 시그널링 접속(first signaling connection)을 통해서 상기 제 1 메시지를 수신하는 단계를 포함하며,
   상기 전송 단계는 상기 제 2 호스트 시스템과 상기 릴레이 서버 간의 사전 확립된 제 2 시그널링 접속을 통해서 상기 제 1 메시지를 상기 제 2 호스트 시스템으로 전송하는 단계를 포함하는
   호스트 시스템 간 접속 확립 방법.
   
9. 제 1 항에 있어서,
   상기 전송 단계는,
   상기 제 1 호스트 시스템과 제 2 호스트 시스템의 어드레스들에 대응하는 2 튜플 엔트리를 상기 KOF 장치상에 생성하는 단계와,
   상기 2 튜플 엔트리를 통과 상태로 설정하는 단계를 더 포함하는
   호스트 시스템 간 접속 확립 방법.
   
10. 제 1 항에 있어서,
    상기 제 1 호스트 시스템에 대하여 상기 KOF 장치상에 존재하는 상태 정보의 양을 판정하는 단계와,
    사전 결정된 최대치를 초과하는 양에 응답하여, 상기 2 개의 호스트 시스템 쌍━각 쌍은 상기 제 2 호스트 시스템과 다른 호스트 시스템을 포함하며, 상기 다른 호스트 시스템은 각 쌍에서 상이함━의 상태 정보를 상기 하나의 호스트 시스템 쌍에 대한 상태 정보로 결합하는 단계━상기 하나의 호스트 시스템 쌍에 대한 상태 정보는 상기 제 2 호스트 시스템의 어드레스와, 상기 2 개의 호스트 시스템 쌍의 나머지 호스트 시스템들의 각각의 어드레스들에 공통적인 어드레스 프리픽스를 포함함━를 더 포함하는
    호스트 시스템 간 접속 확립 방법.

Images