-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fernando Gont wrote:
Joe Touch wrote:
The consensus seems to be that the current state of affairs is something
like: "a mess". Even if you do care to produce a resilient
implementation, that task is going to be much harder than necessary. You
don't know the amount of cycles we spent in producing
draft-gont-tcp-security.... let alone the time it would take to move the
advice in an actual implementation.
Advice in making a hardened version of TCP would be useful to the
implementation community.
To a large extent this is what draft-gont-tcp-security is about.
Implementation advice is outside the scope of the IETF. It's not even
operational, IMO.
However, if you're saying that TCP specs in general are a mess, yes they
are. That's why we created a roadmap document, and why it needs to be
maintained. If you're suggesting we need a clean single documentation of
what TCP is, I might even agree. However:
1) TCPM is not the place that would generate it
(IMO, that'd be TSVWG)
2) this document is not a step in that direction
The tcp roadmap is a roadmap to the documents that the IETF has
published. There's lots of stuff that has not been published by the IETF
and that therefore is not discussed in the tcp roadmap.
This is another area in which this document tries to help.
Those are documents that the IETF may or may not agree with. Neither
"Implemented" nor "published" doesn't mean we should endorse that solution.
You've produced a summary of issues you feel would harden TCP. I feel
that some of them make TCP more brittle, and some make TCP unnecessarily
complex, and in both cases the mods are not needed in the general
Internet.
Is there nothing in the document with which you agree?
That'd be harsh. I agree with some of the implementation advice as
implementation advice. I agree that, in risk-prone environments (where
packets can be tapped, e.g.), some of the recommendations are appropriate.
I'm disagreeing primarily with the general tone and balance of the document.
TCPsecure is a good example; it has caveats in its ID that
indicate where it is useful and where it is not -- it is NOT a general
solution for the entire Internet (the WG basically agreed to that with
the wording for its use cases).
c'mon Joe.. IMO, tcpsecure needed to include those statements about
usefulness in large part because it was IPR-encumbered, and in part as a
political workaround that would avoid further waste of time in endless
discussions.
I disagree. Even if it weren't IPR encumbered, I would disagree with
widescale deployment of a modification to TCP that answers a RST with
one *or more* ACKs. As I said numerous times w.r.t. that document, the
modifications it suggests are generally not needed, unnecessarily
complicate packet processing, and since they don't protect from
in-window injection attacks, I find them useless in the general case.
In many cases the lack of a straight answer may have to do with us being
unable to get to consensus and get something published in a timely
fashion. e.g., the last round on ICMP attacks against TCP was circa
2004. At that point an I-D was published on the subject (now
draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when
everybody did something about it five years ago.
Uh, well, we're deciding whether we agree with what's been deployed.
Deploying some of these changes hasn't always been a good idea; if it
were, we'd be agreeing to it.
Some people prefer to get work done instead of committing/wasting lots
of cycles in endless discussions.
Publishing recommendations without validating them isn't wasting time.
It becomes harder to get s staright answer when it's impossible for a
vendor to point to a counter-measure that is supposed to be the result
of a thorough review process, in a *timely* fashion.
Can you be as specific here as you want us to be? What exactly does a
vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing
known countermeasures?
What's "the existing known counter-measures"?
Limit cycles/resources available for new connections, e.g., for SYN
attacks -- as is already done for things like IKE.
I'm aware there's an effort in the vendor community to improve the
resiliency of TCP basedon the document published by UK CPNI. Yet we're
still debating whether to ignore it or not.... maybe so that we can
publish an RFC in the future tagging those implementations as
non-compliant... or maybe to allow tcp vulnerabilities to be
"rediscovered" every few years.
If the vendors are following this doc already, then we REALLY need to
ensure it's updated with advice appropriate to the context in which it
is deployed.
FWIW, vendors are following the UK CPNI document. The idea of bringing
those results to the IETF is so that these results/advice can be further
discussed, more eyes look into them, and the doc is modified if it is
felt necessary.
I've been saying I feel that mods are necessary, and you keep
complaining. If you're here for a rubber stamp, you came to the wrong WG ;-)
Running around saying the sky is falling for everyone isn't
going to help.
Who did that? We worked on this document very silently for a couple of
years. If we had wanted that "sky is falling" approach, we would have
gone to the press before showing anything (like quite a few folks have
been doing in the recent past). Or we could have announced part of this
stuff as "vulnerabilities" to the press..
The sky has been falling in this WG for several years. Although this
document is the first aggregation of such recommendations, as you know
it's composed of many documents you yourself have been discussing for
that period in this WG..
That wasn't the case.
I tried to get many people to review the document, and have the document
be as objective as possible. At least for the ip-security counterpart, I
recall asking you to have a look at it before publication, even when I
knew that you'd most likely disagree with large parts of the document.
This project is already done.... but nevertheless I'm still spending
some cycles to bring this to the IETF, because I truly believe the IETF
should work on it. Neither me nor UK CPNI have IPRs or anything on the
material covered in our document... so there's no hidden motivation in
all this.
Honestly, I'm not sure why you always have to knock down others' efforts
on a "by default" basis, and prejudge the motivation behind those efforts.
I'm asking the question I apparently keep needing to ask:
Why do you think that just because something is implemented
we should recommend it?
Why do you think that a message that isn't expected indicates
an attack to be defended against, vs. the actions of a
benign endpoint?
For this document, yes, this means:
Does the IETF need such a document at all?
If we do need such a document, is this the right content?
I have a high bar for the need for modifications to TCP, and the need to
propagate local solutions to every endpoint in the Internet. That is the
approach I expect of others in this WG, and yes, I'll speak out when
it's not the case.
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknjvtgACgkQE5f5cImnZru0lwCg6zvNwRNl9SBH1QcMo4Y7xnMz
vRwAoOVpLWkco+DKxLFhY26CVR2LtaJ5
=YkNg
-----END PGP SIGNATURE-----
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf