TCP Maintenance and Minor Extensions WG March 11, 2008, IETF-71 Minutes taken by Gorry Fairhurst 1. WG Status + Agenda bashing (10min) Mark Allman reviewed the Agenda. Status: ECN-SYN has been sent to IESG Waiting for proto writeup by WG Chairs: Soft-errors UTO TCP-Secure has been through WGLC. Applicability statement has been drafted, and recommendations need to be firmed-up. Did anyone object or have comments on this topic? [Post meeting clarification: The chairs got confused during the meeting. This document has not been through WGLC. However, it is believed that all significant outstanding issues have been worked through and when a new Internet-Draft is issued the document will go through WGLC.] Two new items of work were expected: Compound TCP (from ICCRG) Early Retransmit (to be verified as a TCPM Item by the WG) PSavola via jabber: What is the status of draft-ietf-tcpm-icmp-attacks? This needs some work, and has been languishing for some time. The WG Chairs don't have any update on the current status. Mark is looking for energy - offers of help from people interested. The Chairs will contact the author and check the status. 2. 2581bis update - Mark Allman draft-ietf-tcpm-rfc2581bis-03.txt Ted (on the list) considered this document has passed WGLC when the comments have been addresed. The authors think all changes have been implemented. 3. Advancing F-RTO - Pasi Sarolahti draft-ietf-tcpm-rfc4138bis-01.txt Pasi presented the draft. Lars said they had talked about F-RTO at the last meeting, and there was support for this going forward. Ted and Mark have discussed this and people seem to be liking this and the experience is good. We think we should start a WGLC after this meeting. There were no objections. 4. 1323bis - David Borman draft-ietf-tcpm-1323bis-00.txt David said this now referenced RFC 2581. There was currently a null security considerations section. Joe Touch said we should identify issues. Matt Mathis - there could be security issues. Time Stamps can cause robustness issues. Eric Rescorla - see if this changes anything. Joe Touch - can the path change. Matt there is a robustness issue with middleboxes doing things they should not. Joe Touch: It was suggesting the middleboxes can protect only some headers, if you are protecting the TCP header, must this be included? Eric: The option could be removed on path (e.g. from the initial SYN), he will send comments. David will get back to the list with these comments. Gorry: How appropriate are Jumbograms to a general internet deployment? David said this was really meant for point-to-point links, and not for the general Internet. Matt added the experimentation was 15 years old. PSavola: One potential issue in RFC 1323bis: do we want to discuss the specifics how Timestamps option have been used in practice? (e.g., for signalling in the presence of SYN cookies. David had added text describing an offset. David said that he would like to make a separate I-D on TCP MSS issues. Mark said this sounds OK, people can comment if this needs to be done different. Joe Touch: If you supply one example in section 3.3 on RTTM, this will become the default. David, we could choose an alternative RTTM implementation style. Mark: A few people have solved this by changing the weights on the sample. David said that he expected that this should then illustrate that there were multiple approaches. ... We should be careful that we don't suggest something that is too extreme, we need to support this with research. Mark said there were published papers that talk about weight changes. Joe said we should recommend alternatives that we know are safe - but not too much importance to one unless we know how to choose). David said that he should tell people what to do, and not prescribe an algorithm. Mark said we needed to keep the variance and adjust the gain based on the cwnd. Hope to make the next version ready for a WGLC. Lars said we should add milestones for the two documents (Ted to do). Mark: How many have read this version? (2). Mark: How many have read a version since we started updating 1323? (10). 5. TCP Authentication - Joe Touch draft-ietf-tcpm-tcp-auth-opt Presented the draft to SAAG in Vancouver, and feedback from Eric Rescorla. Are we writing an applicability statement here? Joe said it was in the document. Eric: Does this system assume we do not do key management? Joe said other people said this also. Eric: there are a number of styles of key management: manual, external key management, inside TCP, etc. The Design-Team seems convinced this does not fit in the space available, and must be established at SYN time, it starts authenticated and remains authenticated. Eric this could possibly be wrong. Joe said there was limited space in the SYN packet and then has to be consistent with the core of TCP. Eric said I am not convinced. Joe: There is a 40 Byte header in the SYN, but already used for TS, Window Scaling, and other things, at least half is already gone - if more than 15 bytes is needed, we are in trouble. Eric: Be clear what is included and what is not included and say why. Lars said that in previous discussions the key management would be done in SAAG, but not that this would be done in the SYN option. Danny Macpherson: If there is the capability how will this be reconsidered - can we think about other non-routing protocol solutions. Joe said we need some sort of automated key management. Joe: Do we need two documents for requirements and mechanism? Mark said he was not aware of the need for this, but if it made sense then we could split things up. ???: When you say asymmetric is not useful. I may want to be able to do this mid-connection. Joe said the Design-Team said do not do this within the connection. Eric said we should be clear what people want - this is not a replacement for TLS, it is DoS protection. Joe, yes it protects the transport key. Eric this means that we have prior arrangements, if either direction is DoSed then this attacks the connection. There is no management different between symmetric case and asymmetric, it's just performance - the keys are exchanged and then the packets are MAC'ed. Brian Weis said this is just for routing. Eric: This issue is about cut and paste with the same port quartet. You need to be on the wire to do this attack. A pair-wise key per host pair is OK. Joe said we could get this key from a key management system, SAAG mandated an automated key management system. The ISN may help. Eric the state in the TCB is used, the first packet is protected by the master key and the ISN, this provides a way to bootstrap this. Would TS option help against replay attacks? Eric and Joe discussed the relationship between the TSAD and TCB. Brian: The unkeyed case should result in silent reception. Lars: default deny will result in loss of a connection, which is bad. The migration case is important. Eric said if we turn on independently, then we need to handle this. This could be a case for asymmetric. Eric: We need to be concerned about sequence number roll-over, and that the key should not be used for a large number of operations (although this is no longer true for modern MACs). We don't need to change the key. Joe said the question was about coupling the ISN and MAC. One way is to synthesis a 64 bit sequence number, by counting the wraps of the sequence number space. There are pending modifications to the I-D. Joe said there was a list of open questions, all people were welcome to start discussions on this topic.