8. 故障管理 (Fault Management)
SCTPは、ネットワーク障害状況下で信頼性の高い通信を確保するための堅牢な故障検出および回復メカニズムを提供します。
8.1. エンドポイント故障検出 (Endpoint Failure Detection)
SCTPエンドポイントは、ピアエンドポイントの完全な故障を検出できなければなりません。
8.1.1. アソシエーションレベルのエラーカウント
各SCTPアソシエーションはアソシエーションエラーカウンター (Association Error Counter) を維持します:
- いずれかの宛先アドレスのエラーカウンターが閾値に達すると、アソシエーションは失敗したと見なされます
- アソシエーションが失敗した場合、エンドポイントは上位層に報告すべきです (SHOULD)
8.1.2. エンドポイント故障条件
エンドポイントは次の場合に故障したと見なされます:
- すべての宛先アドレスが非アクティブとしてマークされている
- アソシエーションの総エラー数がAssociation.Max.Retrans閾値を超えている
Association.Max.Retrans: 推奨デフォルト値は10回の再送信試行です。
8.1.3. 故障応答
エンドポイント故障が検出されたとき:
1. そのエンドポイントへの新しいデータの送信を停止
2. 上位層にアソシエーション失敗を報告
3. 伝送制御ブロック (TCB) を破棄
4. オプション: ピアに通知するためにABORTチャンクを送信
8.2. パス故障検出 (Path Failure Detection)
SCTPは、他のアクティブなパスが利用可能である場合、個々のトランスポートパスの故障を検出でき、アソシエーション全体に影響を与えません。
8.2.1. パスレベルのエラーカウント
各宛先トランスポートアドレスはパスエラーカウンター (Path Error Counter) を維持します:
- 各送信失敗時に増加
- 送信成功またはHEARTBEAT ACK受信時に0にリセット
8.2.2. パス故障条件
パスは次の場合に非アクティブと見なされます:
- 連続送信失敗がPath.Max.Retransに達する
- 連続HEARTBEAT失敗がPath.Max.Retransに達する
Path.Max.Retrans: 推奨デフォルト値は5回の再送信試行です。
8.2.3. パス状態管理
パス状態:
- Active (アクティブ): パスはデータ送信に利用可能
- Inactive (非アクティブ): パスは一時的に利用不可
状態遷移:
Active -> Inactive:
- 連続失敗がPath.Max.Retransに達する
Inactive -> Active:
- 有効なHEARTBEAT ACKを受信
- データ送信成功と確認受信
8.2.4. パス故障応答
プライマリパスが失敗したとき:
1. パスを非アクティブとしてマーク
2. 別のアクティブなパスを新しいプライマリパスとして選択
3. 新しいプライマリパスで未確認データを再送信
4. HEARTBEATで非アクティブなパスの監視を継続
パス選択戦略:
- 最近成功したパスを優先
- パスのRTTと輻輳状態を考慮
- 利用可能なパスをラウンドロビンで負荷分散(オプション)
8.3. パスハートビート (Path Heartbeat)
HEARTBEATメカニズムは、宛先アドレスの到達可能性を能動的に監視するために使用されます。
8.3.1. HEARTBEAT送信ルール
エンドポイントは、各アイドル宛先アドレスに定期的にHEARTBEATを送信すべきです (SHOULD):
送信間隔:
HB.interval: 推奨デフォルト値は30秒
設定可能範囲: 1秒から数分
送信条件:
- 宛先がHB.interval時間内にデータを送信していない
- 宛先が現在非アクティブ(より頻繁にプローブ)
HEARTBEAT内容:
- Heartbeat Information TLV
- 送信タイムスタンプ
- 宛先アドレス情報
- オプション: 送信者固有情報
8.3.2. HEARTBEAT ACK処理
HEARTBEAT ACKを受信したとき:
1. RTT = 現在時刻 - 送信タイムスタンプ を計算
2. 宛先のRTOを更新
3. 宛先をアクティブとしてマーク
4. パスエラーカウンターを0にリセット
8.3.3. HEARTBEATタイムアウト処理
HEARTBEAT ACKがRTO時間内に受信されない場合:
1. パスエラーカウンターを増加
2. エラー数 >= Path.Max.Retrans の場合:
- パスを非アクティブとしてマーク
- プライマリパスの場合、新しいプライマリパスを選択
3. 回復をプローブするためにHEARTBEATの送信を継続
8.3.4. オンデマンドHEARTBEAT
定期的なHEARTBEATに加えて、エンドポイントは次の場合にオンデマンドHEARTBEATを送信してもよい (MAY):
- ピアのアドレスリスト更新を受信
- パスが回復した可能性がある場合
- パスの到達可能性を迅速に検証する必要がある場合
8.4. "意外な"パケットの処理 (Handle "Out of the Blue" Packets)
"意外な"パケットとは、エンドポイントが受信した既知のアソシエーションと一致しないSCTPパケットです。
8.4.1. 意外なパケットの識別
パケットは次の場合に"意外"と見なされます:
- Verification Tagが既存のアソシエーションと一致しない
- 送信元アドレスとポートが既存のアソシエーションと一致しない
- 宛先ポートは一致するが、対応するアソシエーションが存在しない
8.4.2. 意外なパケット処理ルール
意外なINITチャンクを受信:
エンドポイントがCLOSED状態の場合:
- 通常の手順でINIT ACKを応答
それ以外:
- 静かに破棄
意外なABORTチャンクを受信:
- Tビットが設定されている場合:
- パケットのVerification Tagを使用して検証
- 静かに受け入れて破棄
意外なSHUTDOWN COMPLETEチャンクを受信:
- Tビットを検証
- 静かに受け入れて破棄
その他の意外なチャンクを受信:
ABORTチャンクを送信:
- 受信パケットのVerification Tagを使用
- エラー原因: "Out of the Blue"
- Tビットを1に設定
8.4.3. ABORTチャンク送信
意外なパケットに応答してABORTチャンクを送信する場合:
ABORTチャンク形式:
- Chunk Type = 6
- T bit = 1
- Verification Tag = 受信パケットのVerification Tag
- エラー原因 (オプション):
- Cause Code = 8 (Out of the Blue)
- Cause Info = 受信パケットのコピー
8.4.4. セキュリティ考慮事項
意外なパケットを処理する際のセキュリティ対策:
- 応答レート制限: 増幅攻撃に利用されることを回避
- 送信元アドレス検証: 可能な場合、送信元アドレスの正当性を検証
- 異常のログ記録: 頻繁な意外なパケットを記録して攻撃を検出
8.5. 検証タグの使用 (Verification Tag Usage)
Verification Tagは、パケット偽造とインジェクション攻撃を防ぐためのSCTPの重要なセキュリティメカニズムです。
8.5.1. 検証タグルール
パケット送信時:
- INITまたはINIT ACKでピアが提供したInitiate Tagを使用
- SCTP共通ヘッダーのVerification Tagフィールドとして
パケット受信時:
- Verification Tagがローカルタグと一致するか検証
- 一致しない場合はパケットを破棄(特殊ケースを除く)
特殊ケース:
- INITチャンク: Verification Tagは0でなければならない
- SHUTDOWN COMPLETEとABORT: どのTagを使用するかを示すためにTビットを使用可能
8.5.2. 検証失敗処理
不正なVerification Tagを持つパケットを受信したとき:
INITチャンクの場合:
- セクション8.4に従って処理
Tビット=1のABORTまたはSHUTDOWN COMPLETEの場合:
- パケットのVerification Tagを使用して検証
それ以外:
- パケットを静かに破棄
- 応答を送信しない
まとめ
SCTPの故障管理メカニズムは、多層的な堅牢性を提供します:
- マルチパス冗長性: 単一パスの故障がアソシエーションに影響しない
- 能動的監視: HEARTBEATメカニズムがパス状態を能動的に検出
- 高速フェイルオーバー: 故障検出後、即座にバックアップパスに切り替え
- 防御メカニズム: Verification Tagが悪意のあるパケットインジェクションを防止
- 設定可能な閾値: ネットワーク条件に基づいて故障検出感度の調整を許可
これらのメカニズムが共同で、さまざまなネットワーク障害シナリオ下でのSCTPの信頼性と可用性を確保します。