-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Joe Touch wrote: > >>> So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a >>> trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue >>> in this line, because we do nothing about it. >> Whether we have this document or not, we will continue to have people >> who incorrectly assume that TCP is secure. > > That's correct. But we also have people that do know it is not mean to > be secure, but that it should be resilient enough so that it's still > usable. One way or another, most stacks implement counter-measures for > SYN-floods (on which tcpm did publish something), timers on the > FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP > ISN randomization, etc. > > The reason for which they did that was to improve TCP's security/resiliency. > > Would you argue in favour of predictable ISNs, predictable ports, > time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't. These measures can be used to reduce the impact of attacks when TCP is not secured. However, they DO NOT make TCP secure. They DO make TCP more brittle - they limit the way in which two legitimate endpoints can do legitimate things. >>>> It summarizes issues already raised by the WG, >>> I believe this statement is unfair with respect to our document. e.g., >>> has the issues described in Section 4.3, Section 9.2, or Section 10 been >>> brought to tcpm before??? >> I didn't say that's all it does ;-) Agreed that it raises other issues, >> many of which are operational. > > Many of which arise if you expect to use TCP in some other scenario that > just two computers in a LAN. If that makes those issues "operational", I > agree. Many of those don't arise for computers in a wide area, or with millions of other computers on the network either. They arise only when there are active attacks, and only for some kinds of attackers (on-path, off-path, high-speed access, etc.) IMO, any decision which would be enabled or disabled depending on whether security was a concern or performance was needed is operational. E.g., port randomization helps only when attackers are off-path and when port use is a fraction of the active port space. That's operational. Ditto for ISN randomization. I.e., if the protection is not needed in the absence of attacks, it may be operational. >>>> TCP itself is not a secure protocol, nor is it intended to be. >>> Yeah. But that does not mean that we should not do our best to improve >>> it. >> It means we should not try to give the incorrect impression that it >> *can* be secured. > > It's security/resiliency can be improved. After all, if that were not > the case, I guess you're wasting your time with TCP-AO. Or is it that > you believe the only way to improve a protocol is to throw crypto at it? I *know* that the only way to secure a protocol is to throw crypto at it. I also *know* that unexpected packets are *not* indications of attacks. These two things are not evident in this document, and should be. Further, this document should make a case as to whether the improvements are operational or not. AFAICT, most are operational. >> Interpreting every unexpected event as an attack makes >> a protocol robust but also brittle; TCP is intended to trade flexibility >> for security, AFAICT, because it is agnostic about intent, and gives the >> benefit of doubt at all times. > > I would prefer that instead of making this type of broad statement, you > would argue against a particular recommendation in > draft-gont-tcp-security, and explain how it makes TCP more brittle. Randomizing ports and ISNs assumes there is a window over which some values are NOT used; that window precludes legitimate exchanges from occurring. That is what I mean by "brittle." >> Consider packet drops. That can happen due to loss, non-malicious >> corruption, or jamming, e.g. In the last case, it makes sense to blast >> copies of packets in the hopes of getting something through, but that's >> NOT what we assume. > > Wasn't this very behavior what lead to the Internet congestion collapse > in the 80's, or am I missing something? Loss of a segment can mean: a) congestion (correlated drops) b) non-correlated drops (not related to increasing traffic) c) active removal (attack) If (a), then you backoff. That's how congestion collapse was addressed. If you believe that packet drops are caused by either non-correlated drops or active removal, you send MORE - you send copies of each packet, e.g. That is NOT what we assume, but what I presume you ought to recommend in a document that assumes that every event that COULD have been an attack probably is an attack. >>> Please talk to vendors. I don't want to reproduce here what seems to >>> be the consensus among vendors with respect to the current state of >>> affairs in terms of how up-to-date our specs are. >> Vendors misapply our protocols then complain that they don't work. Yes, >> there are operational issues, but one severe operational issue is not >> using security for some policy, financial, or operation expense and then >> complaining that nonsecure TCP is being attacked. > > Joe, we're talkng about a simple web server being taken down because of > a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web > server should survive these types of attacks. If you're talking about implementation advice (don't put all your resources in pending connections), I agree that a good implementation should be implemented well. But that's operational / implementation advice, not protocol advice. I do not agree that all web servers should implement SYN cookies, e.g. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjqFYACgkQE5f5cImnZrtBNwCgiJPsTDBt34Im+s/TFkBm90DE Xn4AoNlUvCAucvZoVVMTpex4sMXAaXb2 =1ijT -----END PGP SIGNATURE----- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf