요약

  • RFC 3327에 따라 일부 프록시는 REGISTER 도중 Path URI를 선언할 수 있었고, 등록 서버는 이 순서 있는 벡터를 공개 주소–Contact 쌍과 함께 보존했으며, 이후 원 프록시가 후속 요청에서 이를 Route로 변환했다.
  • 이 벡터는 완전한 기록도 증거도 아니었다. 경유한 노드가 아무것도 선언하지 않을 수 있었고, 경유하지 않은 노드가 지정될 수도 있었으며, 등록 서버나 원 네트워크의 정책이 결과를 바꿀 수 있었다.

패킷은 도착했지만, 그 유용한 경로는 곧 사라질 예정이었다

이동 단말은 자신의 원 도메인에 안정적인 공개 주소와 현재 접속 지점을 서술하는 Contact를 갖고 등장한다. 등록 서버는 이 연관 관계를 검증한다. 그러나 Contact만으로는 접근 프록시, 방화벽 근처에 놓인 릴레이, 방문 네트워크를 반드시 거쳐야 한다는 뜻은 아니다. 직접 연결 시도는 필수 정책을 우회하거나 단말에 도달하지 못할 수 있다.

역설은 분명하다. REGISTER는 바로 필요한 중개 노드들을 방금 통과해 왔지만, SIP는 등록 서버가 이 서열을 등록 정보와 함께 보존하도록 강제하지 않았다. 이동 경로의 관찰은 해당 트랜잭션의 현재에 속했고, 라우팅 결정은 미래의 어느 호출에 속했다. 새로운 데이터가 없다면 전자의 성공이 후자를 보장하지 않았다.

Path가 이 간극을 메웠다. REGISTER를 처리하던 프록시는 이후 이 Contact로 향하는 요청에 자신이 사용되기를 원하는 URI를 추가할 수 있었다. 여러 프록시는 순서 있는 목록을 형성했다. 등록 서버는 이 목록을 사용자 주소와 정확한 Contact에 연결해 성공 응답에 되돌려 보냈다. 나중에 원 도메인의 프록시는 이 값들을 Route 집합에 넣어 선택된 Contact로 요청을 보냈다.

Contact에의 부착은 위험한 추상화를 막았다. 하나의 주소에 전화기, 컴퓨터, 게이트웨이가 각기 다른 토폴로지 뒤에서 등록할 수 있었다. 전화기의 경로가 컴퓨터의 경로가 되어서는 안 된다. 갱신은 벡터를 교체할 수 있었고, 등록 만료는 그와 함께 벡터를 만료시켜야 했다. Contact와 Path는 하나의 사실이 되지 않으면서 하나의 수명 단위를 이루었다.

RFC 3263은 DNS를 통해 도메인의 SIP 서버를 찾아냈다. 이 탐색은 서비스로 이어졌지만, 원 도메인과 특정 단말 사이의 임시 이동 경로를 서술하지는 않았다. RFC 3327은 그보다 뒤이고 더 휘발적인 층을 다루었다.

내일을 위한 선언은 어제의 기록이 아니었다

Path라는 단어는 지나치게 문자적인 해석을 유도한다. URI 목록은 REGISTER가 남긴 흔적처럼 보인다. 그러나 표준은 경유한 프록시가 목록에 자신을 등록하지 않는 것을 허용했다. 미래 트래픽을 받아야 할 다른 노드의 URI를 삽입하는 것도 허용했다. 등록 서버는 자신의 정책에 따라 벡터를 변환할 수 있었다. 호출 시점에 원 프록시는 벡터를 기존 Route나 기본 경로와 결합할 수도 있었다.

Path는 이렇게 처방이었다. 다음 요청이 어디로 향해야 하는지를 말했지, 이전 요청이 실제로 어디를 지났는지를 반드시 말하지 않았다. 캡처는 관찰된 메시지에 어떤 값들이 존재했다는 것만 증명한다. 목록의 완전성, 각 노드의 과거 경유, 같은 순서의 미래 실행을 증명하지는 않는다.

이 한계는 네 가지 구별되는 기록을 요구한다. 실제로 관찰된 REGISTER의 이동 경로, 선언된 벡터, 등록 서버가 수용하거나 변환한 버전, 그리고 이후 요청에서 관찰된 Route. 이들을 합치면 더 단순하지만 틀린 역사가 만들어진다.

Via는 다른 질문에 답한다. 응답을 트랜잭션을 따라 어떻게 되돌릴 것인가. Record-Route는 대화를 여는 요청으로부터 대화의 경로를 만든다. Path는 아직 존재하지 않는 대화를 위해 등록 과정에서 학습된다. RFC 3608이 정의한 Service-Route는 단말에게 자신의 미래 발신 요청 경로를 알려준다. Path는 원 측에 Contact로 돌아오는 방법을 알려준다. 비슷한 이름이 상호 교체 가능한 권한을 주지는 않는다.

반환은 삽입을 보이게 했지만 인증하지는 않았다

REGISTER의 성공 응답은 보존된 Path 값을 되돌려 보냈다. 일반 단말은 이를 무시할 수 있었고 자신의 Route로 사용하지 않았다. 그럼에도 검토할 수는 있었다. 예상 밖의 프록시의 존재는 어느 행위자가 방금 미래 호출 경로에 영구적으로 끼어들었을 수 있음을 드러낼 수 있었다.

위험은 등록 트랜잭션을 넘었다. 자신의 URI를 추가할 수 있는 악의적 프록시는 링크가 유지되는 동안 Contact로 향하는 모든 후속 요청을 가로챌 수 있었다. 요소 삭제는 검증을 우회할 수 있고, 순서 변경은 첫 관찰 지점을 옮길 수 있으며, URI의 은밀한 변환은 경로를 무효로 만들 수 있었다.

표준은 적절한 무결성과 상호 인증을 권고했다. 이 보호들은 한정된 질문에만 답한다. 식별된 피어들 사이에서 보호된 바이트가 바뀌었는가? 프록시가 정직한지, 가용한지, 다른 노드를 대변할 자격이 있는지는 증명하지 않는다. 목록의 반환은 등록 서버가 되돌려 보낸 것을 증명할 뿐, 세계가 참으로 만드는 것을 증명하지 않는다.

단말에 대한 경고는 시사적이다. 단말이 스스로 Path를 삽입하면, 프록시들은 그 URI를 피어의 지시로 해석해 나중에 단말에게 프록시 역할을 요구할 수 있었다. 올바른 문법만으로는 부족하다. 작성자의 신원과 역할이 의미론의 일부다.

이후 확장들은 환경을 구체화했다

2002년 12월에 발행된 RFC 3327은 이후 RFC 5626으로 갱신되었다. SIP Outbound는 네트워크 경계 뒤 단말과 에지 릴레이에서 유지되는 흐름에 더 풍부한 틀을 제공했다. 이 진화는 Path를 포렌식 기록으로 바꾸지 않았다. 등록, 흐름, 라우팅의 협력을 구체화했다.

RFC 5627은 단일 흐름을 넘어 단말 인스턴스를 식별하는 GRUU를 도입했다. RFC 3680은 등록 이벤트 알림을 정의했다. RFC 5922는 SIP 도메인 인증서를 규율했다. IANA 등록소는 표준화된 매개변수와 이름을 수록한다. 각각은 인접한 조각이며, 어느 것도 경로의 배치, 채택 또는 진위를 도출하게 해주지 않는다.

RFC 3327의 지속적 기여는 공개 신원, 현재 위치자, 전달 제약, 관찰된 역사를 분리한 것이다. 네트워크는 첫 둘을 알면서도 전달 방법을 몰랐다. 셋째를 알면서 넷째를 갖지 못했다. Path는 이 결핍을 보이게 만들었다 — 단, 라우팅 의도를 과거의 증거로 바꾸지 않는다면.

출처