요약

  • IPv4의 LSRR과 SSRR 옵션은 발신자가 중간 주소들을 제공할 수 있게 했습니다. 참여하는 홉은 다음 주소를 목적지 필드로 옮기고, 자신의 송신 인터페이스 주소를 기록한 뒤 포인터를 앞으로 진행했습니다.
  • 이후의 호스트 요구사항과 보안 지침은 와이어 포맷을 지우지 않았습니다. 대신 권한을 로컬 정책으로 옮겼습니다. 비로컬 포워딩은 기본적으로 꺼진 상태가 되었고, 라우터와 방화벽은 해당 옵션을 기본적으로 폐기하도록 권고받았습니다.

IPv4 목적지 주소는 보통 단순한 질문에 답합니다. 이 데이터그램은 어디서 끝나야 하는가? 소스 라우팅은 그 답을 잠정적인 것으로 만들었습니다. 패킷은 목적지 필드의 주소에 도착하면서도, 옵션 안에 아직 대기 중인 또 다른 주소를 가지고 있을 수 있었습니다. 수신자가 참여에 동의하면 두 값을 맞바꿉니다. 다음에 나열된 주소가 목적지가 되고, 송신 인터페이스의 주소가 비워진 옵션 슬롯에 기록되며, 포인터가 4옥텟 앞으로 이동합니다.

이 변형이야말로 이 이야기의 중심에 있는 메커니즘입니다. 경로는 단지 나중에 분석하기 위한 라벨이 아니었습니다. 패킷을 처리한 인터페이스들의 기록을 쌓아가면서, 다음 포워딩 결정에 영향을 줄 수 있었습니다. IPv4는 두 가지 버전을 제공했습니다. LSRR(Loose Source and Record Route, 느슨한 소스 경로 및 경로 기록)은 경유지를 지정하면서 그 사이의 일반 라우팅을 허용했습니다. SSRR(Strict Source and Record Route, 엄격한 소스 경로 및 경로 기록)는 다음에 명시된 주소가 직접 도달 가능해야 했고, 명시되지 않은 중간 라우터는 허용되지 않았습니다.

RFC 791에서 이는 IPv4의 평범한 옵션 어휘의 일부였습니다. LSRR은 타입 131, SSRR은 타입 137을 사용했습니다. 각각 길이, 포인터, 주소 슬롯을 담았습니다. 둘 다 모든 조각에 복제되었으므로, 단편화가 뒤쪽 조각을 제공된 경로에서 몰래 떼어놓지는 않았습니다. 그러나 이 기능은 빠듯하게 제한되어 있었습니다. IPv4 헤더 전체는 60옥텟을 넘을 수 없어서, 기본 헤더와 옵션 메타데이터를 제외하면 야심적인 여정표를 담을 여유가 거의 없었습니다.

겉보기 권한에도 정확한 한계가 있었습니다. 소스 경로는 참여하는 각 시스템이 처리하는 요청이지, 모든 라우팅 결정을 대체하는 명령이 아니었습니다. LSRR은 여전히 나열된 지점 사이의 경로를 게이트웨이가 찾아주는 데 의존했습니다. SSRR은 다음 주소가 직접 연결된 네트워크에 있지 않으면 실패할 수 있었습니다. 잘못된 길이나 포인터는 안전하게 지시로 취급될 수 없었습니다. 발신자는 바이트를 제공할 뿐이고, 각 수신 시스템은 그 바이트를 다룰지 어떻게 다룰지를 여전히 스스로 결정했습니다.

RFC 1122는 이 로컬 권한을 더 분명히 드러냈습니다. 호스트는 중간 홉으로서 소스 라우팅된 데이터그램을 포워딩할 수 있었지만, 게이트웨이와 유사한 규칙을 따르는 경우에만 그랬습니다. RFC 1122는 로컬 소스 라우팅—다음 홉이 패킷이 도착한 것과 같은 물리적 인터페이스로 나가는 경우—과 비로컬 포워딩을 구분했습니다. 비로컬 케이스를 지원하는 호스트는 이를 비활성화할 수 있는 스위치를 제공해야 했고, 그 스위치는 기본값이 비활성이어야 했습니다. 정책 필터도 여전히 적용되었습니다. 실패는 ICMP 목적지 도달 불가 코드 5, 즉 Source Route Failed로 보고될 수 있었습니다.

이것은 소스 라우팅의 삭제가 아니었습니다. 호스트는 여전히 이를 발신하거나 수신하거나 명시적으로 활성화할 수 있었습니다. 그러나 기본값의 의미가 바뀌었습니다. 패킷 문법이 더 이상 다중 인터페이스 호스트가 자신의 포워딩 지위를 발신자에게 빌려주어야 한다는 뜻을 담지 않게 된 것입니다. 이 메커니즘은 행정 경계를 넘었으므로, 실제로 그 경로가 존재하는지 여부에 관리자의 정책이 개입하게 되었습니다.

보안 분석은 나중에 이 경계가 왜 중요한지 설명했습니다. 발신자가 선택한 경로는 예상치 못한 인터페이스를 통해 시스템에 접근하거나, 라우팅·방화벽 규칙에 내재된 가정을 우회하거나, 토폴로지를 노출하거나, 트래픽이 의도적으로 낭비적인 순서를 거치게 만드는 데 쓰일 수 있었습니다. 구현체는 변경 가능한 파서 상태 그 자체도 방어해야 했습니다. 다음 주소를 읽거나 인터페이스 주소를 쓰기 전에, 길이와 포인터가 유효한 4옥텟 슬롯을 가리키는지 확인해야 했습니다.

이에 따라 RFC 6274는 필요한 특수한 환경을 위한 명시적 활성화 제어를 남겨두면서, 시스템이 LSRR과 SSRR을 기본적으로 폐기할 것을 권고했습니다. 이 옵션들이 정당한 용도를 지닌 적이 없다는 식의 가장은 아니었습니다. 기록 속에는 디버깅과 일부 피어링 계약이 등장합니다. 판단은 더 좁고 더 중대한 것이었습니다. 그 이점은 더 이상 포맷을 이해하는 모든 시스템의 자동 참여를 정당화하지 않는다는 것이었습니다.

RFC 7126은 이 판단을 라우터, 보안 게이트웨이, 방화벽을 위한 운영상 명시적인 조언으로 만들었습니다. 구현은 옵션별 선택지를 제공해야 합니다. 패킷을 폐기하거나, 옵션을 무시하고 일반 목적지에 따라 포워딩하거나, RFC 791대로 소스 경로를 처리하는 것입니다. 기본값은 폐기여야 하고, 그 기본값은 문서화되어야 합니다.

이 선택지들은 서로 바꿔 쓸 수 없습니다. 옵션을 무시하면 패킷이 그 여정 단계에서 발신자가 기대했던 곳이 아닌 다른 곳에 전달될 수 있습니다. 폐기는 요청된 포워딩 의미론이 거부되었다는 사실을 보존합니다. 처리는 로컬 검사와 정책을 전제로 패킷이 제안한 경로를 수용합니다. 따라서 설정 스위치는 단순히 레거시 기능을 켜고 끄는 이상의 일을 합니다. 그 바이트가 도착했을 때 네트워크가 약속하는 해석이 어느 것인지를 밝히는 것입니다.

그 결과 나타나는 역사는 유용한 것에서 쓸모없는 것으로의 깨끗한 행진이 아닙니다. 실용적 권한의 이전입니다. RFC 791은 발신자가 중간 홉을 제안할 수 있는 언어를 제공했습니다. RFC 1122는 비로컬 호스트 참여를 옵트인으로 만들었습니다. RFC 6274는 위험과 구현 의무를 목록화했습니다. RFC 7126은 기본 폐기를 방어 가능한 기준선으로 다루면서 명시적이고 문서화된 예외를 남겼습니다.

출처