요약

  • RFC 3182는 RSVP 정책 데이터 안에 하나 이상의AUTH_DATA요소를 배치했다. 로케이터는 적용되는 정책을 가리켰고, 단순 이름, Kerberos 티켓 또는 인증서는 서로 다른 등급의 신원 증거를 제공했다. 그 어떤 것도 그 자체로 네트워크 자원을 부여하지 않았다.
  • 신원은 종단 간 불변하지 않았다. 유니캐스트 사용자 정책에서는 로케이터가 살아남는 동안 자격 증명이 현재 네트워크 노드로 바뀔 수 있었다. 멀티캐스트에서는 사용자 신원이 현재 노드의 신원이 되었고, 애플리케이션 신원은 첫 번째 요소 또는 정책 결정 지점이 선택한 요소가 될 수 있었다.
  • 성공적인 인증은 인가, 로컬 강제, 경로 전체의 예약, 패킷 처리 및 애플리케이션 결과와 구별된 채 남았다. 이후 RSVP 보안 분석은 이 경계를 명확히 하고 기밀성, 로밍 및 인가 공백을 드러냈다.

이름은 마침내 예약과 함께 이동할 수 있었다

RSVP는 비슷해 보이지만 서로 교환될 수 없는 두 가지 질문으로 시작했다. 노드가 예약을 위한 충분한 자원을 갖고 있는가? 이 요청자가 그 자원을 받을 자격이 있는가? RFC 2205는 전자를 입학 제어(admission control), 후자를 정책 제어(policy control)라고 불렀다. 둘 다 성공해야 했으며, 정책 자료는 그것을 운반하는 RSVP 기계장치에는 불투명하게 유지되었다.

2001년 10월에 Proposed Standard로 발표된 RFC 3182는 두 번째 질문을 위한 어휘를 제공했다. 이 문서는 인증 데이터를POLICY_DATA객체 안에 배치했다. 호스트는 PATH 또는 RESV 시그널링에 신원 자료를 첨부할 수 있었고, 라우터나 정책 서버는 그 자료를 검증하여 요청이 로컬 규칙을 충족하는지 판단할 수 있었다.

이 문서는 RFC 2752를 대체했다. 이것은 두 번째 배포 물결이 아니었다. 대체는 정책 요소 코드포인트 할당과 오류 필드의 폭을 바로잡은 것이다. 이후 Datatracker의 행정적 갱신 역시 메커니즘을 새로 만들지 않는다. 기록이 2026년에 갱신된 이유는 2026년 프로토콜 개정이 등장했기 때문이 아니라 검증된 정오표가 존재하기 때문이다.

그 정오표는 중요하다. 공표된 6.3절은 세션 키를 얻기 위해 Kerberos 티켓을 KDC로 보내야 한다고 말했다. 검증된 정오표 2958은 이 동작을 바로잡는다. 서버는 티켓에서 세션 키를 추출하여 사용자를 인증한다. 이 구별은 역사적 서술이 인정된 오류를 아키텍처로 둔갑시키는 것을 막는다.

로케이터는 규칙집으로 향하는 주소였다

인증 요소에는 두 가지 표준 신원 유형이 있었다. 사용자를 위한AUTH_USER와 애플리케이션을 위한AUTH_APP이다. 어느 요소 안에서든 속성들은 서로 다른 역할을 수행했다.

POLICY_LOCATOR는 입학 정책을 찾아내기 위한 식별 이름(distinguished name)을 실었다.CREDENTIAL은 식별자, Kerberos 티켓, X.509 인증서 또는 PGP 인증서를 실었다. 디지털 서명 속성은 앞선 인증 데이터를 묶을 수 있었다. 정책 오류 속성은 지원되지 않는 자격 증명 유형, 부족한 권한, 만기 또는 신원 변경 같은 이유를 반환할 수 있었다.

이 필드들은 단일 배지가 아니라 하나의 수열을 이루었다. 로케이터는 규칙을 어디서 찾을 수 있는지 대답했다. 자격 증명은 검증자가 검사할 수 있는 자료가 무엇인지 대답했다. 서명은 보호된 내용이 키 연산과 일치하는지 대답했다. 정책 결정 지점(PDP)은 여전히 정책을 선택하고 적용해야 했다. 정책 강제 지점(PEP)은 여전히 노드가 요청을 수락하거나 거부하게 만들어야 했다.

RFC 2753은 이 분할을 명확히 했다. PDP는 정책 결정을 내리고 디렉터리, 인증 시스템, 계정 또는 과금 데이터베이스를 참조할 수 있었다. PEP는 반환된 결정을 강제했다. 자원 가용성은 여전히 정책 승인을 받은 요청을 좌절시킬 수 있었다. 정책 객체가 없다고 해서 정책 평가를 우회해서는 안 되었다. 신원은 시간, 그룹, 요청 대역폭, 로컬 구성 및 행정적 합의와 함께 여러 입력 중 하나였다.

바로 여기서 상징적 해석이 위험해진다. 식별 이름은 구조화되어 있기 때문에 공식적처럼 보인다. 인증서는 서명되어 있기 때문에 권위적처럼 보인다. 그러나 어느 사실도 이 노드의 정책 아래에서 대역폭을 할당할 자격이 있는 사람이 누구인지는 밝히지 않는다. 권한은 책임 있는 결정자가 검증된 증거를 자신이 강제할 권한을 가진 규칙에 연결했을 때에만 개입했다.

세 가지 자격 증명이 하나의 보증 수준을 만들지는 않았다

가장 단순한 형식은 로그인 또는 애플리케이션 식별자를 단순 ASCII 또는 Unicode로 실었다. RFC 3182 자체가 경고하듯 이 방식에는 안전하게 인증될 수 있는 자격 증명이 없었고 본질적으로 덜 안전했다. 문서의vic.exe예제 같은 실행 파일 이름은 문자열을 서술했을 뿐이다. 측정된 바이너리, 게시자, 프로세스 소유자 또는 변조되지 않은 프로그램을 증명하지 않았다.

Kerberos는 다음 RSVP 노드 또는 그 정책 서버를 위한 서비스 티켓을 실었다. 호스트와 검증자는 Kerberos를 지원하고, 관련 다음 홉 또는 PDP 신원을 알아야 하며, 더 큰 영역(realm) 기계장치를 공유해야 했다. 티켓은 그 신뢰 체계 안에서의 인증을 지원할 수 있었다. 그러나 자원 정책, 현재 용량 또는 모든 이후 도메인이 존중해야 하는 보편적 자격을 실지 않았다.

공개 키 형식은 인증서와 디지털 서명을 실었다. 이는 보호된 개인 키, 신뢰할 수 있는 인증 기관, 인증서를 검증할 수 있는 검증자를 전제했다. 그 경우에도 성공한 서명은 특정 검증 문맥에서 키의 통제권을 확립했을 뿐이다. 인증서가 모든 로컬 정책 아래 여전히 수용 가능한지, 폐기 검사가 수행되었는지, 이름이 지정된 조직이 이 예약을 승인했는지, 요청된 애플리케이션이 실제로 트래픽을 보내는 프로세스인지는 증명하지 않았다.

RFC 4230은 나중에 비용과 결여된 문맥을 드러냈다. 모든 시그널링 메시지에 공개 키 신원을 넣는 것은 처리량과 대역폭 부담을 유발했다. 폐기 검사에는 더 많은 기계장치가 필요했다. Kerberos는 사용자 신원을 완전히 기밀로 만들지 않았다. 인증된 주체는 여전히 인가가 없을 수 있었다. 더 강한 자격 증명은 한 번의 영수증을 개선했을 뿐 체인을 무너뜨리지 않았다.

각 홉에서 봉투의 화자는 바뀔 수 있었다

RFC 3182에서 가장 계몽적인 부분은 인증서 구문이 아니었다. 메시지가 이동하는 동안 신원 데이터를 생성하는 규칙이었다.

유니캐스트 세션의 사용자 정책에서 사용자 정책 로케이터는 이전 홉에서 복사되었지만, 인증 자격 증명은 현재 네트워크 노드를 대표했다. 따라서 겉보기 주체와 현재 화자는 서로 다른 단계에서 올 수 있었다. 멀티캐스트 사용자 정책에서는 로케이터와 자격 증명 모두 현재 노드를 대표했다.

애플리케이션 신원은 다른 규칙을 따랐다. 유니캐스트에서는 이전 홉에서 복사될 수 있었다. 멀티캐스트에서는 애플리케이션 요소가 메시지의 첫 번째 요소이거나 PDP가 선택한 요소일 수 있었다. 결과적으로 살아남은 단일 애플리케이션 신원은 모든 기여자의 전수 조사가 아니었다. 그것은 순서 또는 정책 선택의 산출물이었다.

메시지는 여러 인증 요소를 포함할 수 있었다. 정책 인식 노드와 PDP는 정책 정보를 교체할 수도 있었다. 마지막AUTH_DATA값만 저장한 이후 관찰자는 그것이 호스트에서 시작되었는지, 더 이른 사용자 로케이터를 서술하는지, 현재 라우터를 인증하는지, 먼저 도착해서 살아남았는지, 정책 권위가 선택했는지 잃어버리게 된다.

이것이 반드시 손상은 아니었다. 아키텍처가 행정적 및 멀티캐스트 경계를 넘는 방식이었다. 그러나 정당한 변형에는 출처(provenance)가 필요하다. 기록에는 입력 요소, 출력 요소, 행위자, 신뢰 도메인, 결정, 보안 연관 및 변경 이유가 필요하다. 그러한 수훨이 없으면 "신원이 검증되었다"는 말은 안정된 주체를 갖지 못한다.

정책을 모르는 홉은 신원을 판단하지 않고 패킷을 실어 보낼 수 있었다

모든 RSVP 노드가 정책을 이해해야 하는 것은 아니었다. RFC 2753은 노드 중 일부에서만 정책 강제를 허용했고, 정책을 모르는 노드는 행정 도메인 안의 신뢰할 수 있는 정책 기능 노드에 의존했다. RFC 3182는 정책을 모르는 라우터가 정책 객체를 무시하고 처리를 계속할 수 있다고 말했다.

이 동작은 점진적 배포를 보존했다. 동시에 성공적인 통과가 증명하는 것을 한정했다. 메시지가 라우터를 지나갔다고 해서 그 라우터가 사용자, 인증서, 그룹 또는 자격을 평가했다는 뜻은 아니었다. 이후 예약 상태는 일부 홉에서 평가되지 않은 정책 객체와 공존할 수 있었다.

정책 기능 경계에서 PEP는 PDP에 결정을 요청하고 기다릴 수 있었다. 부정적 응답은 거부를 의미했다. 긍정적 응답은 정상적인 RSVP 처리가 계속되도록 허용했으며, 그 이후에도 모든 후속 노드에서의 용량, 스케줄러 설치, 데이터 평면 처리 또는 애플리케이션 수신을 보장하지 않았다.

따라서 이 프로토콜은 여러 종류의 침묵을 실었다. 정책을 모르는 노드는 데이터를 무시할 수 있었다. 정책 기능 노드는 승인할 수 있었다. 자원 제어기는 나중에 용량 부족으로 거부할 수 있었다. 하류 노드는 다른 정책을 적용할 수 있었다. 모든 오류 없는 통과를 하나의 인가 결과로 취급하면 RFC 3182가 의존한 아키텍처가 지워진다.

오류 코드는 불일치를 보존했지만 그 결과까지 보존하지는 않았다

정책 오류 객체는 자격 증명 유형이 지원되지 않는다는 것, 권한이 부족하다는 것, 자격 증명이 만료되었거나 신원이 변경되었다는 것을 말할 수 있었다. PDP가 요소를 검증할 수 없을 때는 강제 지점에 정책 제어 실패를 반환해야 했고, RSVP 오류 메시지에 더 자세한 내용을 추가해야 했다.

이 코드들은 실패를 신원-정책 경계 안에 유지했기 때문에 유용했다.EXPIRED_CREDENTIAL은 자원이 없다는 뜻이 아니었다.INSUFFICIENT_PRIVILEGES는 인증서 서명이 실패했다는 뜻이 아니었다.IDENTITY_CHANGED는 관련 주체가 세션 생성 시점에 동결된 것이 아니라 상태를 지닌 존재임을 인정했다.

그러나 반환된 오류는 자기 범위에서 멈췄다. 이전의 모든 예약 상태가 제거되었는지, 데이터 트래픽이 중단되었는지, 멀티캐스트 트리의 다른 지점이 같은 결과를 받았는지, 애플리케이션이 메시지를 보았는지, 이후 재시도가 바로잡힌 신원을 사용했는지 증명하지 않았다. 오류 영수증은 강제와 결과 관찰의 대체물로 쓰이는 것이 아니라 그것들과 연결되어야 했다.

현재 IANA RSVP Parameters 레지스트리는 여전히 기본POLICY_DATA클래스와 정책 제어 실패 값을 기록하고 있다. 그것은 조율된 번호 공간의 증거다. 구현 전수 조사, 각 인증 하위 유형이 여전히 배포되어 있다는 증명, 또는 특정 라우터가 그것에 따라 동작했다는 증거가 아니다.

무결성은 바이트를 보호했지 정당성을 보호하지 않았다

RFC 3182는 전체 RSVP 메시지에 무결성 보호가 없을 때 정책 객체에 대한 무결성 보호를 권고했다. 그 체계는 사용자에 대한 증거와 발신 노드에 대한 증거를 결합하여 자신의 보안 문맥 안에서 변조나 재생에 저항할 수 있었다.

RFC 4230은 나중에 이 범위를 더 정밀하게 그렸다. RSVP 무결성 객체는 더 큰 시그널링 메시지를 보호했고,POLICY_DATA안의 무결성 객체는 그 정책 컨테이너를 보호했다. 정책 인식 라우터나 PDP는 설계상 여전히 정책 자료를 수정할 수 있었다. 사용자 및 애플리케이션별 정보는 첫 홉 이후 누출될 수 있었다. 라우터 간 RSVP는 무결성은 제공했지만 일반적인 기밀성은 제공하지 않았다.

결과는 세 부분의 검증이다. 먼저 보호된 바이트가 살아남았는지 물어라. 다음으로 어떤 행위자가 관련 키 또는 티켓으로 인증되었는지 물어라. 마지막으로 그 행위자가 현재 정책 아래 권한을 갖고 있었는지 물어라. 처음 두 가지만이 암호학적 질문이다. 유효한 다이제스트는 정책이 공정한지, 최신인지, 합법적인지, 효과적인지 말해줄 수 없다.

도메인 간 사용은 이 공백을 더 예리하게 했다. RFC 2753은 공급자 경계에서 쌍방 합의와 정책 객체 재작성을 전제했다. RFC 4230은 로밍 정책을 결정하기에 충분한 표준화된 인가 데이터를 찾지 못했고, 로밍 환경에서 QoS 예약 인가에 대한 합의된 메커니즘도 없었다. 신원은 국경을 넘을 수 있었지만 위임은 로컬에 머물렀다.

역사적 교훈은 영수증 체인이었다

방어 가능한 기록은 주장된 사용자 또는 애플리케이션 신원으로 시작하여 원시 요소를 보존한다. 그다음 자격 증명 하위 유형, 인증서 또는 티켓 검증, 키와 영역 범위, 재생 및 무결성 문맥, 그리고 정확히 인증된 주체를 기록한다.

다음 기록은 "성공"이 아니다. 정책 로케이터, 정책 버전, 지배하는 행정 도메인, 다른 입력들과 PDP 결정이다. 그다음은 PEP 수신과 강제, 자원 가용성, 설치된 RSVP 상태, 홉별 계속 여부, 그리고 이후의 어떤 교체, 만기 또는 신원 변경이다.

이러한 제어 평면 영수증이 있은 후에야 관찰자는 스케줄러 상태, 패킷 처리, 경로 동작, 애플리케이션 관점의 결과를 덧붙여야 한다. 예약은 인가된 채 용량 때문에 실패할 수 있다. 로컬에 설치되고 다른 곳에서 실패할 수 있다. 경로에 존재하면서 애플리케이션은 쓸 수 없는 서비스를 받을 수 있다. 반대로 정책 오류는 트래픽이 멈췄음을 증명하지 않고도 정확할 수 있다.

멀티캐스트 지점에는 추가 장부가 필요하다. 모든 입력 애플리케이션 신원, 그 순서, 어떤 PDP가 생존자를 선택했는지, 어떤 기여자가 압축된 표현에서 사라졌는지. "첫 번째"는 위임이 아니고, "선택됨"은 모든 수신자나 발신자가 하나의 신원을 공유했다는 진술이 아니다.

Lu Heng의 상징적 계층과 실행 계층의 구별은 이 규율을 설명하는 데 도움이 되지만, RFC 저자들에 대한 주장이 아니라 편집적 렌즈이다. RFC 3182는 신원에게 패킷 안의 자리를 주었다. 실제로 작동하는 시스템은 여전히 누가 결정할 수 있는지, 결정이 어디에 적용되는지, 약속된 효과가 발생했는지 확립해야 했다. 이름은 그 체인을 통해서만 실행 가능해졌다. 결코 그 체인 자체가 되지 않았다.

출처와 한계

프로토콜 기록은RFC 3182 텍스트,RFC Editor 기록,IETF Datatracker 기록,Datatracker API 기록및검증된 기술 정오표 2958에 보존되어 있다. 바로잡힌 선행 문서 경계는RFC 2752에서 나온다.

제어 아키텍처와 보안 문맥은RFC 2205,RFC 2750,RFC 2753,RFC 2747,RFC 4230,RFC 4094및 이후의RFC 4923에서 나온다. 역사적 자격 증명 문맥은 인용된RFC 1510과RFC 2459에서 나온다. 현재 등록 상태는IANA RSVP Parameters 레지스트리이다.

상징, 권한, 실행의 분석적 구별은 Lu Heng의현실 계층과running-code 우선성에세이에서 영향을 받았다. 18개 출처 집합은 2026년 10월 2일 Asia/Shanghai 기준으로 고정되었다. 이 집합은 특정 구현, 운영자, 사용자, 애플리케이션, 예약, 공격, 배포, 상호운용성 결과, 트래픽 추적 또는 서비스 결과를 특정하지 않는다. Proposed Standard 지위, 등록된 값, 유효한 자격 증명, PDP 승인, 로컬 RSVP 상태는 각각 자기 계층만 확립한다.