KR101911913B1 - 서비스 기능 체이닝 방법 및 이를 위한 장치 - Google Patents

Abstract

서비스 기능 체이닝 방법 및 이를 위한 장치가 개시된다. 구체적으로, 서비스 기능 체이닝(SFC: Service Function Chaining)을 지원하는 시스템에 있어서, 상기 시스템에 유입된 패킷에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정하고, 상기 패킷을 서비스 기능 전달자(SFF: Service Function Forwarder)에게 전달하며, 서비스 기능(SF: Service Function)에 의한 상기 패킷의 검사 결과에 기반하여 상기 패킷의 상기 SFP를 변경하는 분류기(Classifier), 상기 패킷의 SFP 정보에 기반하여 상기 패킷을 하나 이상의 SF에게 전달하고, 상기 하나 이상의 SF 중 어느 하나의 SF로부터 SFP 변경 요청이 수신되면, 상기 패킷을 상기 분류기에게 전달하는 SFF 및 상기 패킷의 검사 결과 상기 SFP에 속하지 않은 SF에 의해 상기 패킷의 검사가 요구되면, 상기 SFF에게 SFP의 변경 요청을 전송하는 SF를 포함할 수 있다.

Description

서비스 기능 체이닝 방법 및 이를 위한 장치{METHOD AND APPARATUS FOR SERVICE FUNCTION CHAINING}

본 발명은 보안 서비스를 제공하는 시스템에 관한 것으로서, 보다 상세하게 서비스 기능 체이닝(SFC: Service Function Chaining)을 지원하기 위한 방법 및 시스템, 이를 위한 장치에 관한 것이다.

오늘날 통신 사업자 및 인터넷 서비스 제공 업체와 같은 다양한 기업에서 운영 비용을 줄이고 보다 효율적이고 유연한 방법으로 자원을 활용하기 위해 네트워크 기능 가상화(NFV: Network Functions Virtualization) 기술을 널리 채택하고 있다. 또한, 제3자(third-party)의 서비스 공급 업체에 의해 제공되는 네트워크 기능 및 자원의 사용이 점차 대중화되고 있다. 기업들은 자신의 네트워크 시스템 및 정보 자산을 보호하기 위하여, 보안 기기(security appliance)를 직접 운영하는 대신에 third-party 보안 공급 업체에 의해 제공되는 보안 기능을 가입하여 사용하기 시작하였다.

이러한 운영 모델은 다양한 이점을 제공한다. 회사는 물리적인 보안 장비 구매에 비용을 지불하지 않아도 되기 때문에 자본 지출(capital outlay)을 줄일 수 있다. 또한, 다양한 공격 시그니처(attack signature)에 대한 최신(up-to-date) 데이터베이스를 항상 유지할 수 있다.

다만, 보안 기능(security function)은 다수의 솔루션 공급 업체(solution vendor)에 의해 개발되고, 다수의 네트워크 운영자에 의해 관리되기 때문에, NFV 기반 보안 기능(NFV-based security function)을 성공적으로 배포하기 위해서는 표준화가 요구된다.

대한민국 공개특허공보 10-2012-0045515, 공개일자 2012년 05월 09일

본 발명에서는 보안 정책 시행(enforcement)을 위한 보안 기능에 대한 서비스 기능 체이닝(SFC)을 이용한 I2NSF(Interface to Network Security Functions) 프레임워크의 아키텍처를 제안한다.

본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 양상은, 서비스 기능 체이닝(SFC)을 지원하는 시스템에 있어서, 상기 시스템에 유입된 패킷에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정하고, 상기 패킷을 서비스 기능 전달자(SFF: Service Function Forwarder)에게 전달하며, 서비스 기능(SF: Service Function)에 의한 상기 패킷의 검사 결과에 기반하여 상기 패킷의 상기 SFP를 변경하는 분류기(Classifier), 상기 패킷의 SFP 정보에 기반하여 상기 패킷을 하나 이상의 SF에게 전달하고, 상기 하나 이상의 SF 중 어느 하나의 SF로부터 SFP 변경 요청이 수신되면, 상기 패킷을 상기 분류기에게 전달하는 SFF 및 상기 패킷의 검사 결과 상기 SFP에 속하지 않은 SF에 의해 상기 패킷의 검사가 요구되면, 상기 SFF에게 SFP의 변경 요청을 전송하는 SF를 포함할 수 있다.

바람직하게, 상기 패킷의 SFP의 정보는 네트워크 서비스 헤더(NSH: Network Service Header)에 포함되고, 상기 NSH는 상기 패킷에 부착될 수 있다.

바람직하게, 상기 패킷의 검사 결과 및 상기 SFP의 변경 요청은 상기 NSH의 메타데이터(metadata)에 포함될 수 있다.

바람직하게, 사용자로부터 제공된 상위 레벨 SFC 정책을 상기 분류기에 의해 해석될 수 있는 하위 레벨 SFC 정책으로 변환하고, SF 전달 테이블(forwarding table)을 생성하여 상기 SFF에게 배포하는 SFC 정책 관리자(SFC Policy Manager)를 더 포함할 수 있다.

바람직하게, 상기 SF 전달 테이블의 엔트리(entry)는 SFF 식별자, SFP를 식별하기 위한 서비스 경로 식별자(SPI: Service Path Identifier), SFP 내 SF의 위치를 식별하기 위한 서비스 인덱스(SI: Service Index) 및 다음 홉(next hop)(즉, 다음으로 거쳐야 할 SF) 정보를 포함할 수 있다.

바람직하게, 이용 가능한 SF의 정보를 포함하는 SFC 정보 테이블을 유지하고, 상기 이용 가능한 SF로부터 주기적으로 로드 상태를 수신함으로써, SF의 추가 또는 제거를 개발자 관리 시스템에 요청하는 SFC 카탈로그 관리자(SFC Catalog Manager)를 더 포함할 수 있다.

바람직하게, 상기 SFC 카탈로그 관리자로부터 SF의 추가 또는 제거를 요청 받으면, SF를 생성 또는 제거하는 상기 개발자 관리 시스템을 더 포함할 수 있다.

바람직하게, 상기 SFC 카탈로그 관리자가 상기 개발자 관리 시스템으로부터 추가 또는 제거된 SF 정보를 수신하면, 상기 SFC 정보 테이블을 업데이트할 수 있다.

바람직하게, 상기 SFF가 상기 분류기로부터 수신한 패킷에 대한 상기 SF 전달 테이블의 엔트리를 가지지 않으면, 상기 SFC 카탈로그 관리자에게 SFF 식별자, SPI, SI를 이용하여 다음 홉(next hop) 정보를 요청할 수 있다.

바람직하게, 상기 패킷의 SFP의 정보는 SFP를 식별하기 위한 서비스 경로 식별자(SPI: Service Path Identifier) 및 SFP 내 다음 홉에 해당하는SF의 위치를 식별하기 위한 서비스 인덱스(SI: Service Index)를 포함할 수 있다.

바람직하게, 상기 분류기는 상기 시스템에 유입된 패킷이 전달된 소스(source)가 신뢰할 수 있는 소스인지 여부를 고려하여 상기 패킷의 SFP를 결정할 수 있다.

본 발명의 다른 일 양상은, 서비스 기능 체이닝(SFC: service function chaining)을 지원하기 위한 방법에 있어서, 분류기(Classifier)가 시스템에 유입된 패킷에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정하는 단계, 상기 분류기가 상기 패킷을 서비스 기능 전달자(SFF: Service Function Forwarder)에게 전달하는 단계 및 상기 SFF로부터 패킷을 수신하면, 서비스 기능(SF: Service Function)에 의한 상기 패킷의 검사 결과에 기반하여 상기 패킷의 상기 SFP를 변경하는 단계를 포함할 수 있다.

바람직하게, 상기 SF에 의해 상기 패킷의 검사 결과 상기 SFP에 속하지 않은 SF에 의해 상기 패킷의 검사가 요구되면, 상기 SF에 의해 SFF에게 SFP의 변경 요청이 전송되고, 상기 패킷이 상기 SFF로부터 상기 분류기에게 전달될 수 있다.

바람직하게, 상기 패킷의 SFP의 정보는 네트워크 서비스 헤더(NSH: Network Service Header)에 포함되고, 상기 NSH는 상기 패킷에 부착될 수 있다.

바람직하게, 상기 패킷의 검사 결과는 상기 NSH의 메타데이터(metadata)에 포함될 수 있다.

본 발명의 실시예에 따르면, 보안 기능 체이닝의 상위-레벨(high-level) 정책을 하위-레벨(low-level) 정책으로 해석(interpret)하고, 상위-레벨 정책을 관리할 수 있도록 보안 제어기의 기능들이 확장될 수 있다.

또한, 본 발명의 실시예에 따르면, 시스템에 가용한 서비스 기능(SF: Service Function) 인스턴스(instance)와 그들의 정보(예를 들어, 네트워크 정보 및 워크로드(workload))를 기록하고, 주어진 서비스 기능 체인(chain)/경로(path)를 위해 사용할 SF instance를 결정할 수 있다.

또한, 본 발명의 실시예에 따르면, 보안 제어기(security controller)에 의해 제공되는 전달 정보(forwarding information)에 기반하여, 서비스 기능 전달자(SFF: Service Function Forwarder)는 요구되는 다양한 보안 기능을 통해 네트워크 트래픽 스티어링을 수행할 수 있다.

또한, 본 발명의 실시예에 따르면, 분류기(classifier)가 security controller에 의해 주어진 SFC 정책의 시행을 위해 배치될 수 있다. 이 classifier는 SFF에 의해 요구되는 보안 기능 체인/경로를 통해 트래픽이 전달될 수 있도록 정책들에 기반하여 트래픽 분류를 수행할 수 있다.

본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명의 일 실시예에 따른 SFC 가능한(SFC-enabled) I2NSF 아키텍처를 예시한다.
도 2는 본 발명의 일 실시예에 따른 초기 서비스 기능 경로에 따른 트래픽 스티어링 과정을 예시한다.
도 3은 본 발명의 일 실시예에 따른 DDoS 공격 시나리오에서 동적 SFP 변경을 예시하는 도면이다.
도 4는 본 발명의 일 실시예에 따른 트래픽에 적용 가능한 SFP를 예시한다.
도 5는 본 발명의 일 실시예에 따른 서비스 기능 체이닝 방법을 예시하는 도면이다.
도 6은 본 발명의 일 실시예에 따른 SFC 가능한 시스템 내 장치의 블록 구성도를 예시한다.

이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.

이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.

최근, NFV-based security function을 위한 기본 표준 인터페이스가 I2NSF(Interface to Network Security Functions) 워킹 그룹에 의해 개발되고 있다. 이는 인터넷 엔지니어링 태스크 포스(IETF: Internet Engineering Task Force)로 불리는 국제 인터넷 표준 기구의 일부이다.

I2NSF의 목적은 다수의 보안 솔루션 벤더(security solution vendor)들에 의해 제공되는 이종의(heterogeneous) 네트워크 보안 기능(들)(NSF: network security function)을 위한 표준화된 인터페이스를 정의하기 위함이다.

I2NSF 아키텍처(architecture)에서, NSF(들)의 관리에 대하여 상세히 고려할 필요 없이(NSF의 관리는 결국 보안 정책의 시행(enforce)을 요구한다), 사용자는 사용자의 네트워크 시스템 내 네트워크 자원을 보호하기 위한 보호 정책을 정의할 수 있다. 또한, 다수의 vendor들로부터 NSF(들)로의 표준화된 인터페이스는 이종의 NSF(들)에 대한 태스크(task)의 설정 및 관리를 단순화할 수 있다.

최근 들어 더욱 다양해지고 복잡해지는 네트워크 공격에 효과적으로 대처하기 위해서는 다양한 보안 기능(들)(security functions)(또는 네트워크 보안 기능(들)(NSF: Network Security Functions)이 협력하여(cooperatively) 네트워크 트래픽(traffic)에 대한 복합적인 보안 분석을 수행할 필요가 있다. 또한, 네트워크 트래픽의 특성과 의심되는 수준(suspiciousness level)에 따라 다양한 타입의 네트워크 트래픽이 서로 다른 SF들의 세트를 통해 분석될 필요가 있다.

이러한 요구 사항을 충족시키기 위해서는 개별 보안 기능을 위한 보안 정책 규칙 외에도 네트워크 트래픽 패킷을 검사할 때 통과시켜야 하는 보안 기능의 세트를 결정하는 네트워크 보안을 위한 서비스 기능 체이닝(SFC)에 대한 추가 정책이 필요하다.

또한, 최근 자체 분석 결과를 기반으로 추가 보안 기능을 실행함으로써 보안 기능이 추가 검사를 트리거(trigger)할 수 있게 하는 NSF 능력의 정보 모델이 제안되었다. 그러나, I2NSF 프레임워크의 현재 설계는 보안 기능들 간의 체이닝(chaining)을 가능하게 하기 위해 네트워크 트래픽 스티어링을 완전히 고려하지 않는 단점이 있다.

이러한 단점을 해결하기 위하여 본 발명에서는 보안 정책 시행(enforcement)을 위하여 보안 기능들 간 체이닝(chaining)이 가능한 I2NSF 프레임워크의 아키텍처를 제안한다. 다시 말해, 본 발명에서는 보안 기능 체이닝을 지원하기 위하여 I2NSF 프레임워크에 서비스 기능 체이닝(SFC: Service Function Chaining)으로부터의 추가적인 구성요소를 통합한 아키텍처를 제안한다.

여기서, 보안 기능 체이닝(security function chaining)은 I2NSF 프레임워크 내 네트워크 보안 기능(들)(NSF: network security function) 능력을 위한 정보 모델에 따라 다중 타입의 NSF들을 통해 트래픽을 스티어링(steering)에 의한 네트워크 트래픽에 대한 복합적인 검사(composite inspection)을 가능하게 한다.

본 발명은 크게 다음과 같은 효과를 가진다.

- 보안 기능 체이닝을 위한 정책 설정: 본 발명에 따른 SFC 가능한(SFC-enabled) I2NSF 아키텍처는 정책 설정 및 보안 기능 체이닝(chaining)을 관리를 가능하게 한다. chaining 정책에 기반하여, 관련된 네트워크 트래픽은 조합(composite), 협력(cooperative) 방식으로 다양한 종류의 보안 기능들을 정해진 순서로 거침으로서 복합적인 보안 분석을 거친다.

- 보안 기능 체이닝 을 위한 네트워크 트래픽 스티어링(steering): 본 발명에 따른 SFC-enabled I2NSF 아키텍처는 네트워크 트래픽이 SFC 정책에 기반하여 요구되는 다중의 보안 기능들을 통해 steering되는 것을 가능하게 한다. 또한, NSF 능력을 위한 I2NSF 정보 모델은 NSF가 자신의 검사 결과에 기반하여 추가적인 검사를 위해 또 다른 보안 기능을 호출(call) 할 수 있다. 이러한 요구사항을 만족시키기 위하여, SFC-enabled I2NSF 아키텍처는 또한 하나의 보안 기능으로부터 또 다른 보안 기능으로의 트래픽 전달(forwarding)을 가능하게 한다.

- 보안 기능 instance에서 로드 밸런싱(load balancing): 본 발명에 따른 SFC-enabled I2NSF 아키텍처는 유연한 트래픽 스티어링 메커니즘을 활용함으로써(leveraging) 이용 가능한 보안 기능 instance에서 들어오는(incoming) 트래픽의 로드 밸런싱(load balancing)을 제공한다. 이를 위해, SFC-enabled I2NSF 아키텍처는 보안 기능을 위해 과도한 양이 요구될 때, 보안 기능의 동적인 인스턴스 생성(instantiation)을 수행할 수 있다.

본 문서에서 사용될 수 있는 용어(terminology)들은 다음과 같이 정의된다.

- 서비스 기능/보안 기능(SF: Service Function/Security Function): 수신한 패킷의 특별한 처리를 담당하는 기능. SF는 프로토콜 스택의 다양한 계층(예를 들어, 네트워크 계층 또는 다른 OSI(Open System Interconnection) 계층) 에서 동작할 수 있다.

본 명세서에서, SF는 서비스 기능 및 보안 기능 모두를 나타내기 위해 사용된다.

보안 서비스 기능의 예를 다음과 같다: 방화벽(Firewall), 침입 방지/탐지 시스템(IPS/IDS: Intrusion Prevention/Detection System), 심층 패킷 분석(DPI: Deep Packet Inspection), 어플리케이션 가시성 및 제어(AVC: Application Visibility and Control), 네트워크 바이러스 및 악성코드(malware) 스캐닝, 샌드박스(sandbox), 데이터 유출 방지(DLP: Data Loss Prevention), 분산 서비스 거부 공격(DDoS: Distributed Denial of Service) 완화, TLS(Transport Layer Security) 프록시.

- 분류기(Classifier): 분류를 수행하는 요소. Classifier는 SFC 정책 관리자(SFC Policy Manager)로부터 주어진 정책을 이용한다.

- 서비스 기능 체인(SFC: Service Function Chain): SFC는 선택된 패킷 및/또는 프레임 및/또는 플로우(flow)에 적용되어야 하는 추상화된 SF의 정렬된 세트 및 순서 제약(ordering constraint)을 정의한다.

- 서비스 기능 전달자(SFF: Service Function Forwarder): SFF는 SFC 인캡슐레이션(encapsulation) 내에서 전달되는 정보에 따라 하나 이상의 연결된 SF로의 트래픽의 전달 및 SF로부터 복귀하는 트래픽의 제어를 담당한다. 또한, SFF는 필요하고 지원될 때 Classifier에게 트래픽의 전달, 또 다른 SFF(동일한 또는 서로 다른 타입의 오버레이(overlay) 내)로의 트래픽 이동(transport), 및 서비스 기능 경로(SFP: Service Function Path)의 종료를 담당한다.

- 서비스 기능 경로(SFP: Service Function Path): SFP는 특정 SFF에게 할당된 패킷이 전달되어야 하는 제한된 규격/명세(specification)이다. 패킷 처리를 위한 정확한 위치를 식별할 수 있도록 제한될 수 있거나, 또는 그러한 위치에 대하여 덜 구체적일 수 있다.

- SFC 정책 관리자(SFC Policy Manager): SFC Policy Manager는 상위 레벨 정책을 하위 레벨 정책으로 변환/해석(translate)하고, SFC 인식(SFC-aware) 노드를 위한 설정을 수행하고, 변환/해석된 정책 및 설정을 SFC 인식(SFC-aware) 노드에게 전달하고, 안정된(stabilized) 네트워크를 유지하는 것을 담당한다.

- SFC 카탈로그 관리자(SFC Catalog Manager): SFC Catalog Manager는 이용 가능한 SF instance의 정보를 기록하는 것을 담당한다. 예를 들어, SF instance의 정보는 SF instance에 대한 지원되는 전송 프로토콜(transport protocol), IP 주소, 위치를 포함한다.

- 제어 노드(Control Node): Control Node는 SFC Policy Manager, SFC Catalog Manager, SFF 및 Classifier를 총칭한다.

- 서비스 경로 식별자(SPI: Service Path Identifier): SPI는 서비스 경로(즉, SFP)를 식별한다. Classifier는 경로 선택을 위해 이 식별자를 사용하여야 하며, Control Node는 다음 홉(next hop)(즉, 다음으로 검사를 거쳐야 할 SF 정보)을 찾기 위해 이 식별자를 사용하여야 한다.

- 서비스 인덱스(SI: Service Index): 이는 서비스 경로(즉, SFP) 내 현재 SF의 위치를 식별한다. SI는 요구되는 서비스를 수행한 후에 SF 또는 프록시 노드에 의해 감소(decrement)되어야 한다.

- 네트워크 서비스 헤더(NSH: Network Service Header): 이 헤더는 SFC 관련 정보를 나르기 위해 사용된다. 기본적으로, SPI 및 SI는 이 헤더를 통해 SFC의 Control Node에게 전달(convey)된다.

- SF 전달 테이블(SF Forwarding Table): SFC Policy Manager는 이 테이블을 유지한다. 이는 SFC-enabled I2NSF 아키텍처에 대한 모든 forwarding information을 포함한다. 각 항목(entry)은 SFF 식별자, SPI, SI 및 next hop 정보를 포함한다. 예를 들어, 특정 항목("SFF: 1", "SPI: 1", "SI: 1", "IP: 192.168.xx.xx")은 다음과 같이 해석된다: "SFF 1"은 "SPI 1" 및 "SI 1"을 포함하는 트래픽을 "IP=192.168.xx.xx"에게 전달하여야 한다.

이하, 본 발명에 따른 SFC-enabled I2NSF 아키텍처 및 서비스 체이닝의 동작, 그리고 아키텍처 내 각 구성요소에 관하여 보다 상세히 살펴본다.

도 1은 본 발명의 일 실시예에 따른 SFC 가능한(SFC-enabled) I2NSF 아키텍처를 예시한다.

도 1을 참조하면, 본 발명에 따른 SFC-enabled I2NSF 아키텍처는 I2NSF 사용자(user)(또는 사용자 장치), 보안 관리 시스템(Security Management System) 및 보안 네트워크(Security Network)를 포함하여 구성될 수 있다.

I2NSF User와 Security Management System는 소비자-직면 인터페이스(Consumer-Facing Interface)로 연결될 수 있다. 그리고, Security Management System과 Security Network는 NSF-직면 인터페이스(NSF-Facing Interface)로 연결될 수 있다.

Security Management System은 보안 제어기(Security Controller)와 개발자 관리 시스템(Developer's Management System)을 포함할 수 있다. 그리고, Security Controller는 SFC 정책 관리자(SFC Policy Manager) 및 SFC 카탈로그 관리자(SFC Catalog Manager)를 포함할 수 있다.

Security Controller와 Developer's Management System은 등록 인터페이스(Registration Interface)로 연결될 수 있다.

Security Network는 Classifier, 하나 이상의 SFF(도 1의 경우, SFF1 및 SFF2) 및 하나 이상의 SF(도 1의 경우, SF1, SF2, SF3)를 포함할 수 있다.

본 발명에 따른 SFC-enabled I2NSF 아키텍처는 전송 중인 트래픽 패킷의 복합 검사를 지원하도록 설계되었다. 각 SF의 검사 결과에 따르면, 트래픽 패킷은 보다 자세한 분석을 위해 다른 SF로 스티어링(steering)될 수 있다.

또한, 기존의 I2NSF 프레임워크의 구성 요소에 I2NSF 사용자 (즉, I2NSF User)로부터 높은 레벨의 SFC-관련 정책과 설정을 반영할 수 있다. 또한, 본 발명에서 제안된 아키텍처는 로드 밸런싱(load balancing), 자동 추가의 SF 생성 및 사용되지 않은 SF의 제거 등의 기능을 제공한다.

이러한 설계 목적을 달성하기 위해 기존의 I2NSF 프레임 워크에 여러 구성 요소를 통합할 수 있다.

이하, 각 구성 요소에 대하여 살펴본다.

- I2NSF User

I2NSF user는 네트워크 운영자의 기반시설(infrastructure)을 통해 네트워크 서비스를 제공 받는 기업 네트워크(enterprise network)의 관리자(administrator)(또는 관리자 장치)를 나타낸다.

I2NSF user는 또한 다양한 악의적인(malicious) 공격으로부터 enterprise network 트래픽(traffic)을 보호하기 위하여 네트워크 보안 서비스(network security service)를 이용할 필요가 있다. security service를 요청하기 위하여, I2NSF user는 자신이 원하는 security service의 상위-레벨(high-level) 보안 정책(security policy)을 특정(specify)하고, Security Controller에게 high-level security policy을 알릴 수 있다.

high-level security policy를 준비하는 과정에서, I2NSF user는 각 SF(들)를 위한 security service 또는 보안 정책 규칙 설정(security policy rule configuration)을 실현하기 위하여 요구되는 SF(들)의 타입에 대하여 고려하지 않을 수 있다.

또한, I2NSF user는 Security Controller를 통해 SF(들) 내에서 발생되는 보안 이벤트(들)(security event)를 통지 받을 수 있다. 이들의 security event(들)을 분석함으로써, I2NSF user는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 high-level security policy를 업데이트(또는 생성)할 수 있다.

- SFC Policy Manager

SFC Policy Manager는 본 발명에서 제안된 시스템의 핵심적인 구성 요소이며, 다음과 같은 두 가지의 기능을 담당한다.

(1) I2NSF 클라이언트가 제공하는 높은 레벨의 SFC 정책(또는 설정)을 낮은 레벨의 SFC 정책(또는 설정)으로 해석/변환하고, 해석/변환된 정책을 보안 기능 체이닝을 위해 분류자(classifier)에게 전달한다.

(2) SFC Catalog Manager(Catalog Manager)와 협의하여 SF 전달 테이블 생성 및 SFF(들)에게로 forwarding information을 배포한다.

도 1에서 예시된 바와 같이, SFC Policy Manager는 소비자-직면 인터페이스(Consumer-Facing Interface) 및 NSF-직면 인터페이스(NSF-Facing Interface)를 통해 이러한 추가적인 기능을 수행한다.

Consumer-Facing Interface를 통해 I2NSF User로부터 높은 레벨의 SFC 정책/설정이 주어지면, SFC Policy Manager는 이를 classifier(들)이 이해할 수 있는 낮은 레벨의 정책/설정으로 해석/변환한다. 그 다음, 해석/변환 결과인 낮은 레벨의 정책을 classifier(들)에게 제공한다.

또한, SFC Policy Manager는 traffic steering의 유연한 변경을 위한 새로운 정책을 생성함으로써 SF의 현재 상태에 신속하게 대응할 수 있다. 예를 들어, "방화벽 instance 1"이 혼잡 상태에 있는 경우, "방화벽 instance 1" 대신에 모든 후속된 패킷을 "방화벽 instance 2"로 전달하는 새로운 규칙을 생성할 수 있다.

SFC Policy Manager는 SF 전달 테이블을 생성하기 위해 SFC Catalog Manager로부터 SF(들)에 대한 정보를 획득한다.

테이블 생성 프로세스에서 SFC Policy Manager는 SFC 정책, SF 로드 상태, SF 물리적 위치 및 지원되는 전송 프로토콜(transport protocol) 등과 같이 다양한 기준을 고려한다. SF 전달 테이블의 엔트리는 SFF 식별자, SPI, SI 및 next hop 정보 중 하나 이상을 포함한다. next hop 정보의 일례로서, IP 주소 및 지원되는 전송 프로토콜(transport protocol)(예를 들어, VxLAN 및 GRE)을 포함할 수 있다. 이러한 전달 테이블 업데이트는 푸쉬(push) 또는 풀(pull) 방식으로 SFF(들)에게 배포된다.

- SFC Catalog Manager

SFC Catalog Manager는 보안 컨트롤러에 통합된 구성 요소이며, SFC Catalog Manager는 다음과 같은 세 가지의 기능을 담당한다.

(1) IP 주소, 지원되는 전송 프로토콜(transport protocol), 서비스 이름 및 로드 상태와 같은 사용 가능한 모든 SF instance의 정보를 유지 관리한다.

(2) SFC Policy Manager로부터 사용 가능한 SF instance에 대한 질의에 응답함으로써 주어진 SFP와 관련된 전달 테이블 항목을 생성하는 것을 지원한다.

(3) 자원 낭비를 방지하기 위해 기존 SF instance를 제거하거나 또는 서비스 혼잡을 방지하기 위해 추가적인 SF instance를 동적으로 생성하도록 Developer's Management System에 요청한다.

새로운 SF instance가 등록 될 때마다, Developer's Management System은 등록된 SF instance의 정보를 SFC Catalog Manager에게 전달하므로, SFC Catalog Manager는 사용 가능한 모든 SF instance의 정보 목록을 유지 관리할 수 있다. 그리고, SFC Policy Manager로부터 특정 SFP에 대한 쿼리를 받으면, SFC Catalog Manager는 해당 SFP에 적용할 수 있는 모든 사용 가능한 SF instance를 검색한 다음, 검색 결과를 SFC Policy Manager에게 반환한다.

본 발명에 따른 시스템에서, 각 SF instance는 주기적으로 SFC Catalog Manager에 로드 상태를 보고한다. 이러한 보고를 기반으로 SFC Catalog Manager는 SF instance의 정보를 업데이트하고, SF instance의 추가 생성 또는 제거를 위해 Developer's Management System에 요청하여 SF instance 풀(pool)을 동적으로 관리한다. 결과적으로 SFC Catalog Manager는 혼잡 및 자원 낭비를 방지함으로써 효율적인 자원 활용을 가능하게 한다.

- Developer’s Management System

Developer’s Management System은 벤더의 관리 시스템(Vendor's Management System)으로 지칭될 수도 있다. Developer’s Management System은 네트워크 운영자에게 NSF(들)을 제공하는 제3자(third-party) 보안 벤더에 의해 관리될 수 있다. 다양한 보안 벤더의 다수의 Developer’s Management System(들)이 존재할 수 있다.

본 발명에서는 다음과 같이 추가 기능을 위해 Developer’s Management System을 확장한다.

앞서 설명한 바와 같이, SFC Catalog Manager는 해당 서비스 기능의 기존 instance가 혼잡해지면, Developer’s Management System에게 추가적인 SF instance를 생성하도록 요청한다. 반면, 특정 서비스 기능에 대한 instance 수가 너무 많으면, SFC Policy Manager는 Developer’s Management System에게 SF instance 중 일부를 제거하도록 요청한다. 이러한 요청에 대한 응답으로 Developer’s Management System은 SF instance를 생성 및/또는 제거한다. 새로운 SF instance를 생성하거나 또는 기존 SF instance를 제거할 때, 변경 사항은 SFC Catalog Manager에게 통보된다.

- Classifier

Classifier는 독립된(standalone) 구성 요소로 존재하거나 또는 다른 구성 요소의 하위 모듈(submodule)로 존재할 수 있는 논리적 구성 요소이다.

도 1에서는 Classifier가 standalone 구성 요소로 도시하고 있으나, 본 발명이 이에 한정되는 것은 아니다. 예를 들어, Classifier는 SFF에 포함(즉, 하나의 장치로 함께 구현)될 수 있다.

본 발명에 따른 시스템에서 초기 Classifier는 일반적으로 네트워크 도메인의 경계 라우터(border router)와 같은 진입 점(entry point)에 위치하며, SFC policy manager에 의해 제공된 SFC 정책에 따라 모든 수신 패킷의 초기 분류를 수행한다.

여기서, 분류는 주어진 패킷이 통과해야 하는 SFP를 결정하는 것을 의미한다. SFP가 결정되면 Classifier는 해당 SPI 및 SI를 특정하는 NSH를 구성하고, 이를 패킷에 부착한다. 그러면 패킷은 NSH 정보를 기반으로 결정된 SFP를 통해 전달될 수 있다.

- Service Function Forwarder (SFF)

SFF는 다음과 같은 두 가지 기능을 담당한다.

(1) 패킷을 다음 SFF/SF로 전달한다.

(2) SF로부터의 재분류 요청을 처리한다.

SFF는 기본적으로 전달 기능을 수행하므로, 들어오는 트래픽에 대해 다음 SF/SFF를 찾아야 한다.

SFF는 전달 테이블을 검색하여 주어진 트래픽에 상응하는 next hop 정보를 찾는다.

만약, SFF가 전달 테이블에서 타겟 엔트리를 찾은 경우, SFF는 트래픽에 포함된 next hop 정보에 의해 특정된 다음 SF/SFF로 트래픽을 전달한다.

반면, SFF가 특정 패킷에 대한 엔트리(즉, SF 전달 테이블의 엔트리)를 가지지 않으면, SFF는 SFF 식별자, SPI 및 SI 정보를 이용하여 next hop 정보를 SFC Policy Manager에게 요청한다. SFC Policy Manager는 next hop 정보로 SFF에게 응답한 다음, SFF는 응답으로서 해당 전달 테이블을 업데이트하고 트래픽을 next hop으로 전달한다.

SF가 추가 보안 검사를 위해 의심스러운 패킷을 다른 SF로 전달할 수도 있다. 이를 I2NSF 내 진보된 보안 조치로 지칭한다.

이러한 상황에서, 다음으로 요구되는 SF가 패킷의 현재 SFP 상의 SF가 아닌 경우, 패킷의 SFP를 변경하기 위해 재분류가 요구된다. 현재 SF가 그 자체로 패킷을 재분류 할 수 있는 경우, SF는 진보된 보안 조치를 제공하기 위해 패킷 내의 NSH 내의 SPI 필드를 업데이트한다.

그렇지 않으면, classifier가 독립형(standalone)으로 존재하면, SF는 패킷의 검사 결과를 NSH의 메타데이터(MetaData) 필드에 첨부하여 소스 SFF로 전달한다. 첨부된 MetaData는 보다 엄격한 검사를 위해 패킷의 SFP를 다른 SFP로 변경하기 위한 재분류 요청을 포함한다. SFF가 재분류를 요구하는 트래픽을 수신하면, SFF는 Classifier에게 트래픽을 전달하여 최종적으로 재분류가 수행된다.

SFC는 SFF(들)과 SF(들)로 패킷에 의한 실제 방문 순서를 표현하는 표현된 서비스 경로(RSP: Rendered Service Path)를 정의한다. 패킷의 RSP 정보가 이용 가능한 경우, SFF는 이 RSP 정보를 체크하여 바람직하지 않은 루핑(looping)이 패킷에서 발생했는지를 검출할 수 있다. SFF가 looping을 감지하면, SFF는 이 looping을 Security Controller에 통지할 수 있으며, Security Controller는 이 looping을 해결하기 위한 관련된 보안 정책 규칙을 수정할 수 있다.

다음으로, 도 1에 예시된 architecture의 인터페이스에 대하여 살펴본다.

- CFI(Consumer-Facing Interface): 도 1에서 볼 수 있듯이, CFI는 I2NSF user와 Security Management System 사이에 위치하고, CFI는 사용자의 I2NSF 시스템으로의 인터페이스이다. 이렇게 설계됨으로써, 하위(underlying) SF(들)의 상세한 내용을 숨기고, 사용자에게 SF(들)의 추상적인 시각(abstract view)만을 제공한다.

이 인터페이스의 주요한 목적은 사용자가 I2NSF 시스템에게 보안 서비스를 요청할 수 있도록 허용하기 위함이다. 또한, Security Controller가 하위(underlying) SF(들)로부터 수신한 보안 경보(alert)를 이 CFI를 통해 사용자에게 전달하기 위함이다. 수신한 경보를 분석함으로써, 사용자는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 high-level security policy를 업데이트(또는 생성)할 수 있다.

- NFI(NSF-Facing Interface): NFI는 Security Network와 Security Controller 사이에 위치한다.

NFI의 주요한 목적은 SF(들)로부터 보안 관리 기법을 분리(decouple)함으로써 다양한 보안 솔루션 벤더들의 SF(들)을 제어하고 관리하기 위한 표준화된 인터페이스를 제공하기 위함이다. NFI는 SF(들)의 상세한 내용(예를 들어, 벤더, 유형 인자(form factor) 등)과 독립된다. 따라서, security policy rule을 SF에게 설정할 때, Security Controller는 벤더 간 특정한 차이 및/또는 SF의 form factor를 고려할 필요가 없다.

기본적으로, NFI 인터페이스를 통해, Security Controller는 I2NSF user에 의한 high-level security policy를 시행하기 위하여 플로우 기반(flow-based) security policy를 각 타겟 SF에게 전달할 수 있다. 원격 유지(maintenance)의 목적으로, Security Controller는 NFI 인터페이스를 통해 NSF(들)에게 제어 명령을 트리거할 수 있다.

각 NSF는 또한 Security Controller에게 현재 상태(예를 들어, workload 레벨, 혼잡(congestion) 등)를 주기적으로 알리기 위하여 NFI 인터페이스를 사용할 수 있다. 또한, 보안 이벤트/경보가 SF 상에 발생할 때마다, SF는 NFI 인터페이스를 통해 Security Controller에게 이를 보고할 수 있다.

각 SFF는 SFC Catalog Manager로부터 NFI 인터페이스를 통해 시스템 내 구동 중인 SF의 전달 정보(forwarding information)를 수신할 수 있다. 이때, SFF가 주어진 traffic을 전달하기 위한 forwarding information를 가지고 있지 않은 경우, SFF는 NFI 인터페이스를 통해 SFC Catalog Manager에게 정보의 쿼리(query)를 전송할 수 있다.

- RI(Registration Interface): 도 1에서 볼 수 있듯이, RI는 Security Controller와 Developer's Management System 사이에 위치한다. RI의 주요한 목적은 SF instance의 동적인 life-cycle 관리 및 시스템 상에 새로운 SF instance의 등록을 수행하기 위함이다.

새로운 SF가 시스템 내 요구되면, SFC Catalog Manager는 새로운 SF 생성을 Developer's Management System에게 요청할 수 있다. 이때, SFC Catalog Manager의 요청은 요청된 SF instance의 프로파일(profile)을 포함하고, 이 profile은 SF instance에 의해 제공되어야 하는 보안 능력(security capability) 및 서비스 능력(service capacity)을 특정할 수 있다.

이 요청이 수신되면, Developer's Management System은 요청된 SF profile을 만족하는 새로운 SF instance를 생성하고, SFC Catalog Manager에게 이 새로운 SF instance의 네트워크 액세스 정보(network access information)(예를 들어, IP(Internet Protocol) 주소, 포트 넘버(port number) 등)를 알릴 수 있다. 네트워크 액세스 정보는 시스템 내 새로운 SF instance의 고유한 식별자로서 사용될 수 있다.

반면, SFC Catalog Manager가 특정한 기존의 NSF instance가 더 이상 필요하지 않다고 결정하면, SFC Catalog Manager는 Developer's Management System에게 해당 SF instance를 제거(destruct)하라고 요청할 수 있다. 이 제거 요청(destruction request)는 제거될 SF instance의 고유한 식별자를 포함할 수 있다.

도 2는 본 발명의 일 실시예에 따른 초기 서비스 기능 경로에 따른 트래픽 스티어링 과정을 예시한다.

(1 단계) 트래픽(즉, packet)에 대한 SFC 정책(또는 설정)이 미리 정의된다. 즉, SFC Policy Manager는 높은 레벨의 SFC 정책(또는 설정)을 낮은 레벨의 SFC 정책(또는 설정)으로 해석/변환하고, 해석/변환된 정책을 서비스/보안 기능 체이닝을 위해 classifier에게 전달한다.

(2 단계) 초기 Classifier는 SFC policy manager에 의해 제공된 SFC 정책에 따라 I2NSF 아키텍처 내 들어온 트래픽(즉, packet)을 최초로 분류한다. 즉, 해당 트래픽이 어떠한 SF을 통해 검사되는지에 대한 SFP를 결정한다. SFP가 결정되면 Classifier는 해당 SPI 및 SI를 특정하는 NSH를 구성하고, 이를 패킷에 부착한다.

도 2에서는 해당 트래픽이 SF1을 통해 검사되고, 이어 SF2를 통해 검사되는 SFP가 결정되었다고 가정한다.

(3 단계) 트래픽은 결정된 SFP를 거치도록 트래픽 스티어링된다. 즉, 트래픽은 결정된 SFP에 따라 SFF를 경유하여 SF1에게 전달된다.

(4 단계) SF1에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 SF2에게 전달된다. 이때, 해당 트래픽에 대하여 결정된 SFP(SPI 및 SI를 특정하는 NSH)도 함께 전달된다.

이와 같이, 트래픽이 I2NSF 아키텍처 내 유입되면, 미리 정해진 미리 정의된 SFC 정책(또는 설정)에 따라 해당 트래픽에 대한 SFP가 결정된다.

다만, 본 발명은 이에 한정되는 것은 아니며 SFP가 재분류를 통해 동적으로 변경될 수 있다. 이에 대하여 보다 구체적인 설명은 후술한다.

이하, 본 발명에서 제안되는 SFC-enabled I2NSF 아키텍처의 주요 이점을 다루기 위한 (1) 동적 경로 변경(Dynamic Path Alternation), (2) 신뢰 수준(Trust Level)에 따라 다른 SFP 적용, (3) 동적 SF 인스턴스화(Dynamic SF Instantiation)를 사용한 효과적인 로드 밸런싱(Load Balancing) 실시예를 설명한다.

(1) 동적 경로 변경(Dynamic Path Alternation)

SFC-enabled I2NSF 아키텍처에서 Classifier는 SFC 정책에 따라 들어온(incoming) 트래픽의 초기 SFP를 결정한다.

그 다음 Classifier는 패킷(들)에 결정된 SFP를 특정하는 NSH를 부착하고, 패킷(들)은 초기 SFP의 SF를 통해 분석된다.

그러나, 여기서 SFP는 정적 속성이 아니므로, 재분류를 통해 동적으로 변경될 수 있다. 예를 들어, 초기 SFP에 속하는 특정 SF가 트래픽이 매우 의심스럽다고 (악성일 가능성이 높음) 감지할 수 있다. 이 경우, 트래픽은 좀 더 정교한 SF로 구성된 다른 SFP를 통해 보다 강력한 검사를 받을 필요가 있다.

도 3은 본 발명의 일 실시예에 따른 DDoS 공격 시나리오에서 동적 SFP 변경을 예시하는 도면이다.

SFP-1은 트래픽이 처음에 따르는 기본 서비스 기능 경로를 나타내며, 도 3에서는 SFP-1이 AVC, 방화벽(Firewall) 및 IDS/IPS로 순서로 구성되는 경우를 예시한다.

소스(Source)로부터 수신된 트래픽(즉, 패킷)은 Classifier에 의해 결정된 SFP에 따라 SFF를 경유하여 AVC에게 전달된다. 그리고, AVC에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 Firewall에게 전달된다. 그리고, Firewall에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 IDS/IPS에 전달된다. 그리고, IDS/IPS에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 목적지(Destination)에게 전달된다.

만약, IDS/IPS가 트래픽이 DDoS 공격을 시도하고 있다고 판단하면, DDoS 공격 완화기(DDoS Attack Mitigator)가 공격에 대한 적절한 대책을 실행할 수 있도록 IDS/IPS는 트래픽의 SFP를 기본값(즉, SFP-1)에서 SFP-2로 변경할 수 있다. 즉, IDS/IPS 자체 검사 결과에 기반하여 트래픽의 SFP가 기본값(즉, SFP-1)에서 SFP-2로 변경될 수 있다.

이러한 SFP 변경은 재분류(re-classification)를 지원하는 본 발명에 따른 아키텍처에서 수행될 수 있다.

앞서 도 1을 다시 참조하면, 재분류를 시작하기 위해 IDS/IPS는 자체 검사 결과를 NSH의 MetaData 필드에 추가하여 원래 트래픽을 수신하였던 SFF로 전달한다.

그 다음 SFF는 재분류를 위해 IDS/IPS의 검사 결과를 포함하여 수신된 트래픽을 Classifier에게 전달한다.

Classifier는 검사 결과를 체크하고, SFC 정책의 검사 결과와 관련된 새로운 SFP (SFP-2)를 결정하고, NSH를 SFP-2의 SPI로 업데이트한다. 결국, 트래픽은 DDoS Attack Mitigator로 전달된다.

SFP-2는 트래픽이 따르는 새로운 서비스 기능 경로를 나타내며, 도 2에서는 SFP-2이 AVC, Firewall, DDoS Attack Mitigator, IDS/IPS 순서로 구성되는 경우를 예시한다.

소스(Source)로부터 수신된 트래픽(즉, 패킷)은 Classifier에 의해 결정된 SFP에 따라 SFF를 경유하여 AVC에게 전달된다. 그리고, AVC에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 Firewall에게 전달된다. 그리고, Firewall에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 DDoS Attack Mitigator에 전달된다. 그리고, DDoS Attack Mitigator에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 IDS/IPS에게 전달된다. 그리고, IDS/IPS에 의해 검사가 수행된 후, 해당 트래픽은 목적지(Destination)에게 전달된다.

(2) 신뢰 수준(Trust Level)에 따라 다른 SFP 적용

신뢰할 수 있는 소스로부터 들어온 트래픽은 무해할 가능성이 높으므로 지나치게 검사할 필요가 없다. 반면, 신뢰할 수 없는 소스로부터 들어온 트래픽은 심층적인 검사가 필요하다. 신뢰할 수 있는 소스의 트래픽에 최소한의 요구되는 보안 기능을 적용함으로써 불필요한 자원 낭비를 방지할 수 있다.

또한, 잠재적인 악성 트래픽에 더 많은 자원을 집중할 수 있다. SFC-enabled I2NSF 아키텍처에서는 트래픽 소스의 신뢰 수준을 고려하여 SFC 정책을 구성함으로써, 서로 다른 소스에서 들어오는 트래픽에 서로 다른 SFP를 적용할 수 있다.

도 4는 본 발명의 일 실시예에 따른 트래픽에 적용 가능한 SFP를 예시한다.

도 4(a)는 신뢰할 수 있는 소스로부터 들어온 트래픽에 적용 가능한 SFP(들)을 예시하고, 도 4(b)는 신뢰할 수 없는 소스로부터 들어온 트래픽에 적용 가능한 SFP(들)을 예시한다.

도 4(a)에서는 패킷 헤더 검사만을 수행하도록 구성된 경량(lightweight) IDS/IPS를 가정한다.

이 시나리오에서, 신뢰할 수 있는 소스로부터 트래픽을 수신하면, classifier는 트래픽이 경량 IDS/IPS에 의한 단순한 분석을 통과하도록 도 4(a)와 같은 SFP를 결정한다.

반면, 신뢰할 수 없는 소스로부터 들어온 트래픽은 세 가지 유형의 SF로 구성된 도 4(b)의 SFP를 통해 보다 철저한 검사가 수행될 수 있다.

즉, classifier는 도 4(b)와 같이 트래픽이 Firewall, 안티-스푸핑 기능(Anti-Spoofing function) 및 DPI의 순서로 구성되는 SFP를 결정할 수 있다.

(3) 동적 SF 인스턴스화(Dynamic SF Instantiation)를 사용한 효과적인 로드 밸런싱(Load Balancing)

대규모 네트워크 도메인에서는 일반적으로 다양한 보안 서비스를 제공하는 다수의 SF instance가 존재한다.

이때, 특정 SF instance가 자신의 용량을 초과하여 과도한 트래픽을 경험할 가능성이 있다. 이와 같이 SF instance에 과도한 트래픽이 요구되는 경우, 트래픽의 일부를 동일한 보안 기능의 사용 가능한 다른 instance에 할당하는 것이 바람직하다.

이때, 사용 가능한 동일한 보안 기능의 추가의 instance가 없는 경우, 새로운 SF instance를 생성한 후속(subsequent) 트래픽을 새로운 instance로 전달하는 것이 바람직하다. 이러한 방식으로 서비스 혼잡을 피하고 보다 효율적인 자원 활용을 달성할 수 있다. 이 프로세스는 일반적으로 로드 로드 밸런싱(load balancing)이라고 지칭될 수 있다.

SFC-enabled I2NSF 아키텍처에서 SFC Catalog Manager는 사용 가능한 SF instance의 로드 상태를 주기적으로 모니터링한다. 또한, Developer’s Management System을 통해 새로운 SF instance를 동적으로 생성할 수 있다. 이러한 기능과 유연한 트래픽 스티어링 메커니즘을 통해 로드 밸런싱 서비스를 제공할 수 있다.

예를 들어, 방화벽 instance에서 정체가 발생할 경우, 로드 밸런싱의 상세한 프로세스를 설명한다.

1) SFC Catalog Manager가 방화벽 instance가 너무 많은 요청을 수신하고 있음을 감지한다. 현재, 사용할 수 있는 추가 방화벽 instance가 없는 경우를 가정한다.

2) SFC Catalog Manager는 Developer’s Management System에 새로운 방화벽 instance 생성을 요청한다.

3) Developer’s Management System은 새로운 방화벽 instance를 생성하고, 그 다음 새로운 방화벽 instance의 정보를 SFC Catalog Manager에 등록한다.

4) SFC Catalog Manager는 새로운 방화벽 instance를 반영하도록 SFC 정보 테이블을 업데이트하고, SFC Policy Manager에게 이 업데이트를 통보한다.

5) 수신된 정보를 기반으로 SFC Policy Manager는 트래픽 스티어링을 위한 forwarding information을 업데이트하고, 새로운 forwarding information을 SFF로 전송한다.

6) 새로운 forwarding information에 따라 SFF는 후속 트래픽을 새로운 방화벽 instance로 전달한다. 결과적으로 기존 방화벽 instance의 부담을 효과적으로 줄일 수 있다.

I2NSF 프레임워크의 보안 정책 규칙의 정보 모델 및 데이터 모델은 패킷에 수행할 동작 유형으로서 진보된 보안 조치를 정의한다. 진보된 보안 조치를 통해 기본 NSF(예를 들어, 방화벽)가 패킷의 심층적인 보안 분석을 위해 다른 유형의 NSF를 호출할 수 있다. NSF가 주어진 패킷에 대해 진보된 보안 조치를 트리거하면, 패킷은 진보된 조치를 위한 전용 NSF로 전달되어야 한다. 즉, 진보된 동작은 패킷이 통과해야 하는 다음 NSF를 동적으로 결정한다.

따라서, 전달 구성 요소가 다음에 요구되는 NSF의 네트워크 액세스 정보(예를 들어, IP 주소, 포트 번호)로 설정되면, 패킷은 NSF로 전달될 수 있다. 이러한 진보된 보안 조치를 통해 보안 기능 체인(chain) 및 경로의 정보를 설정하고 관리하기 위한 오버 헤드를 방지할 수 있다.

SFC에서는 패킷의 보안 기능 경로가 동적으로 변경되는 상황을 지원하기 위해 재분류가 필요하며, classifier는 패킷의 보안 기능 경로를 변경하기 위한 재분류 작업을 담당한다.

그러나 classifier가 NSF와 별개의 구성 요소로 존재할 경우, 패킷은 재분류를 위해 NSF에서 classifier로 먼저 전달되어야 하며, 이로 인해 추가적인 지연이 발생될 수 있다.

상술한 바와 같이, I2NSF 프레임워크의 진보된 보안 조치는 미리 정의된 보안 기능 체인 설정의 요구 사항을 생략할 수 있다. 보안 기능 체인/경로 설정이 없으면, 재분류 할 필요가 없다. 즉, classifier를 통한 재분류 없이, 전달자는 직전의(predecessor) NSF에 의해 결정된 진보된 동작에 따라 패킷을 다음의 필요한 NSF로 단순히 전달할 수 있다.

한편, 앞서 설명한 본 발명에 따른 I2NSF 프레임워크에서 보안 기능 체이닝을 사용하기 위해, 본 발명에서는 SFC 아키텍처 내 추가 구성 요소를 적용할 수 있다. 따라서, 본 발명에서 제안된 아키텍처에서 컴포넌트 간 안전한 통신을 달성하기 위해 [RFC7665]에 명시된 SFC 아키텍처의 보안 고려 사항을 적용할 수 있다.

도 5는 본 발명의 일 실시예에 따른 서비스 기능 체이닝 방법을 예시하는 도면이다.

도 5를 참조하면, Classifier는 I2NSF 시스템에 유입된 패킷에 대한 초기 SFP(즉, 제1 SFP)를 결정한다(S501).

이때, Classifier는 SFC Policy Manager로부터 수신한 SFC 정책에 기반하여 유입된 패킷을 분류하고, 해당 패킷에 대한 SFP를 결정할 수 있다.

그리고, Classifier는 패킷을 SFF에게 전달한다(S502).

여기서, 패킷의 SFP 정보는 SFP를 식별하기 위한 SPI 및 SFP 내 다음 홉(next hop)에 해당하는 SF의 위치를 식별하기 위한 SI를 포함할 수 있으며, 이러한 SFP 정보는 NSH에 포함될 수 있다. 그리고, NSH는 패킷에 부착되어 SFF에게 전달될 수 있다.

SFF는 패킷의 SFP 정보에 기반하여 패킷을 하나 이상의 SF에게 전달한다(S503).

즉, 앞서 도 2 또는 도 3에서 설명한 방법에 따라 패킷은 SFF를 경유하여 제1 SF에게 전달되며, 제1 SF에 의해 패킷의 검사가 완료되면, SFF를 경유하여 제2 SF에게 전달된다.

SF는 SFF로부터 수신한 패킷을 검사한다(S504).

패킷의 검사 결과 SF는 SFP 변경이 필요한지 여부를 판단한다(S505). 즉, SF는 해당 패킷의 SFP에 속하지 않은 SF에 의해 패킷의 검사가 요구되는지 여부를 판단한다.

SFP 변경이 필요하면(즉, 해당 패킷의 SFP에 속하지 않은 SF에 의해 패킷의 검사가 요구되면), SF는 SFF에게 SFP의 변경을 요청한다(S506).

이때, SFP의 변경 요청은 패킷에 부착되는 NSH의 메타데이터(metadata)에 포함되어 전송될 수 있다. 또한, SF에 의한 패킷의 검사 결과도 NSH의 메타데이터(metadata)에 포함되어 전송될 수 있다.

SFF는 어느 하나의 SF로부터 SFP 변경 요청이 수신되면, 패킷을 Classifier에게 전달한다(S507).

SFF로부터 패킷을 수신하면, Classifier는 SF에 의한 패킷의 검사 결과에 기반하여 패킷의 SFP를 변경한다(S508).

즉, Classifier는 패킷에 부착된 NSH에 SFP 정보(즉, SPI)를 업데이트한다.

도 6은 본 발명의 일 실시예에 따른 SFC 가능한 시스템 내 장치의 블록 구성도를 예시한다.

도 6을 참조하면, SFC 가능한 시스템 내 장치(600)는 프로세서(processor, 601), 메모리(memory, 602) 및 통신 모듈(communication module, 603)을 포함한다.

SFC 가능한 시스템 내 장치(600)는 앞서 설명한 SF, SFF, Classifier, SFC Policy Manager, SFC Catalog Manager, Security Controller, Developer's Management System, I2NSF user에 해당될 수 있다.

프로세서(601)는 앞서 도 1 내지 도 5에서 제안된 기능, 과정 및/또는 방법을 구현한다. 메모리(602)는 프로세서(601)와 연결되어, 프로세서(601)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(603)은 프로세서(601)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다.

메모리(602)는 프로세서(601) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(601)와 연결될 수 있다.

이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(Firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.

본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

600: SFC 가능한 시스템 내 장치
601: 프로세서
602: 메모리
603: 통신 모듈

Claims (15)

1. 서비스 기능 체이닝(SFC: service function chaining)을 지원하는 시스템에 있어서,
   SFC 정책 관리자(SFC Policy Manager)로부터 주어진 정책에 따라 상기 시스템에 유입된 패킷에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정하고, 상기 패킷을 서비스 기능 전달자(SFF: Service Function Forwarder)에게 전달하며, 서비스 기능(SF: Service Function)에 의한 상기 패킷의 검사 결과에 기반하여 상기 패킷의 상기 SFP를 변경하는 분류기(Classifier);
   상기 패킷의 SFP 정보에 기반하여 상기 패킷을 하나 이상의 SF에게 전달하고, 상기 하나 이상의 SF 중 어느 하나의 SF로부터 SFP 변경 요청이 수신되면, 상기 패킷을 상기 분류기에게 전달하는 SFF;
   상기 패킷의 검사 결과 상기 SFP에 속하지 않은 SF에 의해 상기 패킷의 검사가 요구되면, 상기 SFF에게 SFP의 변경 요청을 전송하는 SF;
   사용자로부터 제공된 상위 레벨 SFC 정책을 상기 분류기에 의해 해석될 수 있는 하위 레벨 SFC 정책으로 변환하고, SF 전달 테이블(forwarding table)을 생성하여 상기 SFF에게 배포하는 SFC 정책 관리자(SFC Policy Manager); 및
   이용 가능한 SF의 정보를 포함하는 SFC 정보 테이블을 유지하고, 상기 이용 가능한 SF로부터 주기적으로 로드 상태를 수신함으로써, SF의 추가 또는 제거를 개발자 관리 시스템에 요청하는 SFC 카탈로그 관리자(SFC Catalog Manager)를 포함하되,
   상기 SF 전달 테이블의 엔트리(entry)는 SFF 식별자, SFP를 식별하기 위한 서비스 경로 식별자(SPI: Service Path Identifier), SFP 내 SF의 위치를 식별하기 위한 서비스 인덱스(SI: Service Index) 및 다음 홉(next hop) 정보를 포함하는 서비스 기능 체이닝 지원 시스템.
2. 제1항에 있어서,
   상기 패킷의 SFP의 정보는 네트워크 서비스 헤더(NSH: Network Service Header)에 포함되고, 상기 NSH는 상기 패킷에 부착되는 서비스 기능 체이닝 지원 시스템.
3. 제2항에 있어서,
   상기 패킷의 검사 결과 및 상기 SFP의 변경 요청은 상기 NSH의 메타데이터(metadata)에 포함되는 서비스 기능 체이닝 지원 시스템.
4. 제1항에 있어서,
   SFC 카탈로그 관리자가 상기 이용 가능한 SF로부터 수신한 로드 상태에 기초하여 동일한 보안 기능을 가지는 이용 가능한 추가 SF를 감지하고, 이용 가능한 추가 SF가 존재하지 않는 경우 상기 동일한 보안 기능을 가지는 추가 SF의 생성을 상기 개발자 관리 시스템에 요청하는 서비스 기능 체이닝 지원 시스템.
5. 삭제
6. 삭제
7. 제4항에 있어서,
   상기 SFC 카탈로그 관리자로부터 SF의 추가 또는 제거를 요청 받으면, SF를 생성 또는 제거하는 상기 개발자 관리 시스템을 더 포함하는 서비스 기능 체이닝 지원 시스템.
8. 제4항에 있어서,
   상기 SFC 카탈로그 관리자가 상기 개발자 관리 시스템으로부터 추가 또는 제거된 SF 정보를 수신하면, 상기 SFC 정보 테이블을 업데이트하는 서비스 기능 체이닝 지원 시스템.
9. 제4항에 있어서,
   상기 SFF가 상기 분류기로부터 수신한 패킷에 대한 상기 SF 전달 테이블의 엔트리를 가지지 않으면, 상기 SFC 카탈로그 관리자에게 SFF 식별자, SPI, SI를 이용하여 다음 홉(next hop) 정보를 요청하는 서비스 기능 체이닝 지원 시스템.
10. 제1항에 있어서,
    상기 패킷의 SFP의 정보는 SFP를 식별하기 위한 서비스 경로 식별자(SPI: Service Path Identifier) 및 SFP 내 다음 홉(next hop)에 해당하는 SF의 위치를 식별하기 위한 서비스 인덱스(SI: Service Index)를 포함하는 서비스 기능 체이닝 지원 시스템.
11. 제1항에 있어서,
    상기 분류기는 상기 시스템에 유입된 패킷이 전달된 소스(source)가 신뢰할 수 있는 소스인 경우, 경량 침입 방지/탐지 시스템(IPS/IDS: Intrusion Prevention/Detection System)만을 통과하도록 SFP를 결정하고,
    상기 시스템에 유입된 패킷이 전달된 소스가 신뢰할 수 없는 소스인 경우, 방화벽(Firewall), 안티-스푸핑 기능(Anti-Spoofing function) 및 심층 패킷 분석(DPI: Deep Packet Inspection)의 순서로 통과하도록 결정하는 서비스 기능 체이닝 지원 시스템.
12. 서비스 기능 체이닝(SFC: service function chaining)을 지원하기 위한 방법에 있어서,
    SFC 정책 관리자(SFC Policy Manager)가 사용자로부터 제공된 상위 레벨 SFC 정책을 분류기에 의해 해석될 수 있는 하위 레벨 SFC 정책으로 변환하고, SF 전달 테이블(forwarding table)을 생성하여 SFF에게 배포하는 단계;
    상기 분류기(Classifier)가 상기 SFC 정책 관리자(SFC Policy Manager)로부터 주어진 정책에 따라 시스템에 유입된 패킷에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정하는 단계;
    상기 분류기가 상기 패킷을 서비스 기능 전달자(SFF: Service Function Forwarder)에게 전달하는 단계;
    상기 분류기가 상기 SFF로부터 패킷을 수신하면, 서비스 기능(SF: Service Function)에 의한 상기 패킷의 검사 결과에 기반하여 상기 패킷의 상기 SFP를 변경하는 단계; 및
    SFC 카탈로그 관리자(SFC Catalog Manager)가 이용 가능한 SF의 정보를 포함하는 SFC 정보 테이블을 유지하고, 상기 이용 가능한 SF로부터 주기적으로 로드 상태를 수신함으로써, SF의 추가 또는 제거를 개발자 관리 시스템에 요청하는 단계를 포함하되,
    상기 SF에 의해 상기 패킷의 검사 결과 상기 SFP에 속하지 않은 SF에 의해 상기 패킷의 검사가 요구되면, 상기 SF에 의해 SFF에게 SFP의 변경 요청이 전송되고, 상기 패킷이 상기 SFF로부터 상기 분류기에게 전달되고,
    상기 SF 전달 테이블의 엔트리(entry)는 SFF 식별자, SFP를 식별하기 위한 서비스 경로 식별자(SPI: Service Path Identifier), SFP 내 SF의 위치를 식별하기 위한 서비스 인덱스(SI: Service Index) 및 다음 홉(next hop) 정보를 포함하는 서비스 기능 체이닝 방법.
13. 삭제
14. 제12항에 있어서,
    상기 패킷의 SFP의 정보는 네트워크 서비스 헤더(NSH: Network Service Header)에 포함되고, 상기 NSH는 상기 패킷에 부착되는 서비스 기능 체이닝 방법.
15. 제14항에 있어서,
    상기 패킷의 검사 결과는 상기 NSH의 메타데이터(metadata)에 포함되는 서비스 기능 체이닝 방법.

Images