TCPその他の機能と性能 + TCP Fast Open + TLS False Start

Transcript

1. Chap. 24 TCPのその他の機能と性能 + TCP Fast Open & TLS False Start 詳解TCP/IP Vol.1 プロトコル @utushiiro
2. ▷ Table of contents ◦ Path MTU Discovery with TCP ◦ Long Fat Pipe ◦ Transaction TCP ▪ TCP Accelerated Open ▪ Truncate TIME_WAIT Delay ◦ TCP Fast Open ◦ TLS on TCP (TLS False Start)
3. パスMTUディスカバリ ▷ パスMTU ◦ 2 台のホスト聞の経路上に存在するネットワーク中で 最も小さい M T U ◦ ルータが転送するIPデータグラムをフラグメント化 するかを調べるためには, IPヘッダのDF(don’t fragment)ビット を使用する. ◦ DFが設定されているデータグラムのサイズがルータのMTUを 超える場合, ICMPエラー(※)を返す. ※ Destination Unreachable/Fragmentation needed and Don’t Fragment was set
4. パスMTUディスカバリ 1. コネクション確立後, 送信インタフェースのMTUから計算したMSSと, 他方のエンドから通知されるMSSのうち小さいものを セグメントサイズの初期値とする. 2. 初期値設定後, そのコネクションのTCPで送られる(すべての) IPデータグラムにDFビットが設定される. 3. 中継ルータがフラグメント化が必要になる場合に ICMPにより送信元にそのホップのMTUを通知する. 4. これを受けてMTUを更新する.
5. ▷ パスMTU機能のON/OFF ◦ net.ipv4.ip_no_pmtu_disc (Linux) ◦ net.inet.tcp.path_mtu_discovery (Mac) ▷ 最小MSS ◦ net.ipv4.route.min_pmtu (Linux) ◦ net.inet.tcp.minmss (Mac) MTU関連のカーネルパラメータ
6. DF bit on Mac & Linux TCPコネクションではパスMTUが有効だと DF ビットが設定される. ▷ Linux ◦ すべてのIPデータグラムで設定される ▷ Mac ◦ 一部のIPデータグラムには設定されていない ※ tcpdump tcp -vvvv で確認
7. Long Fat Pipe ▷ 帯域遅延積 ◦ 通信帯域幅 ✕ RTT ▷ Long Fat Network (LFN) ◦ 帯域遅延積の大きなネットワーク ◦ RFC1072で10^5以上のものがLFN ▷ Long Fat Pipe ◦ LFN上でのTCPコネクション
8. Long Fat Pipe上での問題点と対応 ▷ windowサイズ(16bit field)では不十分 ◦ Window Scale Option ▷ パケット損失のコストが大きい ◦ Selective Acknowledgement ▷ RTTの計測の間隔(window毎に一回)が長くなる ◦ Time Stamp Option ▷ シーケンス番号だけでは一意に識別できない恐れ ◦ Protection Against Wrapped Sequence これらはChap17, 18のスライドで説明済
9. Transaction/TCP TCPは仮想回線(コネクション指向)トランスポートサービス → コネクション確立・終了処理が伴う 数回のRequest/Responseで終わるような単純なサービスでは これらの処理はオーバーヘッドといえる よって, この種のサービスではUDPを使用することが多かった (e.g. DNS, SNMP) ただし, UDPを使うと信頼性を担保するためには 自前でそれらの機能を実装する必要がある
10. Transaction/TCP そこで, この種のサービスに適したTCPの拡張機能を作ろう → Transaction TCP(T/TCP, RFC1644) ※ここでのtransactionはDBの話で出てくるものとは関係ない T/TCPが提唱する機能は主に以下の２つ ▷ TCP Accelerated Open(TCP高速オープン) ◦ 一定期間内での二回目以降のコネクション確立の際の 3 way handshakeを省略する仕組み ▷ TIME_WAIT状態とそれに要求される2MSL待ちを短縮する
11. T/TCPでのTCP Accelerated Open Connection Count(CC)と呼ばれる32bitのカウンタを利用 コネクションが確立される毎にCCは増加する → コネクション毎にCCの値は異なる ※CCは各ホスト(C1,C2,S)で独立, 上記の”増加”, “異なる”は特定ホスト内の話 C1 S CC: X C2 CC: Y SでのCCキャッシュ C1 = X C2 = Y
12. T/TCPでのTCP Accelerated Open C3 S CC: Z’ SでのCCキャッシュ C3 = Z C4 = None C4 CC: W ▷ Z’ > Z なら 3-way-handshake を省略 そうでないなら3-way-handshake実行 ▷ 該当ホストのCCキャッシュが そもそも存在しないなら3-way-handshake実行
13. T/TCPでのTCP Accelerated Open TCP Accelerated Open は要するに, 一度コネクションが確立できたら, 以後一定期間 そのホスト間での新規のコネクションの確立には 確立処理(3-way-handshake)をしなくても 確立できると考えて省略する仕組み. ※前スライドではCCのみを簡単に説明したが 　実際はもう少し色々あるのでRFC参照
14. T/TCPでのTIME_WAITの短縮 TIME_WAITとは アクティブクローズを行ったホストが, 自分から相手へのコネクショ ンは切断し終わり(FIN&ACK), 相手からのコネクション切断要求の FINが来て, ACKを送り返した状態. この状態で一定時間経過後に, 双方のコネクションが切断された状 態(CLOSED)に遷移する.
15. 終了の状態遷移 FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED
16. TIME_WAIT → CLOSED はタイムアウトで遷移するが, このタイムアウト時間は 2MSL (Maximum Segment Linetime) MSL：TCPセグメントがネットワークで生存可能な時間の上限 FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED
17. なぜ 2 MSL ？ ▷ 最後のACKが喪失 → FIN が再送のケース ◦ 最後のACKが相手に届くのに(最高でも)1MSL ◦ これが損失して, 再送のFINが送られてくるのに1MSL ( ACKが２回以上紛失したらどうなるんだろうか？ 謎) CLOSED TIME_WAIT LAST_ACK CLOSED
18. この仕組みによって “信頼性の備えたコネクションの切断” を実現 もう一つのTIME_WAITの目的は “ネットワーク上の古い重複したセグメントの 期限切れを保証し, 再接続後の通信を阻害しない”
19. TCPは再送制御により, セグメントの重複が起きうる. あるコネクションを切断後に, 同一のIP・Portで新規接続する際に, 前のコネクションの重複したパケットが, 新しいコネクションに到着し て処理される恐れ(※)がある. このため, TCPは通信を行うホストの一方でもTIME_WAIT状態に ある場合は接続を拒否する. ※恐れ, としたのは基本的にはSequencingで弾かれる 　(sequence番号が不正でRSTを返す)ため.
20. サーバ等を再起動する際に , ソケットをTIME_WAITの状態にあるポートにbindしようと すると, EADDRINUSE(※)というエラーになる. とはいえ主要なTCPサーバソフトはこれを回避できる SO_REUSEADDRというオプションを有効にしているので, あんま起きない. ※Address already in use, アドレスは既に使用中です
21. TIME_WAITの短縮 TIME_WAITについて理解を深めたところで話を戻すと... TIME_WAITの短縮 → 2MSL(TIME_WAIT遅延)を短縮するということ 　 ホスト間で計測されたRTTをベースに 　 動的にTIME_WAIT遅延を算出 MSL短縮する場合, 古いコネクションのパケットが到着するかもし れない問題があるが, T/TCPではCCでコネクションを識別できるの で, 回避できる.
22. TCP Fast Open T/TCPは結局今使われているの？ → NO. セキュリティがガバガバ ただし, 同じようなアプローチ(※)でより精錬された プロトコルが誕生 → TCP Fast Open (RFC 7413) これは実際に使われている. ※ ２回目以降の3-way-handshakeをbypassingするという試み
23. TCP Fast Open TCP Fast Openでは T/TCPのCC(Connection Count)周りを より精錬された仕組み(TFO Cookie)に昇華 TFO Cookieとは サーバ側がクライアントのIPやサーバシークレットから暗号ア ルゴリズム(AES)を用いて作成するCookie クライアントは２回目以降の接続で使用するために サーバから受け取ったCookieをキャッシュする
24. TCP Fast Open - 初回通信 SYN + Cookie Request SYN, ACK + Cookie ACK サーバ側 Requestを受けて TFO Cookieを作成 クライアント側 送られてきた TFO Cookieを キャッシュする
25. TCP Fast Open - 初回以降の通信 SYN + Cookie + Data SYN, ACK + Data ACK サーバ側 受信したTFO Cookieを検証する 検証をパスすれば SYN, ACKのパケットに データを付加して送信 データ送信まで1RTTかかる (これを1-RTTと呼ぶ)のを0-RTTに
26. TLS on TCP SYN SYN, ACK ACK TLS Client Hello & etc TLS Server Hello & etc TLS Client Finished & etc Data(encrypted) TLS Server Finished & etc ▷ 通常のTLS on TCP クライアント, サーバの双方が Finishedを送受信し終えてから Dataの送受信へと進む つまり通常のTLS on TCPは 3-RTT
27. TLS False Start SYN SYN, ACK ACK TLS Client Hello & etc TLS Server Hello & etc TLS Client Finished & etc TLS Server Finished & etc Data(encrypted) ▷ TLS False Start Finishedを送信し終えたら 相手方からのFinished到着を 待たずにDataの送信を開始する これで 3-RTT が 2-RTT に
28. TCP Fast Open + TLS False Start SYN + Cookie + TLS Client Hello & etc SYN, ACK + TLS Server Hello & etc ACK + TLS Client Finished & etc Data(encrypted) TLS Server Finished & etc TFOと合わせることで 3-RTT が 1-RTT に！ TLS v3では 0-RTTを 目指してるっぽい セキュリティ的にいろいろ 厳しそうだけど...
29. TLS補足 TLS False Startは厳密にはセキュアではなくなる RFC 7918 Sec.4 中間者攻撃を受ける恐れがあるが 上記のRFCで定めている条件下での運用であれば 深刻という程ではない(たぶん) TLS等のセキュリティの話がわからない場合は 以下の本の内容程度は知っておこう (授業でやってるハズ) 暗号技術入門 第3版 秘密の国のアリス
30. Reference & Credit ▷ W. Richard Stevens. 1993. TCP/IP Illustrated (Vol. 1): The Protocols. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. ▷ Presentation template by SlidesCarnival