Transmission Control Protocol
ISBN 0-13-066102-3
↑ Security Assessment of the Transmission Control Protocol (TCP)
↑ Security Assessment of the Transmission Control Protocol (TCP)
↑ http://www.gont.com.ar/talks/hacklu2009/fgont-hacklu2009-tcp-security.pdf Some insights about the recent TCP DoS (Denial of Service) vulnerabilities
↑ Exploiting TCP and the Persist Timer Infiniteness
↑ Laurent Joncheray, Simple Active Attack Against TCP, 1995
1 2 the TCP provides a set of addresses or ports within each host. [rfc:793 RFC 793 - TRANSMISSION CONTROL PROTOCOL]
↑ "Glossary ... socket ... An address that specifically includes a port identifier, that is, the concatenation of an Internet Address with a TCP port." RFC 9293.
IPはパケットの送出を可能にするがパケットの到達を保証しない。TCPは到達確認とデータ再送要求を提供することで、送出されたセグメントが宛先へ到達することを保証する。
TCPの使用で明らかになった主要な問題は、ヘッドオブラインブロッキングとマルチホーミングの欠如による、コールシグナリングに許容できない遅延の発生である。さらに、TCPの多くの用途は適切とはいえない。(少なくとも通常の実装での)最大の問題は、喪失パケットの再送を受信してからでないと受信済みの後続のパケットをアプリケーションで利用できない点である。特にストリーミング、オンラインゲーム、VoIPなどのリアルタイム型アプリケーションで重要な問題であり、データの順序性よりも適時性が重要である。
歴史的・性能的理由により、ストレージエリアネットワーク (SAN) はTCP/IPよりもファイバーチャネルプロトコルを採用することが多い。
組み込みシステムでも、ネットワークブートや多数のクライアントからの簡単な要求を受け付けるサーバ(例えばDNSサーバ)でTCPの複雑さが問題となる可能性がある。さらには、STUNなどの NAT traversal 技法では相対的に複雑なTCPを使わずに、遥かに単純な方法で実現している。
すると送信側は 0 から 999 までのバイトを含む最初のパケットだけを再送する。
SACKオプションの拡張として RFC 2883 で定義されたデュプリケートSACK (D-SACK) オプションがある。パケットの順序がばらばらになると、送信側への確認応答も順序どおりにならないため送信側でパケット喪失と勘違いし、喪失したと思われるパケットを再送することがあり、同時にネットワーク輻輳を防ぐため送信ペースを落とす。このとき、受信側が D-SACK オプションで再送パケットが重複していることを通知すれば、遅くなっていた送信ペースを元に戻すことができる。
SACKオプションは必須ではなく、両者がサポートしている場合だけ使われる。これはコネクション確立時に調整される。SACKオプションは主なTCPスタックでサポートされており、広く使われている。選択確認応答は Stream Control Transmission Protocol (SCTP) でも使われている。
TCPは様々な方法で攻撃される可能性がある。TCPの完全なセキュリティアセスメントの結果は、認識されていた問題の考えうる対策と共に2009年に公表され、その後もIETF内で進められている。