요약

  • 2001년에 표준화된 FORCERENEW는 DHCP 서버가 설정된 클라이언트에게 일반 갱신 절차에 들어가도록 요청할 수 있게 했다. 이 알림은 새 주소도, 직접적인 철회도, 변경이 적용되었음을 확인하는 것도 아니었다.
  • 2012년의 논스 기법은 인증 비밀값을 사전에 별도 채널로 배포할 필요를 없앴다. 설정 과정에서 전달된 값이 이후 알림을 검증하는 키가 되었다.
  • 이 경제성은 협소한 위협 모델에 의존했다: 일반 교환을 관찰할 수 없는 네트워크 외부 공격자에 대한 방어다. 이 기법은 초기 전달을 독립적으로 인증하지 않았고, 모든 로컬 공격자를 막지도 않았으며, 재구성이 활성 세션에 미치는 영향을 무해하게 만들지도 않았다.

묻지 않아도 될, 정상 동작하는 클라이언트

클라이언트는 고장난 상태가 아니다. 주소는 계속 사용 가능하고, 현재 파라미터로도 정상 작동하며, 다음 일반 갱신은 아직 필요하지 않다. 그러나 서버에서는 관리자가 어떤 설정을 바꾸고자 한다. 유효한 구성과 보류 중인 관리 결정은 서로 모순되지 않은 채 공존할 수 있다.

곤란한 점은 클라이언트를 다시 불러내는 일이다. DHCP는 보통 요청과 응답으로 진행된다. 지금은 다른 답이 더 좋다는 것을 알아도 서버가 그 답을 즉시 전달할 기회를 얻는 것은 아니다. 서버는 그 답을 공급하기 전에 다음 질문에 영향을 줄 수 있어야 한다.

RFC 3203은 2001년 12월에 발표되었으며, 이 목적을 위해 FORCERENEW를 도입했다. 서버는 클라이언트에게 유니캐스트 알림을 보냈다. 클라이언트는 이를 받으면 갱신 절차에 들어가 일반적인 DHCPREQUEST를 발행했다. 첫 운영적 결과는 새로 설치된 구성이 아니라 또 하나의 교환이었다.

이 구분은 메시지 이름이 강렬해서 놓치기 쉽다. 그러나 설계는 의도적으로 기존 클라이언트 상태를 재사용했다. 저자들은 새 상태가 없다는 점을 장점으로 제시했다. 즉, 익숙한 절차를 우회하는 대체 절차가 아니라 그 절차로 들어가는 새로운 입구를 추가한 것이다.

임대가 움직이기 전에 주도권이 움직였다

조기 갱신 자체는 새로운 것이 아니었다. 1997년 3월의 기본 명세인RFC 2131은 이미 클라이언트가 T1 이전에 갱신을 시도할 수 있도록 허용했다. FORCERENEW에 일찍 요청할 수 있는 최초의 가능성을 발명한 공으로 돌릴 수는 없다. 그 기여는 이 귀환을 서버 주도로 만든 것이다.

이 구분은 임대를 해석할 때 중요하다. 임대에 남은 시간은 클라이언트가 현재 구성을 계속 사용할 권리의 일부를 설명할 뿐이다. 그것은 관리자에게 어떤 서비스 옵션을 지금 바꾸어야 하는지를 알려주지 않는다. 이 확장은 서버에게 그 두 개의 별개 시간축을 접촉시키는 수단을 제공했다.

주소 변경에는 여전히 추가 조치가 필요했다. RFC 3203은 서버가 클라이언트의 요청에 DHCPNAK로 응답하여 클라이언트가 초기화로 돌아가 DHCPDISCOVER를 브로드캐스트하게 만드는 과정을 기술했다. 그 다음 서버는 DHCPOFFER로 다른 주소를 제시할 수 있었다. FORCERENEW 자체는 NAK도, 오퍼도, 최종 확인도 아니었다. 일반 갱신이 주소를 그대로 두는 경우도 있었다.

패킷 문법은 DHCP의 기존 틀 안에 머물렀다.RFC 2132는 옵션 53을 메시지 타입 옵션으로 정의했고, 이 확장은 FORCERENEW를 위해 값 9를 추가했다. 이는 메시지 타입 값이지, 전송 포트도, 인증 옵션의 번호도 아니다. 공유된 번호 체계가 새 초대를 식별해 주었을 뿐, 그 초대가 시작한 대화의 결과를 결정하지는 못했다.

수동 구성 클라이언트는 자신의 경계를 지켰다

일부 클라이언트는 주소를 DHCP에서 받지 않았다. 수동으로 구성된 주소를 사용하며 다른 로컬 파라미터를 얻기 위해 DHCPINFORM을 보낸다. RFC 3203은 이들을 명시적으로 다루었다. 유니캐스트 알림을 받은 후 새로운 INFORM을 보내야 한다고 했다.

범위는 DHCP로 구성 가능한 파라미터로 한정되었다. 수동으로 구성된 값은 덮어써서는 안 된다. 서버가 클라이언트를 소환할 수 있게 되었다는 사실이, 따라서 그 기기의 모든 설정에 대한 서버의 권한을 확장한 것은 아니다.

이 사례는 단순한 임대 사례보다 더 많은 것을 드러낸다. 알림은 유효하고 응답을 만들어내면서도 주소를 다시 할당 대상으로 돌리지 않을 수 있다. 이후의 주소 요청만을 찾고 있던 운영자는 올바른 INFORM 응답을 실패로 오해할 수 있다. 클라이언트가 소환에 응했는지 판단하기 전에, 그 클라이언트와 DHCP의 기존 관계를 먼저 이해해야 한다.

제안된 용도는 실용적이었다. 이 문서는 홈 게이트웨이의 서비스 변경, 호텔 네트워크의 서비스 선택, 그리고 엄격히 통제된 조건의 서브넷 리넘버링을 논의했다. 이들은 동기 부여 시나리오일 뿐, 도입률 측정도, 특정 제품의 현재 지원 여부에 대한 증거도 아니었다.

같은 텍스트는 주소나 로컬 파라미터의 변경이 활성 세션을 방해할 수 있다고 경고했다. 관리자의 대기 시간을 줄이는 기법이 자동으로 애플리케이션의 복구 시간을 줄여주지는 않는다. 그 방해가 정당한지는 메시지 형식 밖의 결정이다.

요청 부재는 완료된 변경이 아니었다

기대한 DHCPREQUEST가 도착하지 않으면 서버는 지수 백오프와 제한된 재시도 횟수로 FORCERENEW를 재전송할 수 있었다. RFC 3203은 초기 지연을 네트워크의 상황에 맡겼으며, 보편적인 수치 일정을 정하지 않았다.

재전송은 유실된 교환을 복구할 수 있지만 모든 침묵을 설명하지는 못한다. 요청 부재는 전달, 클라이언트 상태, 지원 여부, 또는 알림 거부를 조사해야 할 수 있다. 부재 자체는 원인을 특정하지 않는다. 전송을 반복 기록하는 것이 클라이언트가 재구성했다는 증명이 되지는 않는다.

전달 규칙은 일반적인 브로드캐스트 명령보다 좁았다. 명세된 경로는 유니캐스트였고, 클라이언트에게는 멀티캐스트 FORCERENEW 메시지를 조용히 폐기하도록 지시했다. 서버는 개별 클라이언트를 불러낼 수 있었지만, 그 문서는 수신의 도착이 전체 장비에 걸친 변경의 완료를 뜻하는 무차별 공지를 기술하지 않았다.

따라서 운영 기록에는 서로 다른 여러 사건이 필요하다: 알림, 클라이언트 요청, 서버 응답, 채택된 파라미터, 애플리케이션 동작. 첫 번째는 누군가 프로세스 시작을 시도했다는 증거일 뿐, 나머지를 압축한 대체물이 아니다.

시점 선택은 보안 문제가 되었다

공격자가 거짓 설정을 설치하지 않았어도 영향력을 얻을 수 있다. 클라이언트가 선택한 시점에 새 구성 교환을 시작하게 만드는 능력 자체가 하나의 역량이다. 그래서 RFC 3203은 FORCERENEW의 인증과, 인증 실패 시 거부를 요구했다.

그 참조는 2001년 6월에 발표된RFC 3118이었다. 이 문서에는 성질이 다른 여러 기법이 담겨 있었다. 평문 구성 토큰은 약한 매칭만 제공했고 메시지 전체를 인증하지 못했다. 지연 인증은 공유 비밀을 사용했지만, 그 비밀이 DHCP 교환 밖에서 배포되었다고 가정했다.

클라이언트를 개별적으로 인증하려면 대응하는 클라이언트별 키 관계도 필요했다. 운영자가 짧은 알림을 사용하기 전에, 올바른 비밀을 공급하고 보존하는 상당한 작업이 있을 수 있었다. 패킷의 크기는 기능 도입의 비용을 재는 나쁜 척도였다.

2012년 8월,RFC 6704의 저자들은 구 기준이 이 용례에 필요한 수준보다 엄격했고 FORCERENEW 도입을 제한했다고 주장했다. 이것은 동기에 대한 그들의 시점 고정된 설명이지, 현재 배포 현황 조사가 아니다. 그들이 제안한 경제성은 별도의 사전 키 배포 없이 더 구체적인 트리거를 보호하는 것이었다.

첫 교환이 이후 호출의 키를 공급했다

역사적 선례는 2003년 7월에 발표된RFC 3315의 DHCPv6 Reconfigure Key 기법이었다. 이것은 하나의 인증 아이디어의 계보지, IPv6 구성 프로토콜 전체의 이식이 아니었다. 구 문서는 이후 대체되었으며, 여기서는 전이(전身) 선례로 관련이 있을 뿐 현재의 완전한 DHCPv6 안내서가 아니다.

RFC 6704에 따르면, 논스 인증은 당사자들이 이미 기존의 DHCP 인증 기법을 사용하지 않고 논스 프로토콜을 협상했을 때에만 사용되었다. 클라이언트는 DISCOVER와 REQUEST에서 역량을 광고했다. 서버는 OFFER에서 선호를 표시했다. 역량 광고는 클라이언트 인증 코드가 아니었다. 클라이언트는 이 논스 프로토콜을 선택한 상태에서 인증 옵션을 포함한 DHCP 메시지를 보내서는 안 된다.

논스가 필요하면 서버는 암호학적으로 강한 무작위 또는 의사무작위 128비트 값을 생성했다. 그 값은 REQUEST–ACK 교환 중 ACK로 전달되었고, 양쪽 모두 보관했다. 이후 FORCERENEW는 논스를 다시 공개하는 대신, 보관된 값을 키로 사용해 계산한 HMAC을 담았다.

이것은 특정 공급 단계를 없앴다. 초기 구성 대화가 이후 호출을 인식하기 위한 재료를 공급했다. 신뢰의 기원을 없앤 것이 아니라, 그 이전 대화를 이후 메시지가 수용될 수 있는 이유의 설명에 포함시킨 것이다.

협상은 전달을 제약했다. 서버는 역량을 광고하지 않은 클라이언트의 ACK에 대응하는 논스 인증 옵션을 삽입해서는 안 된다. 반대로 초기 OFFER가 이 기법을 광고했는데 이어지는 ACK에 유효한 대응 옵션이 없으면, 클라이언트는 ACK를 폐기하고 초기화로 돌아가야 했다. 이는 협상과의 일치를 검증한 것이지, 첫 서버의 신원을 독립적으로 확립하지 않았다.

보관된 논스, 변하는 역사

그 값은 한 번의 알림으로 소모되지 않았다. 이름과 달리 여러 호출에 걸쳐 계속 사용될 수 있었다. RFC 6704의 규범적 서버 문구에 따르면 갱신 ACK는 새 논스가 생성된 경우가 아니면 논스를 반복해서는 안 된다. 갱신 중 교체를 보여주는 도표가 매 일반 갱신마다 교체를 요구하는 것은 아니었다.

다만 리바인딩 중 만난 새 서버는 반드시 새 논스를 생성해야 했다. 따라서 이 기법은 보관된 상태와 그 상태가 어떻게 확립되었는지에 의존했다. 패킷에 인증 필드가 보인다고 해서 올바른 상태가 서버 교체를 넘어 살아남았다는 증명이 되지는 않는다.

역사적인 알고리즘은 HMAC-MD5였다. 이를 기술하는 것은 현대적 알고리즘 권고가 아니며, MAC은 대화의 암호화도 아니었다. 신선함은 별도의 주의를 필요로 했다. 2013년,확인된 정오표 3474는 RFC 3118의 리플레이 카운터가 엄격히 증가해야 한다고 명확히 했다. 오래된 메시지에 여전히 올바른 인증 코드가 있다는 이유만으로 동일한 값의 반복이 그 규칙을 충족하지 않는다.

따라서 비밀과 역사는 서로 다른 질문에 답했다. 하나는 코드 검사를 지지했고, 다른 하나는 메시지가 새로운 발생으로 간주될 수 있는지를 판정하는 데 도움을 주었다. 일반적인 "인증됨" 표기가 이 구분을 지키지 못한 실패를 가릴 수 있었다.

처음을 보지 못한 공격자

RFC 6704는 클라이언트와 서버 사이의 일반 교환을 관찰할 수 없는 네트워크 외부 공격자에 초점을 맞췄다. 논스에 접근할 수 없는 그 공격자는 클라이언트가 공격자가 원하는 시점에 갱신하게 만드는 인증된 호출을 만들 수 없었다. 이 보호는 관찰에 대한 특정한 한계를 이용했다.

초기 논스 전달을 가로챌 수 있는 관찰자는 전제를 바꾼다. 로컬 링크의 누군가는 이미 일반 요청을 볼 수 있으며, 논스를 얻으면 이 보호가 무너진다. 이 기법은 초기 구성을 위한 독립적 신뢰 근원을 만들지 않았고, 모든 DHCP 트래픽을 인증하지 않았으며, 도달 가능한 모든 서버가 그 기기에 대한 관리 권한을 갖는다는 것을 증명하지도 않았다.

유효하지 않은 메시지를 거부한다고 해서 서비스 거부가 사라지는 것도 아니다. 검사는 자원을 소모하며, 충분히 많은 가짜 알림이 여전히 클라이언트에 부담을 줄 수 있다. 이들은 명세가 밝힌 설계상 한계이지, 특정 악용 사건의 증거나 현재 공격 빈도의 측정이 아니다.

IANA BOOTP 및 DHCP 파라미터 레지스트리는 메시지 타입 9, 인증 옵션 90, 역량 옵션 145를 각각의 공간에 기록한다. 이 조율 덕분에 구현체들이 같은 필드를 일관되게 해석할 수 있다. 그러나 이것이 어떤 기기가 이 확장을 구현한다는 것, 어떤 쌍이 이를 협상했다는 것, 또는 관리자가 의도한 변경이 적용되었다는 것을 확립하지는 않는다.

FORCERENEW의 지속적 기여는 경계를 갖춘 주도권이었다. 서버는 클라이언트의 다음 일반 질문을 기다리지 않고 클라이언트를 다시 불러낼 수 있었다. 논스 인증은 이후 명시된 위협 모델 안에서 그 초대를 보호하는 비용을 낮췄다. 그래도 클라이언트는 물어야 했고, 서버는 답해야 했으며, 운영자는 결과 구성이 동작하는지 판정해야 했다. 이 노크는 전체 트랜잭션이 아니었기 때문에 유용했다.