RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard
I have commented numerous times that with a paragraph that specifically provides vendors to make connection-less resets == attack packets this will not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to explain why to someone that is unwilling to compromise with even a a vendor MAY maintain state to allow connectionless resets to work. (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: tcpm-boun...@ietf.org [mailto:tcpm-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 24, 2010 10:25 AM To: IETF-Announce Cc: t...@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' draft-ietf-tcpm-tcp-auth-opt-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o pt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=16685rfc_flag=0 ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard
Hi Wesley, I stand red faced and corrected. The last version I saw did not address this (I think that was either 08 or 09) and I assumed the .10 didn't either. I withdraw my objection and apologize for having missed this significant rewrite!! (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] [mailto:wesley.m.e...@nasa.gov] Sent: Friday, February 26, 2010 4:18 PM To: Smith, Donald; 'ietf@ietf.org' Cc: 't...@ietf.org' Subject: RE: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard Hi Donald, as the document shepherd, I need to set the record straight on this, as your statement is simply false. In checking that the WGLC comments had been handled in the following document update, I looked at both the email thread you participated in and the updated document. In this case, the editor very clearly responded to your inputs and made significant changes to the document. You can find an entirely new section (9.7 Connectionless Resets) starting in version 09 of the draft, which specifically responds to your comments with resolutions that were discussed on the mailing list. This section discusses maintenance of the traffic keys across reboots which answers your concern and makes the practice a SHOULD which is stronger even than the MAY that you mention below. I do not understand why you feel like your inputs were ignored, but I hope that you'll agree that this was not the case. From: tcpm-boun...@ietf.org [tcpm-boun...@ietf.org] On Behalf Of Smith, Donald [donald.sm...@qwest.com] Sent: Friday, February 26, 2010 2:45 PM To: 'ietf@ietf.org'; 'IETF-Announce' Cc: 't...@ietf.org' Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (TheTCP Authentication Option) to Proposed Standard I have commented numerous times that with a paragraph that specifically provides vendors to make connection-less resets == attack packets this will not get much if any use among ISPs or other bgp speakers. Those statements have pretty much been ignored. I do not support this draft and believe I have wasted my time trying to explain why to someone that is unwilling to compromise with even a a vendor MAY maintain state to allow connectionless resets to work. (coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: tcpm-boun...@ietf.org [mailto:tcpm-boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, February 24, 2010 10:25 AM To: IETF-Announce Cc: t...@ietf.org Subject: [tcpm] Last Call: draft-ietf-tcpm-tcp-auth-opt (The TCP Authentication Option) to Proposed Standard The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'The TCP Authentication Option ' draft-ietf-tcpm-tcp-auth-opt-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-10. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-o pt-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_iddTag=16685rfc_flag=0 ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ tcpm mailing list t...@ietf.org https://www.ietf.org/mailman/listinfo/tcpm This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [OPSEC] [tcpm] draft-gont-tcp-security
(coffee != sleep) (!coffee == sleep) donald.sm...@qwest.com gcia -Original Message- From: opsec-boun...@ietf.org [mailto:opsec-boun...@ietf.org] On Behalf Of Fernando Gont Sent: Monday, April 13, 2009 1:23 PM To: Joe Touch Cc: t...@ietf.org; ietf@ietf.org; Joe Abley; op...@ietf.org; Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon] Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security 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. Secure is a general term. TCP was intended to address several areas of security. The classic tenets for computer security is: CIA - Confidentiality, Integrity and Availability. TCP doesn't attempt to address Confidentiality. However it was designed to address integrity and availability so failures in those areas should be documented and addressed in some fashion. 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. 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. TCP itself is not a secure protocol, nor is it intended to be. Again, it was intended to help ensure integrity and availability. 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 can be made better that is not an incorrect impression it is a fact. 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? Adding crypto improves confidentiality and integrity but is counter productive to availability as most crypto engines are prone to fairly low pps resource exhaustion attacks. 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. 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? 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. 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. 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. Again the use of a generic secure. What do you mean by nonsecure here? 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. Kind regards, -- Fernando Gont e-mail:
