-----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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf