メインコンテンツまでスキップ

5. アソシエーション初期化 (Association Initialization)

5.1. アソシエーションの正常な確立 (Normal Establishment of an Association)​

別のSCTPエンドポイントZとのアソシエーションを確立したいSCTPエンドポイントAは、INITチャンクを送信しなければなりません (MUST)。Zがアソシエーションを受け入れる場合、INIT ACKチャンクを含むパケットで応答しなければなりません (MUST)。アソシエーションの確立については、以下でさらに説明します。

5.1.1. ストリームパラメータの処理 (Handle Stream Parameters)​

INITまたはINIT ACKチャンクで、送信者はオプション/可変長パラメータセクションに「サポートされるアドレスタイプ (Supported Address Types)」パラメータを含めることで、受信者に特定のアドレスタイプの使用を要求してもよい (MAY)。送信者は、すべてのアドレスタイプをサポートしていない場合、またはピアに特定のアドレスタイプの使用を制限したい場合、このパラメータを含めるべきです (SHOULD)。

INITまたはINIT ACKの受信者は、リストで指定されたアドレスタイプのいずれか、またはINITまたはINIT ACKが送信されたアドレスタイプ（リストにない場合）を使用して、その後のすべての通信を送信しなければなりません (MUST)。

受信者が送信者が期待するアドレスタイプをサポートしていない、または使用を避けたい場合、アソシエーションを中止してもよく (MAY)、「サポートされないアドレスタイプ (Unsupported Address Type)」エラーを送信すべきです (SHOULD)。

注意： INITまたはINIT ACKに「サポートされるアドレスタイプ (Supported Address Types)」パラメータが含まれている場合、受信者は、パラメータで見つかったアドレスタイプのいずれか、またはINIT/INIT ACKが送信されたアドレスタイプのみを使用しなければなりません (MUST)。受信者が他のアドレスタイプを使用できる場合でも同様です。

INITまたはINIT ACKチャンクで、送信者は、含まれる「アウトバウンドストリーム数 (Number of Outbound Streams, OS)」および「インバウンドストリーム数 (Number of Inbound Streams, MIS)」パラメータを通じて、そのストリーム容量を示します。

受信者は、送信者がINITまたはINIT ACKのOSフィールドで示す値を、自身のインバウンドストリームの最大数（つまり、受信者のMIS）として使用すべきです (SHOULD)。送信者は、MISパラメータを使用して、ピアがユーザーメッセージを送信できるストリームの数を制限します。

INITまたはINIT ACKで、送信者のアウトバウンドストリーム数 (OS) およびインバウンドストリーム数 (MIS) は0であってはなりません (MUST NOT)。

受信者がOSまたはMIS値が0のINITまたはINIT ACKを受信した場合、受信者はアソシエーションを中止し、ABORTチャンクを送信すべきであり (SHOULD)、「無効な必須パラメータ (Invalid Mandatory Parameter)」エラーを報告してもよい (MAY)。

受信者はまた、INITまたはINIT ACKのMISフィールドで受信した実際の数にアウトバウンドストリームの使用を制限しなければなりません (MUST)。言い換えると、アソシエーションが確立された後、エンドポイントは以下を使用します：

ユーザーメッセージを送信するアウトバウンドストリーム数 = 
    minimum(ローカルOS, ピアのMIS)

ユーザーメッセージを受信できるインバウンドストリーム数 = 
    minimum(ローカルMIS, ピアのOS)

5.1.2. アドレスパラメータの処理 (Handle Address Parameters)​

初期化中（INITまたはINIT ACKを送信する前）、送信者は、オプションのIPv4アドレスパラメータおよび/またはIPv6アドレスパラメータを使用して、INITまたはINIT ACKにすべてのアドレスを含めるべきです (SHOULD)。このオプションパラメータの省略は、エンドポイントが1つのアドレスのみを持ち、それがINITまたはINIT ACKを送信するために使用されるソースアドレスであることを示します。

INITチャンクを送信する前に、エンドポイントは常にCOOKIE-WAIT状態に入るべきです (SHOULD)。

注意： INITチャンクにアドレスがないことは、送信エンドポイントが他のアドレスを受け入れないという意味ではありません。逆に、アドレスがないことは、送信者がリッスンされることを望まないが、ピアのアドレスのいずれかから送信されたメッセージを受け入れることを示します。

受信者が、送信者がINITまたはINIT ACKで提供したアドレスタイプのいずれもサポートしていない場合、アソシエーションを中止すべきであり (SHOULD)、「サポートされないアドレスタイプ (Unsupported Address Type)」エラー原因を送信してもよい (MAY)。

INITまたはINIT ACKの受信者は、提供されたすべてのアドレス情報（IPヘッダー、IPv4アドレスパラメータ、および/またはIPv6アドレスパラメータから取得した方法にかかわらず）を記録し、その情報を使用してトランスポートアドレスセットを決定しなければなりません (MUST)。

送信者が「ホスト名アドレス (Host Name Address)」パラメータを含む場合、受信者は直ちにABORTチャンクを送信しなければならず (MUST)、「解決不可能なアドレス (Unresolvable Address)」エラー原因を含めてもよい (MAY)。

注意：「ホスト名アドレス (Host Name Address)」パラメータの使用は非推奨です。受信者は、INITまたはINIT ACKの「ホスト名アドレス (Host Name Address)」パラメータを無視しなければならず (MUST)、応答としてABORTチャンクを送信すべきです (SHOULD)。

INIT ACKを送信するエンドポイントは、State Cookieを作成し、INIT ACKのState Cookieパラメータに配置すべきです。State Cookieの使用については、セクション5.1.3を参照してください。

State Cookieには、次の最小限の必要な情報を含める必要があります：

  • 受信したINITチャンクから取得した情報（Initiate Tagおよびオプション/可変長パラメータを含む）
  • State Cookieが作成された時刻
  • ライフスパン（Cookieが有効な時間）
  • State Cookieの完全性と真正性を認証する方法（例：メッセージ認証コード (MAC)）

実装注記： State Cookieを使用して、確立されるアソシエーションの状態に関する追加情報を保存できます。これにより、エンドポイントはアソシエーション確立中にリソース（TCB）の割り当てを延期できます。この最適化は「Cookieアプローチ (Cookie Approach)」と呼ばれ、単純なサービス拒否攻撃を防ぐことができます。

INIT ACKを送信する実装は、攻撃者が有効なState Cookieを推測することを防ぐために、State Cookieを十分に堅牢に保護すべきです (SHOULD)。推奨される技術は、State Cookieに以下を含めることです：

  • ランダムなnonce（アソシエーションインスタンスごとに一意）
  • タイムスタンプ
  • ピアのソースアドレス
  • ピアのソースポート
  • ローカルの宛先アドレス
  • ローカルの宛先ポート
  • 上記のすべてのフィールドをカバーするMAC

このMACを作成するために必要な秘密鍵は、SCTPスタックが初期化されるときに作成されるべきであり (SHOULD)、定期的に更新されるべきです。この鍵は、通信当事者以外の誰にとっても秘密に保たれなければなりません (MUST)。

INIT ACKのState Cookieパラメータにこれらの値を含めることで、COOKIE ECHOチャンクで返されたState Cookieの検証が可能になります。検証プロセスはセクション5.1.4で説明されています。

さらに、送信者は、COOKIE ECHOで返されたCookieの検証とアソシエーションの確立に必要な、State Cookieを生成するために必要な他のデータを含めてもよい (MAY)。

注意： MAC計算には、リプレイされたCookieがサービス拒否攻撃ツールとして使用されないように、タイムスタンプを含めなければなりません (MUST)。

エンドポイントがCOOKIE ECHOチャンクでState Cookieを受信した場合、次に従ってそのCookieを検証しなければなりません (MUST)：

  1. State CookieのMACが有効であることを確認します。MACが無効な場合、パケットを静かに破棄します。

  2. State Cookieが古くなっていないことを確認します。State Cookieが古くなっている場合、エンドポイントは原因コードを「Stale Cookie Error」に設定したERRORチャンクを送信し (SHOULD)、パケットを静かに破棄します。State Cookieの古さは、「Cookie Preservative (Cookie保存)」パラメータを使用して調整できます。セクション5.1.3を参照してください。

  3. ソースアドレスとポート番号がState Cookieに保存されている値と一致することを確認します。一致しない場合、パケットを静かに破棄します。

State Cookieが有効な場合、エンドポイントはそのピアへのアソシエーションを作成し (SHOULD)、送信者にCOOKIE ACKチャンクを送信します。その後、エンドポイントはそのアソシエーションをESTABLISHED状態に移行させるべきです。

実装は、以下に説明する技術または同等の技術を使用して、State Cookieの完全性と真正性を保護しなければなりません (MUST)。

推奨される技術は、State Cookieにメッセージ認証コード (MAC) を含めることです。MACは、送信者には知られているが、潜在的な攻撃者には知られていない秘密鍵を使用して計算されるべきです (SHOULD)。

MACアルゴリズムは、[RFC2104]および[RFC3174]で定義されているHMAC-SHA-1と少なくとも同じくらい安全であるべきです (SHOULD)。

MACを作成および検証するには、秘密鍵が必要です。この秘密鍵は定期的に変更されるべきであり (SHOULD)（例えば、数時間ごと）、攻撃者が正当なトラフィックを観察することで鍵を推測する能力を制限します。

秘密鍵の変更中、実装は古い鍵を一定期間（少なくともCookieライフスパンの2倍）保持し (SHOULD)、古い鍵で作成されたCookieを検証できるようにします。

5.1.6. 正常なアソシエーション確立の例 (An Example of Normal Association Establishment)​

最も単純なケースでは、エンドポイントAがエンドポイントZへのアソシエーションの開始を要求する正常なアソシエーション確立は次のようになります：

エンドポイントA                                エンドポイントZ

INIT    ----[State Cookieを含むINIT ACK]----->
        <----------[COOKIE ECHO]-------------
        ----------[COOKIE ACK]--------------->

この時点で、アソシエーションは両端でESTABLISHED状態になります。

詳細な手順：

A) エンドポイントAはエンドポイントZにINITチャンクを送信し、アソシエーションを確立したいという意向を示します。INITチャンクで、エンドポイントAは、検証タグ（Zから送信されるすべてのパケットで使用される）、サポートする初期TSN、アウトバウンドストリームの数(OS)、インバウンドストリームの最大数(MIS)、およびその他のトランスポートアドレス（ある場合）を提供しなければなりません (MUST)。

B) INITを受信すると、エンドポイントZはINIT ACKチャンクで応答すべきです (SHOULD)。INIT ACKで、Zは検証タグ、初期TSN、OS、MIS、およびトランスポートアドレス（該当する場合）を提供しなければなりません (MUST)。さらに、ZはState Cookieを作成し、INIT ACKに含めなければなりません (MUST)。

C) State Cookieを含むINIT ACKを受信すると、エンドポイントAはCOOKIE ECHOチャンクで応答すべきです (SHOULD)。COOKIE ECHOチャンクは、INIT ACKで受信したState Cookieを含まなければなりません (MUST)。さらに、エンドポイントAは、COOKIE ECHOとバンドルされたユーザーデータを同じパケットで送信してもよい (MAY)。

D) COOKIE ECHOを受信すると、エンドポイントZはState Cookieを検証します。有効な場合、Zはアソシエーションを作成し、COOKIE ACKチャンクで応答します。さらに、Zは、COOKIE ACKとバンドルされたユーザーデータを同じパケットで送信してもよい (MAY)。

E) COOKIE ACKを受信すると、エンドポイントAはアソシエーション状態をCOOKIE-ECHOEDからESTABLISHEDに変更します。Aは、確立されたアソシエーションでユーザーデータを送受信できるようになりました。

アソシエーションのライフタイム中のいつでも、エンドポイントは予期しないまたは重複したINIT、INIT ACK、COOKIE ECHO、またはCOOKIE ACKチャンクを受信する可能性があります。このセクションでは、これらのチャンクの処理方法について説明します。

5.2.1. CLOSED状態でのINIT受信 (INIT Received in CLOSED State)​

エンドポイントがCLOSED状態でINITチャンクを受信した場合、セクション5.1で説明されているように、INIT ACKで応答すべきです (SHOULD)。

エンドポイントがCOOKIE-WAITまたはCOOKIE-ECHOED状態でINITチャンクを受信し、そのInitiate Tagが記録されたピア検証タグと一致しない場合、エンドポイントは古いTCB（ある場合）を破棄し (SHOULD)、新しいINITチャンクに対してINIT ACKで応答すべきです。

エンドポイントがCOOKIE-WAITまたはCOOKIE-ECHOED状態でINITチャンクを受信し、そのInitiate Tagが記録されたピア検証タグと一致する場合、エンドポイントはINIT ACKで応答すべきですが (SHOULD)、状態を変更しません。この状況は、ピアがINIT ACKを受信しなかった、または失った場合に発生する可能性があります。

エンドポイントがCLOSED状態またはCOOKIE-WAIT状態でINIT ACKを受信した場合、エンドポイントはABORTチャンクを送信すべきであり (SHOULD)、「Out of the Blue」エラー原因を含めてもよい (MAY)（セクション3.3.10を参照）。

エンドポイントがCOOKIE-WAIT状態でINIT ACKを受信し、そのInitiate Tagフィールドが自身のTagと一致しない場合、エンドポイントはCLOSED状態に入り (SHOULD)、TCBを破棄し、ABORTチャンクを送信します。

このセクションでは、エンドポイントがCLOSEDおよびCOOKIE-ECHOED状態以外の状態でCOOKIE ECHOチャンクを受信した場合の動作について説明します。

実装注記： エンドポイントは、通常、ピアの再送信またはネットワーク遅延により、アソシエーションのライフタイム中のいつでもCOOKIE ECHOチャンクを受信する可能性があります。

エンドポイントがCOOKIE ECHOチャンクを受信し、同じアソシエーションのTCBが存在する場合、エンドポイントは次のいずれかのアクションに従って処理すべきです (SHOULD)：

A) 現在の状態がESTABLISHEDの場合、エンドポイントはCOOKIE ECHOを静かに破棄すべきです (SHOULD)。または、ピアがCOOKIE ECHOに誤った検証タグを含めている場合、エンドポイントはABORTチャンクを送信してもよい (MAY)。

B) 現在の状態がSHUTDOWN-ACK-SENTの場合、エンドポイントはCOOKIE ECHOを静かに破棄すべきです (SHOULD)。

他のすべてのケースでは、エンドポイントは、セクション5.2.4のルールに従って、COOKIE ECHOを新しいアソシエーションを確立する試みとして扱うべきですが (SHOULD)、既存のTCBの情報を使用してアソシエーション確立プロセスを最適化します。

エンドポイントがCOOKIE-ECHOED状態以外でCOOKIE ACKチャンクを受信した場合、そのチャンクを静かに破棄すべきです (SHOULD)。

エンドポイントがCOOKIE ECHOチャンクを送信した後に「Stale Cookie」エラー原因を含むERRORチャンクを受信し、エンドポイントがCOOKIE-ECHOED状態にある場合、エンドポイントは新しいINITチャンクを使用してアソシエーションを再確立しようと試みてもよい (MAY)。

エンドポイントが再試行することを選択した場合、新しいINITチャンクに「Cookie Preservative」パラメータを含めるべきであり (SHOULD)、その値は受信した「Stale Cookie」エラーで指定されたMeasure of Stalenessフィールドに設定します。

エンドポイントが再試行しないことを選択した場合、CLOSED状態に入り (SHOULD)、上位層に問題を報告すべきです。

5.3. その他の初期化問題 (Other Initialization Issues)​

5.3.1. デフォルトポートの選択 (Selection of Default Port)​

SCTPエンドポイントは、UDPポート9899（SCTP over UDPカプセル化のデフォルトポート）へのSCTPパケットの受信と送信をサポートすべきです (SHOULD)。

5.3.2. IPv4/IPv6共存 (IPv4/IPv6 Coexistence)​

実装は、[RFC4213]で推奨されているように、IPv4とIPv6アドレスの両方の使用をサポートすべきです (SHOULD)。

5.3.3. SCTPアソシエーション識別子 (SCTP Association Identifier)​

各SCTPアソシエーションは、一対の検証タグによって一意に識別されます：

  • ローカル検証タグ（ピアがそのINITまたはINIT ACKで提供）
  • ピアの検証タグ（ローカルのINITまたはINIT ACKで送信）

このTagのペアは、受信したSCTPパケットを多重分離するために使用されます。

5.4. パス検証 (Path Verification)​

通常の動作中、SCTPエンドポイントは、ピアのパスの到達可能性を検証するためにハートビートメカニズムを使用しなければなりません (MUST)。

初期化中（INIT ACKを送信した後）、エンドポイントは、INITまたはINIT ACKで受信したすべてのアドレスが到達可能であることを検証するためにハートビートメカニズムを使用すべきです (SHOULD)。

この検証は、アソシエーションがESTABLISHED状態に入った直後に開始されるべきです (SHOULD)。

実装注記： エンドポイントが複数のIPアドレスを含むINITまたはINIT ACKを受信した場合、各アドレスにHEARTBEATを送信することで、提供されたすべてのアドレスを検証しようと試みるべきです (SHOULD)。

検証プロセス中にHEARTBEATに応答しなかったアドレスは、非アクティブとしてマークされるべきであり (SHOULD)、後でアクティブであることが証明されない限り（HEARTBEATまたはデータ転送を通じて）、通常のデータ転送で使用されるべきではありません。

本章続く...

第5章のより詳細な内容（特定のエラー処理、タイムアウトメカニズム、セキュリティ関連の考慮事項を含む）については、RFC 4960の完全なテキストを参照してください。

に最終更新