요약

  • RFC 1048은 BOOTP의 벤더 필드 앞부분에 4옥텟 값99.130.83.99를 배치하여 해석 문법(grammar)을 선택하도록 했습니다. 태그와 길이로 구획된 하위 필드를 통해 수신자는 고정된 64옥텟 범위 안에서 알려진 옵션을 찾아내고 알 수 없는 옵션을 건너뛸 수 있게 되었습니다.
  • 이 쿠키(cookie)는 아무것도 인증하지 않습니다. 응답이 완벽한 프레임 구조를 갖추었더라도 거짓이거나 낡았거나 무단일 수 있으며, 이 보안 한계는 동일한 옵션 형식이 DHCP로 넘어가면서 RFC 1542 등 후속 BOOTP 지침에서 명시적으로 드러났습니다.

BOOTP의 원래 문제 상황에서 기계는 거의 아무런 로컬 문맥 없이 시작합니다. 하드웨어 주소를 알고 작은 부트스트랩 프로그램을 실행할 수는 있지만, 자신의 IP 주소, 유용한 서버의 주소, 불러와야 할 파일의 이름은 모릅니다. 1985년에 발표된RFC 951은 이 과정을 두 단계로 나누었습니다. 먼저 충분한 설정 정보와 부트 파일 위치를 파악한 뒤, 다른 프로토콜로 그 파일을 가져오는 것입니다.

BOOTP 패킷은vend라는 벤더 전용 영역으로 64옥텟을 예약해 두었습니다. 이는 한편으로는 넉넉하고 다른 한편으로는 애매한 설계였습니다. 서브넷 마스크, 게이트웨이, 타임 서버 등 클라이언트가 일반 서비스를 사용하기 전에 필요로 할 정보를 담을 공간을 제공했지만, “벤더 전용”이라는 것은 같은 바이트가 서로 다른 프로그램에게 서로 다른 의미를 가질 수 있음을 뜻했습니다. RFC 951은 사용된 벤더 데이터가 4바이트 매직 넘버로 시작하도록 권고하여 클라이언트가 뒤따르는 정보의 종류를 식별할 수 있게 했습니다. 식별은 존재했지만, 공통의 문법은 아직 없었습니다.

1988년 2월에 발행된RFC 1048이 이 경계를 바꾸었습니다. 패킷을 확장하지 않고 기존 공간을 이종 클라이언트들이 공유할 수 있을 만큼 자기 기술적으로 만든 것입니다. 설계는 지나치기 쉬울 만큼 단순합니다. 4바이트가 형식을 선택하고, 나머지 바이트는 태그가 붙은 하위 필드로 나뉩니다. 그러나 이 소박한 문법이 형식 식별, 확장 프레이밍, 한정된 할당이라는 세 가지 별개의 문제를, 출처 권위 문제를 해결하는 척하지 않으면서 해결했습니다.

쿠키는 화자가 아니라 언어의 이름이다

RFC 1048은 처음 네 옥텟을 네트워크 바이트 순서로 10진수99.130.83.99, 즉 16진수63.82.53.63으로 설정합니다. 문서의 표현은 정확합니다. 매직 쿠키는 뒤따르는 데이터를 해석할 모드를 식별한다는 것입니다.

이는 표현(representation)에 관한 주장입니다. 프로그램이 쿠키를 보면 사설 벤더 레이아웃 대신 RFC 1048의 파싱 규칙을 적용할 수 있습니다. 이 바이트들은 제조사를 식별하지 않고, BOOTP 서버를 인증하지 않고, 릴레이가 패킷을 보존했다는 증명도, 광고된 라우터가 정당하다는 증명도 제공하지 않습니다. 같은 네 개의 공개 옥텟을 보낼 수 있는 누구나 동일한 통론적 주장을 할 수 있습니다.

BOOTP에는 다른 연관성 필드도 있었습니다. 트랜잭션 ID는 클라이언트가 응답을 미처리 요청과 연관 짓는 데 도움을 주었고, 주소들과 하드웨어 주소는 교환을 전달하고 인식하는 데 도움을 주었습니다. 이런 메커니즘은 “이 패킷은 어떤 시도된 교환과 닮았는가?”라는 질문에 답합니다. 매직 쿠키를 비밀로 만들거나 응답을 서명된 진술로 만들지는 않습니다.

이 구분은 이후 운영상 긴급해졌습니다.RFC 1542는 BOOTP를 본질적으로 불안전한 프로토콜로 규정하며, 무단 서버가 거짓 IP, 라우터, 도메인 네임 서버 정보를 공급할 수 있다고 경고했습니다. 이 위험은 문법이 실패해서 생긴 것이 아닙니다. 파싱과 권위는 서로 다른 통제라는 점에서 비롯됩니다. 거짓 게이트웨이도 흠잡을 데 없는 태그와 길이 필드로 인코딩될 수 있습니다.

길이 필드 덕분에 낯선 옵션도 생존할 수 있었다

쿠키 다음의 일반적인 RFC 1048 옵션은 1옥텟 태그, 1옥텟 길이, 그리고 그 길이만큼의 값 옥텟으로 이루어집니다. 길이에는 태그와 길이 자체는 포함되지 않습니다. 여러 옥텟으로 된 수량은 인터넷 네트워크 바이트 순서를 따릅니다.

이 작은 관례는 낡은 클라이언트에게 낯선 것에 대한 규율된 대응 방식을 제공합니다. 태그를 알아보면 길이를 확인하고 값을 해석합니다. 태그를 알아보지 못하면 선언된 길이만큼 전진하여 다음 하위 필드를 시도합니다. 알 수 없는 항목은 여전히 알 수 없지만, 그 뒤에 오는 모든 것의 프레이밍을 망가뜨릴 필요는 없습니다.

이는 무지를 제한한다는 점에서 강력한 호환성 형태입니다. 파서가 이미 이해하는 옵션에 도달하기 위해 미래의 모든 옵션 목록을 갖출 필요는 없습니다. 발신자도 일반 필드가 등록될 때마다 완전히 새로운 패킷 버전을 협상할 필요가 없습니다. 형식 진화가 점진적으로 이루어질 수 있습니다.

다만 이 보장은 좁습니다. 길이는 값이 어디서 끝나는지 말할 뿐, 그 값이 무엇을 의미하는지는 말하지 않습니다. 사이트별 태그는 외부 구현이 안전하게 건너뛸 수 있으면서도 오직 로컬 합의 아래에서만 의미를 가집니다. 그럴듯한 길이를 가진 알려진 태그도 여전히 잘못된 주소를 운반할 수 있습니다. 올바르게 전진하는 파서가 보여주는 것은 구현이 건전할 경우의 메모리 안전성뿐이며, 어떤 네트워크적 진실도 입증하지 않습니다.

RFC 1084와RFC 1497은 이 핵심 배치를 유지한 채 옵션 카탈로그를 이후에 개정했습니다. 프레이밍의 지속은 유용한 호환성 접점의 역사적 증거입니다. 그러나 모든 배포가 모든 옵션을 똑같이 이해했다는 증거는 아닙니다.

Pad와 End는 문법의 제어 평면에 속한다

두 개의 태그 값은 길이를 수반하지 않습니다. Pad, 태그 0은 1옥텟을 차지하며 뒤따르는 내용을 정렬하거나 미사용 공간을 소비할 수 있습니다. End, 태그 255 역시 1옥텟을 차지하며 옵션 시퀀스가 끝났음을 선언하고, 남은 바이트는 0으로 채웁니다.

이 예외들은 길이가 0인 평범한 데이터가 아닙니다. 바이트 스트림을 어떻게 순회할지 통제합니다. Pad를 마치 다음 옥텟에 길이가 있는 것처럼 다루면 파서가 어긋나고, End 이후의 바이트를 새 옵션으로 다루면 패딩이 날조된 구성으로 변합니다. 상호운용성은 길이를 어떻게 읽는지 만큼이나 언제 길이를 읽지 말아야 하는지 아는 데 달려 있습니다.

순서도 의존성을 운반할 수 있습니다. RFC 1048은 서브넷 마스크와 게이트웨이가 함께 나타날 경우 서브넷 마스크가 먼저 와야 한다고 규정합니다. 클라이언트는 어떤 목적지와 게이트웨이가 로컬인지 판단하려면 마스크가 필요합니다. 옵션들은 순서가 항상 무관한 자루가 아닙니다. 프레이밍과 순서가 함께 사용 가능한 기록을 표현합니다.

일반적 교훈은 TLV 형식이 자동으로 진화 문제를 해결한다는 것이 아닙니다. 형식은 자신의 예외, 종료 규칙, 순서 의존성, 실패 동작을 명시해야 합니다. 그렇지 않으면 길이 필드는 단지 모호성을 패킷 경계에서 구현 내부로 옮길 뿐입니다.

64옥텟은 확장성을 선택의 문제로 만들었다

쿠키는 어떤 옵션도 나타나기 전에 필드 전체 64옥텟 중 4옥텟을 소비합니다. 이후 모든 일반 옵션은 태그와 길이에 2옥텟을 씁니다. IPv4 주소는 4옥텟이 더 필요하고, 목록은 그 배수입니다. RFC 1048은 내용이 벤더 필드를 초과해서는 안 된다고 명시하며, 필수적이지 않은 데이터는 생략하거나 다른 서비스를 통해 발견하도록 권고합니다.

이 한계는 프로토콜의 정치를 형성했습니다. 일반 태그는 희소한 공유 식별자였으므로 널리 유용한 필드는 암묵적으로 주장하는 것이 아니라 등록되어야 했습니다. 태그 128부터 254까지는 사이트별로 남겨졌습니다. 이 구분은 로컬 실험을 허용했지만, 의미의 부담을 참여 사이트에 지웠습니다. 공유된 프레이밍이 사설 옵션을 전 세계적으로 이식 가능하게 만들지는 않았습니다.

등록은 공통 범위에서의 충돌을 줄였습니다. 그러나 특정 클라이언트가 어떤 옵션을 받아야 하는지, 누구의 데이터베이스 항목이 정확한지, 어떤 서비스가 처음 64옥텟 안에 자리할 자격이 있는지는 정하지 않았습니다. 그것들은 운영적 선택으로 남았습니다. 부트 서버 관리자는 로컬 테이블을 통제했고, 클라이언트 구현은 무엇을 요청하고 실행할지 통제했으며, 이후의 발견 서비스들이 맞지 않는 것들을 운반할 수 있었습니다.

고정 필드는 따라서 유용한 규율과 실질적인 락인 압력을 동시에 만들었습니다. 컴팩트한 초기 구성은 구현들이 하나의 공통 봉투로 수렴하도록 장려했습니다. 클라이언트와 서버가 태그 번호와 파싱 규칙에 의존하게 된 뒤에는 봉투를 바꾸는 일이 비쌌습니다. 이후의 사양은 문법 자체를 교체하는 것보다 카탈로그에 담긴 의미를 추가하는 쪽이 훨씬 쉬웠습니다.

효율적인 응답 하나가 여전히 틀릴 수 있었다

RFC 1048은 BOOTP의 중앙 관리 정보를 멀티캐스트나 기타 분산 방식에 의한 발견과 비교합니다. 응답이 클라이언트에게 필요한 모든 것을 담고 있다면 클라이언트는 로컬 테이블을 읽고 효율적으로 진행할 수 있습니다. 그러나 문서는 중앙 관리 정보가 불완전하거나 낡을 수도 있다고도 언급합니다.

이 구분이 중요한 이유는 중앙 통제가 흔히 인증으로 오해되기 때문입니다. BOOTP 데이터베이스를 편집할 수 있는 관리자는 그 데이터베이스가 말하는 내용에 대한 권한을 갖습니다. 그러나 그것이 최종 파일 서버의 신원이나 부트 이미지의 진본성을 자동으로 확립하지는 않습니다. RFC 1048은 BOOTP 데이터베이스만으로는 강력한 파일 서버 인증에 불충분하며, 그 문제는 서비스가 자기 수준에서 해결해야 한다고 말합니다.

따라서 성공적인 부트스트랩에는 적어도 네 개의 기록이 있습니다. 패킷이 지명된 문법 아래에서 파싱 가능하다는 기록, 응답이 요청과 연관된다는 기록, 구성된 값이 어떤 서버 경로에서 왔다는 기록, 그리고 이후의 서비스 트랜잭션이 자신만의 보안 및 응용 규칙 아래에서 성공한다는 기록입니다. 이 기록들을 “쿠키가 부트를 신뢰했다”로 묶어버리면 유용한 모든 경계가 지워집니다.

RFC 1542가 클라이언트에게 옵션을 하나도 보내지 않을 때에도 쿠키를 포함하도록 권고한 것은 이 분리를 특히 선명하게 드러냅니다. 그런 요청은 4바이트 쿠키, End 태그, 그리고 서버가 클라이언트가 기대하는 응답 형식을 알 수 있도록 하는 0바이트 패딩으로 구성됩니다. 이는 내용 이전에 표현을 협상합니다. 응답자를 신뢰할 비밀은 아무것도 운반하지 않습니다.

DHCP는 봉투를 물려받았지, 보증을 물려받은 게 아니다

RFC 1533은 DHCP 옵션을 동일한 BOOTP 벤더 확장 형식, 즉 태그·길이·값에 Pad와 End라는 1옥텟 예외를 두는 형식으로 정의했습니다. BOOTP 매직 쿠키, 네트워크 바이트 순서, 사이트별 범위는 그대로 유지되었습니다.RFC 2132는 이 계보 속에서 성숙한 DHCP 옵션 카탈로그를 이후에 문서화했습니다.

이는 문서화된 형식 계승이지, 1988년의 모든 BOOTP 네트워크에 이후의 DHCP 관행을 소급해 읽어도 된다는 허가가 아닙니다. 옵션 카탈로그는 커졌고, 메시지 사용과 운영 환경은 변했으며, 보안은 여전히 별개의 문제로 남았습니다. RFC 1533 자체가 보안 문제는 다루지 않는다고 밝힙니다. 내구성 있는 컨테이너는 첫 저자들이 열거한 것보다 많은 의미를 운반할 수 있지만, 출처 보증을 몰래 획득할 수는 없습니다.

따라서 RFC 1048의 더 깊은 역사적 성취는 절제입니다. 이른바 다른 기계들이 옵션이 어디서 시작하고 어디서 끝나는지, 이해할 수 없는 옵션을 어떻게 지나칠지 합의할 수 있을 만큼만 표준화했습니다. 공유 범위를 할당하고 로컬 범위를 보존했습니다. 엄격한 작은 봉투를 생산적으로 만들었습니다. 그리고 신원, 신선도, 권한 부여, 서비스 성공을 쿠키의 권위 밖에 남겨두었습니다.

근거의 출처와 한계

RFC 951은 원래의 BOOTP 교환, 64옥텟 벤더 필드, 매직 넘버 권고를 제공합니다.RFC 1048은 일반화된 쿠키와 태그 형식, 순서 및 할당 규칙, 고정 필드 한계, 중앙화된 데이터와 다른 발견 방식의 비교를 정의합니다.RFC 1084와RFC 1497은 이후의 BOOTP 개정을 기록합니다.RFC 1533,RFC 1542,RFC 2132는 DHCP 형식의 계보와 명시된 BOOTP 보안 경계를 보여줍니다.

이 문서들은 사양과 문서화된 설계 전환을 확립합니다. 그러나 역사적 배포 점유율을 측정하지 않고, 특정 네트워크의 구성을 식별하지 않으며, 모든 구현이 알 수 없는 태그를 안전하게 처리했다는 증명도, 오늘날 관측된 어떤 옵션 값이든 무단 서버가 아닌 승인된 서버에서 왔다는 증명도 제공하지 않습니다.