TCPM Meeting - IETF 69 Chicago, IL, USA Thu, July 26 2007, 1300-1500 TCPM + TCP-AUTH Design Team Status + Anti-spoof: will be RFC 4653 very soon + Syn-flood: in the RFC editor's queue + Soft errors: Fernando to rev for minor things, but basically passed wglc and we have consensus + 2581bis: need implementors' input for an implementation report, which is holding up this document right now Sally: when I'm talking later about congestion window validation might recommend sentence change in 2581bis Mark: Yes. + User timeout: will do WGLC, consider it now, so read now! + ICMP attacks: expect rev soon + Proposals for experimental congestion control schemes to be undertaken by this WG. See Lars' ION. IETF will receive an external report on such proposals from the IRTF's ICCRG. This report will focus on safety. + TCP-AUTH design team WG consensus to take on a replacement for the MD5 option. Design team reconciling two documents, making good progress and expect a draft by Labor Day. tcpsecure draft-ietf-tcpm-tcpsecure-08.txt + summary of changes: clarification on data injection, and usefulness in spoofed FIN-special treatment because trying to close connection, lots of editorial fixes. + main open issue: level of recommendations for mitigations all of mitigations labeled as SHOULD, but has been questioned change any to MUST, SHOULD, MAY? Mark notes we NEED INPUT as the question has been hanging out for a while. Suggestion on list: reset and syn baked enough to be SHOULDs, but data injection mitigation not as baked, perhaps MAY? Touch: comfortable w/data protections being MAY. Ok with SHOULD for SYN/FIN but need to be explained (with 2119 required explanation). "If situation of RFC is something care about AND not in a position to deploy appropriate security protections with real confidence (ipsec, md5 or successor, ...)". At the end of day, mitigations in this draft are not required for every implementation. Ted/nohat: works other way. If we make something a SHOULD implementors need to have a good reason not to do it. Touch: Then should be MAY. Recommend in non-2119 language that router vendors or class of users deploy. But, this is not appropriate to require everywhere unless reason not to put in. level of complexity. If you need protection you need real protection and this is not it. Anantha: my understanding of SHOULD is that if someone doesn't want to do so, they need not do it. Thought SHOULD covers that. Ted: it's the default we aretalking about. SHOULD ought to be done unless a good reason not to. I think SYN/RST should be SHOULDs. I think data shold be MAY because I am less sure about it. That's my personal opinion. Lars: hum on whether people feel strongly about different recommendation for differnt mitigations, then all MUST/SHOULD/MAY, then if should do different ones. Mark: different course of action, get MUST out of way. cperk: not hearing anyone arguing for MUST. Mark: hum is MUST. No response. Mark: Hum for all three SHOULDs. Almost no response. Hum for SYN/RST SHOULDs and data injection MAY. Mild response. Hum for all MAYs. Mild response. No big consensus. Last a tad more, but no overwhelming consensus. [ Accoustics really made hums impossible, the "visual hum" below is somewhat clearer.. -- Ted] Suggestion: WGLC, and if have heart attack, find out there. We have an absence of strong consensus to change document to which most people agree. Joe: I object to that. Apathy, or ignorance or both should not cause whatever got into doc to this point move forward. Anantha: to comment on Joe's comment on ignorance or apathy. We're on version 8 and have been discussing this for two years. There is neither ignorance or apathy, it's the way it is. Proposal from Lars: hum on whether group trusts chairs to make a decision? The proposal was rejected by all, including the chairs. Lars, trying with hands: all SHOULDs: 4 two SHOULDs and a MAY: 8 all MAYs: 3 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets draft-ietf-tcpm-ecnsyn-02.txt + Goal: to add ECN to tcp syn/ack to avoid retransmission timeout when syn/ack would have been dropped + Benefits shown in a sigcomm 2005 paper (high for some web traffic). + Simulations for 3 variants shown: plain ECN, ECN+ (syn/ack is ECN capable), ECN/wait (with add'l rtt wait upon a CE notification). Results: as congestion increases, more packets dropped, not many marked difference in variants doesnt change # dropped ECN+, ECN/wait show same benefit So, no danger of congestion collapse, or increase in drop rate or change in aggregate congestion levels if don't wait RTT. + Conclusion: no danger and ecn/wait not compelling + Next steps: can we move forward, or more simulations or what? Mark: In March/06 I wish I hadn't held up so long. Like the simulations, like the data. My argument about response was always about consistency of response when TCP only had one thing outstanding. I'm happy either way, but don't think it should be held up and go forward. Vote for adding RTT, for consistency, but am swayed by evidence that not a big deal Lars: have you looked at how firewalls/nats behave that might see packets? Was to go for proposed, right? Sally: Don't think we have looked at it. Microsoft folks reported at last meeting about middleboxes and ECN, and why ECN is not on by default. Would assume this also applies to syn packets, but don't know. Murari, Microsoft: most of the guys that crash, would crash either way so no worse than ECN. Gorry: what do you think normal response should be if regard CE packet as lost. Recalculate all timers? Mark: what do current standards say about what do? Initial RTO is 3 sec. So, this is a big win, even if wait RTT, over default. Anantha: to follow up on ECN thing. Good idea to post question on the BEHAVE WG or something. Get more responses from correct community. Ted: in absence of strong objection, sounds like last couple of impediments to take to last call have been addressed. Anyone have big heartburn. Going to last call. [Nope.] Advancing RFC 4138 draft-ietf-tcpm-rfc4138bis-00.txt draft-kojo-tcpm-frto-eval-00.txt + Usually spurious retransmissions are due to delay spikes on wireless, or link-layer recovery or bw variation + F-RTO made an Experimental RFC a couple of years ago. now a couple of impl have been deployed + Eval-00 draft has data. + F-RTO now default in Vista + Revising RFC4138 into PS + Specify base alg in TCP + Left out following as experiments: F-RTO with SCTP and SACK-enhancement + Proposal for Response to FRTO identified spurious retransmission: simple only in this doc, others would be left to separate RFCs Mark: at this point the proposal on table is to take F-RTO as PS what need to hear from WG, is opinion. Is the experience good enough. Pasi and co-authors sufficient? Read two documents and send comments to list. Revision of RFC 1323 draft-borman-1323bis-00.txt + what's different from current 1323, where stand and outstanding issues will go through quickly. + see slides Touch: Good idea. Encourage people that clocks in tcp are neither absolute nor correlated to each other on same machine anyway. TCP is not a real time system; hesistate to recommend that this provides any sort of protection but avoids an obvious hole/pitfall. Not so much protection as avoiding pitfall. Goes for a lot of other things. That's the right way to view many of the changes in this document. David: yeah, these raise the lower bound. + OUTSTANDING ISSUES + Biggest: whether or not to allow timestamps to be enabled later, not at beginning. + Should PAWS require DF bit be set? PAWS only protects first frag. Can flag & explain, or require. + is it worth allowing RTTM from DUPACK? + personal opinion is no. to do so, requires changes on both ends of connection put something differnet into echo reply to get valid data... Sally: Did you talk about the problem of changing time constant for any RTT for many measurements per RTT? David: Yes. But the document only flags as issue. Touch: On defering timestamps: easy, and NO. No other tcp option can be initialized after the connection starts. SYN exchange determines this... starting after beginning is bad. Unless the use is optional in all packets after use in SYN. David: agree. Touch: second one is very important. PAWS should REQUIRE DF be set. Put a sentence in there... people who come up and say, if DF bit is set, why use a unique IP ID? Because sender can't know when you send that the next packet thru didn't have DF set. Then a host could reassemble stuff that doesn't belong together. Can't willy-nilly use ID field. Good example of impact. Dave: anyone that has actual text, send some. Anantha: Should the advertised MSS take into account TCP options? David: It should not. Anantha: We do not take options into account in our implementation. We have seen both behaviors since there seems to be no STD which specifies correct behavior. David: We can take it out of the appendix, or write up a one-page RFC. It's not a hard topic if you think about it. You want to avoid IP fragmentation and you get in trouble if you one side assumes options in the MSS number, and other does not. At time you're generating the packet, don't really KNOW what size is. Can't guarantee it. The only way to guarantee that sent packets are not too big, is to assume other side did not acocunt for options. Decrease MSS based on that assumption and then things are guaranteed to fit. Anantha: That makes sense. A separate doc also makes sense. Gorry: If you mandate DF, do you mandate PMTUD? David: Yes, they do fall together. David: This was accepted as WG item in TSVWG and moved into here. It might be good to get offical hum to say WG item. Mark: Just looked thru the magic of cvs, and is 1323bis is on TCPM's original charter. Our assumption is that folks are fine with this. Assume it's ok, unless people start complaing. Don't complain now, because you'd be eating into Sally's time. RFC 2861 on TCP Congestion Window Validation Should we advance CWV (RFC 2861) from experimental to proposed standard? What do real TCPs do? - unsure if any implementations follow SHOULD in RFC2581 - unsure if any using CWV in response to data-limited period How would you evaluate? - better for THIS connection? probably do nothing - better if all N connections traversing a congested link do same thing? Does it matter if CWV moves to PS? - Could matter for some implementations -It matters for revising TFRC for response to data-limited periods Anyone used it? Any opinions? Say "done due diligence and go home"? Mark: one place could matter is if congestion window is quite big and send burst into net, see loss where you wouldn't have had you cut window a bit and slow-started (so sometimes in your advantage). But you don't know about this a-priori. Part of this, the data-limited part is implicitly proposed standard already. RFC2581 explicitly allows TCP to be more conservative than algorithms in RFC2581. This clearly is. Sally: So essentially, the standard says "may" use. Mark: Right--we can't fault people for doing it. Sally: Should we encourage others? Mark: My opinion: yes. Murari: [reconstructed] From a congestion control stand point this makes total sense to reprobe the bandwidth after idle time. I agreed that this is hard to argue against but still doesn't get enabled by default due to apps pushing back on this esp the long lived ones. Most of these apps already want some sort of a quick start mechanism so this would go against that. Ah yes regarding RTT I think my point was that most OS's these days have microsecond timer resolution for tracking RTTs so the idle period should be carefully chosen such that we don't over-react and decay the congestion window. So I suggested that we appropriately adjust the idle time interval as some "reasonable" multiple of RTT. re-probe. The fact that Microsoft hasn't enabled CWV is because of pushback for applications. res using for RTTs these days is fine, RTO are not that large depending on how small RTO is, might be over-reacting. Saman Masi?: two apps that would suffer if CWV were applied - streaming ovr TCP - sending voice over TCP. Not that it is a good idea, but two apps. the thing that bothers me most about CWV is that a rate-variable application would actually do better by padding its stream -- sending unnecessary data only for the purpose of probing the network. Slmar: to add to this comment: skype... does things to try to maintain window during idle periods. Sally: agree that have to address. Hands on going to PS?: 6-7 Opposed: 1 Adding Acknowledgement Congestion Control to TCP draft-floyd-tcpm-ackcc-01.txt Please read draft and give feedback. DCCP CCID 2 is the basis basis. Urgent? no. Useful? yeah---for asymmetric links. Do ACK really contribute to congestion? Sure if some path has only ACKs. If there is data and ACK traffic are the ACKs contributing to congestion? Yes, in some ways. E.g., if drop-tail or red, and units of packets. Feedback? Should this be work item for TCP (as an experimental document)? Anantha: question on kepalives. Even though keepalive not part of standard mention somewhere... if applies to keepalive packets, or no distinciton. He is confused by the draft. Sally: should add as a question. Murari: haven't read, but based on description was going to ask about ABC. Assume sender implements ABC. That means that if get ack for K then we need to pace out data over some intervals such that receiving is less bursty. This is not to slow down, but to reduce short term burstiness. Murari: if link speed is high already pretty good ack ratio. most stacks send ack at end of receive DPC. If get 8 packets, only one ack. For gigabit and higher already see good ack ratio. Sally: current standard says must ack ever 2. Murari: not possible. So for high-bw TCPs the ACK interval may be more than 2. We'd love people to look and verify this. Anantha: love for you to look. Think most implementations follow ack per packet. Murari: tried to do it, but problem is, in one indication, might get 8 packets and we only send after processing incoming segments. Early Retransmit for TCP and SCTP draft-allman-tcp-early-rexmt-05.txt This draft has been around a while. Should we forget this and go away? Or, finish? Sometimes we can't use fast retransmit because the congestion window is small. Limited Transmit (RFC3042) helps if you have data to send and the receiver's windows allows you to send it. We have let ER die before. But people keep asking about it, so we're back. Goal: experimental to gain experience. Murari: makes sense if sending jumbos (e.g., 16k window looks like 2 packets). Randall Stewart: a while ago we talked about something like this, but the idea was to just start a timer, and after RTT and a couple 100 ms, just fire off a retransmit. We never got far, but wonder if anyone has ever done anything like that. Mark: I have heard this idea too. When the congestion window is small, super-fast RTO, basically. There might be some justification for that. If you would write down, might read and say 'OK'. I'm not knee-jerk opposed, but I also don't think it is obviously better than ER. David Borman: Haven't read the document, but seems like some good ideas here, especially in case of not a lot of data to send at the end of a connection. At worst we get a spurious retransmission. Seems like it's a good idea and well worth purusing. Sally: haven't read this version, but read lots of old ones. Fine with going to experimental and encouraging simulations. Need to look at the worst case, if it isn't there. Mark: There is a sketch of the worst case. Sshu?: Recovering more quickly would be good; support effort. Quick viz hum, go ahead and become TCPM WG item for experimental? said yes: 12+; no one opposed A TCP Test to Allow Senders to Identify Receiver Non-Compliance draft-moncaster-tcpm-rcv-cheat-01.txt 2nd time presented. Quite a few updates since Prague. Simple mechanism to allow sender to test receiver compliance regarding ACK generation. Should we move to a WG item? This optional test is meant to plug existing hole in TCP, but not an ideal solution. Some sort of transport layer nonce would be a better solution. Mark: I am a little ocnfused whether outside test (a side thing), or if it should go into TCP (so we think all TCP implementations should do it). Toby: This is definitely an optional thing that people can choose to do. Assumption is that can trust reciever. If you feel you cannot, here is one way to safely check behavior. Mark: this is a recommendation to put in to Microsoft and Sun's TCP, and perhaps not use all the time? Toby: A utility to check sort of thing. Not part of TCP standard. Not part of absolute standard. cperk: That's what I was going to suggest. Having a mechanism is a good thing and the document is something this WG should do, but an informational not a PS. Mark: what would experiment be? Joe: Not proposing a change to TCP, as a mechanism to test for right thing. Not even a protocol at that point, but a procedure for testing things might be a BCP at some level. If test, here is a good way. Joe: If really don't trust info at other end use proper security, nonce is not proper security. Ted: IPsec wouldn't solve problem. Joe: neither would nonce. Ted: this is like ECN nonce, sending real data and really saw packet acked. Joe: ah Murari: what resource are you trying to protect? Avoid committing resources on sender because the receiver is malicious? Toby: yes Murari: A better way to do it is to shrink window to zero and do zero-window probing, if really malicious, wouldn't violate protocol, would inflate and sit there. Toby: There are cases where not extremely malicious receivers can gain something if slightly preturbing the ACK stream. Murari: agree, but don't solve server resources. Mark: Not sure I see this as IETF work. There are a bazillion conormance tests for TCP. Sally wrote a bunch in tbit. These are all very complex and I am not sure this is the right thing for the IETF to work on. Also, the tbit tests aged poorly and had to be updated and so this could be quite a big new task to keep a set of tests current and useful. Bob Briscoe: slightly disagree w/coauthor that only test suite thing. The trouble is getting mis-behaving receivers to connect to your test server. Goal is to write something with IETF stamp of approval that is safe for a server / sending TCP to do in order to test receivers that it thought were non-compliant. In addition, I can imagine test suites using receivers built to be non-compliant, but not sure how to get receivers to come to them. Sally: tbit test, done from web server. Testing their TCP. Usefulness of test depends on population of server.