요약

  • Robert Moskowitz와 Pekka Nikander가 2006년에 제안한 HIP 아키텍처는 공개키 기반 신원을 엔드포인트 이름으로 삼고, IP 주소는 그 엔드포인트를 찾아 패킷을 전달하는 용도로만 두었습니다.
  • 이 분리는 양쪽 호스트가 모두 HIP을 사용할 때 주소 변경을 넘어 연결을 유지할 수 있게 지원할 수 있습니다. 그러나 주소 등록을 이전하거나, 모든 애플리케이션의 접근 규칙을 갱신하거나, 보편적인 연속성을 보장하지는 않습니다.

노트북이 한 네트워크를 떠나 새 주소를 받았습니다. 그곳으로 가는 경로는 바뀌었지만 통신 상대의 기계는 그대로입니다. 인터넷 프로토콜은 오래전부터 하나의 숫자에 두 가지 사실을 모두 담도록 요구해 왔습니다. Robert Moskowitz와 Pekka Nikander가RFC 4423에서 명시적으로 만든 설계 문제가 바로 이것입니다. IP 주소는 위상적 위치를 설명하지만, 동시에 통신 엔드포인트의 이름처럼 취급되어 왔습니다.

그들이 제안한 Host Identity Protocol(HIP)은 인터네트워킹 계층과 전송 계층 사이에 별도의 신원 계층을 삽입했습니다. 이 아키텍처에서 Host Identifier는 공개키입니다. 문서는 그 구체적인 키와 키가 대표하는 추상적인 호스트 신원을 구분합니다. HIP은 프로토콜 상태에서 식별자의 128비트 해시인 고정 길이의 Host Identity Tag(HIT)를 사용합니다. IP 주소는 여전히 유용합니다. 라우터에게 패킷이 어디로 가야 하는지 알려 주기 때문입니다. 그러나 어떤 호스트가 전송 연결을 소유하는지를 정의할 필요는 더 이상 없습니다.

이 결합 방식의 변화가 핵심 아이디어입니다. RFC 4423은 전송 연결을 Host Identity에 묶인 것으로 설명합니다. 이동성, 새로운 네트워크 접속 또는 재번호화로 주소가 바뀌더라도 HIP을 이해하는 피어는 신원에 묶인 연결을 유지하면서 로케이터를 갱신할 수 있습니다. 같은 논리는 하나의 호스트가 여러 인터페이스를 갖는 경우에도 적용될 수 있습니다. 실용적인 관점에서 HIP은 연속성의 한 원천을 주소에서, 참여하는 엔드포인트들이 공유하는 암호화 상태로 옮깁니다.

Moskowitz의 역할은 직함이 아니라 표준 기록을 통해 읽어야 합니다. RFC 4423은 2006년 5월에 Informational 문서로 발표되었습니다. 문서 자체의 초록은 이것이 2003년 가을 기준 저자들의 사고를 담은 스냅샷이며 아키텍처가 진화했을 수 있다고 밝히고, 인터넷 표준을 명시하는 문서가 아니라고 분명히 말합니다. 이후 Moskowitz가 다른 저자들과 함께 편집한RFC 7401은 HIP 버전 2를 Standards Track 프로토콜로 명세합니다. 동의한 호스트들이 IP 계층 상태를 공유하고, 엔드포인트를 인증하는 네 패킷 교환을 거치는 방식을 설명합니다. 그보다 뒤에 Moskowitz와 Miika Komu가 공동 집필한RFC 9063은 아키텍처를 갱신하고 RFC 4423을 폐기하며, RFC 7401 구현에서 얻은 교훈을 반영하고 암호화 민첩성과 신뢰 우선 사용(trust on first use) 같은 질문을 다룹니다.

이 일련의 과정은 하나의 기술 아이디어가 개정되었다는 증거이지, 인터넷에서 주소 의존이 사라졌다는 증거가 아닙니다. HIP의 연속성은 그 엔드포인트들이 관리하는 연결에 적용됩니다. 고객 시스템은 여전히 발신 IP로 트래픽을 허용할 수 있습니다. DNS 레코드는 여전히 예전 주소를 가리킬 수 있습니다. 피어는 HIP을 말하지 않을 수 있습니다. 애플리케이션은 주소를 설정에 저장하거나 평판 신호로 사용할 수 있습니다. 전송 연결이 안정적인 암호화 신원을 갖게 되었다는 이유만으로 이런 의존이 자동으로 이전되지는 않습니다.

Lu Heng의 노트 68은 유용하지만 별개의 경제학적 렌즈를 제공합니다. 고객, 파트너, 보안 담당자들이 기대를 쌓아 가면 주소가 사업상의 기억이 될 수 있다는 관찰입니다. 이 주장은 HIP을 설명하지도, 특정 배포를 증명하지도 않습니다. 참여하는 프로토콜 교환이 사용하는 호스트 신원과 라우팅에 사용되는 로케이터를 분리하는 것이 왜 필요한지를 명확히 해 줄 뿐입니다. HIP은 주소 주변에 축적된 외부 관계를 다시 쓰지 않습니다.

따라서 Moskowitz의 기여는 경계 설계로 이해하는 것이 가장 적절합니다. 네트워크에 연결된 호스트에게, 요컨대 "내 경로는 바뀔 수 있지만, 내 인증된 엔드포인트 신원은 별개의 상태다"라고 말할 수 있는 방법을 줍니다. 이 경계는 좁기 때문에 강력합니다. 이동성과 멀티호밍이 고정 주소에 덜 의존하게 만들 수 있으면서도, 네이밍, 라우팅, 자원 관리, 애플리케이션 정책, 고객 대면 연속성은 각자의 시스템에 맡깁니다.

출처