KR20180112301A - 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이 - Google Patents

신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이 Download PDF

Info

Publication number
KR20180112301A
KR20180112301A KR1020170043017A KR20170043017A KR20180112301A KR 20180112301 A KR20180112301 A KR 20180112301A KR 1020170043017 A KR1020170043017 A KR 1020170043017A KR 20170043017 A KR20170043017 A KR 20170043017A KR 20180112301 A KR20180112301 A KR 20180112301A
Authority
KR
South Korea
Prior art keywords
host
address
packet
domain
gateway
Prior art date
Application number
KR1020170043017A
Other languages
English (en)
Other versions
KR102326977B1 (ko
Inventor
곽병옥
Original Assignee
한국전자통신연구원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원 filed Critical 한국전자통신연구원
Priority to KR1020170043017A priority Critical patent/KR102326977B1/ko
Publication of KR20180112301A publication Critical patent/KR20180112301A/ko
Application granted granted Critical
Publication of KR102326977B1 publication Critical patent/KR102326977B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0236Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • H04L61/2007
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1466Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 개시는 신뢰 도메인의 IP 주소 공간을 비신뢰 공간으로부터 격리하고, 인증과 신뢰 검증을 거쳐 신뢰 도메인 내부로의 접근을 허용함으로써, 외부 공격을 원천 차단할 수 있는 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이에 관한 것이다. 이를 위한, 신뢰 도메인간 통신 방법은, 신뢰 도메인 내 호스트로부터 등록 요청을 수신하는 단계, 및 상기 호스트의 등록 요청에 대한 응답으로, 상기 호스트에 IP (Internet Protocol) 주소를 할당하는 단계를 포함한다.

Description

신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이{METHOD FOR COMMUNIATING BETWEEN TRUST DOMAINS AND GATEWAY THEREFOR}
본 개시는 신뢰 도메인의 IP 주소 공간을 비신뢰 공간으로부터 격리하고, 인증과 신뢰 검증을 거쳐 신뢰 도메인 내부로의 접근을 허용함으로써, 외부 공격을 원천 차단할 수 있는 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이에 관한 것이다.
인터넷 기반의 IP 네트워크 상에서 패킷 전송은 IP 주소를 통해 이루어진다. 이때, IP 주소는 네트워크 상에서 호스트의 위치를 의미한다. 이에 따라, 송신자의 주소를 위조(예를 들어, 주소 스푸핑(Address Spoofing)) 등의 형태로 수신자를 공격할 수 있어, IP 네트워크는 사이버 위협의 원인이 될 수 있다.
초기 인터넷인 보안을 고려하지 않고 설계되어, 도청, 감청 등의 공격에 취약한 문제를 가지고 있다. 이에 따라, 악의적인 사용자의 감시 및 차단 또는 신뢰성 있는 데이터 전달을 위해 다양한 보안기술이 개발되고 있다. 일 예로, IP 네트워크 보안 문제를 해결하기 위해, 방화벽, 통합 위협 관리(UTM, unified threat management), IDS(Intrusion Detection System), NAC(Network Access Controller), TMS(Traffic Management System) 등의 보안장비가 이용되고 있다. 다만, 이들 장비들은 IP 네트워크 상의 보안 위협을 해결할 근본적인 해결책이라 볼 수 없다. 이에 따라, APT 등 지능적인 공격에 대한 대응책 마련이 시급한 상태이다.
현 인터넷의 IP 주소 기반의 통신은 공격자 위조(Spoofing)나 서비스 거부(DoS) 등 각종 악의적 공격에 취약한 상태이고, 이에 따라, 향후 대량으로 보급될 사물 인터넷(IoT), 커넥티드 카(Connected Car) 등 새로운 서비스에 현재 사용되고 있는 보안 프로토콜이나 솔루션을 적용하기 어렵다. 이에 따라, 새로운 네트워크 구조 기반의 신뢰 통신 기술의 개발 필요성이 증가하고 있다.
특히, 현재 인터넷과 같이 세계적 규모의 연결성(Global Connectivity)은 그대로 유지하면서, 신뢰 도메인 관리를 통한 신뢰 네트워킹이 가능하도록 하는 신뢰 네트워킹 인프라를 구축할 필요가 있다.
본 개시의 기술적 과제는, 신뢰 도메인간 신뢰 네트워킹을 가능하게 하는 신뢰 도메인을 구성하는 방법을 제공하는 것이다.
구체적으로, 본 발명은 상호 신뢰관계를 가진 통신 참여자들만으로 구성된 신뢰 도메인을 구성하여 신뢰 도메인을 구축하는 방법에 관한 것이다.
또한, 본 개시의 기술적 과제는, 신뢰 도메인간 통신시, 게이트웨이에서 검증을 통과한 트래픽만 신뢰 도메인에 진입을 허용함으로써, 신뢰 도메인의 신뢰 수준을 유지하고, 신뢰 도메인 상의 공격을 차단할 수 있는 방법을 제공하기 위한 것이다.
본 개시에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 개시의 일 양상에 따르면, 신뢰 도메인 내 호스트로부터 등록 요청을 수신하는 단계, 및 상기 호스트의 등록 요청에 대한 응답으로, 상기 호스트에 IP (Internet Protocol) 주소를 할당하는 단계를 포함하는 신뢰 도메인간 통신 방법이 제공된다.
이때, 상기 IP 주소는, 상기 신뢰 도메인 내에서 상기 호스트가 사용할 내부 IP 주소 및 상기 호스트가 상기 신뢰 도메인 외부와의 통신을 위해 사용할 가상 IP 주소를 포함할 수 있다.
상기 방법은, 상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트의 IP 주소 정보 요청하는 제1 요청 메시지를 수신하는 단계, 상기 호스트가 상기 신뢰 도메인에 등록된 호스트인지 여부를 확인하는 단계, 및 상기 호스트가 상기 신뢰 도메인에 등록되어 있으면, 상기 타 신뢰 도메인으로 상기 타 호스트의 IP 주소 정보를 요청하는 제2 요청 메시지를 전송하는 단계를 더 포함할 수 있다.
이때, 상기 제1 요청 메시지는 상기 호스트의 내부 IP 주소를 포함하는 반면, 상기 제2 요청 메시지는 상기 호스트의 가상 IP 주소를 포함할 수 있다.
상기 방법은, 상기 제2 요청 메시지에 대한 응답으로, 상기 타 신뢰 도메인으로부터 제1 응답 메시지를 수신하는 단계, 상기 타 호스트가 상기 타 신뢰 도메인에 등록되어 있는지 여부를 판단하는 단계, 및 상기 타 호스트가 상기 타 신뢰 도메인에 등록되어 있는 것으로 판단되면, 상기 제1 요청 메시지에 대한 응답으로, 상기 호스트에 제2 응답 메시지를 전송하는 단계를 더 포함할 수 있다.
이때, 상기 제1 응답 메시지 및 상기 제2 응답 메시지는 상기 타 호스트의 가상 IP 주소를 포함할 수 있다.
상기 방법은, 상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트로 전달하기 위한 IP 패킷을 수신하는 단계, 상기 IP 패킷을 기초로, ID(Identification) 포워딩 패킷을 생성하는 단계, 및 상기 ID 포워딩 패킷을 상기 타 신뢰 도메인으로 전송하는 단계를 포함할 수 있다.
이때, 상기 IP 패킷은, 상기 호스트의 내부 IP 주소 및 상기 타 호스트의 가상 IP 주소를 포함하고, 상기 ID 포워딩 패킷을 생성하는 단계는, 상기 IP 패킷에, 상기 호스트의 내부 IP 주소에 대응하는 제1 ID 및 상기 타 호스트의 가상 IP 주소에 대응하는 제2 ID를 포함하는 ID 포워딩 헤더를 부가함으로써 수행될 수 있다.
상기 방법은, 타 신뢰 도메인으로부터, 상기 호스트의 IP 주소 정보를 요청하는 요청 메시지를 수신하는 단계, 및 상기 제1 요청 메시지에 대한 응답으로, 상기 타 신뢰 도메인으로 응답 메시지를 전송하는 단계를 포함할 수 있다.
이때, 상기 요청 메시지는 상기 타 신뢰 도메인에 등록된 타 호스트의 가상 IP 주소를 포함하고, 상기 응답 메시지는 상기 호스트의 가상 IP 주소를 포함할 수 있다.
상기 방법은, 타 신뢰 도메인으로부터 ID 포워딩 패킷을 수신하는 단계, 상기 ID 포워딩 패킷을 수신할 수신 호스트를 결정하는 단계, 상기 ID 포워딩 패킷에 대해 ID-IP 변환을 수행하는 단계, 및 상기 ID 포워딩 패킷으로부터 추출된 IP 패킷을 상기 수신 호스트로 전송하는 단계를 포함할 수 있다.
이때, 상기 ID 포워딩 패킷은 ID 포워딩 헤더를 포함하고, 상기 ID 포워딩 헤더는 상기 수신 호스트의 ID 및 상기 타 신뢰 도메인에 등록된 타 호스트의 ID를 포함할 수 있다.
이때, 상기 ID-IP 변환은, 상기 수신 호스트의 ID에 대응하는 상기 수신 호스트의 내부 IP 주소 및 상기 타 호스트의 ID에 대응하는 상기 타 호스트의 가상 IP 주소를 IP 헤더에 적용함으로써 수행될 수 있다.
본 개시의 일 양상에 따르면, 신뢰 도메인 내 호스트 및 타 신뢰 도메인과 통신을 수행하기 위한 통신부, 상기 호스트에 대한 정보를 저장하기 위한 메모리, 및 상기 통신부 및 상기 메모리를 제어하는 제어부를 포함하는 게이트웨이가 제공될 수 있다. 이때, 상기 제어부는, 상기 통신부를 통해 상기 호스트로부터 등록 요청이 수신되면, 상기 호스트의 등록 요청에 대한 응답으로, 상기 호스트에 IP (Internet Protocol) 주소를 할당할 수 있다. 그리고, 상기 IP 주소는, 상기 신뢰 도메인 내에서 상기 호스트가 사용할 내부 IP 주소 및 상기 호스트가 상기 신뢰 도메인 외부와의 통신을 위해 사용할 가상 IP 주소를 포함할 수 있다.
이때, 상기 제어부는, 상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트의 IP 주소 정보를 요청하는 제1 요청 메시지가 수신되면, 상기 호스트가 상기 신뢰 도메인에 등록된 호스트인지 여부를 확인하고, 상기 호스트가 상기 신뢰 도메인에 등록되어 있으면, 상기 타 신뢰 도메인으로 상기 제2 요청 메시지가 전송되도록 상기 통신부를 제어할 수 있다.
이때, 상기 제1 요청 메시지는 상기 호스트의 내부 IP 주소를 포함하는 반면, 상기 제2 요청 메시지는 상기 호스트의 가상 IP 주소를 포함할 수 있다.
본 개시에 대하여 위에서 간략하게 요약된 특징들은 후술하는 본 개시의 상세한 설명의 예시적인 양상일 뿐이며, 본 개시의 범위를 제한하는 것은 아니다.
본 개시에 따르면, 신뢰 도메인간 신뢰 네트워킹을 가능하게 하는 신뢰 도메인을 구성하는 방법이 제공될 수 있다.
구체적으로, 본 개시에 따르면, 상호 신뢰관계를 가진 통신 참여자들만으로 구성된 신뢰 도메인을 구성하여 신뢰 도메인을 구축하는 방법이 제공될 수 있다.
또한, 본 개시에 따르면, 신뢰 도메인간 통신시, 게이트웨이에서 검증을 통과한 트래픽만 신뢰 도메인에 진입을 허용함으로써, 신뢰 도메인의 신뢰 수준을 유지하고, 신뢰 도메인 상의 공격을 차단할 수 있는 방법이 제공될 수 있다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 발명에 따른 신뢰 네트워킹 게이트웨이의 블록도이다.
도 2는 게이트웨이에 호스트가 등록되는 절차를 나타낸 도면이다.
도 3은 신뢰 도메인 내 호스트가 타 신뢰 도메인 내 호스트와 통신하기 위한 검증 절차를 나타낸 도면이다.
도 4 내지 도 6은 게이트웨이가 통신 경로를 설정하는 절차를 나타낸 도면이다.
도 7은 본 발명에 따른 게이트웨이를 통한 패킷 포워딩 절차를 나타낸 것이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 도면에서 유사한 참조부호는 여러 측면에 걸쳐서 동일하거나 유사한 기능을 지칭한다. 도면에서의 요소들의 형상 및 크기 등은 보다 명확한 설명을 위해 과장될 수 있다. 후술하는 예시적 실시예들에 대한 상세한 설명은, 특정 실시예를 예시로서 도시하는 첨부 도면을 참조한다. 이들 실시예는 당업자가 실시예를 실시할 수 있기에 충분하도록 상세히 설명된다. 다양한 실시예들은 서로 다르지만 상호 배타적일 필요는 없음이 이해되어야 한다. 예를 들어, 여기에 기재되어 있는 특정 형상, 구조 및 특성은 일 실시예에 관련하여 본 발명의 정신 및 범위를 벗어나지 않으면서 다른 실시예로 구현될 수 있다. 또한, 각각의 개시된 실시예 내의 개별 구성요소의 위치 또는 배치는 실시예의 정신 및 범위를 벗어나지 않으면서 변경될 수 있음이 이해되어야 한다. 따라서, 후술하는 상세한 설명은 한정적인 의미로서 취하려는 것이 아니며, 예시적 실시예들의 범위는, 적절하게 설명된다면, 그 청구항들이 주장하는 것과 균등한 모든 범위와 더불어 첨부된 청구항에 의해서만 한정된다.
본 발명에서 제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
본 발명의 어떤 구성 요소가 다른 구성 요소에 “연결되어” 있다거나 “접속되어” 있다고 언급된 때에는, 그 다른 구성 요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있으나, 중간에 다른 구성 요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어"있다거나 "직접 접속되어"있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 발명의 실시예에 나타나는 구성부들은 서로 다른 특징적인 기능들을 나타내기 위해 독립적으로 도시되는 것으로, 각 구성부들이 분리된 하드웨어나 하나의 소프트웨어 구성단위로 이루어짐을 의미하지 않는다. 즉, 각 구성부는 설명의 편의상 각각의 구성부로 나열하여 포함한 것으로 각 구성부 중 적어도 두 개의 구성부가 합쳐져 하나의 구성부로 이루어지거나, 하나의 구성부가 복수 개의 구성부로 나뉘어져 기능을 수행할 수 있고 이러한 각 구성부의 통합된 실시예 및 분리된 실시예도 본 발명의 본질에서 벗어나지 않는 한 본 발명의 권리범위에 포함된다.
본 발명에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 발명에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다. 즉, 본 발명에서 특정 구성을 “포함”한다고 기술하는 내용은 해당 구성 이외의 구성을 배제하는 것이 아니며, 추가적인 구성이 본 발명의 실시 또는 본 발명의 기술적 사상의 범위에 포함될 수 있음을 의미한다.
본 발명의 일부의 구성 요소는 본 발명에서 본질적인 기능을 수행하는 필수적인 구성 요소는 아니고 단지 성능을 향상시키기 위한 선택적 구성 요소일 수 있다. 본 발명은 단지 성능 향상을 위해 사용되는 구성 요소를 제외한 본 발명의 본질을 구현하는데 필수적인 구성부만을 포함하여 구현될 수 있고, 단지 성능 향상을 위해 사용되는 선택적 구성 요소를 제외한 필수 구성 요소만을 포함한 구조도 본 발명의 권리범위에 포함된다.
이하, 도면을 참조하여 본 발명의 실시 형태에 대하여 구체적으로 설명한다. 본 명세서의 실시예를 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 명세서의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략하고, 도면상의 동일한 구성요소에 대해서는 동일한 참조부호를 사용하고 동일한 구성요소에 대해서 중복된 설명은 생략한다.
본 발명은, 신뢰기반 영역을 기초로 신뢰 도메인을 구성하고, 신뢰 도메인들간의 연결을 통해 인터넷 상에서 전역적 연결성을 확보하기 위한 것이다. 신뢰 도메인들간의 신뢰 관계 관리를 통해, 신뢰 도메인 상의 공격을 탐지한 뒤 이를 차단하는 후천적 방법 대신, 신뢰 도메인 상의 공격을 원천 배제할 수 있다.
신뢰 도메인간의 통신은, 기존 인터넷을 사용하기 위해, IP(Internet Protocol) 기반으로 이루어질 수 있다. 따라서, 신뢰 도메인 내부의 참여자가 다른 신뢰 도메인에 속한 참여자와 통신을 수행하는 경우, 신뢰 도메인 내 게이트웨이를 거쳐야 한다. 이에, 신뢰 도메인 내 게이트웨이를 통해, 신뢰 도메인 내 사용자의 인증을 수행한다면, 신뢰 도메인간 송수신되는 패킷의 무결성(Integrity)이나 기밀성(Confidentiality)를 보장할 수 있을 것이다.
이하, 후술되는 실시예들에서는, 신뢰 도메인 내 게이트웨이를 이용하여 신뢰 도메인의 신뢰 수준 및 보안 수준을 향상시키는 방안에 대해 상세히 살펴보기로 한다. 신뢰 도메인 내 게이트웨이는 '신뢰 네트워킹 게이트웨이(TWNGW : Trustworthy Networking Gateway)'라 호칭할 수도 있다.
도 1은 본 발명에 따른 신뢰 네트워킹 게이트웨이의 블록도이다.
도 1을 참조하면, 게이트웨이는, 신뢰 도메인 관리부(110), 경로 설정 관리부(120), 포워딩 관리부(130), 보안 관리부(140), ID(Identification) 패킷 엔진(150), 등록 호스트 관리부(160) 및 외부 호스트 관리부(170)를 포함한다.
신뢰 도메인 관리부(110)는, 신뢰 도메인 내 통신 참여자(일 예로, 호스트 또는 단말 등)의 등록, 삭제 또는 조회 등의 역할을 수행한다. 아울러, 신뢰 도메인 내 통신 참여자와 통신을 수행하는 외부 통신 참여자(일 예로, 호스트 또는 단말 등)의 신뢰 검증을 수행할 수도 있다.
경로 설정 관리부(120)는 게이트웨이와 타 신뢰 도메인에 포함된 게이트웨이 간에 신뢰성 있는 ID 패킷을 송수신하기 위한 경로를 설정하는 역할을 수행한다.
포워딩 관리부(130)는, 경로 설정 관리부에 경로가 설정되면, 게이트웨이에 등록된 호스트로부터 패킷을 수신하여, 목적지 호스트가 속한 타 게이트웨이로 ID 패킷을 송신하는 역할을 수행한다. 또한, 포워딩 관리부(130)는 타 게이트웨이로부터 ID 패킷을 수신한 뒤, 게이트웨이에 등록된 호스트로 ID 패킷을 전달하는 역할을 수행할 수 있다.
보안 관리부(140)는 게이트웨이간 경로 설정 및 포워딩 패킷 송수신시 패킷 보안을 위해, 암호, 복호, 서명 또는 인증을 수행하는 역할을 수행한다. 구체적으로, 보안 관리부(140)는 게이트웨이가 타 게이트웨이로 ID 패킷을 송신하는 경우, ID 패킷을 암호화 및/또는 서명하는 기능을 수행한다. 또는, 보안 관리부(140)는 게이트웨이가 타 게이트웨이로부터 ID 패킷을 수신한 경우, ID 패킷을 복호화 및/또는 인증하는 기능을 수행할 수 있다.
ID 패킷 엔진(150)은 경로 설정 및/또는 포워딩 패킷을 게이트웨이 간에 전송 처리하는 역할을 수행한다. 구체적으로, ID 패킷 엔진은, 게이트웨이 간 네트워크 레이어 L2/L3 에서, 경로 설정 및/또는 포워딩 패킷을 처리한다.
등록 호스트 관리부(160)는 경로 설정 및 게이트웨이에 등록된 호스트 정보를 관리하는 역할을 수행한다. 구체적으로, 등록 호스트 관리부는 신뢰 도메인 내 호스트에 할당된 IP 주소(내부 IP 주소)와 상기 호스트의 외부 통신을 위해 할당된 ID를 매핑 및 관리하는 역할을 수행한다. 또한, 등록 호스트 관리부(160)는 신뢰 도메인 내 호스트가 외부 비신뢰 영역을 거쳐 타 신뢰 도메인의 호스트와 통신할 수 있도록, 가상 IP를 할당하고 이를 관리하는 역할을 수행할 수 있다. 아울러, 등록 호스트 관리부(160)는 상기 호스트의 인증 정보(예를 들어, 호스트의 공개키 또는 서명 등)을 저장 및 관리할 수도 있다.
이때, 내부 IP 주소는 호스트가 내부 도메인에 소멸되기 전까지, 호스트에 대한 정보가 갱신되기 전까지 또는 기 설정된 시간 동안 유효하게 지속될 수 있다. 반면, 가상 IP 주소는 신뢰 도메인 외부로의 통신이 요청될 때 마다 재할당될 수 있다.
외부 호스트 관리부(170)는 게이트웨이간 경로 설정을 위해, 외부 호스트 정보를 관리하는 역할을 수행한다. 구체적으로, 외부 호스트 관리부(170)는 타 신뢰 도메인에 포함된 호스트의 가상 IP 주소와 상기 호스트의 ID를 캐싱(Caching)하고, 이를 매핑 및 관리하는 역할을 수행한다. 아울러, 외부 호스트 관리부(170)는 타 신뢰 도메인에 포함된 호스트의 인증 정보(예를 들어, 호스트의 공개키 또는 서명 등)를 저장 및 관리할 수도 있다.
이하, 등록 호스트 관리부(160) 및 외부 호스트 관리부(170)가 저장 및 관리하는 데이터(즉, IP 주소 및 ID 등에 대한 정보)를 신뢰 객체 테이블이라 호칭하기로 한다. 즉, 신뢰 객체 테이블은, 신뢰 도메인 내 등록된 호스트에 대한 정보(예를 들어, 등록된 호스트의 이름, 등록된 호스트의 ID, 등록된 호스트에 할당된 IP 주소 및 등록된 호스트에 할당된 가상 IP 주소 등)뿐만 아니라, 신뢰 도메인 외부 호스트에 대한 정보(예를 들어, 외부 호스트의 ID 및 회부 호스트에 할당된 가상 IP 주소 등)를 등록 및 관리하는 데이터라 할 수 있다.
도 1에 도시된 각 기능 블록들은, 하드웨어, 소프트웨어 또는 이들의 조합을 통해 구현될 수 있다. 일 예로, 각 기능블록들은, 게이트웨이의 전반적인 동작을 제어하기 위한 제어부(예컨대, CPU, MCU, FPGA 등의 연산 장치), 데이터를 저장하기 위한 메모리, 호스트 또는 타 게이트웨이와 통신을 수행하기 위한 통신부 등을 통해 구현될 수 있다.
상술한 게이트웨이의 블록도를 참조하여, 게이트웨이의 동작에 대해 살펴보기로 한다.
도 2는 게이트웨이에 호스트가 등록되는 절차를 나타낸 도면이다.
본 발명에 따르면, 신뢰 도메인에 참여하고자 하는 참여자는 신뢰 도메인 내 게이트웨이에 등록되어야만, 신뢰 도메인 외부와 통신할 수 있다.
게이트웨이로의 등록을 위해, 먼저, 통신에 참여하고자 하는 호스트(A)는 자신의 신뢰 도메인을 관리하는 게이트웨이 시스템으로 등록을 요청할 수 있다(S210).
호스트(A)의 등록 요청을 수신하면, 게이트웨이의 신뢰 도메인 관리부(110)는 등록 호스트 관리부(160)에 호스트 등록 처리를 요청할 수 있다(S220).
호스트 등록 처리 요청을 수신하면, 등록 호스트 관리부(160)는 호스트 등록 절차를 수행할 수 있다(S230). 구체적으로, 신뢰 도메인 관리부는 호스트의 이름을 등록하고, 등록된 이름에 연계하여 신뢰 도메인 내에서 사용하는 IP 주소(내부 IP 주소), 외부 통신을 위해 사용되는 ID, 외부에서 호스트의 IP 주소를 요청받을 경우 임의로 상기 호스트를 판별할 수 있는 가상 IP 등을 할당할 수 있다. 여기서, 가상 IP는 상기 호스트가 송수신하는 패킷이 비 신뢰 인터넷 구간을 통과하는 경우, 상기 호스트를 식별하기 위한 용도로 사용될 수 있다.
호스트 등록이 완료되면, 등록 호스트 관리부(160)는 신뢰 도메인 관리부에 호스트 등록이 완료되었음을 통보할 수 있다(S240).
호스트 등록이 완료되었음을 수신한 경우, 신뢰 도메인 관리부(110)는 호스트 등록을 요청한 호스트(A)에 등록이 허가되었음을 알리는 등록 허가 완료 메시지와 함께, 호스트가 사용할 신뢰 도메인 내 IP 주소를 알려준다(S250). 여기서, IP 주소는, 등록 허가 완료 메시지에 포함될 수도 있고, 이와 별개의 메시지로 전송될 수도 있다.
신뢰 도메인 관리부(110)가 호스트(A)에 알려주는 IP 주소는, 호스트가 신뢰 도메인 내부에서 사용하는 IP 주소를 의미할 수 있다. 가상 IP 주소는, 신뢰 도메인 관리부가 호스트(A)에게 알려줄 필요가 없다. 가상 IP 주소는 신뢰 도메인 외부 비신뢰 구간을 거치는 패킷에 대해 상기 호스트(A)를 식별하기 위한 용도로 사용되고, 패킷은 게이트웨이를 거쳐 외부로 송신되므로, 게이트웨이가 가상 IP 주소를 관리하는 것으로 충분하다. 다만, 호스트(A)의 등록이 완료될 때, 신뢰 도메인 내부에서 사용하는 IP 주소뿐만 아니라, 가상 IP 주소를 호스트 (A)에게 알려주는 것도, 본 발명의 범주에 속한다고 할 것이다.
등록 완료된 호스트는, 할당받은 IP 주소(즉, 신뢰 도메인 내부에서 사용하는 IP 주소)를 이용하여 통신을 수행할 수 있다. 이때, 등록 완료된 호스트가 신뢰 도메인 외부와 통신하는 경우, 상기 통신은 게이트웨이를 거쳐 이루어지게 된다. 이때, 게이트웨이는 신뢰 도메인의 검증 및 IP 패킷의 변환 등의 역할을 수행하게 된다. 이하, 게이트웨이에서의 검증 절차에 대해 상세히 살펴보기로 한다.
도 3은 신뢰 도메인 내 호스트가 타 신뢰 도메인 내 호스트와 통신하기 위한 검증 절차를 나타낸 도면이다.
신뢰 도메인 내 호스트가 타 신뢰 도메인 내 호스트와 통신하기 위해, 게이트웨이는 상대 호스트가 타 신뢰 도메인에 등록되어있는지를 검증할 수 있다. 상대 호스트가 타 신뢰 도메인에 등록되어 있다면, 게이트웨이는 타 신뢰 도메인으로부터 상대 호스트에게 할당된 가상 IP 주소를 응답받을 수 있다.
도 3을 예로 들어 설명하면, 신뢰 도메인 X에 속하는 호스트 A는 신뢰 도메인 Y에 속하는 호스트 B의 이름으로, 신뢰 도메인 X의 게이트웨이에게 B의 주소를 요청할 수 있다(S301).
신뢰 도메인 X의 게이트웨이는 호스트 A가 신뢰 도메인에 등록된 호스트인지를 확인한다(S302). 호스트 A가 신뢰 도메인에 등록된 호스트라면, 신뢰 도메인 X의 게이트웨이는 신뢰 도메인 Y의 게이트웨이에게, 신뢰 도메인 X의 호스트 A가 신뢰 도메인 Y의 호스트 B에 대한 IP 주소 검색을 요청하였음을 전달한다(S303).
이때, 신뢰 도메인 X의 게이트웨이는 신뢰 도메인 Y로, 신뢰 도메인 X 또는 신뢰 도메인 X에 등록된 호스트 A에 대한 정보 중 적어도 하나를 전달할 수 있다. 여기서, 호스트 A에 대한 정보는 호스트 A의 이름, 호스트 A에 할당된 ID 또는 호스트 A에 할당된 가상 IP 주소 중 적어도 하나를 포함할 수 있다. 신뢰 도메인 X의 게이트웨이가 신뢰 도메인 Y의 게이트웨이로 전달하는 정보는 암호화 및/또는 서명을 거칠 수 있다.
신뢰 도메인 Y의 게이트웨이는 신뢰 도메인 X 또는 신뢰 도메인 X 에 등록된 호스트 A에 대한 정보의 복호화 및/또는 인증을 수행하고, 호스트 A의 정보를 이용하여, 호스트 A가 신뢰 도메인 X에 등록된 호스트인지를 확인한다(S304).
호스트 A가 신뢰 도메인 X에 존재하는 호스트임을 확인한 경우, 신뢰 도메인 Y의 게이트웨이는 캐시 ID 관리부를 이용하여 캐시 ID 테이블에 호스트 A에 대한 정보를 저장한다(S305). 호스트 A에 대한 정보는 추후 호스트 A와의 통신을 위한 정보로 활용될 수 있다.
신뢰 도메인 Y의 게이트웨이는 신뢰 도메인 Y에 등록된 호스트 B의 정보를 신뢰 도메인 X의 게이트웨이로 전달한다(S306). 여기서, 호스트 B에 대한 정보는 호스트 B의 이름, 호스트 B에 할당된 ID 또는 호스트 B에 할당된 가상 IP 주소 중 적어도 하나를 포함할 수 있다. 신뢰 도메인 Y의 게이트웨이가 신뢰 도메인 X의 게이트웨이로 전달하는 정보는 암호화 및/또는 서명을 거칠 수 있다.
신뢰 도메인 X의 게이트웨이는 호스트 B에 대한 정보의 복호화 및/또는 인증을 수행하고, 호스트 B의 정보를 이용하여 호스트 B가 신뢰 도메인 Y에 등록된 호스트인지를 확인한다(S307).
호스트 B가 신뢰 도메인 Y에 존재하는 호스트을 확인한 경우, 신뢰 도메인 X의 게이트웨이는 캐시 ID 관리부를 이용하여 캐시 ID 테이블에 호스트 B에 대한 정보를 저장한다(S308). 호스트 B에 대한 정보는 추후 호스트 B와의 통신을 위한 정보로 활용될 수 있다.
신뢰 도메인 X의 게이트웨이는 호스트 A의 요청에 따른 응답으로, 호스트 B의 IP 주소를 호스트 A에게 전달할 수 있다(S309). 여기서, 호스트 B의 IP 주소는, 신뢰 도메인 Y가 호스트 B에 대해 할당한 가상 IP 주소일 수 있다. 호스트 A는 게이트웨이로부터 응답받은 호스트 B의 IP 주소(즉, 가상 IP 주소)를 이용하여, 호스트 B와 통신을 수행할 수 있다.
상술한 예에서와 같이, 신뢰 도메인 내 호스트는 신뢰 도메인 내부에서, 내부 IP 주소를 사용한다. 그러나, 신뢰 도메인 외부와 통신하는 경우에는 내부 IP 주소 대신 임의로 할당된 가상 IP 주소를 사용할 수 있다. 내부 IP 주소 대신 가상 IP 주소를 사용하게 됨에 따라, 내부 IP 주소는 신뢰 도메인 외부로 공개되지 않게 된다. 이때, 가상 IP 주소는 외부로의 통신이 요청될 때 마다, IP/ID 관리부를 통해 재할당될 수 있다.
외부 통신시, 내부 IP 대신 가상 IP를 이용함으로써, 신뢰 도메인 내 호스트의 IP가 외부에 공개되는 것을 방지할 수 있다. 아울러, 게이트웨이를 통해, 검증된 호스트로부터의 요청만을 신뢰 도메인 내부로 전달할 수 있게 된다. 이에 따라, 외부 공격을 원천 차단하고, 신뢰 도메인의 신뢰 수준을 유지할 수 있다.
타 신뢰 도메인과 통신을 수행하기 위해, 게이트웨이는 타 신뢰 도메인으로의 경로를 설정할 수 있다. 게이트웨이의 경로 설정 절차에 대해서는 도 4 내지 도 6을 참조하여 상세히 설명하기로 한다.
도 4 내지 도 6은 게이트웨이가 통신 경로를 설정하는 절차를 나타낸 도면이다. 도 4 내지 도 6에 도시된 경로설정 절차는 게이트웨이의 경로 설정 관리부를 중심으로 수행될 수 있다.
도 4는, 신뢰 도메인 내부의 호스트로부터 타 신뢰 도메인에 포함된 호스트의 IP 주소를 요구하는 패킷(예를 들어, REQ_IP 메시지)을 수신한 경우, 게이트웨이가 타 신뢰 도메인의 게이트웨이로 경로 설정 메시지를 전달하는 과정을 나타내고, 도 5는 경로 설정 메시지에 대한 응답을 수신하고 그 결과를 내부 호스트에게 전달하는 과정을 나타낸다. 아울러, 도 6은 경로 설정 메시지를 수신하여, 이에 대한 응답으로 응답 메시지를 전송하는 과정을 나타낸다.
이하, 설명의 편의를 위해, 타 신뢰 도메인에 포함된 호스트를 응답 호스트 또는 목적지 호스트라 호칭하고, 타 신뢰 도메인에 포함된 게이트웨이를 응답 게이트웨이 또는 목적지 게이트웨이라 호칭하기로 한다. 아울러, 목적지 게이트웨이로 경로 설정 메시지를 전달하는 게이트웨이를 소스 게이트웨이, 소스 게이트웨이로 목적지 호스트의 IP 주소를 요구하는 호스트를 소스 호스트라 호칭하기로 한다.
먼저, 소스 게이트웨이가 목적지 게이트웨이로 경로 생성 패킷(메시지)를 전송하는 과정에 대해 살펴보기로 한다.
도 4를 참조하면, 먼저 소스 게이트웨이는 신뢰 도메인 내부의 소스 호스트로부터 목적지 호스트의 IP 주소를 요청하는 메시지(예를 들어, REQ_IP 메시지)를 수신할 수 있다(S401). 여기서, 메시지에는 주소 정보가 포함될 수 있고, 상기 주소 정보는 목적지 호스트의 ID, 소스 호스트의 ID, 소스 호스트의 IP 주소 또는 소스 게이트웨이의 IP 주소 중 적어도 하나를 포함할 수 있다. 상기 주소 정보는 REQ_IP 메시지의 헤더에 포함될 수 있으나, 이에 한정되는 것은 아니다.
신뢰 도메인 내부의 소스 호스트로부터 목적지 호스트의 IP 주소를 요청하는 메시지를 수신하면, 소스 게이트웨이는 수신한 메시지가 유효한지 확인한다(S402). 일 예로, 소스 게이트웨이는 소스 호스트가 소스 게이트웨이에 등록되어 있는지 여부에 기초하여, 수신한 메시지의 유효성을 판단할 수 있다. 이때, 소스 호스트가 등록되어 있는지 여부는, 신뢰 객체 테이블과, 소스 호스트의 IP 주소 또는 소스 호스트의 ID를 이용하여 결정될 수 있다.
수신한 메시지가 유효한 메시지가 아닌 것으로 판단한 경우(예를 들어, 소스 호스트가 소스 게이트웨이에 등록되어 있지 않은 경우), 소스 게이트웨이는 수신한 메시지를 폐기할 수 있다. 이와 달리, 수신한 메시지가 유효한 메시지인 것으로 판단되는 경우, 소스 게이트웨이는 경로 생성을 요청하는 패킷(예를 들어, PATH_REQ 메시지)을 생성할 수 있다(S403).
이때, 메시지에는 주소 정보가 포함될 수 있고, 상기 주소 정보는, IP 주소를 요청한 소스 호스트의 ID, 경로 생성을 요청하는 소스 신뢰 도메인의 ID(여기서, 신뢰 도메인의 ID는 게이트웨이의 IP 주소를 포함할 수 있음), 목적지 호스트의 ID 또는 목적지 도메인의 ID (여기서, 목적지 도메인의 ID는 목적지 게이트웨이의 IP 주소를 포함할 수 있음) 중 적어도 하나를 포함할 수 있다. 상기 주소 정보는 PATH_REQ 메시지의 헤더에 포함될 수 있으나, 이에 한정되는 것은 아니다.
패킷이 생성되면, 생성된 패킷에 인증정보를 추가할 수 있다(S404). 일 예로, PATH_REQ 메시지의 헤더에 요청 호스트의 공개 키(Public Key) 및/또는 서명 등의 인증 정보를 추가할 수 있다.
이후, 상기 패킷을 목적지 게이트웨이에 전달하기 위해, 목적지 정보를 추가할 수 있다(S405). 여기서, 목적지 정보는 목적지 게이트웨이의 IP 헤더를 포함할 수 있다.
패킷 생성이 완료되면, 소스 게이트웨이는 생성된 패킷(즉, PATH_REQ 메시지)을 목적지 게이트웨이로 송신할 수 있다(S406).
다음으로, 소스 게이트웨이가 목적지 게이트웨이로부터 경로 생성 응답 패킷(메시지)를 수신한 경우에 대해 살펴보기로 한다.
도 5를 참조하면, 소스 게이트웨이는 목적지 게이트웨이로부터 경로 생성 요청에 따른 응답을 수신할 수 있다(S501). 일 예로, 목적지 게이트웨이로부터 수신하는 경로 생성 응답 패킷은 PATH_RSP 메시지일 수 있다.
목적지 게이트웨이로부터 경로 생성 응답 패킷을 수신하면, 소스 게이트웨이는 수신한 패킷이 목적지 신뢰 도메인으로부터 수신한 것인지 확인할 수 있다(S502). 이를 위해, 게이트웨이는 패킷의 IP 헤더가 유효한 값인지 확인할 수 있다.
패킷의 IP 헤더가 유효하지 않은 경우, 소스 게이트웨이는 수신한 패킷을 폐기할 수 있다. 반면, 패킷의 IP 헤더가 유효한 경우, 소스 게이트웨이는 수신한 패킷이 유효한 패킷인지를 확인한다(S503). 일 예로, 수신한 패킷의 유효성은, PATH_RSP 헤더를 가지고 있는지 여부에 따라 판단될 수 있다.
수신한 패킷이 유효하지 않을 경우(예를 들어, PATH_RSP 헤더를 가지고 있지 않은 경우), 소스 게이트웨이는 수신한 패킷을 폐기할 수 있다. 반면, 패킷이 유효하다고 판단되는 경우, 소스 게이트웨이는 수신한 패킷을 신뢰할 수 있는지를 검증할 수 있다(S504). 일 예로, 수신한 패킷의 신뢰성은, PATH_RSP 패킷 헤더의 인증 정보(예를 들어, 서명(Signature))를 이용하여 검증될 수 있다.
수신한 패킷을 신뢰할 수 없을 경우, 소스 게이트웨이는 수신한 패킷을 폐기한다. 반면, 수신한 패킷을 신뢰할 수 있는 경우, 소스 게이트웨이는 응답 호스트에 대한 정보와 응답 신뢰 도메인에 대한 정보를 신뢰 객체 테이블에 구축할 수 있다(S505). 여기서, 응답 호스트에 대한 정보는 응답 호스트의 가상 IP 주소, 응답 호스트의 ID 또는 응답 호스트의 공개키 중 적어도 하나를 포함할 수 있다. 아울러, 응답 신뢰 도메인에 대한 정보는 응답 게이트웨이의 IP 주소 또는 응답 신뢰 도메인의 ID 중 적어도 하나를 포함할 수 있다.
이후, 소스 게이트웨이는 목적지 호스트의 IP 주소를 요청한 소스 호스트에게 전송할 패킷(메시지)를 생성할 수 있다(S506). 이때, 생성되는 패킷(예를 들어, RSP_IP 메시지)에는 목적지 호스트에 대한 정보(예를 들어, 목적지 호스트의 ID 또는 목적지 호스트의 가상 IP 주소 중 적어도 하나) 및 목적지 호스트의 IP 주소를 요청한 호스트에 대한 정보(예를 들어, RSP_REQ 메시지를 전송한 호스트의 IP 주소 등)이 포함될 수 있다.
이후, 소스 게이트웨이는 소스 호스트로 생성한 패킷을 전송할 수 있다(S507).
상술한 실시예에서는, 소스 게이트웨이가 목적지 게이트웨이로 경로 설정 요청 패킷을 전송하고, 이에 대한 응답을 수신하는 절차에 대해 설명하였다.
다음으로, 게이트웨이가 타 게이트웨이로부터 경로 설정 요청 패킷을 수신하였을 때의 동작에 대해 살펴보기로 한다 (즉, 목적지 게이트웨이의 동작에 대해 설명하기로 함).
도 6을 참조하면, 먼저, 소스 게이트웨이로부터 경로 설정 요청 패킷을 수신하면(S601), 목적지 게이트웨이는 소스 게이트웨이로부터 수신한 패킷(예를 들어, PATH_REQ 메시지)이 소스 신뢰 도메인으로부터 수신한 것인지 확인할 수 있다(S602). 이를 위해, 목적지 게이트웨이는 패킷의 IP 헤더가 유효한 값인지 확인할 수 있다.
패킷의 IP 헤더가 유효하지 않은 경우, 목적지 게이트웨이는 수신한 패킷을 폐기할 수 있다. 반면, 패킷의 IP 헤더가 유효한 경우, 목적지 게이트웨이는 수신한 패킷이 유효한 패킷인지 여부를 확인한다(S603). 일 예로, 수신한 패킷의 유효성은, PATH_REQ 헤더를 가지고 있는지 여부에 따라 판단될 수 있다.
수신한 패킷이 유효하지 않을 경우(예를 들어, PATH_REQ 헤더를 가지고 있지 않은 경우), 목적지 게이트웨이는 수신한 패킷을 폐기할 수 있다. 반면, 패킷이 유효하다고 판단되는 경우, 목적지 게이트웨이는 수신한 패킷을 신뢰할 수 있는지 검증할 수 있다(S604). 일 예로, 수신한 패킷의 신뢰성은, PATH_REQ 패킷 헤더의 인증 정보(예를 들어, 서명(Signature))를 이용하여 검증될 수 있다.
수신한 패킷을 신뢰할 수 없을 경우, 목적지 게이트웨이는 수신한 패킷을 폐기한다. 반면, 수신한 패킷을 신뢰할 수 있는 경우, 목적지 게이트웨이는 소스 호스트에 대한 정보와 소스 신뢰 도메인에 대한 정보를 신뢰 객체 테이블에 구축할 수 있다(S605). 여기서, 소스 호스트에 대한 정보는 소스 호스트의 가상 IP 주소, 소스 호스트의 ID 또는 소스 호스트의 공개키 중 적어도 하나를 포함할 수 있다. 아울러, 소스 신뢰 도메인에 대한 정보는 소스 게이트웨이의 IP 주소 또는 소스 신뢰 도메인의 ID 중 적어도 하나를 포함할 수 있다.
이후, 목적지 게이트웨이는 소스 게이트웨이에 전송할 패킷(메시지)을 생성할 수 있다(S606). 이때, 생성되는 패킷(예를 들어, PATH_RSP 메시지)의 헤더에는, 패킷 전송측에 대한 정보(예를 들어, 목적지 호스트의 ID, 목적지 신뢰 도메인의 ID 또는 목적지 게이트웨이의 IP 주소 중 적어도 하나) 및 패킷 수신측에 대한 정보(예를 들어, 소스 호스트의 ID, 소스 호스트의 가상 IP 주소, 소스 신뢰 도메인의 ID 또는 소스 게이트웨이의 IP 주소 중 적어도 하나)가 포함될 수 있다.
이후, 목적지 게이트웨이는 생성된 패킷에 인증정보를 추가할 수 있다(S607). 일 예로, 목적지 게이트웨이는 PATH_RSP 패킷 헤더에 인증 정보(예를 들어, 목적지 호스트의 공개키 또는 서명 중 적어도 하나)를 추가할 수 있다.
소스 게이트웨이로 생성된 패킷을 전송하기 위해, 경로 설정 패킷에는 소스 게이트웨이의 IP 헤더가 추가될 수 있다(S608). 생성된 패킷은 소스 게이트웨이에 전송될 수 있다(S609).
다음으로, 게이트웨이를 통해 패킷을 포워딩하는 절차에 대해 살펴보기로 한다.
도 7은 본 발명에 따른 게이트웨이를 통한 패킷 포워딩 절차를 나타낸 것이다.
설명의 편의를 위해, 패킷을 전송하는 측을 '소스'라 호칭하고, 패킷을 수신하는 측을 '목적지'라 호칭하기로 한다.
도 7은 소스 게이트웨이가 신뢰 도메인 내 소스 호스트로부터 IP 패킷을 수신할 경우, 게이트웨이는 수신한 IP 패킷을 ID 포워딩 패킷으로 변환하는 과정 및 목적지 게이트웨이가 ID 포워딩 패킷을 IP 패킷으로 변환하고, 변환된 IP 패킷을 목적지 호스트로 전송화는 과정을 나타낸 흐름도이다. 본 실시예는 게이트웨이의 포워딩 관리부를 중심으로 수행될 수 있다.
먼저, 소스 게이트웨이가 소스 호스트로부터 IP 패킷을 수신할 수 있다. 이때, IP 패킷의 목적지 IP 주소는 목적지 호스트의 가상 IP 주소일 수 있다. 소스 호스트는 RSP_IP를 통해 목적지 호스트의 가상 IP를 획득하거나, 게이트웨이의 신뢰 객체 테이블로부터 목적지 호스트의 가상 IP를 가져올 수 있다. 목적지 호스트의 가상 IP는 도 4를 통해 설명한 경로 설정 절차를 거쳐, 신뢰 객체 테이블에 구축될 수 있다.
소스 호스트로부터 IP 패킷을 수신하면(S701), 소스 게이트웨이는, 소스 호스트가 소스 게이트웨이에 등록되어 있는지 여부를 확인한다(S702). 소스 호스트가 소스 게이트웨이에 등록되어 있지 않은 경우, 소스 게이트웨이는 수신한 IP 패킷을 폐기할 수 있다.
소스 호스트가 소스 게이트웨이에 등록되어 있으나, 목적지 호스트가 신뢰 객체 테이블에 등록되어 있지 않은 경우(예를 들어, 목적지 호스트의 가상 IP 주소가 신뢰 객체 테이들에 등록되어 있지 않은 경우), 소스 게이트웨이는 수신한 IP 패킷을 폐기할 수 있다. 이 경우, 목적지 호스트로 IP 패킷을 포워딩하기에 앞서, 도 4 내지 도 6을 통해 설명한 경로 설정 절차가 선행되어야 할 것이다.
소스 호스트 및 목적지 호스트가 신뢰 객체 테이블에 등록되어 있음이 확인된 경우, 소스 게이트웨이는 IP 패킷을 기초로 ID 포워딩 패킷(ID_FWD 패킷)을 생성할 수 있다(S703).
소스 게이트웨이는 IP 패킷에 ID 포워딩 패킷으로 변환을 위한 헤더를 부가함으로써, ID 포워딩 패킷을 생성할 수 있다. 구체적으로, IP 패킷을 기초로, ID 포워딩 패킷을 생성하기 위해, ID 포워딩 헤더가 생성될 수 있다. 이때, ID 포워딩 헤더에는 소스 호스트의 ID 및 목적지 호스트의 ID가 추가될 수 있다. ID 헤더를 제외한 IP 패킷 전체는 암호화가 수행되고, 소스 호스트를 인증할 수 있는 공개키와 서명 정보가 헤더에 추가될 수 있다.
그리고, ID 포워딩 패킷을 전달하기 위해, 목적지 게이트웨이와 관련한 IP 헤더가 추가될 수 있다.
상기 과정을 거쳐 ID 포워딩 패킷이 생성되면, 소스 게이트웨이는 생성된 ID 포워딩 패킷을 목적지 게이트웨이로 전송할 수 있다(S704).
목적지 게이트웨이가 소스 게이트웨이로부터 ID 포워딩 패킷을 수신하면, 목적지 게이트웨이는 ID 포워딩 패킷의 신뢰 채널 패킷인지 여부를 확인한다(S705). 일 예로, 목적지 게이트웨이는 ID 포워딩 패킷의 IP 헤더가 유효한 값인지 여부를 기초로, ID 포워딩 패킷을 확인할 수 있다.
IP 헤더가 유효하지 않은 경우, 목적지 게이트웨이는 ID 포워딩 패킷을 폐기할 수 있다. 반면, IP 헤더가 유효한 값을 갖는 경우, 목적지 게이트웨이는 신뢰 객체를 확인할 수 있다(S706).
구체적으로, 목적지 게이트웨이는 ID 포워딩 헤더가 유효한 값인지 확인한다. ID 포워딩 헤더가 유효하지 않거나, ID 포워딩 패킷의 소스 호스트 ID가 신뢰 객체 테이블에 등록되어 있지 않다면, 패킷을 폐기할 수 있다. 신뢰 객체 테이블에 소스 호스트의 ID를 등록하는 것은 도 4 내지 도 6의 경로 설정 과정을 통해 수행될 수 있다.
소스 호스트가 신뢰 객체 테이블에 등록되있는 것으로 판단되면, 목적지 게이트웨이는 수신한 ID 포워딩 패킷을 신뢰할 수 있는지 여부를 검증한다(S707). 구체적으로, 목적지 게이트웨이는 수신한 ID 포워딩 패킷의 인증 정보(예컨대, 서명(Signature))을 기초로, ID 포워딩 패킷을 신뢰할 수 있는지 여부를 검증할 수 있다.
ID 포워딩 패킷의 검증이 완료되면, 목적지 게이트웨이는 수신한 ID 포워딩 패킷을 복호화할 수 있다(S707). 구체적으로, 목적지 게이트웨이는 ID 포워딩 패킷 중 목적지 호스트로 보내야할 IP 패킷 전체를 복호화할 수 있다. 이때, ID 포워딩 패킷의 헤더(즉, ID 포워딩 헤더)는 복호화의 범위에 포함되지 않는다.
복호화가 완료되면, 목적지 게이트웨이는 ID-IP 변환을 수행하고, ID 포워딩 패킷에서 ID 포워딩 헤더를 삭제할 수 있다(S707). ID-IP 변환은 소스 호스트와 목적지 호스트의 IP 주소를 구하여, IP 헤더에 그 값을 적용하는 과정을 나타낸다. 이때, 소스 호스트의 IP 주소는 신뢰 객체 테이블 및 ID 포워딩 헤더에 포함된 소스 호스트의 ID를 이용하여 획득될 수 있다. 이때, 소스 호스트의 IP 주소는 소스 호스트의 가상 IP 주소일 수 있다. 목적지 호스트의 IP 주소는 신뢰 객체 테이블 및 ID 포워딩 헤더에 포함된 목적지 호스트의 ID를 이용하여 획득될 수 있다. 이때, 목적지 호스트의 IP 주소는 목적지 신뢰 도메인 내부에서 목적지 호스트가 사용하는 내부 IP 주소일 수 있다.
이후, 목적지 게이트웨이는 목적지 호스트로 IP 패킷을 전송할 수 있다(S708).
상술한 실시예들에서 살펴본 바와 같이, 신뢰 도메인 내 통신은 기존의 인터넷과 같이 로컬(Local) IP를 이용하여 이루어진다. 이에 따라, 신뢰 도메인 내 호스트는 게이트웨이로부터 실제 IP 주소(Real IP Address)에 해당하는 내부 IP 주소를 할당받을 수 있다. 아울러, 신뢰 도메인 외부 통신을 위해, 상기 내부 IP 주소 대신 가상 IP 주소(Imaginary IP Address)가 부여될 수 있다. 가상 IP 주소는 특정 신뢰 도메인 내에서만 의미가 있고, 실제 외부의 통신 참여자는 이를 인지하지 못하도록 한다.
신뢰 도메인 내 게이트웨이는 호스트에게 부여한 실제 주소 공간(즉, 내부 IP 주소)과 가상 주소 공간(즉, 가상 IP 주소)를 관리하고, 인증 절차에 따라, 식별자(ID) 및 IP 주소의 대응 관계를 관리할 수 있다. 이에 따라, 게이트웨이는 실제 IP 주소, 식별자, 가상 IP 주소의 대응 관계를 기반으로 주소 변환을 수행하는 NAT (Network Address Translator)로 기능할 수 있다. 아울러, 식별자를 이용함으로써, 신뢰 도메인 간 통신이 비신뢰 영역을 통과하는 경우, 패킷의 무결성(Integrity) 및 기밀성(Confidentiality)이 보장될 수 있다.
본 개시에 따르면, 신뢰 도메인 내 통신 참여자들에게 자신을 증명할 수 있는 신분증(Self-Certifying ID)을 부여함으로써 신뢰 도메인을 구성할 수 있다. 신뢰 도메인 내 통신은 추가적 보안 기능 없이 초기 인터넷과 같은 상호 신뢰를 기반으로 수행되는 반면, 신뢰 도메인 외 통신은 통신 참여자가 인증 절차를 거쳐 특정 신뢰 도메인에 진입할 수 있도록 허용하게 된다.
이상에서 본 발명이 구체적인 구성요소 등과 같은 특정 사항들과 한정된 실시예 및 도면에 의해 설명되었으나, 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐, 본 발명이 상기 실시예들에 한정되는 것은 아니며, 본 발명이 속하는 기술분야에서 통상적인 지식을 가진 자라면 이러한 기재로부터 다양한 수정 및 변형을 꾀할 수 있다.
따라서, 본 발명의 사상은 상기 설명된 실시예에 국한되어 정해져서는 아니 되며, 후술하는 특허청구범위뿐만 아니라 이 특허청구범위와 균등하게 또는 등가적으로 변형된 모든 것들은 본 발명의 사상의 범주에 속한다고 할 것이다.
110 : 신뢰 도메인 관리부
120 : 경로 설정 관리부
130 : 포워딩 관리부
140 : 보안 관리부
150 : ID 패킷 엔진
160 : 등록 호스트 관리부
170 : 외부 호스트 관리부

Claims (15)

  1. 신뢰 도메인 내 호스트로부터 등록 요청을 수신하는 단계; 및
    상기 호스트의 등록 요청에 대한 응답으로, 상기 호스트에 IP (Internet Protocol) 주소를 할당하는 단계를 포함하되,
    상기 IP 주소는, 상기 신뢰 도메인 내에서 상기 호스트가 사용할 내부 IP 주소 및 상기 호스트가 상기 신뢰 도메인 외부와의 통신을 위해 사용할 가상 IP 주소를 포함하는, 신뢰 도메인 간 통신 방법.
  2. 제1항에 있어서,
    상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트의 IP 주소 정보 요청하는 제1 요청 메시지를 수신하는 단계;
    상기 호스트가 상기 신뢰 도메인에 등록된 호스트인지 여부를 확인하는 단계; 및
    상기 호스트가 상기 신뢰 도메인에 등록되어 있으면, 상기 타 신뢰 도메인으로 상기 타 호스트의 IP 주소 정보를 요청하는 제2 요청 메시지를 전송하는 단계를 더 포함하는, 신뢰 도메인 간 통신 방법.
  3. 제2항에 있어서,
    상기 제1 요청 메시지는 상기 호스트의 내부 IP 주소를 포함하는 반면, 상기 제2 요청 메시지는 상기 호스트의 가상 IP 주소를 포함하는 것을 특징으로 하는, 신뢰 도메인 간 통신 방법.
  4. 제2항에 있어서,
    상기 제2 요청 메시지에 대한 응답으로, 상기 타 신뢰 도메인으로부터 제1 응답 메시지를 수신하는 단계;
    상기 타 호스트가 상기 타 신뢰 도메인에 등록되어 있는지 여부를 판단하는 단계; 및
    상기 타 호스트가 상기 타 신뢰 도메인에 등록되어 있는 것으로 판단되면, 상기 제1 요청 메시지에 대한 응답으로, 상기 호스트에 제2 응답 메시지를 전송하는 단계를 더 포함하는, 신뢰 도메인 간 통신 방법.
  5. 제4항에 있어서,
    상기 제1 응답 메시지 및 상기 제2 응답 메시지는 상기 타 호스트의 가상 IP 주소를 포함하는 것을 특징으로 하는, 신뢰 도메인 간 통신 방법.
  6. 제1항에 있어서,
    상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트로 전달하기 위한 IP 패킷을 수신하는 단계;
    상기 IP 패킷을 기초로, ID(Identification) 포워딩 패킷을 생성하는 단계; 및
    상기 ID 포워딩 패킷을 상기 타 신뢰 도메인으로 전송하는 단계를 포함하는, 신뢰 도메인 간 통신 방법.
  7. 제6항에 있어서,
    상기 IP 패킷은, 상기 호스트의 내부 IP 주소 및 상기 타 호스트의 가상 IP 주소를 포함하고,
    상기 ID 포워딩 패킷을 생성하는 단계는, 상기 IP 패킷에, 상기 호스트의 내부 IP 주소에 대응하는 제1 ID 및 상기 타 호스트의 가상 IP 주소에 대응하는 제2 ID를 포함하는 ID 포워딩 헤더를 부가함으로써 수행되는 것을 특징으로 하는, 신뢰 도메인 간 통신 방법.
  8. 제1항에 있어서,
    타 신뢰 도메인으로부터, 상기 호스트의 IP 주소 정보를 요청하는 요청 메시지를 수신하는 단계; 및
    상기 제1 요청 메시지에 대한 응답으로, 상기 타 신뢰 도메인으로 응답 메시지를 전송하는 단계를 포함하는, 신뢰 도메인 간 통신 방법.
  9. 제8항에 있어서,
    상기 요청 메시지는 상기 타 신뢰 도메인에 등록된 타 호스트의 가상 IP 주소를 포함하고,
    상기 응답 메시지는 상기 호스트의 가상 IP 주소를 포함하는 것을 특징으로 하는, 신뢰 도메인 간 통신 방법.
  10. 제1항에 있어서,
    타 신뢰 도메인으로부터 ID 포워딩 패킷을 수신하는 단계;
    상기 ID 포워딩 패킷을 수신할 수신 호스트를 결정하는 단계;
    상기 ID 포워딩 패킷에 대해 ID-IP 변환을 수행하는 단계; 및
    상기 ID 포워딩 패킷으로부터 추출된 IP 패킷을 상기 수신 호스트로 전송하는 단계를 포함하는, 신뢰 도메인 간 통신 방법.
  11. 제10항에 있어서,
    상기 ID 포워딩 패킷은 ID 포워딩 헤더를 포함하고, 상기 ID 포워딩 헤더는 상기 수신 호스트의 ID 및 상기 타 신뢰 도메인에 등록된 타 호스트의 ID를 포함하는 것을 특징으로 하는, 신뢰 도메인 간 통신 방법.
  12. 제11항에 있어서,
    상기 ID-IP 변환은, 상기 수신 호스트의 ID에 대응하는 상기 수신 호스트의 내부 IP 주소 및 상기 타 호스트의 ID에 대응하는 상기 타 호스트의 가상 IP 주소를 IP 헤더에 적용함으로써 수행되는 것을 특징으로 하는, 방법.
  13. 신뢰 도메인 내 호스트 및 타 신뢰 도메인과 통신을 수행하기 위한 통신부;
    상기 호스트에 대한 정보를 저장하기 위한 메모리; 및
    상기 통신부 및 상기 메모리를 제어하는 제어부를 포함하되,
    상기 제어부는, 상기 통신부를 통해 상기 호스트로부터 등록 요청이 수신되면, 상기 호스트의 등록 요청에 대한 응답으로, 상기 호스트에 IP (Internet Protocol) 주소를 할당하되,
    상기 IP 주소는, 상기 신뢰 도메인 내에서 상기 호스트가 사용할 내부 IP 주소 및 상기 호스트가 상기 신뢰 도메인 외부와의 통신을 위해 사용할 가상 IP 주소를 포함하는, 게이트웨이.
  14. 제13항에 있어서,
    상기 제어부는, 상기 호스트로부터 타 신뢰 도메인에 포함된 타 호스트의 IP 주소 정보를 요청하는 제1 요청 메시지가 수신되면, 상기 호스트가 상기 신뢰 도메인에 등록된 호스트인지 여부를 확인하고,
    상기 호스트가 상기 신뢰 도메인에 등록되어 있으면, 상기 타 신뢰 도메인으로 상기 제2 요청 메시지가 전송되도록 상기 통신부를 제어하는 것을 특징으로 하는, 게이트웨이.
  15. 제14항에 있어서,
    상기 제1 요청 메시지는 상기 호스트의 내부 IP 주소를 포함하는 반면, 상기 제2 요청 메시지는 상기 호스트의 가상 IP 주소를 포함하는 것을 특징으로 하는, 게이트웨이.
KR1020170043017A 2017-04-03 2017-04-03 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이 KR102326977B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020170043017A KR102326977B1 (ko) 2017-04-03 2017-04-03 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020170043017A KR102326977B1 (ko) 2017-04-03 2017-04-03 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이

Publications (2)

Publication Number Publication Date
KR20180112301A true KR20180112301A (ko) 2018-10-12
KR102326977B1 KR102326977B1 (ko) 2021-11-16

Family

ID=63876754

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020170043017A KR102326977B1 (ko) 2017-04-03 2017-04-03 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이

Country Status (1)

Country Link
KR (1) KR102326977B1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060130811A (ko) * 2005-06-08 2006-12-20 (주)아이비트 분산구조의 디엔에스 프록시 서버 기능이 내장된아이피브이4/아이피브이6 변환장치 및 이 장치를 이용한변환방법
KR20070041629A (ko) * 2004-08-13 2007-04-18 콸콤 플라리온 테크놀로지스, 인코포레이티드 이동성 관리에서 vpn 지원을 위한 방법 및 장치
US20100061309A1 (en) * 2003-07-14 2010-03-11 Buddhikot Milind M Method and system for mobility across heterogeneous address spaces
KR20160092645A (ko) * 2015-01-28 2016-08-05 한국전자통신연구원 식별자 및 위치자 분리 환경에서의 로컬 도메인 내 종단 호스트간의 통신 방법 및 시스템

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100061309A1 (en) * 2003-07-14 2010-03-11 Buddhikot Milind M Method and system for mobility across heterogeneous address spaces
KR20070041629A (ko) * 2004-08-13 2007-04-18 콸콤 플라리온 테크놀로지스, 인코포레이티드 이동성 관리에서 vpn 지원을 위한 방법 및 장치
KR20060130811A (ko) * 2005-06-08 2006-12-20 (주)아이비트 분산구조의 디엔에스 프록시 서버 기능이 내장된아이피브이4/아이피브이6 변환장치 및 이 장치를 이용한변환방법
KR20160092645A (ko) * 2015-01-28 2016-08-05 한국전자통신연구원 식별자 및 위치자 분리 환경에서의 로컬 도메인 내 종단 호스트간의 통신 방법 및 시스템

Also Published As

Publication number Publication date
KR102326977B1 (ko) 2021-11-16

Similar Documents

Publication Publication Date Title
JP4302398B2 (ja) インターネットプロトコルのアドレス機構
US7552323B2 (en) System, apparatuses, methods, and computer-readable media using identification data in packet communications
US9602485B2 (en) Network, network node with privacy preserving source attribution and admission control and device implemented method therfor
US20180115520A1 (en) Dark virtual private networks and secure services
Nowaczewski et al. Securing Future Internet and 5G using Customer Edge Switching using DNSCrypt and DNSSEC.
CA2506418C (en) Systems and apparatuses using identification data in network communication
CN115603932A (zh) 一种访问控制方法、访问控制系统及相关设备
US20220232000A1 (en) Secure communication system
EP2276206B1 (en) A method, device and communication system for managing and inquiring mapping information
JP2007318806A (ja) 移動ネットワーク環境におけるデータトラフィックの保護方法
Richardson et al. Opportunistic encryption using the internet key exchange (ike)
JP6763605B2 (ja) データ通信システム、キャッシュdns装置及び通信攻撃防止方法
KR100856918B1 (ko) IPv6 기반 네트워크상에서의 IP 주소 인증 방법 및IPv6 기반 네트워크 시스템
US20220368688A1 (en) Secure communication system
EP1836559B1 (en) Apparatus and method for traversing gateway device using a plurality of batons
KR20180099293A (ko) 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이
US11582201B1 (en) Establishing and maintaining trusted relationship between secure network devices in secure peer-to-peer data network based on obtaining secure device identity containers
US20220400011A1 (en) Anti-replay protection based on hashing encrypted temporal key in a secure peer-to-peer data network
KR102326977B1 (ko) 신뢰 도메인간 통신 방법 및 이를 위한 게이트웨이
KR102059150B1 (ko) IPsec 가상 사설 네트워크 시스템
Kwak et al. Trust domain based trustworthy networking
RU2163745C2 (ru) Система защиты виртуального канала корпоративной сети с аутентифицирующим маршрутизатором, построенной на каналах и средствах коммутации сети связи общего пользования
Raheem et al. Supporting communications in the iots using the location/id split protocol: a security analysis
He et al. Network-layer accountability protocols: a survey
Kwak et al. Design and implementation of trust domain gateway system

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant