Re: [tcpm] tcpsecure recommendations

> There are three issues listed in the ID:
> 
> "Blind reset attack using the RST bit"
> "Blind reset attack using the SYN bit"
> "Blind data injection attack"
> 
> The third one says "data corruption may result" - IMO, data 
> corruption is a possibility any time you don't use strict 
> authentication, so it's inaccurate to imply that if these 
> checks are in place that data corruption won't occur (which 
> is what is implied, IMO).

"data corruption may result" because it is not the data what the
application intended to receive in the first place. Keeping the focus
intact, the liberal ACK allowed by the RFC has led to this condition
which otherwise would have been prevented. So data corruption can happen
in various places and various layers, we are simply talking about
plugging one hole which is in the jurisdiction of TCP.

> 
> The ACK war doesn't take down the connection. What takes down 
> the connection is that it accepted data it shouldn't have. 
> IMO, the UTO taking the connection down at this point is not 
> as much an attack succeeding, as it is TCP succeeding in not 
> letting the attack go unnoticed.

Agree that the connection might get torn down due to UTO/application
timeout, but why did this happen due to the liberal ACK range allowed.
Now this is what is being debated and the mitigation suggested. 

> 
> Again, I don't see this case as needing a SHOULD. This is a 
> data plane issue, not, IMO, a control plane one.

Data plane versus control plane, the distinction becomes blurry when FIN
comes into picture... Not sure how the data/control plane distinction is
made and why it is needed for determining the strength of the
mitigation. You haven't made this clear so far. 

> 
> ...
> | Data injection is about strict ACK checking and applies to 
> FIN segments.
> | To re-iterate: preventing anything which causes the connection tear 
> | down maliciously is critical. So it could be a RST/SYN or 
> Data or FIN.
> 
> If preventing anything that could cause a malicious teardown 
> is critical, then use of strict authentication is required. 
> Implications to the contrary endorse the use of this 
> "protocol robustness" mechanism for true security (a 
> misconception that the title doesn't help abate).

Agreed but again the above statement doesn't help in debate which we are
having, ie., the strength of the data mitigation. All so far I can
gather is that : somehow you are saying data mitigation is tied to "data
plane" and the rest are tied to control plane and hence in one case is a
SHOULD and the other a MAY. Sounds very dubious to me.

-Anantha
_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm