요약

  • RFC 3993은 DHCP 릴레이가 고객이 서로 다른 물리적 접속 경로를 사용하더라도 안정적으로 유지되도록 의도된 사업자 정의 가입자 ID(Subscriber-ID)를 붙일 수 있게 했다.
  • 이 표준은 값을 전달했지만, 그 할당과 의미는 사업자 구성에 맡겼다. 덕분에 이 레이블은 정책 적용에 유용했고, 장기적인 연관 추적에도 잠재적으로 유용할 수 있었다.

케이블은 바뀌어도 계정은 남는다

DHCP 서버는 직접 볼 수 없는 클라이언트에 대해 결정을 내려야 할 때가 있다. 규모가 큰 접속 네트워크에서 릴레이는 클라이언트의 로컬 브로드캐스트를 받아 중앙 서버로 전달한다. 릴레이는 요청이 사업자 네트워크에 어디로 들어왔는지에 대한 정보를 추가할 수 있다. 그러면 서버는 모든 접속 구간마다 자체 로컬 서버를 두지 않고도 주소와 구성을 돌려줄 수 있다.

이 구조 속에서 릴레이는 메신저인 동시에 관찰자가 되었다. 2001년에 발행된 RFC 3046은 릴레이 에이전트 정보를 담을 컨테이너를 마련했다. 초기 필드에는 Circuit-ID와 Remote-ID가 있었다. 하나는 유입 회선을, 다른 하나는 원격 모뎀을 기술할 수 있었다. 이런 값들은 서버가 회선과 장비를 구분하는 데 도움이 되었지만, 그 값은 네트워크를 따라갔다. 사업자가 동일한 행정적 처리를 원하더라도 고객이 다른 경로로 옮겨지면 회선에 의존하는 값은 바뀔 수 있었다.

RFC 3993은 바로 이 경계면을 다루었다. 2005년에 발행된 이 문서는 기존의 릴레이 에이전트 정보 옵션에 Subscriber-ID 서브옵션을 추가했다. 의도된 값은 물리적 접속 구조와 독립적일 수 있었고, 고객이 경로 사이를 이동하거나 네트워크가 바뀌더라도 안정적으로 유지될 수 있었다. 사업자는 하나의 필드에 두 가지 역할을 강요하는 대신, 회선 및 원격 식별자와 함께 이 값을 사용할 수 있었다.

회선에 실린 것은 정의가 아니라 값이었다

이 사양의 절제된 태도가 핵심이다. Subscriber-ID는 NVT ASCII 문자열로, 서브옵션 코드 6에 1옥텟 길이로 전달된다. 최소 1옥텟을 담아야 하고 NUL로 종료되지 않는다. 이 규칙들은 두 시스템이 메시지에서 값을 찾는 방법만 알려 준다. 문자가 무엇을 의미하는지는 알려 주지 않는다.

RFC 3993은 그 의미가 사업자 고유(providerspecific)라고 규정한다. 식별자는 사업자가 할당하며, 이를 할당하고 구성하는 데 쓰이는 메커니즘은 이 메모의 범위 밖이다. 릴레이는 이 값을 포함하도록 구성될 수 있다. 이를 지원하도록 구성된 서버는 주소나 기타 매개변수를 할당할 때 다른 릴레이·클라이언트 데이터와 함께 이 값을 사용할 수 있다. 값의 존재도 하류에서의 사용도 의무는 아니다.

이러한 분리 덕분에 옵션은 보편적이지 않으면서도 이식 가능해졌다. 한 사업자는 값을 청구 계정에 매핑할 수 있고, 다른 사업자는 서비스 프로필에 연결할 수 있다. RFC는 어느 모델도 요구하지 않으며, 같은 문자열이 다른 행정 도메인에서 같은 것을 지칭할 필요도 없다. 따라서 DHCP 패킷만으로는 어떤 사람, 장치, 계약 또는 권한이 특정 신원을 가진다고 확립할 수 없다. 그 연결은 사업자의 기록과 운영상의 선택 안에 존재한다.

이는 작은 프로토콜 추가였지만, 파급력 있는 통제 경계를 만들었다. 클라이언트는 사업자의 안정 레이블을 스스로 주장하는 신원으로 제공하지 않는다. 사업자가 운영하는 릴레이가 이를 삽입하고, 중앙 서비스는 이를 바탕으로 주소나 구성을 결정할 수 있다. 값의 권위는 문자열의 표기가 아니라 신뢰 구조와 사업자의 매핑에서 나온다.

신뢰가 편의를 의미 있게 만든다

릴레이 에이전트 정보 옵션은 릴레이와 서버 사이의 신뢰 관계에 의존한다. RFC 3993은 사기성 데이터가 서비스 절도, 희소 주소 고갈, 서비스 거부, 부적절한 구성에 기여할 수 있다고 경고한다. RFC 3046은 옵션의 반환 경로를 기술한다. 이를 인식한 서버는 릴레이 정보를 릴레이로 되돌려 보내고, 릴레이는 클라이언트에게 응답을 보내기 전에 그 정보를 제거한다. 이를 통해 사업자 측 통제 교환이 클라이언트용 신원 인증서와 구별되도록 유지된다.

신뢰 경계는 강화될 수 있다. RFC 3993은 주변 방어를 언급하고, 별도의 DHCP 릴레이 인증 서브옵션이나 IPsec을 통한 더 깊은 보호를 권장한다. RFC 4030은 재생 탐지 절차를 포함한 인증 서브옵션을 규정한다. 인증은 릴레이 옵션 데이터가 수용된 경로를 통해 왔음을 확립하는 데 도움이 될 수 있다. 그러나 RFC 3993이 의도적으로 다른 곳에 맡긴 사업자 고유의 의미까지 공급하지는 못한다.

안정성은 또한 프라이버시의 트레이드오프를 만든다. 회선 식별자는 메시지가 네트워크 어디로 들어왔는지 드러낼 수 있다. 가입자 식별자는 행정적 주체를 회선을 넘어 따라갈 수 있다. RFC 3993은 노출될 경우 이 값이 특정 호스트나 사용자를 식별할 수 있다고 경고한다. 이후 RFC 7819는 Subscriber-ID를 활동을 시간에 걸쳐 연결할 수 있는 장기 식별자로 다룬다. 재구성 부담을 줄여 주는 그 이점이, 기록이 연결 가능한 기간을 늘릴 수도 있다.

RFC 4580은 비슷한 개념을 DHCPv6으로 가져왔다. 이 역시 할당과 의미를 사양 밖으로 남기고, 의도된 교환을 하나의 행정 도메인으로 한정한다. 이 병렬 구조는 설계 패턴을 확인해 주지만, DHCPv4 레이블과 DHCPv6 레이블의 자동적 동등성을 의미하지는 않는다.

이 RFC들은 의도된 메커니즘과 명시된 위험을 확립한다. 그러나 운영자들이 얼마나 널리 배치했는지, 특정 고객의 이동이 성공했는지, 사업자가 어떤 프라이버시 통제를 사용했는지는 보여 주지 않는다. 따라서 여기의 역사는 설계 경계에 관한 것이다. DHCP는 사업자의 안정 레이블을 변화하는 접속 토폴로지를 넘어 전달할 수 있었지만, 그 레이블이 무엇을 의미하고 어떤 결정이 뒤따르는지의 책임은 사업자에 남아 있었다.

출처