요약

  • TCP-AO는 주소와 포트를 그대로 두고 TCP 옵션만 재작성하는 중간 장치와 공존할 수 있다. 단, 양쪽 끝점이 모든 비-AO 옵션을 MAC 계산 범위에서 제외해야 한다.
  • NAT 또는 NAPT는 더 어려운 경계다. TCP-AO는 양쪽 IP 주소와 양쪽 TCP 포트를 인증 대상 연결의 일부로 취급하므로, 이들을 바꾸는 문제는 옵션 보호 범위를 조정하는 스위치로 해결할 수 없다.

하나의 패킷, 두 종류의 개입

같은 인증된 TCP 세그먼트가 두 장치를 통과한다고 상상해 보자. 첫 번째 장치는 끝점의 주소와 포트는 건드리지 않지만 타임스탬프 옵션을 조정한다. 두 번째 장치는 세그먼트를 전달하기 전에 주소나 포트를 변환한다. 두 장치 모두 송신자와 수신자 사이의 바이트를 바꾸었지만, RFC 5925는 이들에게 서로 다른 결과를 부여한다.

옵션을 재작성하는 장치는 수용할 수 있다. 다만 공짜는 아니다. TCP-AO에는 TCP-AO 이외의 TCP 옵션을 MAC 계산에 포함할지 결정하는 Master Key Tuple 플래그가 있다. 경로에 옵션을 바꾸는 장치가 있으면, 끝점은 보호되는 연결에서 해당 옵션들을 계산에서 제외하도록 구성할 수 있다.

주소 변환 장치는 같은 탈출구를 쓸 수 없다. TCP-AO는 보호되는 연결을 식별하는 매개변수에 출발지·목적지 주소와 출발지·목적지 포트를 포함한다. RFC의 요구사항 평가는 분명하다. IP 주소가 연결을 정의하므로 주소 보호는 선택 사항이 아니고, 포트가 연결을 정의하므로 포트 보호도 선택 사항이 아니다.

모든 중간 장치를 하나의 범주로 취급하면 이 차이를 놓치기 쉽다. TCP-AO는 전송 중 수정이 항상 불가능하다고 결정한 것이 아니다. 명시된 구성 선택을 통해 일부 필드를 보호에서 제거할 수 있다고 결정했지만, 소켓 쌍은 MAC이 증명하던 정체성의 일부로 남아 있었다.

전부 아니면 전무인 옵션 양보

TCP 옵션 플래그는 문제가 되는 옵션 하나만 예외로 두는 것보다 넓다. 활성화하면 TCP-AO 이외의 모든 옵션이 전송된 순서대로 포함된다. 비활성화하면 모든 옵션이 건너뛰어진다. TCP-AO 자체는 MAC 필드를 0으로 둔 채 MAC 입력에 남아, 길이와 키 식별자에 대한 보호를 유지한다.

이 설계는 NAT가 아닌 중간 장치가 옵션을 수정해도 모든 세그먼트의 인증이 실패하지 않게 한다. 동시에 보안 비용을 드러낸다. RFC 5925는 무시된 옵션이 전송 중 변경될 수 있다고 경고한다. 변경된 타임스탬프는 효율성을 떨어뜨릴 수 있다. 변경된 윈도 스케일 옵션은 정상 동작을 막을 수 있다. 이러한 노출은 옵션을 무시하도록 구성된 연결에 적용된다. 호환성 설정은 해당 필드가 더 이상 중요하지 않다는 일반적인 선언이 아니다.

따라서 “이 장치가 재작성하는 옵션 하나를 제외한 모든 TCP 옵션을 신뢰한다”는 정확한 구성은 없다. 선택지는 그 부류를 보호하거나 그 부류를 제외하는 것이다. 옵션 조작에 의존하는 네트워크 설계는 더 큰 경계를 받아들이고, 이를 연결의 보안 매개변수 일부로 문서화해야 한다.

변환이 필드 하나 이상을 바꾸는 이유

NAT와 NAPT는 주소와 포트 튜플을 재작성한다. 일반적인 TCP 포워딩에서는 변환 장치가 두 끝점의 관점이 대응하도록 충분한 매핑 상태를 유지한다. 그러나 TCP-AO에서는 그 끝점 관점이 인증 계산에도 입력된다. 서로 다른 튜플로 계산하는 송신자와 수신자는 헤더 세부사항에 대해 의견이 다른 정도가 아니라, 서로 다른 연결 정체성을 인증하는 것이다.

따라서 RFC 5925는 TCP-AO가 NAT/NAPT를 가로질러 네이티브로 상호운용할 수 없다고 말한다. 정체성 규칙을 약화하는 대신 그 경계를 우회하는 경로를 스케치한다. 보호되는 세그먼트를 다른 전송 계층으로 캡슐화하거나, 트래버설 메커니즘을 적용하거나, NAT 트래버설을 지원하는 IPsec을 대신 사용하는 것이다. 변환된 값을 조정할 수 있으면 송신자는 수신자가 보는 값으로 계산할 수 있다. 조정할 수 없으면 RFC는 터널이 필요하다고 말한다.

이러한 서술은 하나의 보편적인 배포 레시피를 확립하지 않는다. RFC는 TCP-AO NAT 트래버설 프로토콜을 표준화하지 않고, 현재 변환 장치의 보급률을 측정하지 않으며, 운영자가 어떤 터널을 선택해야 하는지도 말하지 않는다. 조정되지 않은 변환 장치가 왜 호환되지 않는지 정의하고, 주변 아키텍처는 다른 메커니즘에 맡긴다.

연결 정체성을 둘러싼 경계

역사적 선택은 단순히 “보안 대 중간 장치”가 아니었다. TCP-AO는 변경 가능한 전송 장식과 TCP 연결에 이름을 부여하는 끝점 튜플 사이의 좁은 구분을 유지했다. 구현이 선택된 연결에서 비-AO 옵션의 인증을 포기하도록 허용했다. 그러나 주소와 포트의 인증을 포기하면서 여전히 같은 연결을 보호한다고 주장하도록 허용하지는 않았다.

그 경계는 겉보기 도달 가능성이 충분한 증거가 아닌 이유도 설명한다. 옵션 보호 범위가 비활성화되어 있어서 연결이 옵션 재작성 장치를 통과할 수 있다. TCP 흐름이 바깥 헤더가 변환을 흡수하는 터널 안에 있어서 변환 장치를 통과할 수 있다. 어느 관찰도 네이티브 TCP-AO가 변환 후 헤더를 종단 간에 인증했다는 것을 증명하지 않는다.

신뢰할 수 있는 질문은 더 구체적이다. 각 끝점이 어떤 바이트를 MAC 입력에 넣었는가, 그리고 어떤 경로 요소가 그 바이트를 바꾸도록 허용되었는가? 이렇게 표현하면 호환성은 중간 장치에 붙는 라벨이 아니라 연결의 감사 가능한 속성이 된다.

출처