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.
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.
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?
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.
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?
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.
Kind regards,
--
Fernando Gont
e-mail: fernando(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf