SIP (RFC 3261) におけるNAT越えの課題と対策

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

SIP (RFC 3261) におけるNAT越えの課題と対策

背景

Session Initiation Protocol (SIP) は、RFC 3261（2002年6月発行）で定義された、マルチメディア通信セッションの確立、変更、終了に使用されるシグナリングプロトコルです。VoIP (Voice over IP) やWebRTCなどのリアルタイム通信において中心的な役割を担っています。しかし、SIPが設計された当初から、ネットワークアドレス変換（NAT）デバイスの普及は予見されていましたが、その複雑な相互作用が大きな課題となってきました。

NATは、プライベートネットワーク内の複数のデバイスが単一のグローバルIPアドレスを共有することを可能にし、IPアドレスの枯渇問題の緩和とセキュリティの向上に貢献しました。しかし、SIPメッセージのペイロードやヘッダに含まれるIPアドレスやポート番号が、NATデバイスによるアドレス変換の対象外であるため、通信の確立が困難になるという問題を引き起こします。

設計目標

SIPにおけるNAT越えの設計目標は、以下の点を達成することです。

  1. エンドツーエンドの接続性確保: プライベートネットワーク内のSIPクライアントが、インターネット上の他のSIPエンティティと安定して通信できること。

  2. メディアパスの確立: SIPシグナリングだけでなく、RTP/RTCPなどのリアルタイムメディアトラフィックもNATを越えて適切にルーティングされること。

  3. NATタイプへの対応: フルコーンNATからシンメトリックNATまで、様々なNATタイプに対応できる柔軟性を持つこと。

  4. スケーラビリティと信頼性: 多数の同時接続を処理し、ネットワーク障害に対する回復力があること。

  5. セキュリティの確保: NAT越えソリューションが新たなセキュリティ脆弱性をもたらさないこと。

詳細

NATの挙動とSIPへの影響

NATは、IPパケットのヘッダにある送信元/宛先IPアドレスとポート番号を書き換えますが、SIPメッセージやSDP (Session Description Protocol) のペイロードに含まれるIPアドレスやポート番号は変更しません。このミスマッチがSIP通信における主要な課題です。

SIPメッセージ内のIPアドレス/ポート情報:

SIP Via ヘッダ (Request):
  Via: SIP/2.0/UDP [クライアント公開IP]:[公開ポート];rport;branch=...

  # NATによって変更される可能性のあるSource IP/Port。


  # rportパラメータはRFC 3581 (2003年8月発行) で定義され、応答パケットを


  # 同じポートに返すよう指示し、NATマッピングの維持に貢献する。

SIP Contact ヘッダ (Registration/Request):
  Contact: <sip:[クライアント公開IP]:[公開ポート]>

  # 登録や後続リクエストの宛先を示す。クライアントが自身のIP/ポートをAdvertizeする。


  # クライアントがプライベートIPを通知すると、外部からの到達が不可能になる。

SDP (Session Description Protocol) Content:
  c= (connection information):
    c=IN IP4 [メディアソースIP]

    # メディアフローの宛先IPアドレス。SDPにはメディアセッションの属性が含まれる。

  m= (media description):
    m=[メディアタイプ] [メディアポート] [プロトコル] [フォーマット]

    # メディアフローの宛先ポート。

これらのヘッダやSDP内のプライベートIPアドレスが外部に通知されると、そのアドレスへの到達が不可能となり、通話の確立やメディアの送受信が失敗します。

NATタイプとSIPトラバーサルの困難さ:

graph TD
    subgraph "NAT Types("Client behind NAT")"
        N0["Full-Cone NAT"] --> N1["Restricted-Cone NAT"]
        N1 --> N2["Port-Restricted Cone NAT"]
        N2 --> N3["Symmetric NAT"]
    end

    subgraph "NAT Traversal Solutions"
        S1["STUN(\"RFC 5389\")"]
        S2["TURN(\"RFC 5766\")"]
        S3["ICE(\"RFC 8445\")"]
        S4["SIP ALG"]
        S5["SBC(\"Session Border Controller\")"]
    end

    subgraph "SIP Protocol Elements"
        P1["SIP User Agent"]
        P2["SIP Proxy/Registrar"]
    end

    N0 -- "Works well with" --> S1
    N1 -- "Requires" --> S1
    N2 -- "Requires" --> S1
    N3 -- "STUN alone insufficient, requires" --> S2
    S1 -- "Provides server-reflexive candidates to" --> S3
    S2 -- "Provides relayed candidates to" --> S3
    S3 -- "Combines S1 & S2 for optimal path selection" --> P1
    S4 -- "Attempts to modify SIP/SDP in NAT, often problematic" --> N0
    S5 -- "Terminates/proxies SIP, handles NAT for all types" --> P1
    P1 -- "Registers with" --> P2
    P2 -- "Manages presence for" --> P1

  • フルコーンNAT: 内部IPアドレスとポートから外部へのマッピングが確立されると、どの外部IP/ポートからでも、このマッピング宛てのパケットは内部に転送されます。STUNで公開IP/ポートを発見すれば比較的容易。

  • アドレス制限コーンNAT: フルコーンNATと同様ですが、外部からの受信は、過去にパケットを送信したことがある外部IPアドレスからのみ許可されます。

  • ポート制限コーンNAT: アドレス制限コーンNATに加えて、外部からの受信は、過去にパケットを送信したことがある外部IPアドレスとポート番号の組み合わせからのみ許可されます。

  • シンメトリックNAT: 内部IPアドレスとポートから外部IPアドレスとポートへのマッピングが、宛先ごとに異なります。このタイプのNATでは、STUNで発見した公開IP/ポートは特定の宛先に対してのみ有効であり、他の宛先には使えません。このため、STUNだけでは解決が困難です。

主要な対策プロトコル

  1. STUN (Session Traversal Utilities for NAT)

    • 概要: RFC 5389（2008年10月発行）で定義。クライアントが自身の背後にあるNATのタイプと、NATによって割り当てられた自身の公開IPアドレスおよびポート番号を検出するためのプロトコルです。

    • 仕組み: クライアントはSTUNサーバーにBinding Requestを送信します。STUNサーバーはそのリクエストを受け取った際の送信元IPアドレスとポートを応答メッセージに含めて返します。クライアントはこの情報を使って、自身の外部アドレスを知ることができます。

    • 限界: シンメトリックNATでは、STUNサーバーとの通信で得られた公開IP/ポートが、実際のピアとの通信では異なるマッピングになるため、STUN単独ではNAT越えが困難です。

  2. TURN (Traversal Using Relays around NAT)

    • 概要: RFC 5766（2010年4月発行）で定義。STUNの拡張であり、シンメトリックNATなどSTUNでは解決できない困難なNAT環境において、メディアトラフィックをリレーするためのプロトコルです。

    • 仕組み: クライアントはTURNサーバーにAllocate Requestを送信し、TURNサーバー上にリレーアドレス（公開IPとポート）を確保します。クライアントはこのリレーアドレスをピアに通知し、ピアはリレーアドレス宛にパケットを送信します。TURNサーバーはこれらのパケットをクライアントに転送します。

    • 利点と欠点: あらゆるNATタイプに対応可能ですが、すべてのメディアトラフィックがTURNサーバーを経由するため、サーバーのリソース消費が増大し、遅延が発生する可能性があります。

  3. ICE (Interactive Connectivity Establishment)

    • 概要: RFC 8445（2018年8月発行）で定義。STUNとTURNを統合したフレームワークであり、P2P（Peer-to-Peer）通信において、利用可能な様々なIPアドレスとポートの候補（Candidate）を収集し、最適な通信経路を確立するためのプロトコルです。

    • 仕組み:

      1. 候補収集: UAは自身のホストIP/ポート、STUNを使ってNAT越えで得られるサーバーリフレキシブIP/ポート、TURNを使って得られるリレーIP/ポートなど、複数の候補を収集します。

      2. 候補交換: SIPのSDPを通じて、これらの候補リストをピアと交換します。

      3. 接続性チェック: ピア間でSTUNのConnectivity Checkを用いて、各候補ペア間の接続性を確認します。

      4. 最適なパス選択: 接続性チェックの結果に基づいて、最も直接的で効率的な通信パスを選択します。

    • 利点: ほとんどすべてのNAT環境に対応し、可能な限り直接的なP2P通信を試み、困難な場合はTURNリレーにフォールバックします。

ICEを用いたSIP通信フロー (シグナリングおよびメディアパス確立):

sequenceDiagram
    participant "UA_A as SIP User Agent A (Behind NAT)"
    participant "STUN_S as STUN Server"
    participant "TURN_S as TURN Server"
    participant "UA_B as SIP User Agent B (Public IP)"
    participant "SIP_P as SIP Proxy"

    UA_A ->> STUN_S: STUN Binding Request (Discover Public IP/Port)
    STUN_S -->> UA_A: STUN Binding Response (Server-Reflexive Candidate A)

    UA_A ->> TURN_S: TURN Allocate Request (Request Relay Port)
    TURN_S -->> UA_A: TURN Allocate Response (Relayed Candidate A)

    UA_A ->> SIP_P: SIP REGISTER
    SIP_P -->> UA_A: SIP 200 OK

    UA_B ->> SIP_P: SIP INVITE
    SIP_P ->> UA_A: SIP INVITE (SDP contains ICE Candidates A: Host, Server-Reflexive, Relayed)

    UA_B ->> STUN_S: STUN Binding Request (Discover Public IP/Port)
    STUN_S -->> UA_B: STUN Binding Response (Server-Reflexive Candidate B)

    UA_A ->> UA_B: SIP 200 OK (SDP contains ICE Candidates B: Host, Server-Reflexive, Relayed)

    Note over UA_A,UA_B: ICE Candidate Exchange Complete.
    Note over UA_A,UA_B: Start ICE Connectivity Checks (STUN binding requests/responses).
    UA_A ->> UA_B: STUN Connectivity Check (Candidate Pair 1)
    UA_B ->> UA_A: STUN Connectivity Check Response (Candidate Pair 1)
    UA_A ->> UA_B: STUN Connectivity Check (Candidate Pair 2, via TURN_S if direct fails)
    TURN_S -->> UA_B: STUN Connectivity Check (Relayed by TURN_S)
    UA_B ->> UA_A: STUN Connectivity Check Response (Candidate Pair 2, via TURN_S)
    Note over UA_A,UA_B: ICE agent determines best candidate pair.
    UA_A ->> UA_B: RTP/RTCP (Using best candidate pair directly or via TURN relay)
    UA_B ->> UA_A: RTP/RTCP

  1. SIP ALG (Application Layer Gateway)

    • 概要: 一部のNAT/ルーターに組み込まれている機能で、SIPメッセージを検査し、ペイロード内のプライベートIPアドレスやポート番号を公開IP/ポートに自動的に書き換えます。

    • 問題点: 実装が不完全な場合が多く、SIPの複雑なダイアログや暗号化されたSIP（SIPS）に対応できない、または誤動作することが頻繁にあります。そのため、通常は推奨されず、無効化することが推奨されます。

  2. SBC (Session Border Controller)

    • 概要: 専用のネットワークデバイスで、SIPセッションの境界（サービスプロバイダと顧客ネットワーク間など）に配置されます。NAT越え、セキュリティ、QoS、プロトコル変換など、多岐にわたる機能を提供します。

    • 仕組み: SBCはSIPシグナリングとメディアパスの両方を終端（またはプロキシ）し、自身の公開IPアドレスとポートをクライアントに提供します。クライアントから見るとSBCが対向ピアとして振る舞うため、NAT越えが容易になります。

既存プロトコルとの比較

特徴 STUN (RFC 5389) TURN (RFC 5766) ICE (RFC 8445) SIP ALG SBC
機能 クライアントの公開IP/ポート検出 メディアトラフィックのリレー 最適なP2P通信パスの確立 (STUN/TURNの統合) SIPペイロードの書き換え SIP終端/プロキシ、NAT越え、セキュリティ、QoSなど
NAT対応 フルコーン、アドレス/ポート制限コーン すべてのNATタイプ (特にシンメトリックNAT) すべてのNATタイプ 部分的 (不完全な実装が多い) すべてのNATタイプ
トラフィックパス シグナリングのみ (直接通信を支援) すべてのメディアトラフィックをリレー 可能であれば直接P2P、困難な場合はTURNリレーにフォールバック SIPメッセージのみ、メディアは直接 シグナリングとメディアの両方を処理/終端
オーバーヘッド 低 高 (サーバー負荷、遅延増大) 中 (初期接続確立時の遅延) ルーター/ファイアウォールのCPU負荷 高 (専用ハードウェア/VMが必要)
推奨度 ICEの一部として、または単純なNAT環境で ICEの一部として、または困難なNAT環境で最後の手段として VoIP/WebRTCの標準的なNAT越え手法 非推奨、通常は無効化が望ましい 大規模エンタープライズ/サービスプロバイダで必須

相互運用

SIPのNAT越えソリューションは、SIP (RFC 3261) 自体とは独立して機能するプロトコル（STUN, TURN, ICE）として設計されており、SIPの拡張としてSDPを介して情報を交換します。

  • SIPとSTUN/TURN/ICE: SIP UAはSTUN/TURNサーバーと通信して候補アドレスを収集し、これらの候補情報をSDPの属性としてSIP INVITEメッセージに含めて交換します。ICEはこれらの候補アドレスを元に接続性チェックを行い、最適なメディアパスを決定します。

  • SBCの役割: SBCは、異なるネットワーク間のSIP相互運用において重要な役割を果たします。特に、NATを越えるだけでなく、異なるSIPドメイン間のルーティング、プロトコル変換、セキュリティポリシーの適用など、多様な機能を統合的に提供し、複雑なネットワーク環境でのSIP通信を可能にします。

セキュリティ考慮

NAT越えのメカニズムを導入する際には、新たなセキュリティリスクを考慮し、適切に対処する必要があります。

  • リプレイ攻撃: STUN/TURN/ICEのメッセージは、タイムスタンプやワンタイムnonce、メッセージインテグリティチェック（HMAC）などのメカニズムを用いて保護され、リプレイ攻撃を防ぎます。特にTURNでは、Allocation Requestに対する認証情報（ユーザ名とパスワード）が求められます。

  • ダウングレード攻撃: ICEでは、ピアが提供する候補リストの中から最もセキュリティレベルの高い（例: SRTPを利用する）候補を優先的に選択するよう実装することが重要です。シグナリング段階で強制的に暗号化を要求する（例: SIP over TLS）ことで、ダウングレード攻撃を防ぎます。

  • キー更新: SRTP（Secure Real-time Transport Protocol）などのメディア暗号化プロトコルを使用する場合、鍵の定期的な更新メカニズムを組み込むことが推奨されます。DTLS-SRTPは、鍵交換と鍵更新を自動的に処理します。

  • 0-RTTの再送リスク: SIPの初期INVITEでは、セッション情報が交換される前にメディアが送信される0-RTTメカニズムはありません。ICEの接続性チェックは、通信確立前に安全なチェックが行われるため、0-RTTのような初期の再送リスクは直接的には発生しません。ただし、SDP情報が適切に保護されていない場合、中間者攻撃によって改ざんされるリスクは考慮すべきです。

  • DoS/DDoS攻撃: STUN/TURNサーバーは、多数のリクエストやメディアトラフィックを処理するため、DoS/DDoS攻撃の標的となりやすいです。適切なレート制限、認証、フィルタリングメカニズムを導入し、サーバーを保護する必要があります。

実装メモ

プロトコルを実装するネットワークエンジニアとして、以下の点に注意が必要です。

  • MTU/Path MTU: SIPやRTPパケットが大きすぎると、IPフラグメンテーションが発生し、NAT越えやファイアウォール通過が困難になることがあります。Path MTU Discovery (PMTUD) を利用するか、MSS (Maximum Segment Size) を調整して、パケットサイズがPath MTUを超えないように設計することが重要です。特に、TURNでリレーされるパケットは、UDPヘッダの追加オーバーヘッドも考慮する必要があります。

  • HOL blocking (Head-of-Line Blocking) 回避: TCPベースのSIPトラフィックにおいて、パケットロスが発生すると、その後のパケットがすべてブロックされるHOL Blockingのリスクがあります。これはUDPベースのRTPでは問題になりませんが、SIPシグナリングがTCPを使用する場合に考慮が必要です。WebRTCではHTTP/2のマルチプレクシングがこの問題の緩和に寄与しますが、SIPではTCPセッションごとにHOL blockingが発生しえます。

  • キュー制御と優先度: リアルタイム通信であるVoIPの品質を確保するためには、ルーターやスイッチでSIPシグナリングとRTPメディアトラフィックに適切なQoS (Quality of Service) を設定し、高優先度のキューに入れることが不可欠です。DiffServ (DSCP) やIEEE 802.1p (CoS) を活用し、パケットロス、ジッタ、遅延を最小限に抑えるように設計します。

  • NATマッピングの維持: クライアント側のNATマッピングがタイムアウトしないよう、定期的にSTUN Binding RequestやSIP REGISTERメッセージを送信するなどのキープアライブメカニズムを実装することが重要です。RFC 3581のrportパラメータも、NATマッピング維持に役立ちます。

まとめ

SIP (RFC 3261) におけるNAT越えは、VoIP通信を世界中で利用可能にするための中心的な課題であり続けています。この課題に対し、STUN (RFC 5389) による公開IP/ポートの検出、TURN (RFC 5766) によるメディアリレー、そしてこれらを統合したICE (RFC 8445) による最適な通信経路の確立といったプロトコル群が進化してきました。

SIP ALGのような安易な解決策は信頼性に欠け、Session Border Controller (SBC) は大規模な展開において包括的なソリューションを提供します。実装においては、MTU、HOL Blocking、QoSなどのネットワーク層の課題への配慮に加え、リプレイ攻撃やダウングレード攻撃といったセキュリティ脅威に対する防御策を講じることが不可欠です。これらの対策を適切に組み合わせることで、SIPベースのリアルタイム通信は、様々なネットワーク環境下でも高品質かつ安全に提供されることが期待されます。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました