-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fernando Gont wrote: > Smith, Donald wrote: > >>>>> 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. >> I talk to vendors a lot. I don't think there is a consensus on the >> "how up-to-date our specs are". > > 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. 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 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. 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). >> I can't even get a straight answer on how they addressed the >> icmp-blind resets or the tcp-blind resets from several years ago. >> There were several possible mitigations with some trade offs on each >> of them. Yet finding out how your favorite vendor addressed those is >> likely to be difficult. > > 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. > 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? > 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. Running around saying the sky is falling for everyone isn't going to help. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknjq78ACgkQE5f5cImnZrv1lwCg3sR/xHE5SRW9nld39xFN+ZCb rWkAn2pA80tWrpS/8iQTau97RoFpaEBl =yF7F -----END PGP SIGNATURE----- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf