미들박스

Middlebox

미들박스는 패킷 [1]전송 이외의 목적으로 트래픽을 변환, 검사, 필터링 및 조작하는 컴퓨터 네트워킹 장치입니다.이러한 외부 기능은 애플리케이션 성능을 방해하고 엔드 투 엔드 원칙과 같은 "중요한 아키텍처 원칙"을 위반한다는 비판을 받아 왔습니다.미들박스의 예로는 방화벽, Network Address Translator(NAT; 네트워크주소 변환기), 로드밸런서 Deep Packet Inspection(DPI; 딥 패킷인스펙션) [2]박스가 있습니다.

UCLA 컴퓨터 공학 교수 Licia Zhang은 1999년[1][3]미들박스라는 용어를 만들었다.

사용.

미들박스는 프라이빗 네트워크와 퍼블릭 네트워크 양쪽에 폭넓게 배치되어 있습니다.전용 미들박스 하드웨어는 네트워크 보안 및 성능을 개선하기 위해 기업 네트워크에 널리 구현되지만 홈 네트워크 라우터에도 방화벽, NAT 또는 기타 미들박스 [4]기능이 통합된 경우가 많습니다.2017년 한 연구에서는 트래픽 흐름의 양방향 및 모바일 운영자와 데이터 센터 네트워크를 포함한 [2]광범위한 네트워크에 걸쳐 자율 시스템에서 1,000개 이상의 구축을 집계했습니다.

다음으로 자주 도입되는 미들박스의 예를 나타냅니다.

  • 방화벽은 네트워크 관리자가 정의한 일련의 사전 정의된 보안 규칙을 기반으로 트래픽을 필터링합니다.IP 방화벽은 IP 및 트랜스포트 헤더의 필드에 근거해 패킷을 거부합니다(를 들어 특정 포트 번호에 대한 착신 트래픽, 특정 서브넷에 대한 트래픽 거부 등). 다른 유형의 방화벽에서는 세션 [5]또는 응용 프로그램레이어에서 트래픽을 검사하는 규칙 세트를 사용하는 경우가 있습니다.[1]
  • 침입 탐지 시스템(IDS)은 트래픽을 모니터링하고 오프라인 분석을 위해 데이터를 수집하여 보안 이상을 확인합니다.방화벽과 달리 IDS는 패킷을 실시간으로 필터링하지 않습니다.이는 패킷이 보다 복잡한 검사를 할 수 있기 때문에 패킷이 [6]착신했을 때 패킷을 받아들일지 거부할지를 결정해야 하기 때문입니다.
  • Network Address Translator(NAT; 네트워크주소 변환기)는, 그것들을 통과하는 패킷의 송신원IP 주소 또는 행선지IP 주소, 또는 그 양쪽 모두를 대체합니다.통상, NAT 는 복수의 엔드 호스트가 단일의 IP 주소를 공유할 수 있도록 배치됩니다.NAT 의 「배후에」 있는 호스트에는 프라이빗 IP 주소가 할당되어 퍼블릭인터넷 앞으로 패킷이 NAT 를 통과합니다.이것에 의해, 내부 프라이빗 주소가 공유 퍼블릭주소로 [7]치환됩니다.이것들은 셀룰러 네트워크 프로바이더에 의해서 희소한 [8]자원을 관리하기 위해서 널리 사용되고 있습니다.
  • WAN 옵티마이저는 대역폭 소비와 엔드포인트 간의 인식 지연을 개선합니다.일반적으로 대기업에 배치되는 WAN 옵티마이저는 송신 엔드포인트와 수신 엔드포인트 양쪽에 배치됩니다.그 후, 디바이스는 [9]인터넷을 통과하는 트래픽을 캐시 및 압축하도록 조정됩니다.
  • 로드 밸런서는 서비스에 대한1개의 엔트리 포인트를 제공하지만 실제로 서비스를 제공하는1개 이상의 호스트에 트래픽플로우를 전송합니다.
  • 셀룰러 네트워크는 미들박스를 사용하여 희소한 네트워크 자원을 효율적으로 사용하고 클라이언트 디바이스를 보호합니다.

비판과 과제

미들박스는 애플리케이션 개발에 기술적인 문제를 일으켜 컴퓨터 시스템[10] 설계의 엔드 투 엔드 원칙을 위반하여 네트워크 [11]아키텍처 커뮤니티에서 "손상"과 "해체"를 초래했습니다.

응용 프로그램 간섭

일부 미들박스는 애플리케이션 기능을 방해하여 엔드호스트 애플리케이션의 정상적인 동작을 제한하거나 방해합니다.

특히 Network Address Translator(NAT; 네트워크주소 변환기)는 NAT 디바이스가 퍼블릭 IP 주소 앞으로 트래픽을 여러 리시버로 분할한다는 점에서 문제가 됩니다.인터넷상의 호스트와 NAT 의 배후에 있는 호스트간의 접속이 NAT 의 배후에 있는 호스트에 의해서 개시되면, NAT 는 그 접속의 트래픽이 로컬호스트에 속하는 것을 학습합니다.따라서, 인터넷으로부터의 트래픽이 특정의 포토상의 퍼블릭(공유) 주소를 수신처로 하고 있는 경우, NAT 는 트래픽을 적절한 호스트에 송신할 수 있습니다.다만, 인터넷상의 호스트에 의해서 개시된 접속은, 어느 내부 호스트에 속하는지를 NAT 에 「학습」할 기회는 없습니다.게다가 내부 호스트 자체는, 접속처의 주소를 잠재적인 클라이언트에 통지하기 위한 자신의 퍼블릭 IP 주소조차 모르는 경우가 있습니다.이 문제를 해결하기 위해 몇 가지 새로운 프로토콜이 [12][13][14]제안되었습니다.

또한 AT&TT-Mobile같은 셀 운영자에 의한 미들박스 도입이 불투명하기 때문에 애플리케이션 개발자는 종종 "운영자에 의해 강제되는 미들박스 정책을 알지 못한다"면서도 운영자는 애플리케이션 동작과 요건에 대한 완전한 지식이 부족하다.예를 들어, 한 통신사는 "방화벽의 비활성 TCP 접속에 의해 유지되고 있는 자원을 신속하게 재활용하기 위한 어그레시브 타임아웃 값"을 설정했습니다.이것에 의해, 예기치 않게, 푸시 베이스의 E-메일이나 인스턴트 메시징등의 애플리케이션에 의해서 유지되고 있는 장기간의 접속이나 아이돌 상태의 접속이 빈번하게 중단되는 일이 있습니다.[8]

미들박스에 기인하는 다른 일반적인 애플리케이션 과제로는 "스텔" 또는 오래된 [15]콘텐츠를 제공하는 웹 프록시, 원하는 [16]포트의 트래픽을 거부하는 방화벽 등이 있습니다.

인터넷 확장성과 설계

미들박스에 대한 한 가지 비판은 미들박스가 전송 프로토콜의 선택을 제한하여 애플리케이션 또는 서비스 설계를 제한할 수 있다는 것입니다.미들박스는 예상 동작에 부합하지 않는 트래픽을 필터링하거나 삭제할 수 있으므로 신규 또는 일반적이지 않은 프로토콜 또는 프로토콜 확장이 [17]필터링될 수 있습니다.특히, 미들박스는 프라이빗 주소 영역의 호스트를 "다른 호스트와 통신할 수 있는 핸들을 통과시키지 못하게 하기 때문에" 다양한 피어 투 피어 [10][18]시스템뿐만 아니라 SIP(Session Initiation Protocol)와 같은 새로운 프로토콜의 확산을 방해했습니다.이러한 유연성의 점진적 감소는 프로토콜 [19][20]골화로 설명되었습니다.

반대로 일부 미들박스는 새 프로토콜과 이전 프로토콜 간의 변환을 제공하여 프로토콜 배포를 지원할 수 있습니다.예를 들어 IPv6로드밸런서, 프록시, 기타 형식의 NAT 의 퍼블릭엔드포인트에 배치하여 IPv4 또는 IPv6 경유로 백엔드 트래픽을 라우팅할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c Brian Carpenter. "Middleboxes: Taxonomy and Issues". RFC 3234.
  2. ^ a b Shan Huang; Steve Uhlig; Félix Cuadrado (2017). "Middleboxes in the Internet: A HTTP perspective". 2017 Network Traffic Measurement and Analysis Conference (TMA). pp. 1–9. doi:10.23919/TMA.2017.8002906. ISBN 978-3-901882-95-1. S2CID 34925433.
  3. ^ Kromhout, Wileen Wong (February 2, 2012), "Lixia Zhang named to UCLA's Jonathan B. Postel Chair in Computer Science", UCLA Newsroom, archived from the original on April 25, 2019, retrieved 2015-06-14
  4. ^ Ido Dubrawsky and Wes Noonan. "Broadband Routers and Firewalls". CISCO Press. Retrieved 15 July 2012.
  5. ^ Magalhaes, Ricky. "The Difference Between Application and Session Layer Firewalls". Retrieved 17 July 2012.
  6. ^ "Understanding Intrusion Detection Systems". Retrieved 17 July 2012.
  7. ^ K. Egevang and P. Francis. "The IP Network Address Translator (NAT)". RFC 1631.
  8. ^ a b Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Z. Morley Mao, Ming Zhang (August 2011). "An Untold Story of Middleboxes in Cellular Networks" (PDF). ACM SIGCOMM Computer Communication Review. Association for Computing Machinery. 41 (4): 374–385. doi:10.1145/2043164.2018479.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  9. ^ Poe, Robert. "What Is WAN Optimization, and How Can It Help You?". Retrieved 17 July 2012.
  10. ^ a b Michael Walfish, Jeremy Stribling, Maxwell Krohn,Hari Balakrishnan, Robert Morris, and Scott Shenker (2004). "Middleboxes No Longer Considered Harmful" (PDF). 6th Symposium on Operating Systems Design and Implementation. USENIX Association: 215–230.{{cite journal}}: CS1 maint: 여러 이름: 작성자 목록(링크)
  11. ^ Walfish; et al. (2004). "Middleboxes no longer considered harmful" (PDF). OSDI. Retrieved 17 July 2012.
  12. ^ J. Rosenberg; et al. "Session Traversal Utilities for NAT (STUN)". RFC 5389.
  13. ^ "NAT-PMP". Retrieved 17 July 2012.
  14. ^ "Port Control Protocol Working Group". Retrieved 17 July 2012.
  15. ^ "BlueCoat Knowledge Base: Proxy is displaying stale content". Retrieved 17 July 2012.
  16. ^ "Using FaceTime and iMessage behind a firewall". Retrieved 17 July 2012.
  17. ^ Honda; et al. (2011). "Is it still possible to extend TCP?" (PDF). Internet Measurement Conference.
  18. ^ Bryan Ford; Pyda Srisuresh; Dan Kegel (2005). "Peer-to-Peer Communication Across Network Address Translators" (PDF). 2005 USENIX Annual Technical Conference. USENIX Association: 179–192. arXiv:cs/0603074. Bibcode:2006cs........3074F.
  19. ^ Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tuxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives". IEEE Communications Surveys & Tutorials. 19 (1): 619–639. doi:10.1109/COMST.2016.2626780. hdl:2164/8317. ISSN 1553-877X. S2CID 1846371. Archived (PDF) from the original on 2017.
  20. ^ Corbet, Jonathan (January 29, 2018). "QUIC as a solution to protocol ossification". lwn.net. Retrieved 2020-03-14.