요약

  • RFC 3964는 6to4가 패킷을 올바르게 캡슐 해제하면서도 그 터널 입구를 가장 잘 특정해 주는 외부 IPv4 주소를 삭제할 수 있음을 보였다. 포함된 프리픽스의 일치는 스푸핑을 좁혀 주었지만 릴레이, 운영자 또는 행위자를 인증하지는 않았다.
  • 실질적인 통제는 캡슐 해제 전에 외부–내부 패킷 수신 기록, 구체적 릴레이 인스턴스, 각 접수 판정을 보존한 뒤 전달, 배달, 귀속을 별개의 결과로 유지하는 것이었다.

이 이야기의 처음에 패킷에는 네 개의 주소가 있다. 마지막에는 평범한 관찰자에게 두 개만 보인다.

RFC 3964의 예제는 거의 소박할 정도다. 하나의 6to4 사이트가2002:0800:0001로 시작하는 출발지를 가진 IPv6 패킷을 보내고, 그 IPv4 운반체는8.0.0.1에서8.0.0.2로 떠난다. 수신자는 IPv4 헤더를 제거하고 원래 IPv6 패킷을 전달한다. 변환은 올바르다. 그러나 누군가 먼저 그 연관을 기록하지 않으면 되돌릴 수 없다. 하류에서는 마지막 터널 입구를 특정했던 외부 출발지가 사라진다.

이것은 6to4의 가장자리에서 우연히 생긴 부작용이 아니었다. 설계에서 비롯된 것이다.RFC 3056은 공개 IPv4 주소를 가진 사이트가2002:V4ADDR::/48을 구성할 수 있게 했다. 두 6to4 사이트가 직접 통신하면 포함된V4ADDR가 IPv4 터널 목적지를 제공했다. 6to4 사이트가 네이티브 IPv6와 통신할 때는 두 세계 사이에 릴레이가 섰다. IPv4 라우팅이 외부 패킷을 배달했고, 포장이 제거된 뒤에는 IPv6 라우팅이 내부 패킷을 운반했다.

이는 6to4에 우아한 배포 특성을 주었다. 보편적인 레지스트리가 각 임시 사이트 프리픽스를 할당할 필요가 없었다. 주소 자체가 경로 힌트를 제공했다. 그러나 그로 인해 하나의 패킷이 두 개의 권한 체계에 관여하게 되었다. 외부 헤더는 "이 패킷을 터널 경계로 넘겨준 IPv4 종단은 어디인가?"에 답했다. 내부 헤더는 "패킷이 주장하는 IPv6 출발지는 어디인가?"에 답했다. 이 질문들은 제한된 경우에만 겹친다.

비교이지, 신원 증명이 아니다

RFC 3964는 중요한 일관성 검사를 요구했다. 내부 출발지가 6to4 주소라면 릴레이는2002:V4ADDR::/48에 포함된 IPv4 값과 외부 IPv4 출발지를 비교할 수 있었다. 불일치는 패킷을 폐기해야 함을 뜻했다. 캡슐화기와 캡슐화 해제기는 부적절한 특수 목적, 멀티캐스트, 브로드캐스트, 루프백 또는 비전역 값도 거부해야 했다. 관련 주소 클래스는RFC 1812같은 IPv4 라우터 규칙에 근거했으며 지금은IANA IPv4 Special-Purpose Address Space 레지스트리에 기록되어 있다.

이 검사는 의미가 있었다. 특정 6to4 프리픽스를 위조하려는 공격자는 외부 IPv4 출발지도 일치시켜야 했다.BCP 38 / RFC 2827이 지정하고BCP 84 / RFC 3704가 멀티홈 네트워크로 확장한 출발지 필터링이 원점 근처에서 그것을 더 어렵게 만들 수 있었다.

그러나 일치는 인증이 아니다. 통과한 비교는 두 주소 필드가 한 장치의 규칙 아래에서 한 시점에 일관적이었다는 것을 증명할 뿐이다. 누가 출발지를 통제했는지, 종단이 승인된 라우터인지, 주소 할당이 현재 유효한지, 어떤 애플리케이션이 패킷을 만들었는지는 증명하지 않는다. 수신 필터링 역시 또 하나의 경계가 있는 수신 기록이다. 접속이나 경로 집합에 대한 개연성은 보여줄 수 있어도 사람의 신원은 보여줄 수 없다.

역방향은 더 깊은 한계를 드러냈다. 6to4 사이트로 향하는 네이티브 IPv6 출발지에는 릴레이의 외부 IPv4 주소와 비교할2002:출발지 프리픽스가 없다. RFC 3964는 6to4 라우터가 그 패킷이 합법적 릴레이에서 왔는지 스푸핑하는 제3자에게서 왔는지 쉽게 판단할 수 없다고 말했다. 터널은 프레임을 배달했지만 프레임은 릴레이 자격증명을 실지 않았다.

이것은RFC 3756이 서술한 IPv6 Neighbor Discovery의 신뢰 문제와 닮았다. 제어 또는 데이터 패킷을 보낼 만큼 가까이 있다는 것은 그 역할을 차지할 권한이 있다는 뜻이 아니다. 6to4에서 겉보기 "링크"는 공개 IPv4 인터넷이었다.

링크 계층 세부로 취급된 헤더

RFC 3964의 가장 날카로운 운영 문장은 네이티브 IPv6에 대한 공격 논의에 나온다. 6to4 릴레이는 링크 계층 주소처럼 취급했기 때문에 보통 IPv4 주소를 기록하지 않았다고 명시한다. 캡슐 해제 이후 IPv4 노드가 시작한 공격은src_v4추적이 잃어버린 채 IPv6 패킷으로 계속될 수 있었다.

이 구분은 서로 반대되는 두 오류를 막는다. 외부 출발지는 결정적인 귀속이 아니었다. 스푸핑되었을 수 있고, 원점이 아니라 릴레이를 가리킬 수도 있으며, 여러 릴레이가 공유하는 애니캐스트 주소일 수도 있었다. 그럼에도 그것은 여전히 가치 있는 증거였다. 불완전한 단서를 삭제한다고 남아 있는 내부 주장이 더 신뢰할 수 있게 되는 것은 아니다. 다만 사후 복원이 더 빈약해질 뿐이다.

올바른 기록은 관계적이다. 캡슐 해제 전에 운영자는 수신 인터페이스, 구체적 터널 종단, 외부 IPv4 쌍, 내부 IPv6 쌍, 패킷 시각, 프로토콜, 적용된 경로 에포크, 각 검사 결과를 보존할 수 있다. 캡슐 해제 후 새 기록은 내부 패킷이 전달되었는지, 폐기되었는지, 속도 제한되었는지를 명시해야 한다. 목적지의 불만을 그 터널 경계 수신 기록과 결합할 수 있다. 그 결합이 없으면 하류 관찰자는 내부 주소를 탓할 수 있고, 악용 신고는 포장만 전달한 릴레이를 탓할 수 있다.

RFC 6169는 나중에 이 문제를 일반화했다. 외부 패킷을 운반하는 네트워크는 터널 종단이 상응하는 검사를 수행하지 않는 한 내부 주소를 필터링하지 않으며, 터널을 인식하지 못하는 보안 장치는 정책 가시성을 잃을 수 있다. RFC 3964는 변환 자체가 증거를 분할했던 구체적 초기 사례를 제공했다.

애니캐스트는 도달성을 쉽게, 인스턴스 식별을 어렵게 만들었다

RFC 3068은192.88.99.1을 6to4 릴레이 애니캐스트 주소로 할당했다. IPv4 라우팅은 가까운 릴레이를 선택할 수 있었고, 실패한 릴레이는 경로를 철회하고 다른 릴레이가 대신할 수 있었다. 목표는 운영의 단순함이었다. 그 RFC는 비용도 인정했다. 6to4 라우터가 애니캐스트 주소로 보낼 때 특정 릴레이를 식별하기 어려웠다.

따라서 그 주소는 익숙한 형태가 시사하는 것보다 적게 증명했다.192.88.99.1로의 경로는 라우팅이 어떤 광고된 경로를 선택했다는 것만 보여주었다. 어느 물리적 인스턴스가 패킷을 받을지, 그 인스턴스가 릴레이할 의사가 있는지, 네이티브 IPv6 도달성이 있는지, RFC 3964의 검사를 수행하는지, 반환 경로가 같은 운영자를 사용할지는 증명하지 않았다.

2011년 운영 권고 RFC 6343은 그 결과를 문서화했다. 순방향과 반환 트래픽은 흔히 서로 다른 릴레이를 통과했다. 경로는 원치 않거나 고장난 릴레이로 이어질 수 있었다. 상태 저장 필터는 외부 출발지가 다른 반환 경로를 거부할 수 있었다. 관리되지 않는 릴레이는 블랙홀과 불만의 원천이 되었다. 편의 계층은 공유 수신 기록을 만들지 않은 채 다중 운영자 거래를 감추었다.

표준 역사는 결국 권장되는 접점을 좁혔다.RFC 7526은 2015년 애니캐스트 6to4와192.88.99.1을 공식적으로 폐기했다. 그것은 기본 RFC 3056 메커니즘이나2002::/16을 폐기하지 않았다. 이 정밀성이 중요하다. 정책 문서는 모든 경로, 호스트, 구성된 터널 또는 잔존 패킷이 사라졌음을 증명하지 않고도 하나의 발견 및 릴레이 모델을 은퇴시킬 수 있다.

올바른 처리조차 완료된 배달은 아니었다

RFC 3964는 서비스 거부, 반사, 패킷 세탁, 로컬 IPv4 브로드캐스트, 서비스 탈취, 관리상 악용을 정리했다. 검사도 규정했다. 비교가 의미 있는 곳에서 외부 출발지와 포함된 출발지 값을 비교하고, 무효한 IPv4 목적지를 거부하며, 6to4 트래픽을 다시 6to4로 릴레이하지 않고, 타인의 로컬 프리픽스로 향하는 트래픽을 거부하며, 경로와 릴레이 범위를 제한한다.

이러한 통제를 하나의 녹색 "유효" 상태로 뭉개면 안 된다. 패킷은 주소 비교는 통과하고 특수 주소 검사에서 실패할 수 있다. 모든 접수 검사를 통과하고 이후 IPv6 정책에 의해 폐기될 수 있다. 릴레이는 전달하면서도 반환 경로가 없을 수 있다. 목적지는 수신하면서도 애플리케이션이 거부할 수 있다. 릴레이 운영자는 트래픽을 발생시킨 적 없이 악용 불만을 받을 수 있다.

따라서 증거 사슬은 터널보다 길다.

  1. IPv4 라우팅이 종단 또는 애니캐스트 경로를 선택했다.
  2. 구체적 인터페이스가 프로토콜 41 패킷을 수신했다.
  3. 외부와 내부 헤더가 함께 관측되었다.
  4. 각 주소, 방향, 릴레이 규칙이 자체 판정을 산출했다.
  5. 캡슐 해제가 IPv6 패킷을 산출했다.
  6. IPv6 전달이 이를 접수해 전송했다.
  7. 목적지가 수신하거나 거부했다.
  8. 애플리케이션이 효과를 낳았다.
  9. 별개의 증거가 이 사건을 승인된 행위자와 연결했다.

터널은 6단계까지를 완료하면서 9단계까지를 미해결로 남길 수 있었다. 이것이 RFC 3964의 역사적 교훈이다. 기술적으로 성공한 변환이 출처에 대한 남아 있는 가장 좋은 단서가 버려지는 순간이 될 수 있다.

출처와 한계

주요 증거는 RFC 3964의전문,RFC Editor 기록및정오표 기록이다. 두 건의 검증된 기술적 정오표는 공격 예제의 목적지와 잘못 입력된 애니캐스트 프리픽스를 바로잡지만, 어느 쪽도 배포된 실패를 증명하지는 않는다. 역사적 맥락은 RFC3056과3068에서, 필터링 맥락은 RFC2827과3704에서, 이후 운영 및 은퇴 맥락은 RFC6343과7526에서, 그리고 더 넓은 터널, 라우터, Neighbor Discovery 맥락은 RFC6169,1812,3756에서 온다.

이 기록들은 프로토콜 설계, 명시된 위협, 이후 표준 지침을 확립한다. 특정 공격 명명, 공급업체 결함, 릴레이 인구, 트래픽 규모, 보편적 필터링 관행 또는 피해 결과를 확립하지는 않는다.