요약

  • RFC 3320은 수신자에게 각 신호 메시지를 압축 해제하기 위한 경계가 설정된 가상 머신을 제공했으며, 여기에는 발신자가 압축 해제 프로그램을 함께 제공하는 메시지도 포함된다.
  • 성공적인 디코딩만으로 영구 상태 생성이 승인되지 않았다. 상태 생성이나 압축기 피드백 이전에 애플리케이션이 결과를 인증하고 유효한 컴파트먼트 식별자를 반환해야 했다.

압축은 메시지와 함께 프로그램도 옮겼다

2003년 1월, RFC 3320은 SIP와 RTSP 같은 애플리케이션을 위한 Signaling Compression(SigComp)을 기술했다. 그 전제는 단순히 프로토콜 설계자가 압축기를 골라 모든 엔드포인트에 설치할 수 있다는 것이 아니었다. 발신자는 압축 알고리즘을 선택할 수 있고, 필요하면 수신자의 Universal Decompressor Virtual Machine(UDVM)이 실행할 바이트코드를 포함할 수 있었다. 따라서 수신자는 유용한 새로운 압축 해제 동작을 수용하면서도, 그것이 호스트를 제한 없이 제어하는 것은 막을 방법이 필요했다.

이 설계는 이야기의 초점을 "압축이 몇 바이트를 절약했는가?"에서 "들어오는 메시지가 수신자에게 무엇을 하게 만들 수 있는가?"로 바꾸었다. 이 RFC는 SigComp가 실제로 어느 정도 배포되었는지, 실무에서 얼마나 많은 대역폭을 절약했는지는 규정하지 않는다. 그것이 명시하는 것은 프로토콜 경계다. 발신자는 제약된 계산에 영향을 줄 수 있지만, 수신자는 자원과 현재 메시지보다 오래 지속되는 상태에 대한 권한을 유지한다.

메시지마다 새로 설정되는 실행 경계

들어오는 각 SigComp 메시지는 별개의 UDVM 인스턴스를 시작한다. 이 머신에는 제한된 압축 해제 메모리가 주어지며, 엔드포인트는 최소 2,048바이트를 제공해야 한다. 또한 메시지 길이와 설정된cycles_per_bit에서 파생되는 명령어 예산을 가진다. n바이트 메시지의 최대치는(8*n + 1000) * cycles_per_bit이며, 이 매개변수의 최소값은 16이다. 이는 메시지별 한도다. 하나의 실행을 제약할 뿐, 엔드포인트 전체가 서비스 거부 공격에 면역이거나 호스트 전체 자원이 이 수식만으로 제한된다는 보장은 아니다.

새 인스턴스 규칙은 실패를 국지화한다는 점에서 역사적으로 중요하다. 한 메시지가 형식이 잘못되었거나 실행 허용치를 소진하더라도, 이후 메시지가 같은 가상 머신 상태 뒤에 자동으로 갇히는 것은 아니다. 이것은 패킷 스트림이 하나의 계속 커지는 디코더를 공유한다고 가정하는 것과 다르다. 프로토콜이 선택된 상태를 메시지 간에 공유할 수 있게 하더라도, 수신자는 의도적인 재시작 경계를 얻는다.

디코딩과 기억은 별개의 권한이다

SigComp는 임시 압축 해제 메모리와 컴파트먼트에 할당되는 상태 메모리를 구분한다. 컴파트먼트는 피어 또는 통신 컨텍스트에 연관된 애플리케이션 정의 그룹이며, 애플리케이션은 해당 컨텍스트가 끝나면 닫을 수 있다. 상태를 유지하지 않기로 선택한 엔드포인트는 상태 예산을 0으로 설정할 수 있다. 따라서 이 프로토콜은 지속성을 디코딩의 전제 조건으로 만들지 않고, 의도적으로 무상태인 압축을 허용한다.

더 미묘한 규칙은 압축 해제 이후에 나온다. 애플리케이션은 디코딩된 메시지를 받아 자신의 프로토콜과 컨텍스트에 맞는 인증을 적용할 수 있다. 메시지를 유효한 컴파트먼트 식별자와 연관시킬 의사가 있을 때에만, SigComp 계층은 그 컴파트먼트를 위한 새 상태를 생성하고 압축기에 피드백을 전달할 권한을 얻는다. 애플리케이션이 충분한 확신을 확립하지 못하면 유효한 컴파트먼트를 제공하지 않는다. 그러면 UDVM은 요청된 영구 상태를 저장하지도, 피드백을 전달하지도 않은 채 종료된다.

이 배치는 의미론적 결정을 압축 해제기 밖에 둔다. 가상 머신은 바이트열이 자원 규칙 하에서 디코딩되었음을 확립할 수 있지만, 그 결과 신호 메시지가 진짜인지, 기대한 대화에 속하는지, 이후 압축에 영향을 미쳐야 하는지는 확립할 수 없다. 그런 질문에 대해 더 많이 아는 쪽은 애플리케이션이며, 최종 결정권을 유지한다. RFC 4896은 이후 상태 생성과 인증의 경계를 명확히 하며, 디코더의 출력 자체가 신뢰 결정은 아니라는 점을 재확인했다.

기존 상태에는 다른 관문이 있다

시점 문제가 있다. 애플리케이션은 메시지를 인증하려면 그것을 먼저 디코딩해야 하는데, 압축 해제 자체가 이미 기존 상태의 이점을 누릴 수 있다는 것이다. SigComp는 기존 상태에 대한 접근을 애플리케이션의 압축 해제 후 결정과 별도로 처리한다. 상태 식별자는 상태 바이트의 해시에서 파생되므로, 상태를 지명하는 메시지는 수신자가 그 상태를 UDVM에 노출하기 전에 프로토콜의 식별자 검사를 통과해야 한다. 상태가 일단 제공되면, 새 상태를 유지할 수 있는지는 여전히 압축 해제 후 승인 규칙이 지배한다.

이 구분은 두 질문을 하나로 뭉개는 것을 피한다. "이 메시지가 이전에 수립된 압축 상태를 읽어도 되는가?"와 "이 디코딩된 메시지가 영구 상태를 생성하거나 갱신해도 되는가?"는 서로 다른 시점에서 서로 다른 근거를 사용한다. 이들을 혼동하면 보안 설계가 모순처럼 보일 수 있다. 압축 해제 전 접근은 디코딩이 진행되도록 제약되고, 압축 해제 후 지속성은 애플리케이션 수준의 확신을 기다린다.

이후 문서들이 인접한 공백을 메웠다

RFC 3321은 확장 동작과 확인(acknowledgment) 메커니즘을 추가했다. 신뢰할 수 없는 전송에서는 발신자가 수신자의 상태에 의존하기 전에 확인이 중요하다. RFC 4077은 압축 해제 실패를 보고하기 위한 부정 확인(negative acknowledgment)을 규정했다. RFC 5049는 SIP에 SigComp 요구 사항을 적용했으며, 여기에는 이 프레임워크를 사용하는 모든 애플리케이션에 일반화되어서는 안 되는 요구 사항이 포함되어 있다. RFC 4464는 사용자 안내서를, RFC 4465는 일련의 토터처 테스트를 제공했다. 이 문서들은 설계에 운영적 설명, 실패 보고, 애플리케이션별 프로파일이 필요했음을 보여준다. 그 자체로 채택이나 측정된 효과를 증명하지는 않는다.

RFC 3320의 지속적인 기여는 권한의 분리다. 메시지는 경계가 설정된 머신에게 자신을 디코딩하도록 요청할 수 있다. 그 의미가 이후 메시지에 영향을 미치는 기억이 될 만큼 신뢰할 수 있는지는 애플리케이션이 결정한다. 이 단계들을 분리해 두면 수신자의 자원 경계와 신뢰 경계가 드러나고, "압축이 해제되었다"가 조용히 "이제 우리가 그것을 기억한다"로 변하지 않는다.

출처