----- Original Message -----
From: "Fernando Gont" <fernando(_at_)gont(_dot_)com(_dot_)ar>
To: "Joe Touch" <touch(_at_)ISI(_dot_)EDU>
Cc: <tcpm(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>; "'Joe Abley'"
<jabley(_at_)ca(_dot_)afilias(_dot_)info>;
<opsec(_at_)ietf(_dot_)org>; "'Lars Eggert'"
<lars(_dot_)eggert(_at_)nokia(_dot_)com>; "'Eddy,Wesley M.
(GRC-RCN0)[Verizon]'" <wesley(_dot_)m(_dot_)eddy(_at_)nasa(_dot_)gov>
Sent: Tuesday, April 14, 2009 7:44 AM
Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security
Joe Touch wrote:
<snip>
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.
<snip>
If you're here for a rubber stamp, you came to the wrong WG ;-)
Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and
when it comes to advice on this issues, I believe it's even more
credible. Ask the question in bugtraq or full-disclosure, and that's
most likely the conclusion you'll get to.
Which is for me the crux of the issue. This document is a done deal, let it go.
On the other hand, looking at the references, I see that while much of it is
based on IETF RFC, there are also a number of IETF I-D cited and I think that
our efforts would be better spent progressing these to RFC, after which, this
document may be worth revisiting.
Tom Petch
I'm involved in the IETF, and honestly believe that the IETF should work
on this. I do know that the end result of that process would be such
that I probably won't be as happy with the resulting RFC than with the
UK CPNI document. But at least I would have helped to change the current
state of affairs a little bit.
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..
I'd probably argue that the case with tcpm is that at (many) times
protocol specifications have been taken as if they were casted in stone.
And unless one is part of some small circle of people that is supposed
to have been allowed by God to modify such specs, it will be very hard
there's no effort that takes less than quite a few years.
Very loud people take the time to maintain endless discussions, and most
mere mortals that need to get work done end up completely avoiding tcpm
altogether, because it requires a huge spend of time.
Virtually every developer that I know of won't care about what the end
result in tcpm is. At most, they will post a question to hear comments.
But that's it. To a large extent people cannot believe the amount of
energy we spend for such a null progress.
Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks).
The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD,
Linux, extreme networks, and Cisco (this last one "unofficially"). To
them, the draft looks okay. Many other people have also agreed with
that. But I cannot get those folks involved in our endless discussions.
The ROI for them is NULL.
Do they care about the outcome? Not really. They agree with the
proposal, it is in the code already, and has been running for years.
They just let us waste our time.
I agree that there are benefits to be gained from having a more
conservative philosophy, to put it some way. I believe that it is a good
thing to challenge proposals, to aim at improving their quality, etc.
This has helped improve many documents, including those I have authored.
But I believe at some point it starts looking as "everything that
neither me or my inner circle proposes will be banned".
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?
That's not how the tcp-security document was produced. For instance,
many of the recommendations had never been implemented. And the document
argues *against* some common implementation strategies.
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?
We simply raise the bar about what we react to. If there are packets for
which there's no legitimate use, we don't react to them (if this doesn't
cause harm).
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.
And do you believe that such propagation depends on our outcome? --
Thanks God, it doesn't. Try to find any implementation that is
fully-compliant with the RFCs, and let me know if you find any.
The lack of advice on all these issues has put vendors in a position in
which they have to figure out that advice by themselves. Sometimes they
got to the right answers, sometimes not.
Have a look at the vulnerability advisories referenced in the I-D: the
same errors are committed over and over again.
draft-gont-tcp-security is an effort to help the vendor/developer
community in that area.
P.S.: My apologizes for the possible politically-incorrect comments. But
this is the best trade-off I have been able to get between being
politically-correct and being honest.
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