Summary

  • TCP、UDP、SCTP のポートは終端の振り分けと既定の待ち合わせには役立つが、アプリケーション、内容、利用者、意図を認証しない。
  • ポートから推測したサービスを強制的な判定に使うと、正当な通信を止める一方、通信を別ポート、動的交渉、中継、カプセル化、暗号化へ誘導し得る。

経路上で確実に読めるのは、外側のプロトコル番号、アドレス、可視な場合のポートである。登録表を参照すれば、その番号の既定用途も分かる。だが、実際のプログラム、相手の認証、利用許可、通信内容、サービスの成否は別の証拠を要する。

RFC 3639 は、周知ポートであっても意味が保証されるのは終端システムに対してだけだと述べる。終端から明示的な信号を受けるか、当事者と経路装置の間に取り決めがない限り、途中の装置は特定の意味を一般に読み込むべきではない。二つの終端は任意のポートを選べる。制御交換の中で後続ポートを決めるプロトコルもある。交渉に加わらず、その結果も通知されていない装置には、番号と実サービスを結ぶ根拠がない。

それでも安定した番号には価値がある。既定の接続先、集計分析、負荷把握、ファイアウォール、品質制御に使える。RFC の争点は利用の可否ではなく、確信の上限である。ポート 25 を止めて迷惑メールを抑えようとすれば、正当なメールまで止める可能性がある。この例は現在の特定事業者の実測ではなく、規則の適用範囲が証拠を超える危険を示す。

さらに制御は相手の設計を変える。別ポート、プロキシ、動的交渉を使うことも、元のパケットを別の外装に入れることもできる。GRE では経路に見えるヘッダーが変わり、ESP では内側の情報が隠れ、暗号化され得る。利用者が望む暗号化やセキュリティは不正の証拠ではない。安定した手掛かりを締め付ければ、その手掛かりが将来も見えるとは限らない、という因果が重要だ。

RFC 7605 は、ポートとサービスの対応は究極的には終端間の合意であり、途中の解釈は誤り得ると再確認した。RFC 6335 と IANA のサービス名・ポート番号登録表 は既定値を調整するが、通信の正体を認証しない。TCP、UDP、SCTP のポートは終端通信を振り分け、IP プロトコル番号登録表 は別の数値空間を調整する。それらはアプリケーションの本人確認ではない。

RSVP のようにネットワークへ明示的に伝える場合や、SIP のように通信条件を動的に決める場合、正当に参加する装置はより強い情報を得られる。それでも信号、相手の身元、方針上の許可、実際の提供結果は一つではない。

文書の地位と範囲は RFC Editor 情報、Datatracker、履歴、正誤表、テキスト版で確認できる。Lu Heng の現実の層、最小共通仕様、稼働するコードの優先という視点を当てれば、登録された記号、終端の実利用、制度上の判断を混ぜない理由が見える。