포트 제어 프로토콜

Port Control Protocol
인터넷 프로토콜 제품군
응용계층
수송층
인터넷 계층
링크층

PCP(Port Control Protocol)는 IPv4 또는 IPv6 네트워크의 호스트가 네트워크 주소 변환(NAT) 또는 패킷 필터링을 수행하는 업스트림 라우터에 의해 수신되는 IPv4 또는 IPv6 패킷이 변환되고 전달되는 방법을 제어할 수 있도록 하는 컴퓨터 네트워킹 프로토콜입니다. 호스트가 명시적인 포트 포워딩 규칙을 만들 수 있도록 함으로써 네트워크 트래픽을 쉽게 처리하여 NAT이나 방화벽 뒤에 배치된 호스트가 인터넷의 나머지 부분에서 연결되도록 구성할 수 있습니다(네트워크 서버 역할도 할 수 있습니다). 이는 많은 애플리케이션의 요구 사항입니다.[1][2]

또한 PCP를 통해 사용할 수 있는 명시적 포트 포워딩 규칙을 통해 호스트는 서버에 대한 연결 유지 관리 및 TCP 홀 펀칭과 같은 다양한 NAT 순회 기술에 필요한 발신 NAT keepalive 메시지의 해결 방법을 제거하여 생성된 트래픽 양을 줄일 수 있습니다. 동시에 생성된 트래픽이 적으면 전력 소비가 줄어 모바일 장치의 배터리 런타임이 직접적으로 향상됩니다.[1]

PCP는 NAT-PMP(NAT Port Mapping Protocol)의 후속 제품으로 2013년에 표준화되었으며, 이 프로토콜은 유사한 프로토콜 개념과 패킷 형식을 공유합니다.[3] PCP는 IPv6 및 추가 NAT 시나리오에 대한 지원을 추가합니다.

로컬 네트워크에서 UPnP IGD(Universal Plug and Play Internet Gateway Device)가 사용되는 환경에서는 UPnP IGD와 PCP 간의 연동 기능이 IGD에 내장되어야 합니다. UPnP IGD-PCP Interworking Function은 RFC6970에 명시되어 있습니다.[4]

PCP(Port Control Protocol) 서버 IP 주소로 호스트를 구성하는 DHCP(IPv4 및 IPv6) 옵션은 RFC7291에 명시되어 있습니다.[5] PCP 서버 목록 중에서 서버를 선택하기 위해 따라야 할 절차는 RFC7488에서 설명하고 있습니다.[6]

NAT64가 구축된 환경에서 PCP는 PCP로 제어되는 NAT64 장치가 NAT64(RFC7225)를 통해 IPv4 변환 IPv6 주소를 구축하는 데 사용하는 IPv6 접두사를 학습할 수 있습니다.

개요

많은 응용 프로그램과 네트워크 장비 구축은 원래 구상된 인터넷을 통한 IP 엔드 투 엔드 연결 모델을 따라 네트워크 위치를 로컬 네트워크 외부에서 연결할 수 있어야 하므로 네트워크 서버로 작동하고 원격 클라이언트의 연결을 수락할 수 있습니다. 이러한 장비의 예로는 IP 네트워크를 통한 원격 감시를 제공하는 네트워크 서버가 포함된 IP 카메라가 있습니다.

일반적으로 네트워크 장비 구축은 NAT(예: IPv4 주소 공유) 또는 패킷 필터링(네트워크 보안 및 보호 향상을 위해)을 수행하는 라우터나 방화벽 뒤에 장치를 배치합니다. 결국 엔드 투 엔드 연결이 끊어지고 나머지 인터넷에서 장비와 애플리케이션에 액세스할 수 없게 됩니다.[1][3]

문제가.

배치된 장비가 로컬 네트워크를 넘어 서버 역할을 확장하여 액세스할 수 있도록 하려면 네트워크 게이트웨이(일반적으로 CPE)에서 포트 포워딩을 수동으로 구성해야 합니다. 또는 실제 클라이언트로부터의 "firewall 펀칭" 연결 및 연결을 "merging"하는 데 사용되는 배치된 장비에서 추가 중간 서버로의 연결을 시작하는 애플리케이션 수준의 해결책. 두 가지 접근 방식 모두 단점이 있습니다. 수동 CPE 구성은 일반적으로 불편하거나 불가능한 반면, 추가 중간 서버를 사용하면 복잡성과 비용이 증가합니다.[2][3]

예를 들어, (클라이언트 역할을 하는) 온라인 컴퓨터 게임은 게임 플레이 데이터를 교환하기 위해 게임 서버와의 통신이 필요합니다. 게임 서버가 클라이언트에 데이터를 제공할 수 있도록 하려면 해당 클라이언트가 서버에 액세스할 수 있어야 합니다. 일반적으로 클라이언트는 통신 채널을 열기 위해 게임 서버에 대한 연결을 시작합니다. 그러나 이러한 개방형 연결은 유휴 상태가 될 수 있으며 이후 네트워크 게이트웨이에 의해 폐쇄될 수 있으며, 이로 인해 킵얼라이브 메시지 형태를 사용하여 연결을 유지해야 할 필요성이 있습니다.[3] keepalive 메시지는 통신 채널을 통해 트래픽을 생성하여 게이트웨이 서버가 닫지 않도록 하는 클라이언트와 서버 간에 전송되는 작은 메시지입니다. 따라서 연결을 유지하려면 클라이언트와 서버 간에 빈 메시지를 지속적으로 교환해야 합니다. 이로 인해 네트워크 채팅이 증가하고 네트워크 대역폭과 CPU 주기가 낭비되며 배터리로 구동되는 장치의 자율성이 저하됩니다.

또한 일부 네트워크 애플리케이션(예: FTP)은 애플리케이션 레벨 게이트웨이(ALG)를 포함하고 복잡성을 증가시키는 여러 연결을 동적으로 열어야 합니다.[2][3]

솔루션으로서의 PCP

PCP를 사용하면 장비와 응용 프로그램이 외부 IP 주소, 프로토콜 및 포트, 내부 IP 주소, 프로토콜 및 포트 간에 명시적인 매핑을 만들 수 있습니다. 이러한 명시적 매핑을 사용하면 인바운드 통신이 로컬 네트워크의 경계를 넘어 서버 역할을 확장하거나 다양한 서비스를 단순화하고 리소스 소비를 줄일 수 있습니다. 생성된 매핑은 DHCP(Dynamic Host Configuration Protocol)가 리스를 구현하는 방식과 유사하게 알려진 수명을 연장할 수 있는 정도로 영구적입니다. 동시에 PCP를 사용하면 애플리케이션이 필요에 따라 동적으로 추가 매핑을 생성할 수 있으므로 ALG 지원 NAT 장치와 방화벽을 사용할 필요가 줄어들거나 없어집니다.[1][3]

생성된 명시적 매핑은 알려진 수명(일반적으로 몇 시간)을 가지며, 매핑을 보존하기 위해 호스트와 서버 간에 애플리케이션 수준의 킵얼라이브 메시지를 교환할 필요가 없습니다. 그 결과, 네트워크 사용량과 전력 소비가 감소하고, 애플리케이션 수준의 킵얼라이브 로직을 클라이언트 및 서버 측에서 더 이상 구현할 필요가 없습니다. PCP 매핑 응답은 관련 외부에서 볼 수 있는 매개 변수(IP 주소, 프로토콜 및 포트)를 응용 프로그램에 제공하며, 이 매개 변수는 응용 프로그램별로 다른 클라이언트에 공지되어 들어오는 연결을 설정할 수 있습니다. 또한 PCP는 매핑이 이미 설정된 상태에서 외부 IP 주소가 변경되면 응용 프로그램에 정보를 제공할 수 있습니다.[1][3]

PCP는 다양한 유형의 NAT을 처리할 수 있으며, 이를 통해 NAT64, NAT66 및 NAT44를 지원하며, IPv4 및 IPv6 방화벽 장치에 PCP를 포함할 수도 있습니다. PCP는 대규모 Aggregation 지점(예: 통신사 등급 NAT의 일부로)과 저렴한 소비자 등급 기기 내부에서 모두 사용하도록 설계되었습니다. 서버 역할을 하는 장기 매핑(예: IP 카메라 또는 온도 센서)과 단기 매핑(예: 온라인 컴퓨터 게임 중)이 모두 지원됩니다.[1][2][3]

PCP는 16비트 포트 번호(예: TCP, UDP, 스트림 제어 전송 프로토콜(Stream Control Transmission Protocol, SCTP) 또는 데이터그램 혼잡 제어 프로토콜(DCCP)을 사용하는 전송 계층 프로토콜을 지원합니다. 포트 번호(예: RSVP(Resource Reservation Protocol), ESP(Encapsulation Security Payload), ICMP 또는 ICMPv6)를 사용하지 않는 프로토콜은 IPv4 방화벽, IPv6 방화벽 및 NPTv6(IPv6 Prefix Translation) 기능에 대해 지원되지만 NAT의 경우 외부 IP 주소당 하나 이상의 클라이언트에서 지원할 수 없습니다.[3]

PCP 규격에는 다중 홈 네트워크(여러 네트워크 게이트웨이 또는 기본 경로가 있는)를 처리하기 위한 메커니즘이 정의되어 있지 않습니다. 그럼에도 불구하고, 이러한 네트워크에서는 conntrackd와 같은 조정 메커니즘을 사용하여 PCP를 구현할 수 있습니다. 그러나 서로 다른 네트워크에 각각 고유한 외부 IP 주소가 있는 경우 프로토콜이 클라이언트에 제공할 특정 외부 IP 주소를 필요로 하기 때문에 주어진 PCP 매핑은 하나 또는 다른 하나만 사용할 수 있습니다. 그런 다음 해당 네트워크를 사용할 수 없게 되면 다른 네트워크의 외부 IP 주소를 사용하려면 PCP 매핑을 업데이트해야 합니다.[3]

PCP 규격에는 원격 시스템에 수신 연결에 대한 IP 주소, 프로토콜 및 포트를 알리는 방법을 설명하는 메커니즘이 정의되어 있지 않습니다. RFC6887에 따르면 PCP는 어떠한 랑데부 기능도 제공하지 않으며, 이는 외부 네임 서비스 서버를 사용하는 것과 같은 애플리케이션별 방식으로 수행되어야 합니다.

역사

PCP는 NAT-PMP(NAT Port Mapping Protocol)의 후속 제품으로 2013년에 표준화되어 유사한 프로토콜 개념과 패킷 형식을 공유했습니다. 설계상의 차이점 중 하나로 NAT-PMP는 소비자 등급의 기기에 구축되는 것으로 제한적인 반면 PCP는 통신사 등급의 기기도 지원하도록 설계되었습니다.[3]: 50, 87 2005년부터 다양한 애플 제품에 NAT-PMP를 구현하고 있습니다.[8]: 1

PCP는 2001년 범용 플러그 앤 플레이(UPnP) 규격의 일부로 표준화된 인터넷 게이트웨이 장치 프로토콜(UPnP IGD)에 관한 것입니다. UPnP IGD는 복잡하고 수동 구성에 맞추어 설계된 반면, PCP는 소프트웨어 애플리케이션 내에서 단순화되고 자동화된 사용을 위해 설계되었습니다. NAT-PMP 사양에는 NAT-PMP의 생성을 촉발한 UPnP IGD 및 후속 PCP의 문제 목록이 포함되어 있습니다.[8]: 26–32

PCP사용

보안

명시적 PCP 매핑이 생성되는 동안 교환되는 네트워크 패킷(명시적 매핑을 설정하는 데 필요한 협상이 포함된 패킷, 호스트와 PCP 지원 NAT 디바이스 또는 방화벽 간에 교환됨)을 변경할 수 있는 공격자 제외, PCP는 생성된 명시적 매핑이 암시적 매핑의 도메인을 초과하지 않는 한 안전한 것으로 간주됩니다. 즉, 암시적 매핑은 NAT 장치와 방화벽이 정기적인 아웃바운드 클라이언트 연결을 처리하는 방식의 결과로 생성되며, 이는 명시적 매핑 메커니즘을 통해 새로운 매핑 가능성이 도입되지 않는 한 PCP가 안전하다는 것을 의미합니다.[3]

보안 측면에서 중요한 PCP 기능은 THRD_PARTY 매핑 요청 옵션. 이 옵션을 사용하면 매핑 요청의 일부로 추가로 지정된 IP 주소를 해당 목적으로 실제 매핑 요청 패킷의 소스 IP 주소를 사용하는 기본 동작을 따르지 않고 작성된 명시적 매핑의 내부 주소로 사용해야 함을 의미합니다. 이러한 매핑 요청은 지정된 IP 주소에 대해 다른 곳에 부과된 알 수 없는 규칙으로 인해 PCP 지원 NAT 장치 또는 방화벽이 허용하는 것보다 높은 명시적 매핑 권한을 부여하여 공격자가 일부 트래픽을 훔치거나 서비스 거부(DoS) 공격을 수행할 수 있도록 할 수 있습니다.[3]

또한 명시적인 PCP 보안 메커니즘은 PCP 프로토콜의 확장으로 사용 가능하며, 인증되고 무결성이 보호된 대역내 신호 전달 채널을 사용하여 인증 및 액세스 제어 메커니즘을 제공합니다. EAP(Extensible Authentication Protocol)를 사용하여 PCP 협상 세션과 관련된 장치 간의 인증을 수행합니다. 이러한 PCP 지원 NAT 장치 또는 방화벽은 인증되지 않은 매핑 요청을 여전히 수락할 수 있으며, 동시에 이전에 설명한 모든 명시적인 매핑 제약 조건이 여전히 적용됩니다.[1][3][11]

내부

내부적으로 PCP는 사용자 데이터그램 프로토콜(UDP)을 기본 프로토콜로 사용하여 호스트와 PCP 지원 NAT 장치 또는 방화벽(서버라고 함) 간에 제어 메시지를 교환함으로써 작동합니다. 이 통신은 일단 서버에 제출되고 처리된 응답을 생성하는 호스트에 의해 생성된 포트 매핑 요청으로 구성됩니다. UDP의 비신뢰성 특성에 따라 UDP 데이터그램이 손실, 복제 또는 재정렬될 수 있습니다. 요청을 제출한 후에는 어떤 종류의 응답도 보장되지 않으므로 호스트 요청을 "힌트"라고도 합니다. 서버는 직접 응답 외에도 무료 알림(예: 외부 IP 주소의 변경 사항을 호스트에 알리기 위한 유니캐스트 알림)도 생성합니다.[1][3]

포트 제어 프로토콜 opcodes[3]
오피코드 묘사
맵 호스트가 서버 역할을 하고 인바운드 통신을 수신할 수 있도록 인바운드 전달을 위한 매핑을 만들거나 갱신합니다.
또래 아웃바운드 매핑을 생성하거나 갱신하여 호스트가 단일 피어와의 열린 통신을 유지할 수 있도록 합니다.
발표하다 서버 재시작 및 외부 IP 주소 변경을 포함하여 호스트에 대한 다양한 변경 사항을 알립니다.

교환된 메시지에는 해당 메시지가 속한 트랜잭션 또는 해당 메시지가 나타내는 "세션" 단계를 결정할 수 있는 수단이 없습니다. 이러한 단순화된 설계는 각 메시지가 성공적으로 처리되기 위해 추가적인 컨텍스트가 필요하지 않고 모든 메시지를 자체적으로 설명하고 완성하는 것에 기초합니다. 서버는 현재 호스트 요청을 처리할 수 없는 경우 호스트 요청을 무시하기로 결정할 수 있습니다. 이러한 경우 호스트는 요청을 다시 전송해야 합니다. 또한 호스트는 원하지 않는 매핑 응답을 무시하도록 안전하게 결정할 수 있습니다.[3]

PCP 요청을 생성하기 위해 서버의 IP 주소는 호스트에서 수동으로 구성되거나 호스트의 DHCP 리스의 일부로 발견되거나 호스트의 구성된 기본 게이트웨이로 설정됩니다. 호스트 요청 메시지는 클라이언트의 모든 원본 UDP 포트에서 수신되는 서버의 UDP 포트 5351로 전송됩니다. 요청되지 않은 멀티캐스트 서버 알림(예: 서버 재시작 알림)은 서버의 UDP 포트 5351에서 수신되는 호스트의 UDP 포트 5350으로 전송됩니다.[3]

모든 PCP 메시지의 최대 UDP 페이로드 길이는 1100옥텟입니다. 각 PCP 메시지는 관련 작업을 결정하는 opcode, 관련 opcode 고유 정보(예: 매핑할 포트) 및 0 이상의 옵션(예: 위에서 설명한 THRD_PARTY 옵션)을 포함하는 요청 또는 응답 헤더로 구성됩니다. 결과 코드는 서버 응답의 일부로 반환됩니다. 각 결과 코드는 특정 작업이 재시도되거나 반복되어야 하는 시기를 호스트에 알려주는 관련 수명을 가집니다. 예를 들어, 결과 수명은 고장 조건이 지속될 것으로 예상되는 기간 또는 생성된 매핑이 지속될 기간을 지정할 수 있습니다.[3]

참고 항목

참고문헌

  1. ^ a b c d e f g h Dan Wing (December 2011). "Port Control Protocol". The Internet Protocol Journal. Cisco Systems. Retrieved January 31, 2014.
  2. ^ a b c d "Port Control Protocol Overview (Junos OS 13.3)". Juniper Networks. August 14, 2013. Retrieved January 31, 2014.
  3. ^ a b c d e f g h i j k l m n o p q r s D. Wing; S. Cheshire; M. Boucadair; R. Penno; P. Selkirk (April 2013). Wing, D. (ed.). "RFC 6887: Port Control Protocol (PCP)". Internet Engineering Task Force (IETF). doi:10.17487/RFC6887. Retrieved June 5, 2023. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  4. ^ Boucadair, M.; Penno, R.; Wing, D. (July 2013). "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)". doi:10.17487/rfc6970. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  5. ^ Boucadair, M.; Penno, R.; Wing, D. (July 2014). "DHCP Options for the Port Control Protocol (PCP)". doi:10.17487/rfc7291. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  6. ^ Boucadair, M.; Penno, R.; Wing, D.; Patil, P.; Reddy, T. (March 2015). "Port Control Protocol (PCP) Server Selection". doi:10.17487/rfc7488. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  7. ^ Boucadair, M. (May 2014). "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)". doi:10.17487/rfc7225. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  8. ^ a b S. Cheshire; M. Krochmal (April 2013). "RFC 6886: NAT Port Mapping Protocol (NAT-PMP)". Internet Engineering Task Force (IETF). doi:10.17487/RFC6886. Retrieved August 8, 2014. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)
  9. ^ https://developer.apple.com/documentation/dnssd/kdnsserviceerr_natportmappingunsupported/
  10. ^ https://datatracker.ietf.org/doc/html/draft-ietf-pcp-dslite-00
  11. ^ M. Cullen; S. Hartman; D. Zhang; T. Reddy (September 2015). "RFC 7652: Port Control Protocol (PCP) Authentication Mechanism". Internet Engineering Task Force (IETF). doi:10.17487/RFC7652. Retrieved April 29, 2016. {{cite journal}}: 저널 인용 요구사항 journal= (도와주세요)

외부 링크