RFC 9293: トランスミッション・コントロール・プロトコル(TCP) ─ Part2

(続く)

3.10. イベント処理

このセクションで説明する処理は、可能な実装の一例である。他の実装では処理シーケンスがわずかに異なるかも知れないが、このセクションの実装とは細部が異なるだけで、本質的な違いはない。

TCPエンドポイントの活動は、イベントへの応答として特徴付けることができる。発生するイベントは、ユーザ・コール、セグメントの到着、タイムアウトの3つのカテゴリに分類できる。このセクションでは、TCPエンドポイントが各イベントに応答して実行する処理について説明する。多くの場合、必要な処理はコネクションの状態に依存する。

• 発生するイベント:
  • ユーザ・コール
    • OPEN
    • SEND
    • RECEIVE
    • CLOSE
    • ABORT
    • STATUS
  • セグメントの到着
    • SEGMENT ARRIVES
  • タイムアウト
    • USER TIMEOUT
    • RETRANSMISSION TIMEOUT
    • TIME-WAIT TIMEOUT

TCP/ユーザ・インタフェースのモデルは、ユーザコマンドは即時返答を受け取り、場合によってはイベントまたは疑似割り込みによって遅延応答を受け取るというものである。以下の説明では、「シグナル」という用語は、遅延応答を引き起こすことを意味する。

本文書では、エラー応答は文字列で識別する。例えば、存在しないコネクションを参照するユーザ・コマンドは、「error: connection not open」を受け取る。

シーケンス番号、確認応答番号、ウィンドウなどに関するすべての算術演算は、modulo $2^{32}$(シーケンス番号領域のサイズ)であることに留意する。また、「=<」は(modulo $2^{32}$)以下を意味することにも留意する。

受信セグメントの処理について考える自然な方法は、最初に適切なシーケンス番号かどうか(つまり、そのコンテンツがシーケンス番号領域内で予想される「受信ウィンドウ」の範囲内にあること)が検証され、その後、一般的にシーケンス番号順にキューに入れられ、処理されると考える。

あるセグメントが既に受信した他のセグメントと重複している場合、新しいデータだけが含まれるようにセグメントを再構築し、一貫性が保たれるようにヘッダ・フィールドを調整する。

状態の変更が指定されていない場合、TCPコネクションは同じ状態のままであることに留意する。

3.10.1. Openコール

CLOSED状態(つまり、TCBが存在しない)

• コネクション状態情報を保持するために新しいトランスミッション・コントロール・ブロック(TCB)を作成する。ローカル・ソケット識別子、リモート・ソケット、Diffservフィールド、セキュリティ/コンパートメント、ユーザ・タイムアウト情報を入力する。リモートソケットの一部はパッシブOPENでは指定されない可能性があり、着信SYNセグメントのパラメータで埋める必要があることに留意する。要求されたセキュリティとDiffserv値がこのユーザに許可されているか確認する: もし、許可されていなければ、「error: Diffserv value not allowed」または「error: security/compartment not allowed」を返す。パッシブの場合、LISTEN状態になって戻る。アクティブでリモート・ソケットが指定されていない場合、「error: remote socket unspecified」を返し、アクティブでリモート・ソケットが指定されている場合、SYNセグメントを発行する。初期送信シーケンス番号(ISS)を選択する。<SEQ=ISS><CTL=SYN>形式のSYNセグメントが送信する。SND.UNAをISSに、SND.NXTをISS+1に設定し、SYN-SENT状態に入り、戻る。
• 呼び出し元が指定されたローカル・ソケットにアクセスできない場合、「error: connection illegal for this process」を返す。新しいコネクションを作成する余地がない場合、「error: insufficient resources」を返す。

LISTEN状態

• OPENコールがアクティブで、リモートソケットが指定されている場合は、コネクションをパッシブからアクティブに変更し、ISSを選択する。SYNセグメントを送信し、SND.UNAをISSに、SND.NXTをISS+1に設定する。SYN-SENT状態に入る。SENDに関連付けられたデータは、SYNセグメントと一緒に送信されるか、ESTABLISHED状態に入った後に送信キューに入れられる。コマンドで要求された場合、緊急ビットはこのコマンドの結果として送信されるデータセグメントと一緒に送信しなければならない。リクエストをキューに入れる余地がない場合、「error: insufficient resources」と応答する。リモートソケットが指定されていなかった場合、「error: remote socket unspecified」を返す。

SYN送信状態

SYN受信状態

ESTABLISHED状態

FIN-WAIT-1状態

FIN-WAIT-2状態

CLOSE-WAIT状態

CLOSING状態

LAST-ACK状態

TIME-WAIT状態

• 「error: connection already exists」を返す。

3.10.2. SENDコール

CLOSED状態 (つまり、TCBが存在しない)

• ユーザがそのようなコネクションにアクセスできない場合、「error: connection illegal for this process」を返す。
• それ以外の場合、「error: connection does not exist」を返す。

LISTEN状態

• リモート・ソケットが指定されている場合は、コネクションをパッシブからアクティブに変更し、ISSを選択する。SYNセグメントを送信し、SND.UNAをISSに、SND.NXTをISS+1に設定する。SYN-SENT状態に入る。SENDに関連付けられたデータは、SYNセグメントと一緒に送信されるか、ESTABLISHED状態に入った後に送信のキューに入れられる。コマンドで緊急ビットが要求された場合、このコマンドの結果として送信されるデータセグメントと一緒に送信しなければならない。リクエストをキューに入れる余裕がない場合、「error: insufficient resources」と応答する。リモート・ソケットが指定されていない場合、「error: remote socket unspecified」を返す。

SYN-SENT状態

SYN-RECEIVED状態

• ESTABLISHED状態に入った後、送信のためにデータをキューに入れる。キューに入れる余裕がない場合は、「error: insufficient resources」と応答する。

ESTABLISHED状態

CLOSE-WAIT状態

• バッファをセグメント化し、ピギーバックされた確認応答(確認応答値 = RCV.NXT)と一緒に送信する。このバッファを記憶するのに十分な領域がない場合、単に「error: insufficient resources」を返す。
• URGENTフラグが設定されている場合、SND.UP <- SND.NXTとし、送信セグメントに緊急ポインタを設定する。

FIN-WAIT-1 状態

FIN-WAIT-2 状態

CLOSING状態

LAST-ACK状態

TIME-WAIT状態

• 「error: connection closing」を返し、リクエストを処理しない。

3.10.3. RECEIVEコール

CLOSED状態 (つまり、TCBが存在しない)

• ユーザがそのようなコネクションにアクセスできない場合、「error: connection illegal for this process」を返す。
• それ以外の場合、「error: connection does not exist」を返す。

LISTEN状態

SYN-SENT状態

SYN-RECEIVED状態

• ESTABLISHED状態に入った後、送信データをキューに入れる。キューに入れる余裕がない場合は、「error: insufficient resources」と応答する。

ESTABLISHED状態

FIN-WAIT-1状態

FIN-WAIT-2状態

• リクエストを満たすのに着信セグメントのキューが十分にない場合、リクエストをキューに入れる。RECEIVEを記憶するキュー領域がない場合、「error: insufficient resources」と応答する。
• キューに入れられた受信セグメントを受信バッファに再アセンブルし、ユーザに返す。このとき、「push seen」(PUSH)とマークする。
• RCV.UPが現在ユーザに渡しているデータより先行している場合、緊急データの存在をユーザに通知する。
• TCPエンドポイントがユーザにデータを配信する責任を負う場合、その事実を確認応答を通じて送信者に通知しなければならない。このような確認応答のフォーメーションについては、着信セグメントの処理の説明で後述する。

CLOSE-WAIT状態

• リモート側はすでにFINを送信しているため、RECEIVEはすでに手元にあるがまだユーザに配信されていないデータによって満たされれなければならない。配信を待っているテキストがない場合、RECEIVEは「error: connection closing」応答を受け取る。そうでなければ、残っているデータを使ってRECEIVEを満たすことができる。

CLOSING状態

LAST-ACK状態

TIME-WAIT状態

• 「error: connection closing」を返す。

3.10.4. CLOSEコール

CLOSED状態 (つまり、TCBが存在しない)

• ユーザがそのようなコネクションにアクセスできない場合、「error: connection illegal for this process」を返す。
• それ以外の場合、「error: connection does not exist」を返す。

LISTEN状態

• 未処理のRECEIVEはすべて、「error: closing」応答と共に返す。TCBを削除し、CLOSED状態に入り、戻る。

SYN-SENT状態

• TCBを削除し、キューに入っているSENDまたはRECEIVEに対して「error: closing」応答を返す。

SYN-RECEIVED状態

• SENDが発行されておらず、送信する保留データがない場合、FINセグメントを形成して送信し、FIN-WAIT-1状態に入る。そうでなければ、ESTABLISHED状態に入った後、処理のためにキューに入れる。

ESTABLISHED状態

• 先行するすべてのSENDがセグメント化されるまでこのリクエストをキューに入れ、FINセグメントを形成して送信する。いずれにせよ、FIN-WAIT-1状態に入る。

FIN-WAIT-1状態

FIN-WAIT-2状態

• 厳密に言えば、これはエラーであり、「error: connection closing」と応答を返す必要がある。2回目のFINが送信されない限り、「ok」応答も受け入れられる(ただし、最初のFINは再送される可能性がある)。

CLOSE-WAIT状態

• 先行するすべてのSENDがセグメント化されるまで、このリクエストをキューに入れる。次に、FINセグメントを送り、LAST-ACK状態に入る。

CLOSING状態

LAST-ACK状態

TIME-WAIT状態

• 「error: connection closing」と応答する。

3.10.5. ABORTコール

CLOSED状態 (つまり、TCBが存在しない)

• ユーザがそのようなコネクションにアクセスできない場合、「error: connection illegal for this process」を返す。
• それ以外の場合、「error: connection does not exist」を返す。

LISTEN状態

• 未処理のRECEIVEはすべて、「error: connection reset」応答で返す必要がある。TCBを削除し、CLOSED状態に入り、戻る。

SYN-SENT状態

• キューに入れられたすべてのSENDとRECEIVEは、「connection reset」通知を伝える必要がある。TCBを削除し、CLOSED状態に入り、戻る。

SYN-RECEIVED状態

ESTABLISHED状態

FIN-WAIT-1 状態

FIN-WAIT-2 状態

CLOSE-WAIT状態

• 以下のリセットセグメントを送信する:
  <SEQ=SND.NXT><CTL=RST>
• キューに入れられたすべてのSENDとRECEIVEに、「connection reset」通知を伝える必要がある。送信(上記で形成されたRSTを除く)または再送のためにキューに入れられたすべてのセグメントはフラッシュする必要がある。TCBを削除し、CLOSED状態に入り、戻る。

CLOSING状態

LAST-ACK状態

TIME-WAIT状態

• 「ok」で応答し、TCBを削除し、CLOSED状態に入り、戻る。

3.10.6. STATUSコール

CLOSED状態 (つまり、TCBが存在しない)

• ユーザがそのようなコネクションにアクセスできない場合、「error: connection illegal for this process」を返す。
• それ以外の場合、「error: connection does not exist」を返す。

LISTEN状態

• 「state = LISTEN」とTCBポインタを返す。

SYN-SENT状態

• 「state = SYN-SENT」とTCBポインタを返す。

SYN-RECEIVED状態

• 「state = SYN-RECEIVED」とTCBポインタを返す。

ESTABLISHED状態

• 「state = ESTABLISHED」とTCBポインタを返す。

FIN-WAIT-1状態

• 「state = FIN-WAIT-1」とTCBポインタを返す。

FIN-WAIT-2状態

• 「state = FIN-WAIT-2」とTCBポインタを返す。

CLOSE-WAIT状態

• 「state = CLOSE-WAIT」とTCBポインタを返す。

CLOSING状態

• 「state = CLOSING」とTCBポインタを返す。

LAST-ACK状態

• 「state = LAST-ACK」とTCBポインタを返す。

TIME-WAIT状態

• 「state = TIME-WAIT」とTCBポインタを返す。

3.10.7. セグメントが到着(SEGMENT ARRIVES)

3.10.7.1. CLOSED状態

(If) 状態がCLOSED(つまり、TCBが存在しない)の場合、

• 着信セグメント内のすべてのデータは破棄される。RSTを含む着信セグメントは破棄される。RSTを含まない着信セグメントにより、応答としてRSTを送信する。確認応答とシーケンス・フィールドの値は、問題のあるセグメントを送信した TCP エンドポイントが許容できるリセット・シーケンスになるように選択する。
  • (If) ACKビットがオフの場合、シーケンス番号0を使用する
    <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
  • (If) ACKビットがオンの場合、
    <SEQ=SEG.ACK><CTL=RST>
• 戻る。

3.10.7.2. LISTEN状態

(If) 状態がLISTENの場合、

1. まず、RSTを確認する。

   • 着信RSTセグメントは、このコネクションが送信したものに応答して送信されたものではないため、有効ではない。着信RSTは無視する必要がある。戻る。

2. 次に、ACKを確認します。

   • 確認応答がまだLISTEN状態のままコネクションに到着した場合、その確認応答は不正である。到着したACKを含むセグメントに対して、許容可能なリセット・セグメントを形成する必要がある。RSTは以下のようにフォーマットする必要がある:
     <SEQ=SEG.ACK><CTL=RST>
   • 戻る。

3. 3番目に、SYNを確認する。

   • (If) SYNビットが設定されていれば、セキュリティを確認する。着信セグメントのセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合、リセットを送信して戻る。
     <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
   • RCV.NXTをSEG.SEQ+1に設定し、IRSをSEG.SEQに設定し、他の制御またはテキストを後で処理するためにキューに入れる。ISSを選択し、以下の形式のSYNセグメントを送信する:
     <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
   • SND.NXTをISS+1に設定し、SND.UNAはISSに設定する。コネクション状態はSYN-RECEIVEDに変更する必要がある。他の受信制御またはデータ(SYNと組み合わせたもの)は SYN-RECEIVED状態で処理されるが、SYNとACKの処理は繰り返されるべきではないことに留意する。LISTENが完全に指定されていない(つまり、リモートソケットが完全に指定されていない)場合、指定されていないフィールドをここで埋める必要がある。

4. 4番目、他のデータまたは制御:

   • これは到達すべきではない。セグメントを破棄して戻る。他の制御セグメントまたはデータ保持セグメント(SYNを含まない)はACKが必要であるため、最初のステップのRST確認で最初に破棄されない限り、2番目のステップのACK処理で破棄されることになる。

3.10.7.3. SYN-SENT状態

(If) 状態がSYN-SENTの場合、

1. まず、ACKビットを確認する。

   • (If) ACKビットが設定されている場合、
     • (If) SEG.ACK =< ISS または SEG.ACK > SND.NXTの場合、リセットを送信する(RSTビットが設定されていなければ、セグメントを削除して戻る)
       <SEQ=SEG.ACK><CTL=RST>
     • そしてセグメントを破棄する。戻る。
     • (If) SND.UNA < SEG.ACK =< SND.NXTの場合、ACKは受け入れられる。展開されたTCPコードの中には、SEG.ACK == SND.NXTというチェック(「=<」ではなく「==」を使用)を使用しているものがあるが、これは、TCPピアがSYN上のすべてのデータを受け入れて確認できるわけではないため、スタックがSYN上でデータを送信できる場合には適切ではない。

2. 次に、RSTビットを確認する。

   • (If) RST ビットが設定されている場合、
     • 潜在的なブラインド・リセット攻撃は、RFC 5961[9]に記載されている。この文書に記載されている緩和策は、その中で説明されている特定の適用性を持っており、暗号化保護(IPsecやTCP-AOなど)の代替ではない。RFC 5961に記載されている緩和策をサポートするTCP実装は、次の段落の動作を実行する前に、シーケンス番号がRCV.NXTと正確に一致することを最初に確認する必要がある。
     • (If) ACK が受け入れ可能な場合、ユーザに「error: connection reset」を通知し、セグメントを破棄し、CLOSED状態に入り、TCBを削除して戻る。そうでなければ(ACKなし)、セグメントを破棄して戻る。

3. 3番目に、セキュリティを確認する:

   • (If) セグメント内のセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合は、リセットを送信する。
     • (If) ACKがある場合、
       <SEQ=SEG.ACK><CTL=RST>
     • そうでなければ、
       <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
   • (If) リセットが送信された場合は、セグメントを破棄して戻る。

4. 4番目に、SYNビットを確認する。

   • このステップに到達するのは、ACKがOKか、ACKが存在せず、セグメントにRSTが含まれていない場合のみである。
   • (If) SYNビットがオンで、セキュリティ/コンパートメントが許容可能な場合、RCV.NXTはSEG.SEQ+1に設定され、IRSはSEG.SEQに設定される。 SND.UNAはSEG.ACK(ACKがある場合)と等しくなるまで前に進める必要があり、それによって確認された再送キュー上のセグメントは削除する必要がある。
   • (If) SND.UNA > ISS (SYNがACKされている)の場合、コネクション状態をESTABLISHEDに変更し、ACKセグメントを形成し、
     <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
   • そして、それを送る。送信のためにキューに入れられたデータまたは制御を含めてもよい。TCP実装の中には、受信したセグメントに後の処理ステップで確認応答を生成するデータが含まれている場合、このセグメントの送信を抑制し、SYNの余分な確認応答が送信を抑えるものもある。セグメント内に他の制御やテキストがある場合は、セクション3.10.7.4の6番目のステップで処理を続行し、URGビットをチェックする。それ以外の場合は、戻る。
   • そうでなければ、SYN-RECEIVEDに入り、SYN,ACKセグメントを形成し、
     <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>
   • それを送る。変数を設定する:
     SND.WND <- SEG.WND
     SND.WL1 <- SEG.SEQ
     SND.WL2 <- SEG.ACK
     (If) セグメント内に他の制御やテキストがある場合は、ESTABLISHED状態に達した後、処理のためにそれらをキューに入れ、戻る。
   • SYNセグメント(これは前述の「セグメント内のテキスト」である)上でアプリケーション・データを送受信することは合法であることに留意する。このトピックに関して、歴史的に大きな誤った情報と誤解があった。ファイアウォールやセキュリティ・デバイスの中には、これを疑わしいと見なすものもある。しかし、この機能はT/TCP[21]で使用され、TCP Fast Open (TFO)[48]でも使用されているため、実装やネットワーク・デバイスが許可することが重要である。

5. 第5に、(If) SYNビットもRSTビットも設定されていない場合、セグメントを破棄して戻る。

3.10.7.4. その他の状態

そうでなければ、

1. まず、シーケンス番号を確認する:

   • SYN-RECEIVED状態
   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
   • CLOSE-WAIT状態
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態

     • セグメントは順番に処理される。到着時の最初のテストは古い重複を破棄するために行われるが、それ以降の処理はSEG.SEQの順番で行われる。セグメントの内容が古い部分と新しい部分の境界にまたがる場合は、新しい部分のみが処理される。

     • 一般に、受信セグメントの処理は、可能な限りACKセグメントを集約するように実装しなければならない(MUST-58)。例えば、TCPエンドポイントがキューイングされたセグメントを処理する場合、ACKセグメントを送信する前にそれらをすべて処理しなければならない(MUST-59)。

     • 着信セグメントの受け入れ可能性テストには4つのケースがある:

       セグメント長	受信ウィンドウ	テスト
       0	0	SEG.SEQ = RCV.NXT
       0	>0	RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
       >0	0	受け入れられない
       >0	>0	RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

       表6: セグメントの許容性テスト

     • ここで説明するシーケンス番号検証を実装する場合、付録A.2に留意すること。

     • RCV.WNDがゼロの場合、セグメントは受け入れられないが、有効なACK、URG、RSTを受け入れるために特別な容認が必要である。

     • (If) 受信セグメントが受け入れられない場合、応答として確認応答を送る必要がある(RSTビットが設定されていなければ、セグメントを破棄して戻る)
       <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

     • 確認応答を送信した後、受け入れられないセグメントを破棄して戻る。

     • TIME-WAIT状態については、ここで説明しているシーケンス番号確認に依存するのではなく、タイムスタンプを利用して、着信SYNセグメントを処理するための改良アルゴリズムが[40]で説明されていることに留意する。この改良されたアルゴリズムが実装されると、TIME-WAIT状態のコネクションで受信された、タイムスタンプ・オプションを持つ着信SYNセグメントには、上記のロジックは適用できない。

     • 以下では、セグメントはRCV.NXTで始まり、ウィンドウを超えない理想的なセグメントだと仮定する。ウィンドウの外側にある部分(SYNとFINを含む)を切り捨て、セグメントがRCV.NXTで始まる場合にのみ処理を進めることで、この仮定に合うように実際のセグメントを調整することができる。より大きな開始シーケンス番号を持つセグメントは、後の処理のために保持する必要がある(SHLD-31)。

2. 次に、RSTビットを確認する:

   • RFC 5961 [9]のセクション3では、潜在的なブラインド・リセット攻撃とオプションの緩和アプローチについて記載している。これは、暗号学的保護(IPsecやTCP-AOなど)は提供しないが、RFC 5961で記載されている状況で適用できる。RFC 5961で述べられている保護を実装するスタックには、以下の3つのチェックが適用される。それ以外の場合、これらの状態の処理は以下に示す。
     1. RSTビットが設定され、シーケンス番号が現在の受信ウィンドウの外にある場合、静かにセグメントを破棄する。
     2. RSTビットが設定され、シーケンス番号が次に予期されるシーケンス番号(RCV.NXT)と正確に一致する場合、TCPエンドポイントはコネクション状態に応じて、以下に規定する方法でコネクションをリセットしなければならない 。
     3. RSTビットを設定し、シーケンス番号が次に期待されるシーケンス値と正確に一致せず、現在の受信ウィンドウ内にある場合、TCPエンドポイントは確認応答(チャレンジACK)を送信しなければならない:
        <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
        チャレンジACKを送信した後、TCPエンドポイントは受け入れられないセグメントを破棄し、それ以降の着信パケットの処理を停止しなければならない。RFC 5961とErrata ID 4772[99]には、実装におけるACKスロットリング(throttling)に関する追加の考慮事項が含まれていることに留意する。
   • SYN-RECEIVED状態
     • RSTビットが設定されている場合、
       • (If) このコネクションが受動的OPENで開始された(つまり、LISTEN状態から来た)場合、このコネクションをLISTEN状態に戻してから戻る。ユーザに通知する必要はない。このコネクションがアクティブOPENで開始された(つまり、SYN-SENT状態から来た)場合、コネクションは拒否された。ユーザに「connection refused」を通知する。いずれの場合も、再送キューをフラッシュする必要がある。そして、アクティブOPENの場合、CLOSED状態に入り、TCBを削除して戻る。
   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
   • CLOSE-WAIT状態
     • RSTビットを設定している場合、未処理のRECEIVEとSENDはすべて「reset」応答を受信する必要がある。すべてのセグメント・キューをフラッシュする必要がある。ユーザは、要求されていない一般的な「connection reset」信号を受け取る必要がある。CLOSED状態に入り、TCBを削除して戻る。
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態
     • RSTビットが設定されている場合は、CLOSED状態に入り、TCBを削除して戻る。

3. 第三に、セキュリティをチェックする:

   • SYN-RECEIVED状態
     • (If) セグメント内のセキュリティ/コンパートメントがTCB内のセキュリティ/コンパートメントと正確に一致しない場合、リセットを送信して戻る。
   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
   • CLOSE-WAIT状態
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態
     • (If) セグメント内のセキュリティ/コンパートメントがTCBのセキュリティ/コンパートメントと正確に一致しない場合、リセットを送信する。未処理のRECEIVEとSENDはすべて「reset」応答を受信する必要がある。すべてのセグメント・キューをフラッシュする必要がある。ユーザは、要求されていない一般的な「connection reset」信号を受け取る必要がある。CLOSED状態に入り、TCBを削除して戻る。
   • このチェックは、異なるセキュリティを持つこれらのポート番号間の古いコネクションからのセグメントが、現在のコネクションが中止されるのを防ぐために、シーケンス・チェックの後に置かれていることに留意する。

4. 4番目に、SYNビットを確認する:

   • SYN受信状態
     • (If) 接続がパッシブOPENで開始された場合、このコネクションをLISTEN状態に戻してから戻る。そうでなければ、以下の同期状態の指示に従って処理する。
   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
   • CLOSE-WAIT状態
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態
     • (If) これらの同期状態でSYNビットが設定されている場合、RFC 5961[9]で述べられているように、正当な新規コネクションの試み(例えば、TIME-WAITの場合)、コネクションをリセットする必要があるエラー、または攻撃試行の結果のいずれかである可能性がある。TIME-WAIT状態の場合、タイムスタンプ・オプションが使用され、期待値を満たす場合、([40]に従って)新規コネクションを受け入れることができる。他のすべてのケースについては、RFC 5961はいくつかの状況に適用可能な緩和策を提供しているが、暗号学的保護を提供する代替案もある(セクション7を参照)。 RFC 5961は、これらの同期状態において、シーケンス番号に関係なくSYNビットが設定されている場合、TCPエンドポイントはリモートピアに「チャレンジACK」を送信しなければならないと推奨している:
       <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
     • 確認応答を送信した後、TCP実装は受け入れられないセグメントを破棄し、それ以降の処理を停止しなければならない。RFC 5961とErrata ID 4772 [99]には、実装に関するACKスロットリングに関する注意事項が追加されていることに留意する。
     • RFC 5961に従わない実装の場合、この段落ではRFC 793に記載されているオリジナルの動作が続く。SYNがウィンドウ内にある場合、それはエラーである。リセットを送信し、すべての未処理のRECEIVEとSENDがあれば「reset」応答を受信し、すべてのセグメント・キューをフラッシュし、ユーザは要求されていない一般的な「connection reset」信号を受信し、CLOSED 状態に入り、TCBを削除して戻る。
     • (If) SYNがウィンドウ内にない場合、このステップには到達せず、最初のステップ(シーケンス番号の確認)でACKが送信される。

5. 5番目に、ACKフィールドを確認する:

   • (If) ACKビットがオフの場合、セグメントを削除し
   • (If) ACKビットがオンの場合、
     • RFC 5961[9]のセクション5では、潜在的なブラインド・データ・インジェクション攻撃と、実装が含めることを選択してもよい緩和策について述べている(MAY-12)。RFC 5961を実装するTCPスタックは、ACK値が((SND.UNA - MAX.SND.WND) =< SEG.ACK =< SND.NXT)の範囲内にある場合にのみ受け入れられるという入力チェックを追加しなければならない。ACK値が上記の条件を満たさないすべての着信セグメントは破棄し、ACKを送り返されなければならない。新しい状態変数MAX.SND.WNDは、ローカル送信者がピアからこれまでに受信した最大のウィンドウ(ウィンドウ・スケーリングの影響を受ける)として定義されるか、最大許容ウィンドウ値にハード・コーディングかも知れない。ACK値が受け入れられる場合、以下の状態ごとの処理が適用される:
     • SYN-RECEIVED状態
       • (If) SND.UNA < SEG.ACK =< SND.NXTの場合、ESTABLISHED状態に入り、以下の変数を次のように設定して処理を続ける:
         SND.WND <- SEG.WND
         SND.WL1 <- SEG.SEQ
         SND.WL2 <- SEG.ACK
       • (If) セグメントの確認応答が受け入れられない場合は、リセットセグメントを形成し
         <SEQ=SEG.ACK><CTL=RST>
       • それを送る。
     • ESTABLISHED状態
       • (If) SND.UNA < SEG.ACK =< SND.NXTであれば、SND.UNA <- SEG.ACKを設定する。これにより完全に確認応答を返した再送キュー上のセグメントはすべて削除される。ユーザは、送信され完全に確認応答されたバッファに対して、肯定的な確認応答を受け取る必要がある(つまり、SENDバッファは「ok」応答で返される必要がある)。ACKが重複している場合(SEG.ACK =< SND.UNA)、それを無視できる。ACKがまだ送信されていないものに確認応答を返した場合(SEG.ACK > SND.NXT)、ACKを送信し、セグメントを破棄して戻る。
       • (If) SND.UNA =< SEG.ACK =< SND.NXTの場合、送信ウィンドウを更新する。もし、(SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and SND.WL2 =< SEG.ACK))の場合、SND.WND <- SEG.WND、SND.WL1 <- SEG.SEQ、SND.WL2 <- SEG.ACKを設定する。
       • SND.WNDはSND.UNAからのオフセットであること、SND.WL1はSND.WNDの更新に使用される最後のセグメントのシーケンス番号を記録していること、SND.WL2はSND.WNDの更新に使用される最後のセグメントの確認番号を記録することに留意する。ここでの確認が、ウィンドウを更新するために古いセグメントが使用されることを防いでいる。
     • FIN-WAIT-1 状態
       • ESTABLISHED状態の処理に加えて、FINセグメントが確認された場合、FIN-WAIT-2に入り、その状態で処理を続行する。
     • FIN-WAIT-2 状態
       • ESTABLISHED状態の処理に加えて、再送キューが空の場合、ユーザのCLOSEを確認(「ok」)できるが、TCBは削除しない。
     • CLOSE-WAIT状態
       • ESTABLISHED状態と同様の処理を行う。
     • CLOSING状態
       • ESTABLISHED状態の処理に加えて、ACKがFINを確認すると、TIME-WAIT状態に入る。それ以外の場合、セグメントを無視する。
     • LAST-ACK状態
       • この状態で到達できる唯一のものは、FINに対する確認応答だけである。FINが確認されたら、TCBを削除し、CLOSED状態に入り、戻る。
     • TIME-WAIT状態
       • この状態で到達できる唯一のものは、リモートFINの再送だけである。それを確認し、2 MSLタイムアウトを再開する。

6. 6番目に、URG ビットを確認する:

   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
     • (If) URGビットが設定されている場合、RCV.UP <- max(RCV.UP,SEG.UP)となり、緊急ポインタ(RCV.UP)が消費されるデータよりも前にある場合、リモート側に緊急データがあることをユーザに通知する。この一連の緊急データに対して、ユーザが既に通知を受けている場合(あるいはまだ「緊急モード」の場合)、再度ユーザに通知はしない。
   • CLOSE-WAIT状態
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態
     • リモート側からFINを受信しているため、このようなことは起こらないはずである。URGを無視する。

7. 7番目に、セグメント・テキストを処理する:

   • ESTABLISHED状態
   • FIN-WAIT-1 状態
   • FIN-WAIT-2 状態
     • ESTABLISHED状態になると、セグメント・データをユーザの RECEIVEバッファに配送できる。バッファがいっぱいになるか、セグメントが空になるまで、セグメントからのデータをバッファに移動できる。セグメントが空で、PUSHフラグが付いている場合、バッファが返されるときに、PUSHを受信したことがユーザに通知する。
     • TCPエンドポイントがユーザへのデータ配信に責任を負う場合、データの受信を確認しなければならない。
     • TCPエンドポイントがデータに対する責任を負うと、受け入れられたデータに対してRCV.NXTを進め、現在のバッファーの可用性に応じて RCV.WNDを調整する。RCV.NXTとRCV.WNDの合計は減らしてはならない。
     • TCP実装は、ウィンドウ内にあるがウィンドウの左端ではない有効なセグメントが到着した場合、RCV.NXTを確認するACKセグメントを送信してもよい(MAY-13)。
     • セクション3.8のウィンドウ管理に関する提案に留意すること。
     • フォームの確認応答を送信する:
       <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
     • この確認応答は、可能であれば、過度の遅延を発生させることなく、送信中のセグメントにピギーバックする必要がある。
   • CLOSE-WAIT状態
   • CLOSING状態
   • LAST-ACK状態
   • TIME-WAIT状態
     • リモート側からFINを受信しているため、これは発生しない。セグメント・テキストは無視する。

8. 8番目に、FINビットを確認する:

   • 状態がCLOSED、LISTEN、SYN-SENTの場合、SEG.SEQを検証できないため、FINを処理しない。セグメントを破棄して戻る。
   • (If) FINビットが設定されている場合、ユーザに「connection closing」の信号を送り、保留中のRECEIVEを同じメッセージで返し、FIN上でRCV.NXTを進め、FINに対する確認応答を送信する。FINは、ユーザにまだ配信されていないセグメント・テキストに対するPUSHを意味することに留意する。
     • SYN-RECEIVED状態
     • ESTABLISHED状態
       • CLOSE-WAIT状態に入る。
     • FIN-WAIT-1 状態
       • (If) FINが(おそらくこのセグメント内で)ACKされた場合、TIME-WAITに入り、時間待機タイマーを開始し、他のタイマーをオフにする。それ以外の場合、CLOSING状態に入る。
     • FIN-WAIT-2 状態
       • TIME-WAIT状態に入る。時間待機タイマーを開始し、他のタイマーをオフにする。
     • CLOSE-WAIT状態
       • CLOSE-WAIT状態を維持する。
     • CLOSING状態
       • CLOSING状態を維持する。
     • LAST-ACK状態
       • LAST-ACK状態を維持する。
     • TIME-WAIT状態
       • TIME-WAIT状態を維持する。2 MSL時間待機タイムアウトを再開する。
     • そして戻る。

3.10.8. タイムアウト

ユーザ・タイムアウト(USER TIMEOUT)

• どの状態でも、ユーザ・タイムアウトが期限切れになった場合、すべてのキューをフラッシュし、一般的に「error: connection aborted due to user timeout」をユーザに通知する、また、未処理の呼び出しがある場合、TCBを削除し、CLOSED状態に入り、戻る。

再送タイムアウト(RETRANSMISSION TIMEOUT)

• どの状態でも、再送キュー内のセグメントで再送タイムアウトが期限切れになった場合、再送キューの先頭にあるセグメントを再度送信し、再送タイマーを再初期化して戻る。

TIME-WAITタイムアウト(TIME-WAIT TIMEOUT)

• コネクションで時間待ちタイムアウトの期限切れになった場合、TCBを削除し、CLOSED状態に入り、戻る。

4. 用語集

ACK
シーケンス領域を占有しない制御ビット(確認応答)。これは、このセグメントの確認応答フィールドが、このセグメントの送信者が受信を期待している次のシーケンス番号を指定していること、つまり、それ以前のすべてのシーケンス番号の受信を確認していることを示す。

コネクション
ソケットのペアによって識別される論理的な通信パス。

データグラム
パケット交換型コンピュータ通信ネットワークで送信されるメッセージ。

送信先アドレス
セグメントを受信するエンドポイントのネットワーク層アドレス。

FIN
シーケンス番号を1つ占有する制御ビット(finis)で、送信側がシーケンス領域を占有するデータや制御をこれ以上送信しないことを示す。

フラッシュ
ストア(バッファやキュー)からすべてのコンテンツ(データまたはセグメント)を削除すること。

フラグメント(断片化)
データの論理単位の一部。特に、インターネット・フラグメントはインターネット・データグラムの一部である。

ヘッダ
メッセージ、セグメント、フラグメント、パケット、またはデータ・ブロックの先頭にある制御情報。

ホスト
コンピュータ。特に、通信ネットワークの観点から見たメッセージの送信元または送信先。

識別(Identification)
インターネット・プロトコル・フィールド。送信者によって割り当てられたこの識別値は、データグラムのフラグメントを組み立てる際に役立つ。

インターネット・アドレス
ネットワーク層アドレス。

インターネット・データグラム
インターネット・ホスト間で交換されるデータの単位で、データグラムを送信元から送信先までルーティングするためのインターネット・ヘッダと一緒に交換されるデータの単位。

インターネット・フラグメント
インターネット・ヘッダを持つインターネット・データグラムのデータの一部。

IP
インターネット・プロトコル。[1]及び[13]を参照のこと。

IRS (Initial Receive Sequence)
初期受信シーケンス番号。接続時に送信者が最初に使用するシーケンス番号。

ISN (Initial Sequence Number)
初期シーケンス番号。接続時に最初に使用されるシーケンス番号(ISSまたはIRS)。一定期間内で一意であり、攻撃者が予測できない方法で選択する。

ISS (Initial Send Sequence)
初期送信シーケンス番号。送信者が接続時に使用する最初のシーケンス番号。

左のシーケンス
これは、データを受信するTCPエンドポイントが確認する次のシーケンス番号(または、現在確認されていないシーケンス番号の中で一番小さいもの)であり、送信ウィンドウの左端と呼ばれることもある。

モジュール
通常、プロトコルや他の手順を実装したソフトウェアのこと。

MSL (Masimum Segment Lifetime)
セグメントの最大有効期間。TCPセグメントがインターネットワーク・システム内に存在できる時間。任意に2 分と定義される。

オクテット
8ビットのバイト。

オプション
オプション・フィールドには複数のオプションを含めることができ、各オプションの長さは数オクテットになる場合がある。

パケット
論理的に完全である場合とそうでない場合があるヘッダを持つデータ・パッケージ。論理的なデータ・パッケージというよりも、物理的なデータ・パッケージであることが多い。

ポート
エンドポイントでコネクションを多重分離に使われるコネクション識別子の一部。

プロセス
実行中のプログラム。TCPエンドポイントまたは他のホスト間プロトコルの観点から見たデータの送信元または送信先。

PUSH
シーケンス領域を占有しない制御ビットで、このセグメントには受信側ユーザに強引に押し出さなければならないデータが含まれていることを示す。

RCV.NXT
受信する次のシーケンス番号

RCV.UP
受信する緊急ポインタ

RCV.WND
受信ウィンドウ

受信する次のシーケンス番号
これは、ローカルTCPエンドポイントが受信を期待している次のシーケンス番号である。

受信ウィンドウ
これは、ローカル(受信側)TCPエンドポイントが受信を許容するシーケンス番号を表す。したがって、ローカルTCPエンドポイントは、RCV.NXTからRCV.NXT + RCV.WND - 1 の範囲にオーバーラップするセグメントは、許容可能なデータまたは制御を伝送するとみなす。この範囲外のシーケンス番号を含むセグメントは、重複またはインジェクション攻撃とみなし、破棄する。

RST
制御ビット(リセット)は、シーケンス領域を占有せず、受信側がそれ以上のやり取りをせずにコネクションを削除する必要があることを示す。受信側は、受信セグメントのシーケンス番号と確認応答フィールドに基づいて、リセット・コマンドを受け入れるか無視するかを判断できる。いかなる場合も、RSTを含むセグメントの受信は、応答としてRSTを生成することはない。

SEG.ACK
セグメント確認

SEG.LEN
セグメント長

SEG.SEQ
セグメント・シーケンス

SEG.UP
セグメント緊急ポインタ・フィールド

SEG.WND
セグメント・ウィンドウ・フィールド

セグメント
データの論理単位。特に、TCPセグメントは、TCPモジュールのペア間で転送されるデータの単位をいう。

セグメント確認応答
到着セグメントの確認応答フィールドのシーケンス番号。

セグメント長
セグメントが占有するシーケンス番号領域の量(シーケンス領域を占有する制御を含む)。

セグメント・シーケンス
到着したセグメントのシーケンス・フィールドの番号。

送信シーケンス
これは、ローカル(送信側)TCPエンドポイントがコネクションで使用する次のシーケンス番号である。最初に初期シーケンス番号曲線(ISN)から選択され、送信されるデータまたはシーケンス制御のオクテットごとにインクリメントされる。

送信ウィンドウ
これは、リモート(受信側)TCPエンドポイントが受信を希望するシーケンス番号を表す。これは、リモート(データ受信側)TCPエンドポイントからのセグメントで指定されたウィンドウ・フィールドの値である。TCP実装が発行する可能性のある新しいシーケンス番号の範囲は、SND.NXTとSND.UNA + SND.WND - 1の間にある(もちろん、SND.UNAとSND.NXTの間でシーケンス番号が再送は予期される)。

SND.NXT
シーケンスの送信

SND.UNA
左シーケンス

SND.UP
緊急ポインタの送信

SND.WL1
最後のウィンドウ更新時のセグメント・シーケンス番号

SND.WL2
最後のウィンドウ更新時のセグメント確認応答番号

SND.WND
送信ウィンドウ

ソケット(またはソケット番号、またはソケット・アドレス、またはソケット識別子)
特にポート識別子を含むアドレス、つまりインターネット・アドレスとTCPポートを連結したもの。

送信元アドレス
送信エンドポイントのネットワーク層アドレス。

SYN
受信セグメント内の制御ビット。1つのシーケンス番号を占め、コネクション開始時にシーケンス番号の開始位置を示すために使用する。

TCB
トランスミッション・コントロール・ブロック。接続の状態を記録するデータ構造。

TCP
トランスミッション・コントロール・プロトコル: インターネットワーク環境における信頼性の高い通信のためのホスト間プロトコル。

TOS
サービス種別は、廃止されたIPv4フィールドである。現在、同じヘッダ・ビットが、DiffServコードポイント(DSCP)値と2ビットのECNコードポイント[6]を含むDiffServフィールド[4]に使用されている。

サービス種別 (Type of Service)
「TOS」を参照のこと。

URG
シーケンス領域を占有しない制御ビット(緊急)は、緊急ポインタが示す値よりも小さいシーケンス番号で消費されるデータがある限り、緊急処理を行うよう受信ユーザに通知する必要があることを示すために使用する。

緊急ポインタ
URGビットがオンの場合にのみ意味を持つ制御フィールド。このフィールドは、送信側ユーザの緊急呼に関連付けられたデータ・オクテットを示す緊急ポインタの値を伝達する。

5. RFC 793からの変更点

本文書は、RFC 793と、793を更新したRFC 6093及び6528を廃止する。いずれの場合も、規範となるプロトコル仕様と要件のみが本文書に組み込まれており、背景や根拠を含む情報的なテキストは含まれていない。これらの文書の情報的な内容は、TCPを学び、理解する上で依然として価値があり、規範的な内容が本文書に組み込まれたとしても、有効な情報的な参考文献である。

本文書の本文は、RFC 793のセクション3「機能仕様」というタイトルから、フォーマットとレイアウトを可能な限り近づけながら、改作したものである。

RFC 793への更新が報告され、承認され、または保留された、該当するRFC正誤表のコレクションを組み込んだ(正誤表ID: 573[73]、574[74]、700[75]、701[76]、1283[77]、1561[78]、1562[79]、1564[80]、1571[81]、1572[82]、2297[83]、2298[84]、2748[85]、2749[86]、934[87]、3213[88]、3300[89]、3301[90]、6222[91])。いくつかの正誤表は、他の変更により適用されなかった(正誤表 ID: 572[92]、575[93]、1565[94]、1569[95]、2296[96]、3305[97]、3602[98])。

RFC 1011、1122、6093に記載されている緊急ポインタの仕様の変更を組み込んだ。これらの変更が必要な理由の詳細については、RFC 6093を参照のこと。

RFC 793のRTOの説明は、RFC 6298を参照するように更新した。RFC 1122のRTOに関する文章は、もともとRFC 793の文章を置き換えるものだったが、RFC 2988は RFC 1122を更新する必要があり、その後RFC 6298によって廃止された。

RFC 1011 [18]には、TCP仕様に必要な変更を含む、RFC 793に関する多くのコメントを含んでいる。これらはRFC 1122で拡張され、RFC 793に対する他の変更と解説のコレクションが含まれている。プロトコルに影響を与える規範的な項目は、RFC 1122に組み込まれていた歴史的に有用な実装上のアドバイスや有益な議論は、ここに組み込まれた。RFC 793からTCP仕様となった本文書は、RFC 1011を更新し、RFC 1011に記載されているコメントを組み込んでいる。

RFC 1122にはTCP要件以上のものが含まれているため、本文書がRFC 1122を完全に廃止することはできない。本文はRFC 1122を「更新中」とだけマークしているが、RFC 1122に記載されているTCPに関するすべての内容は事実上廃止されると理解する必要がある。

RFC 6528の安全な初期シーケンス番号生成アルゴリズムを組み込んだ。これにより軽減される攻撃についての説明、PRFアルゴリズムの選択と秘密鍵データの管理に関するアドバイスについては、RFC 6528を参照のこと。

RFC 6429に基づく注記を追加し、システム・リソース管理上の懸念がコネクション・リソースの再利用が可能になることを明示的に明確にした。RFC 6429は、ここに記載されている解説がこの基本TCP仕様に反映されたという意味で、廃止した。

輻輳制御の実装に関する記述が、このトピックに関するIETFのBCPまたは標準化過程の一連の文書と、一般的な実装の現状に基づいて追加された。

6. IANAに関する考慮事項

IANAは、このセクションで説明するように、「トランスミッション・コントロール・プロトコル(TCP)ヘッダ・フラグ」レジストリにいくつかの変更を加えた。

このレジストリは、元々RFC 3168で作成されたが、RFC 3168で定義された新しいビットのみを登録し、RFC 793や他の文書で前に登録されていた他のビットは無視した。その後、ビット7もRFC 8311[54]で更新された。

「ビット」列は、図1のTCPヘッダの16ビット整列ビュー内の各ヘッダ・フラグのオフセットを参照するため、以下では「ビット・オフセット」列に名前を変更している。オフセット0～3のビットはTCPセグメントのデータ・オフセット・フィールドであり、ヘッダ・フラグではない。

IANAは「割り当てに関する注記」の欄を追加した。

IANAは以下に示す値を割り当てている。

ビット・ オフセット	名前	参照	課題ノート
4	将来の利用に予約	RFC 9293
5	将来の利用に予約	RFC 9293
6	将来の利用に予約	RFC 9293
7	将来の利用に予約	RFC 8311	以前はHistoric RFC 3540 でNS(Nonce Sum)として 使用されていた。
8	CWR (輻輳ウィンドウの削減)	RFC 3168
9	ECE (ECN-エコー)	RFC 3168
10	緊急ポインタ・フィールドは重要(URG)	RFC 9293
11	確認応答フィールドは重要(ACK)	RFC 9293
12	プッシュ機能(PSH)	RFC 9293
13	コネクションのリセット(RST)	RFC 9293
14	シーケンス番号の同期(SYN)	RFC 9293
15	送信者からのデータはもうない(FIN)	RFC 9293

表7: TCPヘッダ・フラグ

「TCPヘッダ・フラグ」レジストリは、グローバルな「トランスミッション・コントロール・プロトコル(TCP)パラメータ」レジストリ<https://www.iana.org/assignments/tcp-parameters/>のサブレジストリに移動した。

レジストリの登録手順は標準アクションのままだが、本文書の参考文献が更新され、注記を削除した。

7. セキュリティとプライバシーの考慮事項

TCPの設計には、コネクションとアプリケーション・データ転送の堅牢性と信頼性を向上させる基本的なセキュリティ機能のみが含まれているが、あらゆる形式の機密性、認証、他の一般的なセキュリティ機能をサポートするための暗号化機能は組み込まれていない。特定のタイプの攻撃に対するTCPコネクションの堅牢性を向上させるために、非暗号学的な拡張機能(例: [9])が開発されたが、非暗号学的な拡張機能の適用性と保護は限定的である(例えば、[9]のセクション1.1を参照)。アプリケーションは通常、下位層(IPsecなど)や上位層(TLSなど)のプロトコルを利用して、TCPコネクションやTCPで伝送されるアプリケーション・データにセキュリティとプライバシーを提供している。セキュリティ機能をサポートするために、TCPオプションに基づく方法も開発されている。

TCPコネクション(制御フラグを含む)に対して機密性、完全性保護、認証を完全に提供するには、IPsecが現在唯一の有効な方法である。完全性保護と認証については、TCP認証オプション(TCP-AO)[38]が利用可能で、セグメント・ペイロードの機密性を提供する拡張機能が提案されている。このセクションで説明する他の方法は、ペイロードの機密性や完全性保護を提供するかも知れないが、TCPヘッダについては、フィールドのサブセット(例: tcpcrypt [57])をカバーするか、またはまったくカバーしない(例: TLS)。TCPに追加された他のセキュリティ機能(例えば、ISN生成、シーケンス番号チェックなど)は、攻撃を部分的にしか阻止できない。

存続期間の長いTCPフローを使用するアプリケーションは、前のTCP仕様[33]に記載されていた制御フラグの処理を悪用する攻撃に対して脆弱だった。TCP-MD5は、このようなコネクションの一部で認証をサポートするために一般的に実装されたTCPオプションだったが、欠陥があり、現在では非推奨となっている。TCP-AOは、存続期間の長いTCPコネクションを攻撃から保護する機能を提供し、TCP-MD5よりも優れた特性を持っている。TCP-AOは、アプリケーション・データやTCPヘッダのプライバシーを提供しない。

TCPの実験的拡張機能「tcpcrypt」[57]は、コネクションのデータを暗号学的に保護する機能を提供する。TCPフローのメタデータは引き続き見ることができるが、アプリケーション・ストリームは完全に保護する。TCPヘッダ内では、緊急ポインタとFINフラグのみがtcpcryptによって保護される。

TCPロードマップ[49]には、TCPのセキュリティに関連するいくつかのRFCに関する注釈が含まれている。これらのRFCによって提供された機能拡張の多くは、ISNの生成、ブラインド・イン・ウィンドウ攻撃の軽減、ソフトエラーとICMPパケットの処理の改善など、本文書に統合している。これらはすべて、前のTCP仕様に必要な変更を記述した参照RFCでより詳細に説明されている。さらに、緊急ポインタ・フィールドに関連するセキュリティ上の考慮事項については、RFC 6093[39]を参照のこと。これにより、新しいアプリケーションが緊急ポインタを使うのを妨げることにもなる。

TCPはバルク転送フローに使用されることが多いため、TCP輻輳制御ロジックを悪用した攻撃が行われる可能性がある。その一例が「ACK分割」攻撃である。TCP輻輳制御の仕様に加えられた更新には、このような攻撃に対する緩和策として機能する適切なバイト・カウンティング(ABC)[29]などのメカニズムが含まれている。

他の攻撃は、TCPサーバのリソースを使い果たすことに重点を置いている。例えば、SYNフラッディング[32]や進行していないコネクションでのリソースの浪費[41]などがある。オペレーティング・システムは通常、これらの攻撃に対する緩和策を実装している。一般的な防御の中には、プロキシ、ステートフル・ファイアウォール、エンドホストTCP実装の外部にある他のテクノロジーを利用するものもある。

プロトコルの「ワイヤーイメージ」の概念は、RFC 8546 [56]で説明されており、TCPの平文ヘッダが、パケットを送信先にルーティングするために厳密に必要とされる以上のメタデータをパス上のノードにさらす方法について説明している。パス上の敵対者は、このメタデータを利用できるかも知れない。この点でTCPから学んだ教訓は、QUIC[60]のような新しいトランスポートの設計に適用されている。さらに、TCPとその拡張の経験に部分的に基づいて、IETFが RFC 9065 [61]で文書化し、RFC 8558 [58]と[67]でIABが推奨している、将来のTCP拡張や他のトランスポートに適用できるかも知れない考慮事項がある。

また、ホストのTCP実装 (オペレーティング・システム) のバージョンやプラットフォーム情報を推測するために使用できる「フィンガープリント」による方法もある。これらは、セグメントに存在するオプション、オプションの順序、さまざまな条件の場合の特定の動作、パケットのタイミング、パケットサイズ、実装者が決定するように任されているプロトコルの他の側面など、いくつかの側面の観察記録を収集し、ホストと実装に関する情報を識別するためにこの観察を使用することができる。

ICMPメッセージ処理はTCPコネクションともやり取りできるため、TCPコネクションに対するICMPベースの攻撃の可能性がある。これらについては、実装された緩和策とともにRFC 5927[100]で説明されている。

8. 参考文献

8.1. 引用規格

[1] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[2] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[4] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[5] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.

[6] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[7] Floyd, S. and M. Allman, "Specifying New Congestion Control Algorithms", BCP 133, RFC 5033, DOI 10.17487/RFC5033, August 2007, <https://www.rfc-editor.org/info/rfc5033>.

[8] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[9] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, DOI 10.17487/RFC5961, August 2010, <https://www.rfc-editor.org/info/rfc5961>.

[10] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[11] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, DOI 10.17487/RFC6633, May 2012, <https://www.rfc-editor.org/info/rfc6633>.

[12] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[14] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[15] Allman, M., "Requirements for Time-Based Loss Detection", BCP 233, RFC 8961, DOI 10.17487/RFC8961, November 2020, <https://www.rfc-editor.org/info/rfc8961>.

8.2. 参考規格

[16] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[17] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, <https://www.rfc-editor.org/info/rfc896>.

[18] Reynolds, J. and J. Postel, "Official Internet protocols", RFC 1011, DOI 10.17487/RFC1011, May 1987, <https://www.rfc-editor.org/info/rfc1011>.

[19] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[20] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, <https://www.rfc-editor.org/info/rfc1349>.

[21] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, DOI 10.17487/RFC1644, July 1994, <https://www.rfc-editor.org/info/rfc1644>.

[22] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/info/rfc2018>.

[23] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known TCP Implementation Problems", RFC 2525, DOI 10.17487/RFC2525, March 1999, <https://www.rfc-editor.org/info/rfc2525>.

[24] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.

[25] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP Processing of the IPv4 Precedence Field", RFC 2873, DOI 10.17487/RFC2873, June 2000, <https://www.rfc-editor.org/info/rfc2873>.

[26] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, DOI 10.17487/RFC2883, July 2000, <https://www.rfc-editor.org/info/rfc2883>.

[27] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.

[28] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, December 2002, <https://www.rfc-editor.org/info/rfc3449>.

[29] Allman, M., "TCP Congestion Control with Appropriate Byte Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.

[30] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <https://www.rfc-editor.org/info/rfc4727>.

[31] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[32] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, <https://www.rfc-editor.org/info/rfc4987>.

[33] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, DOI 10.17487/RFC4953, July 2007, <https://www.rfc-editor.org/info/rfc4953>.

[34] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, DOI 10.17487/RFC5044, October 2007, <https://www.rfc-editor.org/info/rfc5044>.

[35] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, DOI 10.17487/RFC5461, February 2009, <https://www.rfc-editor.org/info/rfc5461>.

[36] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI 10.17487/RFC5570, July 2009, <https://www.rfc-editor.org/info/rfc5570>.

[37] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>.

[38] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.

[39] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, January 2011, <https://www.rfc-editor.org/info/rfc6093>.

[40] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191, April 2011, <https://www.rfc-editor.org/info/rfc6191>.

[41] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender Clarification for Persist Condition", RFC 6429, DOI 10.17487/RFC6429, December 2011, <https://www.rfc-editor.org/info/rfc6429>.

[42] Gont, F. and S. Bellovin, "Defending against Sequence Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012, <https://www.rfc-editor.org/info/rfc6528>.

[43] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <https://www.rfc-editor.org/info/rfc6691>.

[44] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, <https://www.rfc-editor.org/info/rfc6864>.

[45] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-editor.org/info/rfc6994>.

[46] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, <https://www.rfc-editor.org/info/rfc7094>.

[47] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.

[48] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.

[49] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <https://www.rfc-editor.org/info/rfc7414>.

[50] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[51] Fairhurst, G. and M. Welzl, "The Benefits of Using Explicit Congestion Notification (ECN)", RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.

[52] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, <https://www.rfc-editor.org/info/rfc8095>.

[53] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, <https://www.rfc-editor.org/info/rfc8303>.

[54] Black, D., "Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation", RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

[55] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

[56] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, <https://www.rfc-editor.org/info/rfc8546>.

[57] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, Q., and E. Smith, "Cryptographic Protection of TCP Streams (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, <https://www.rfc-editor.org/info/rfc8548>.

[58] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.

[59] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.

[60] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[61] Fairhurst, G. and C. Perkins, "Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols", RFC 9065, DOI 10.17487/RFC9065, July 2021, <https://www.rfc-editor.org/info/rfc9065>.

[62] IANA, "Transmission Control Protocol (TCP) Parameters", <https://www.iana.org/assignments/tcp-parameters/>.

[63] Gont, F., "Processing of IP Security/Compartment and Precedence Information by TCP", Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seccomp-prec-00, 29 March 2012, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seccomp-prec-00>.

[64] Gont, F. and D. Borman, "On the Validation of TCP Sequence Numbers", Work in Progress, Internet-Draft, draft-gont-tcpm-tcp-seq-validation-04, 11 March 2019, <https://datatracker.ietf.org/doc/html/draft-gont-tcpm-tcp-seq-validation-04>.

[65] Touch, J. and W. M. Eddy, "TCP Extended Data Offset Option", Work in Progress, Internet-Draft, draft-ietf-tcpm-tcp-edo-12, 15 April 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-tcp-edo-12>.

[66] McQuistin, S., Band, V., Jacob, D., and C. Perkins, "Describing Protocol Data Units with Augmented Packet Header Diagrams", Work in Progress, Internet-Draft, draft-mcquistin-augmented-ascii-diagrams-10, 7 March 2022, <https://datatracker.ietf.org/doc/html/draft-mcquistin-augmented-ascii-diagrams-10>.

[67] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170, December 2021, <https://www.rfc-editor.org/info/rfc9170>.

[68] Minshall, G., "A Suggested Modification to Nagle's Algorithm", Work in Progress, Internet-Draft, draft-minshall-nagle-01, 18 June 1999, <https://datatracker.ietf.org/doc/html/draft-minshall-nagle-01>.

[69] Dalal, Y. and C. Sunshine, "Connection Management in Transport Protocols", Computer Networks, Vol. 2, No. 6, pp. 454-473, DOI 10.1016/0376-5075(78)90053-3, December 1978, <https://doi.org/10.1016/0376-5075(78)90053-3>.

[70] Faber, T., Touch, J., and W. Yui, "The TIME-WAIT state in TCP and Its Effect on Busy Servers", Proceedings of IEEE INFOCOM, pp. 1573-1583, DOI 10.1109/INFCOM.1999.752180, March 1999, <https://doi.org/10.1109/INFCOM.1999.752180>.

[71] Postel, J., "Comments on Action Items from the January Meeting", IEN 177, March 1981, <https://www.rfc-editor.org/ien/ien177.txt>.

[72] "Segmentation Offloads", The Linux Kernel Documentation, <https://www.kernel.org/doc/html/latest/networking/segmentation-offloads.html>.

[73] RFC Errata, Erratum ID 573, RFC 793, <https://www.rfc-editor.org/errata/eid573>.

[74] RFC Errata, Erratum ID 574, RFC 793, <https://www.rfc-editor.org/errata/eid574>.

[75] RFC Errata, Erratum ID 700, RFC 793, <https://www.rfc-editor.org/errata/eid700>.

[76] RFC Errata, Erratum ID 701, RFC 793, <https://www.rfc-editor.org/errata/eid701>.

[77] RFC Errata, Erratum ID 1283, RFC 793, <https://www.rfc-editor.org/errata/eid1283>.

[78] RFC Errata, Erratum ID 1561, RFC 793, <https://www.rfc-editor.org/errata/eid1561>.

[79] RFC Errata, Erratum ID 1562, RFC 793, <https://www.rfc-editor.org/errata/eid1562>.

[80] RFC Errata, Erratum ID 1564, RFC 793, <https://www.rfc-editor.org/errata/eid1564>.

[81] RFC Errata, Erratum ID 1571, RFC 793, <https://www.rfc-editor.org/errata/eid1571>.

[82] RFC Errata, Erratum ID 1572, RFC 793, <https://www.rfc-editor.org/errata/eid1572>.

[83] RFC Errata, Erratum ID 2297, RFC 793, <https://www.rfc-editor.org/errata/eid2297>.

[84] RFC Errata, Erratum ID 2298, RFC 793, <https://www.rfc-editor.org/errata/eid2298>.

[85] RFC Errata, Erratum ID 2748, RFC 793, <https://www.rfc-editor.org/errata/eid2748>.

[86] RFC Errata, Erratum ID 2749, RFC 793, <https://www.rfc-editor.org/errata/eid2749>.

[87] RFC Errata, Erratum ID 2934, RFC 793, <https://www.rfc-editor.org/errata/eid2934>.

[88] RFC Errata, Erratum ID 3213, RFC 793, <https://www.rfc-editor.org/errata/eid3213>.

[89] RFC Errata, Erratum ID 3300, RFC 793, <https://www.rfc-editor.org/errata/eid3300>.

[90] RFC Errata, Erratum ID 3301, RFC 793, <https://www.rfc-editor.org/errata/eid3301>.

[91] RFC Errata, Erratum ID 6222, RFC 793, <https://www.rfc-editor.org/errata/eid6222>.

[92] RFC Errata, Erratum ID 572, RFC 793, <https://www.rfc-editor.org/errata/eid572>.

[93] RFC Errata, Erratum ID 575, RFC 793, <https://www.rfc-editor.org/errata/eid575>.

[94] RFC Errata, Erratum ID 1565, RFC 793, <https://www.rfc-editor.org/errata/eid1565>.

[95] RFC Errata, Erratum ID 1569, RFC 793, <https://www.rfc-editor.org/errata/eid1569>.

[96] RFC Errata, Erratum ID 2296, RFC 793, <https://www.rfc-editor.org/errata/eid2296>.

[97] RFC Errata, Erratum ID 3305, RFC 793, <https://www.rfc-editor.org/errata/eid3305>.

[98] RFC Errata, Erratum ID 3602, RFC 793, <https://www.rfc-editor.org/errata/eid3602>.

[99] RFC Errata, Erratum ID 4772, RFC 5961, <https://www.rfc-editor.org/errata/eid4772>.

[100] Gont, F., "ICMP Attacks against TCP", RFC 5927, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-editor.org/info/rfc5927>.

付録A. 他の実装に関する注意事項

このセクションには、現在RFCシリーズにも、TCP標準にも含まれていない、TCP実装上の決定事項に関する追加的な注釈や参考文献が含まれている。これらの項目は実装者が考慮することができるが、標準に含めるというコンセンサスはまだない。

A.1. IP セキュリティ・コンパートメントと優先順位

IPv4仕様[1]には、(現在は廃止されている)サービス種別(TOS)フィールドに優先順位(precedence)が含まれていた。これは[20]で修正され、その後、Differentiated Services (Diffserv)[4]の定義によって廃止された。ネットワーク層、TCP実装、アプリケーションの間で、TOSを設定し伝達することは廃止され、現在のTCP仕様ではDiffservに置き換えられている。

RFC 793は、コネクション内及びアプリケーション要求との一貫性を保つために、着信TCPセグメントのIPセキュリティ・コンパートメントと優先順位をチェックすることを要求していた。RFC 793の具体的な更新がないまま、IPのこれらの各側面は時代遅れになっている。優先順位に関する問題は、標準化過程の[25]で修正されたため、現在のTCP仕様にはその変更が含まれている。しかし、マルチレベル・セキュア(MLS)システムで使用する可能性のあるIPセキュリティ・オプションの状態は、現在のところIETFでは明らかではない。

着信パケットが期待されるセキュリティ・コンパートメントや優先順位に適合しない場合にコネクションをリセットすることは、攻撃ベクトルとして認識されており[63]、IPセキュリティ・コンパートメントやDiffservコードポイントの値が一致しないことでコネクションが中断されるのを防ぐため、TCP仕様を修正することについて議論されている。

A.1.1. 優先順位

Diffservでは、以前の優先順位値はクラス・セレクタのコードポイントとして扱われ、互換性のある処理方法はDiffservアーキテクチャに記述されている。RFC 793及び1122によって定義されたRFC TCP仕様には、コネクションがいずれかのエンドポイント・アプリケーションによって要求された最も高い優先順位を使用し、コネクション全体で優先順位の一貫性を保つことを意図したロジックが含まれていた。廃止されたTOSのこのロジックはDiffservには適用されず、TCP実装に含めるべきではない。ただし、コネクション内でのDiffserv値の変更は推奨しない。これに関する議論は、RFC 7657(セクション5.1、5.3、及び6)[50]を参照のこと。

廃止されたTCPのTOS処理ルールは、コネクション上で使用される双方向(または対称)の優先順位の値を前提といたが、Diffservアーキテクチャは非対称である。この点に関する古いTCPのロジックの問題は[25]で説明されており、TCPのIP優先順位を無視するという解決策が説明されている。RFC 2873は標準化過程文書であるため(ただし、RFC 793を更新するものとしてマークされていない)、現在の実装はこのような状況でも堅牢であることが期待される。各方向で使用されるDiffservフィールド値はTCPとネットワーク層の間のインタフェースの一部であり、使用されている値は、TCPとアプリケーションの間で双方向に示すことができることに留意する。

A.1.2. MLSシステム

[1]で定義されているIPセキュリティ・オプション(IPSO)とコンパートメントは、RFC 1038で改良されたが、後にRFC 1108で廃止された。商用IPセキュリティ・オプション(CIPSO)はFIPS-188(2015年にNISTによって廃止された)で定義されており、一部のベンダーとオペレーティング・システムでサポートされている。RFC 1108は現在歴史的(Historic)になっているが、RFC 791自体はIPセキュリティ・オプションを削除するよう更新されていない。IPv6では、同様のオプション(Common Architecture Label IPv6 Security Option (CALIPSO))が定義されている[36]。RFC 793には、TCPセグメントの処理におけるIPセキュリティ/コンパートメント情報を含むロジックが含まれている。本文書のIPの「セキュリティ/コンパートメント」への言及は、マルチレベル・セキュア(MLS)システムの実装者に関連するかも知れないが、インターネット上で実行するコードと矛盾しないように、MLS以外の実装では無視できる。詳細については、付録A.1を参照のこと。RFC 5570では、IPSO、CIPSO、またはCALIPSOが使用される可能性がある、いくつかのMLSネットワーク・シナリオについて説明されていることに留意する。このような特殊なケースでは、TCP実装者はRFC 5570のセクション7.3.1を参照し、この文書のガイダンスに従う必要がある。

A.2. シーケンス番号の検証

TCPシーケンス番号検証ルールによって、ACKフィールドの処理が妨げられる場合がある。これは、同時オープン、自己接続、同時クローズ、同時ウィンドウ・プローブの条件における潜在的な問題についての記述を含む[64]で述べられているように、コネクションの問題につながる可能性がある。本文書では、許容できるシーケンス番号を拡張することで、この問題を軽減するためのTCP仕様の変更の可能性についても説明している。

インターネットでのTCPの使用では、このような状況はほとんど発生しない。一般的なオペレーティング・システムは、さまざまな代替緩和策を持っており、そのいずれかを成文化するための標準はまだ更新されていないが、実装者は[64]に記述されている問題を考慮する必要がある。

A.3. Nagleの修正

一般的なオペレーティング・システムでは、Nagleアルゴリズムと遅延確認応答の両方を実装しており、デフォルトで有効になっている。TCPは、要求/応答形式の通信を行う多くのアプリケーションで使用されており、Nagleアルゴリズムと遅延確認応答の組み合わせにより、アプリケーションのパフォーマンスが低下する可能性がある。このようなアプリケーションの状況を改善するNagleアルゴリズムの修正が[68]に説明されている。

この変更はいくつかの一般的なオペレーティング・システムに実装されており、TCPの相互運用性には影響しない。さらに、一般的にソケット・オプションでサポートされているため、多くのアプリケーションは単にNagleを無効にしている。TCP標準は、このNagleの修正を含むように更新されていないが、実装者はそれを考慮することが有益であると考えるかも知れない。

⚠️ 参考

<https://zenn.dev/moatdrive/articles/marcs-blog-nagle>

A.4. 低水準点の設定

オペレーティング・システムのカーネルTCP実装の中には、ソケット層が送信データをTCPに渡すまで(SO_SNDLOWAT)、または受信時にアプリケーションに渡すまで (SO_RCVLOWAT)のバッファのバイト数を指定できるソケット・オプションを含まれている。

さらに、別のソケット・オプション(TCP_NOTSENT_LOWAT)を使用して、書き込みキューの未送信バイト量を制御できる。これは、送信側TCPアプリケーションが大量のバッファデータ(及びそれに対応する遅延)を作り出すことを回避するのに役立つ。例として、これは、複数の上位レベルのストリームからのデータをコネクションに多重化するアプリケーション、特にストリームがインタラクティブ/リアルタイムとバルクデータ転送が混在している場合に有用である。

付録B. TCP要件の概要

このセクションはRFC 1122から改変されたものである。

このリストにはPLPMTUDに関連する要件はないが、PLPMTUDが推奨されていることに留意すること。

機能	ReqID	MUST	SHOULD	MAY	SHOULD NOT	MUST NOT
PUSHフラグ
プッシュされていないデータを集約またはキューに入れる	MAY-16			X
送信者は連続するPSHビットを折り畳む	SHLD-27		X
SEND呼び出しはPUSHを指定できる	MAY-15			X
* 指定できない場合: 送信側バッファは無期限になる	MUST-60					X
* 指定できない場合: PSH最後のセグメント	MUST-61	X
受信者のALP(1)にPSHを通知する	MAY-17			X
可能な限り、最大サイズのセグメントを送信する	SHLD-28		X
ウィンドウ
符号なし数値として扱う	MUST-1	X
32ビット数値として扱う	REC-1		X
ウィンドウを右から縮小する	SHLD-14				X
* ウィンドウが縮小時に新しいデータを送る	SHLD-15				X
* ウィンドウ内で古い未確認データを再送する	SHLD-16		X
* 右端を越えたデータに対してコネクションをタイムアウトする	SHLD-17				X
ウィンドウの縮小に対して堅牢である	MUST-34	X
受信側のウィンドウを無期限に閉じる	MAY-8			X
標準的なプローブ・ロジックを使用する	MUST-35	X
送信側のプローブがゼロ・ウィンドウとなる	MUST-36	X
* RTO後の最初のプローブ	SHLD-29		X
* 指数関数バックオフ	SHLD-30		X
ウィンドウを無期限にゼロのままにすることを許可する	MUST-37	X
SND.UNA+SND.WNDを超えて古いデータを再送する	MAY-7			X
ゼロ・ウィンドウでもRSTとURGを処理する	MUST-66	X
緊急データ
緊急ポインタのサポートを含める	MUST-30	X
ポインタは最初の非緊急オクテットを示す	MUST-62	X
任意の長さの緊急データ・シーケンス	MUST-31	X
ALP(1)に非同期で緊急データを通知する	MUST-32	X
ALP(1)は、緊急データが送信されたかどうか、どのくらいの量が送信されたかを知ることができる	MUST-33	X
ALPは緊急メカニズムを採用する	SHLD-13				X
TCPオプション
必須のオプション・セットをサポートする	MUST-4	X
任意のセグメントでTCPオプションを受信する	MUST-5	X
サポートされていないオプションを無視する	MUST-6	X
EOL+NOP以外のすべてのオプションの長さを含める	MUST-68	X
不正なオプション長に対処する	MUST-7	X
ワード・アライメントに関係なくオプションを処理する	MUST-64	X
MSSオプションの送受信の実装	MUST-14	X
IPv4 MSSオプションの送信(536を除く)	SHLD-5		X
IPv6 MSSオプションの送信(1220を除く)	SHLD-5		X
MSSオプションを常に送信する	MAY-3			X
IPv4の送信MSSのデフォルトは536	MUST-15	X
IPv6の送信MSSのデフォルトは1220	MUST-15	X
有効な送信セグメント・サイズを計算する	MUST-16	X
MSSはさまざまなMTUを考慮する	SHLD-6		X
MSSは非SYNセグメントでは送信しない	MUST-65					X
MMS_Rに基づくMSS値	MUST-67	X
ゼロを埋め込む	MUST-69	X
TCPチェックサム
送信側はチェックサムを計算する	MUST-2	X
受信側のチェックサムをチェックする	MUST-3	X
ISNの選択
クロック駆動のISNジェネレータ・コンポーネントを含む	MUST-8	X
PRFコンポーネントを使用したセキュアな ISNジェネレータ	SHLD-1		X
ホスト外部からPRFを計算可能にする	MUST-9					X
コネクションを開く
同時オープン試行をサポートする	MUST-10	X
SYN-RECEIVEDは最後の状態を記憶する	MUST-11	X
パッシブOPEN呼び出しが他の呼び出しに干渉する	MUST-41					X
機能: 同じポートを同時にLISTENする	MUST-42	X
必要に応じて、SYNの送信元アドレスをIPに問い合わせる	MUST-44	X
* それ以外の場合は、接続のローカル・アドレスを使用する	MUST-45	X
ブロードキャスト/マルチキャストIPアドレスに対してOPENする	MUST-46					X
ブロードキャスト/マルチキャスIPアドレスへのセグメントを静かに破棄する	MUST-57	X
コネクションを閉じる
RSTはデータを含むことができる	SHLD-2		X
中断されたコネクションをアプリケーションに通知する	MUST-12	X
半二重でコネクションを閉じる	MAY-1			X
* データ損失を示すためにRSTを送信する	SHLD-3		X
2MSL秒間のTIME-WAIT状態	MUST-13	X
* TIME-WAIT状態からのSYNの受け入れ	MAY-2			X
* タイムスタンプを使用して待ち時間を短縮する	SHLD-4		X
再送
指数関数的バックオフ、スロースタート、輻輳回避を実装する	MUST-19	X
同じIP IDで再送する	MAY-4			X
カーンのアルゴリズム	MUST-18	X
ACKの生成
可能な限り集約する	MUST-58	X
順序が乱れたセグメントをキューに入れる	SHLD-31		X
ACKを送信する前にすべてのキューを処理する	MUST-59	X
順序が乱れているセグメントに対して ACKを送信する	MAY-13			X
遅延ACK	SHLD-18		X
* 遅延 < 0.5 秒	MUST-40	X
* 2つ目のフルサイズ・セグメントまたは 2*RMSSごとにACKを送る	SHLD-19		X
受信側のSWS回避アルゴリズム	MUST-39	X
データの送信
設定可能なTTL	MUST-49	X
送信側SWS回避アルゴリズム	MUST-38	X
Nagleアルゴリズム	SHLD-7		X
* アプリケーションはNagleアルゴリズムを無効にできる	MUST-17	X
コネクションの失敗
R1再送時にIPに否定的なアドバイスを与える	MUST-20	X
R2再送時にコネクションを閉じる	MUST-20	X
ALP(1)はR2を設定できる	MUST-21	X
ALPにR1<=retxs<R2を通知する	SHLD-9		X
R1の推奨値	SHLD-10		X
R2の推奨値	SHLD-11		X
SYNと同じメカニズム	MUST-22	X
* R2はSYNに対して少なくとも3分	MUST-23	X
キープアライブ・パケットの送信
キープアライブ・パケットを送信する:	MAY-5			X
* アプリケーションは要求できる	MUST-24	X
* デフォルトは「オフ」	MUST-25	X
* 一定期間アイドル状態の場合のみ送信する	MUST-26	X
* インターバルを設定できる	MUST-27	X
* デフォルトは少なくとも2時間	MUST-28	X
* ACKの損失を耐性がある	MUST-29	X
* データなしで送信する	SHLD-12		X
* ガベージ・オクテットを送信するように設定できる	MAY-6			X
IPオプション
TCPが理解できないオプションを無視する	MUST-50	X
タイムスタンプのサポート	MAY-10			X
レコードルートのサポート	MAY-11			X
ソース経路:
* ALP(1)で指定できる	MUST-51	X
** データグラム内のソース経路をオーバーライドする	MUST-52	X
* ソース経路からリターン経路を構築する	MUST-53	X
* 後にソース経路をオーバーライドする	SHLD-24		X
IPからの ICMP メッセージの受信
IPからのICMPメッセージを受信する	MUST-54	X
* 宛先未到達 (0,1,5) => ALPに通知	SHLD-25		X
* 宛先未到達時 (0,1,5) に中断	MUST-56					X
* 宛先未到達 (2-4) => コネクションを中断	SHLD-26		X
* ソースクエンチ => サイレント破棄	MUST-55	X
* 時間を超過した場合の中断	MUST-56					X
* パラメータの問題で中断	MUST-56					X
アドレスの検証
無効な IP アドレスへのOPEN呼び出しを拒否する	MUST-46	X
無効なIPアドレスからのSYNを拒否する	MUST-63	X
ブロードキャスト/マルチキャスト・アドレスへのSYNをサイレント破棄する	MUST-57	X
TCP/ALPインターフェースサービス
エラーレポートのメカニズム	MUST-47	X
ALPはエラー レポート・ルーチンを無効にできる	SHLD-20		X
ALP は送信用の Diffserv フィールドを指定できる	MUST-48	X
* 変更せずにIPに渡す	SHLD-22		X
ALPは中にDiffservフィールドを変更できる	SHLD-21		X
ALPは通常、接続中にDiffservを変更できる	SHLD-23				X
受信したDiffservフィールドをALPに渡す	MAY-9			X
FLUSH呼び出し	MAY-14			X
OPENのオプションのローカルIPアドレス・パラメータ	MUST-43	X
RFC 5961のサポート
データ・インジェクション保護を実装	MAY-12			X
明示的輻輳通知
ECNをサポート	SHLD-8		X
代替輻輳制御
代替適合アルゴリズムを実装	MAY-18			X

表8 : TCP 要件の概要

脚注: (1) 「ALP」とは、アプリケーション層プログラムを意味する。

謝辞

本文書は、 ジョン・ポステルが編集を担当したRFC 793の大部分を改訂した版である。彼の優れた仕事のおかげで、私たちが改訂の必要性を感じるまで、30年間存続することができた。

アンドレ・オッパーマンは寄稿者であり、本文書の最初の改訂版の編集に協力した。

本文書の作成における、IETF TCPMワーキング・グループの議長の支援に感謝する。

マイケル・シャーフ

西田佳史

パシ・サロラティ

マイケル・テュクセン

TCPMメーリング・リスト、ワーキング・グループ会議、およびエリア・レビューにおいて、有益なコメント、批評、レビューが次の人物から届いた(名字のアルファベット順に列挙): プラヴィーン・バラスブラマニアン、デビッド・ボーマン、モハメド・ブカデール、ボブ・ブリスコ、ニール・カードウェル、ユチュン・チェン、マーティン・デューク、フランシス・デュポン、テッド・フェイバー、ゴリー・フェアハースト、フェルナンド・ゴント、ロドニー・グライムス、イー・ファン、ラーフル・ジャダフ、マルク・コジョー、マイク・コセック、ジュハマティ・クウシサーリ、ケビン・レイヒー、ケビン・メイソン、マット・マティス、スティーブン・マクイスティン、ジョナサン・モートン、マット・オルソン、トミー・ポーリー、トム・ペッチ、ハーゲン・パウル・ファイファー、カイル・ローズ、アンソニー・サバティーニ、マイケル・シャーフ、グレッグ・スキナー、ジョー・タッチ、ミヒャエル・テュクセン、レジー・ヴァルゲーズ、バーニー・ヴォルツ、ティム・ウィチンスキー、ロイド・ウッド、アレックス・ジマーマン。

順番は、原文の通り

ジョー・タッチは、セグメント・サイズのパラメータとPMTUD/PLPMTUDの推奨事項の説明を明確にするための追加の支援を行なった。マルク・コジョは、TCP輻輳制御に関するセクションの文章のまとめを手伝ってくれた。

本文書には、以下の人物が報告した正誤表の内容が含まれている(時系列順にリスト): イン・シュウミン、ボブ・ブレーデン、モリス・M・キーサン、ペイチュン・チェン、コンスタンティン・ハーゲマイヤー、ヴィシュワス・マンラル、ミキータ・イェフスティフェエフ、イ・ウンジュン、ホアン・ボトング、チャールズ・デン、マーリン・バグ。

著者のアドレス

ウェスリー・M・エディ (編集者)
MTI Systems
アメリカ合衆国
メール: [e-mail]

更新履歴

• 2024.6.11
• 2024.6.22