----- Original Message ----- From: "Fernando Gont" <fernando@xxxxxxxxxxx> To: "Joe Touch" <touch@xxxxxxx> Cc: <tcpm@xxxxxxxx>; <ietf@xxxxxxxx>; "'Joe Abley'" <jabley@xxxxxxxxxxxxxxx>; <opsec@xxxxxxxx>; "'Lars Eggert'" <lars.eggert@xxxxxxxxx>; "'Eddy,Wesley M. (GRC-RCN0)[Verizon]'" <wesley.m.eddy@xxxxxxxx> 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@xxxxxxxxxxx || fgont@xxxxxxx > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf