요약

  • RFC 2979는 의도적인 보안 거부와 표준을 준수하는 프로토콜 사용의 의도치 않은 실패를 분리하고, 후자의 책임을 방화벽과 그 관련 소프트웨어에 두었다.
  • Path MTU Discovery 오류와 부분적으로만 이해된 SMTP 확장이라는 구체적 예는 중개 장치가 단순한 규칙을 시행하는 것처럼 보이면서 대화를 깨뜨릴 수 있음을 보여주었다.

정책 결정과 프로토콜 실패는 같은 것이 아니었다

인터넷의 종단 간 이상은 2000년 전후에서 실용적 경계와 마주쳤다. 조직들은 자신들이 완전히 신뢰할 수 없는 네트워크에 가치 있는 내부 시스템을 점점 더 연결하기 시작했다. 방화벽은 선별 지점을 제공했다. 그러나 선별 시스템은 종종 충분히 명세되지 않았고, 그 동작은 시행하려던 정책을 넘어선 문제를 일으킬 만큼 달랐다.

RFC 2775는 이미 '투명성'을 종단 간 기능, 성능, 주소 투명성을 포함한 여러 아키텍처적 속성으로 기술한 바 있었다. RFC 2979는 이 문제를 특정한 운영 계약으로 좁혔다. 그 핵심 규칙은, 방화벽·터널·접속 협상 기능의 도입이 그것이 없다면 동작했을 합법적이고 표준을 준수하는 사용의 의도치 않은 실패를 초래해서는 안 된다는 것이었다. 그렇게 되었다면 방화벽과 관련 소프트웨어를 고쳐야 했고, 기존 프로토콜이나 그 구현을 바꿀 필요는 없었다.

이것은 모든 패킷을 통과시키라는 요구가 아니었다. RFC 2979는 사이트가 합법적이지 않다고 판단하는 접근을 차단할 권리를 명시적으로 보존했으며, 시도되는 트래픽이 표준을 따르는 경우에도 그렇다. 이 문서는 SOCKS 같은 추가 인증 또는 권한 부여 기능, 그리고 이를 요구하는 구성도 허용했다. 중요한 구분은 정책에 따른 의도적 거부와, 트래픽을 오해한 중개 장치가 일으키는 우연한 파손 사이의 구분이었다.

버려진 오류 메시지는 그렇지 않아도 유효한 흐름을 좌초시킬 수 있었다

Path MTU Discovery 예는 이 규칙을 구체화했다. IPv4 발신자는 Don't Fragment 비트를 설정한 패킷을 보낼 수 있었다. 패킷이 이후 링크에 비해 너무 클 때, 라우터는 발신자가 패킷 크기를 줄일 수 있도록 ICMP "Destination Unreachable / Fragmentation Needed" 메시지를 반환했다. 나가는 패킷은 허용하면서 짝이 되는 응답을 폐기하는 방화벽은, 발신자가 절대 맞지 않을 트래픽을 반복하게 만들 수 있었다. 이는 유의미한 보안 결정이 아니라 블랙홀이었다.

RFC 2979는 모든 ICMP 메시지가 통과해야 한다고 말하지 않았다. 이 문서는 합법적인 아웃바운드 트래픽에 묶인 오류를 Echo 요청, 리디렉트, 무관한 오류와 다르게 다루었으며, 후자는 사이트가 차단할 수 있었다. 맥락과 목적이 중요했다. 같은 프로토콜 계열에는 유효한 교환에 필요한 제어 정보와, 정책이 합리적으로 거부할 수 있는 트래픽이 함께 들어 있었다.

확장 목록은 삼자 간 불일치로 변할 수 있었다

SMTP 예는 더 미묘한 실패를 드러냈다. 클라이언트가 EHLO로 서버에 확장을 요청하고, 서버가 지원하는 것을 알리면, 클라이언트는 확장을 선택할 수 있다. 서버의 응답을 필터링하지 않고 수용 명령 목록에 EHLO만 추가한 프록시는, 양쪽 종단이 프록시가 이해하지 못하는 기능에 합의하게 놔둘 수 있었다. 각 종단은 그럴듯하게 동작했지만, 중개 장치는 자신이 올바르게 운반할 수 없는 대화에 그들을 넣어 놓은 것이다.

교훈은 모든 방화벽이 모든 새 확장을 구현해야 한다는 것이 아니었다. RFC 2979는 애플리케이션 프로토콜이 애플리케이션을 해치지 않는 한 방화벽 운영을 용이하게 하도록 권고했고, 명세는 방화벽이 처리해야 할 것을 설명할 수 있다고 했다. 이 문서는 80번 포트가 열려 있을 가능성이 높다는 이유만으로 새 프로토콜을 HTTP 안에 숨기는 것을 경계했다. 보안이 강화된 부분 집합, 적절한 통과 기능, 별도로 등록된 포트가 더 정직한 설계 선택일 수 있었다.

이 RFC가 바꾼 것 — 그리고 증명할 수 없는 것

RFC 2979는 Internet Standard가 아니라 Informational 메모로 발행되었다. 초안 이력은 2000년 8월 IESG 승인을 기록하며, 발행은 10월에 뒤따랐다. 이 기록은 제품 채택, 준수율, 우회 감소, 개선된 보안 성과가 아니라 문서화된 설계 원칙과 예를 확립한다.

이 RFC의 역사적 기여는 책임의 경계였다. 보안 정책은 흐름을 거부할 수 있지만, 우연한 비호환성이 조용히 애플리케이션 개발자가 우회로를 파는 의무로 전환되어서는 안 된다는 것이었다. 현대 운영자는 무엇을 바꾸기 전에 그 경계를 사용해 실패를 분류할 수 있다. 흐름이 정책에 의해 의도적으로 거부된 것인가, 아니면 필터, 프록시 또는 파서가 준수하는 동작을 깨뜨린 것인가? 이 진단은 RFC에서 도출한 추론이지, 운영자가 실제로 무엇을 했는지에 대한 측정이 아니다.

RFC 3093의 이후 "Firewall Enhancement Protocol"은 HTTP 안에 IP/TCP를 실어 나르는 것을 제안했으며 2001년 4월 1일자였다. 이는 방화벽 장벽에 대한 인접한 응답이지, RFC 2979가 실패했거나 그 터널이 배치되었다는 증거가 아니다. 방화벽 동작을 NAT와 혼동해서도 안 된다. RFC 2979는 한 기기가 둘 다 수행하더라도 이 둘을 별개의 기능으로 명시적으로 다루었다.

출처:RFC 2979;RFC 2775;RFC 3093;초안 이력;RFC 1191;RFC 1869.