$Id: tcpm.jhtml,v 1.7 2004/11/25 03:52:26 nishida Exp $

tcpm related docs

RFCs

I-Ds

F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP

誤ったRTOの expireによる再送の検出。
同種の提案に、Eifelや DSACKがあるが、F-RTOは TCP optionを利用しないのが特徴。 senderのみの修正で実装できる。しかし、Eifelと DSACKは packet reorderなどの eventで生じる不必要な再送も検出できる。
RTOが expireした時、F-RTOは通常の再送を行うが（ここまでは標準と同じ動作）、その後以前に送っていないデータを転送する。
もし、timeout後に到着した１、２番目の ACKが共に windowを進める ACKだった場合 F-RTOはこのRTOが誤りだったと見倣す。しかし、もしどちらかの ACKが DUPACK だった場合、slow-startで unackな segmentを転送する。SACK-basedの F-RTOの場合、dupackからでも supurious timeoutを検出できる。

RTOが expireしたら first unacknowledged segmentを送出し、 SpuriousRecoveryを falseにセットする。また highest seqnoを recoverに記録。
最初のACKが返ってきたときに、ACKによって動作を変える。
dupackか recoverと同じACKが返送された場合、従来の RTO処理へ戻る。

Improving the robustness of TCP to Non-Congestion Events.

通常TCPは 3 dupackの受信を輻輳の開始と判断しているが、この判断は無線環境や packet reorderが瀕出する環境では必ずしも正しくない。この問題に対処するために、 TCPの輻輳に対する反応を短い時間遅延させ、dupackが輻輳ではない eventから生じたものかどうかを判定する期間を設ける提案。

Transmission Control Protocol security considerations.

昔から指摘されていたTCPのセキュリティ上の問題点とその対策について解説したもの。

Blind reset attack using RST bit
特定のTCPコネクションにRST送る攻撃を行う場合、攻撃者はコネクション中の sequence numberを推測する必要があると思われていたが、実際は最後に ACKされた sequence numberと、最後に receiver windowに加えられた sequence numberの間にある数値を推測できればよい。
つまり、攻撃者は 2^32の空間ではなく、2^32/(RCV.WND *2)の空間から目的の数値を推測すればよい。このことから、攻撃者は(双方のポート番号を知っていると仮定すると）約200秒以内にはコネクションをresetできることになる。最近のTCPは Window Sizeを大きめに設定(64K)している場合が多いので、この攻撃を受ける確率が高くなる。

対策
RFC793では、RST bitの立ったパケットのシーケンス番号(SEG.SEQ)が、
(RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND)を満たす場合、コネクションを resetしていたが、これを以下の様に変更する。
- RCV.NXT = SEG.SEQなら reset
- RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WNDの場合、ACKを返す。
Blind reset attack using the SYN bit
上記とほぼ同様の手段だが、RSTではなく SYN bitを使ってコネクションをリセットする攻撃

対策
RFC793では、SYN bitの立ったパケットのシーケンス番号(SEG.SEQ)が、
(RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND)を満たす場合、コネクションを resetしていたが、これを以下の様に変更する。
- RCV.NXT = SEG.SEQなら acknouwledgeされたseqnoから１を引いた値で ACKを返す。
- RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WNDの場合、ACKを返す。
legitimateなpeerは ACKを受信するとコネクションをリセットする。
Blind Data injection attack
上記２つの攻撃の応用。sequence番号を guessし、SYNも RSTも立てないパケットを送信することにより、TCP connectionにデータを紛れ込ますことができる。TCPは、ACKが
(SND.UNA - (2^32 -1)) <= SEG.ACK < SND.NXTの場合、正しいと判断するので、攻撃者はシーケンス番号とACK番号の (2^32/RCV.WND *2)) * (2^32 /(SND.WND *2)通りの組合せを試せばよい。

対策
ACK番号のチェックを厳しくする。
SND.UNA - MAX.SND.WND <= SEG.ACK < SND.NXTの場合、正しいと判断する。この対策はアタックされる確率を減らすだけでなので、より完全な対策を求める場合は、 RFC2385の手法を試すべき。

A Roadmap for TCP Specification Documents.

TCPやその拡張を規定する RFCドキュメントを示したもの。

Base: RFC793, RFC1122, RFC1323, RFC2873, RFC2988
Congestion Control: RFC2581, RFC3042, RFC3168, RFC3390 RFC3782
SACK-based loss recovery: RFC2018, RFC2883, RFC3517

RFC1156, RFC2012, RFC2452

RFC1144, RFC1948, RFC2140, RFC2488, RFC2525, RFC3360, RFC3449, RFC3481, RFC3493

RFC2861, RFC3465, RFC3522, RFC3540, RFC3649, RFC3742

RFC1146, RFC1644, RFC1693
RFC1644,RFC1379は複雑すぎ、DOSに弱いなどの問題がある。
RFC1693は、この拡張を利用するアプリの目的が TCPのそれと一致していなかったり、アプリはこの extenssionを使わず別のプロトコルを利用している。

back