Last Modified: 2004-11-02
|Mar 04||Submit FRTO draft to IESG for publication as an Experimental RFC|
|Mar 04||Submit Reordering Mitigation draft to IESG for publication as an Experimental RFC|
|May 04||Submit DCR draft to IESG for publication as an Experimental RFC|
|May 04||Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC|
|May 04||Develop (providing editors are available) milestones for advancement to Draft Standard of identified important TCP specs (e.g. RFC 2018, 2581, 2988...)|
|Jun 04||Submit a revision of RFC 1323 to the IESG for publication as a Proposed or Draft Standard (depending on the nature of the changes to the document)|
Taken by Aaron Falk
Chaired by Ted Faber
- TCP Roadmap
- Soft Errors
- User Timeout
- PAWS vs. Segment Reordering
- Timestamp defense vs. off-path spoofing
- FRTO Draft in AD review
- TCP RST summary document, now a wg document, waiting for revision, expect completion before next IETF
- TCP secure: minor revisions pending, expecting new revision in two weeks. Not many substantive comments. Expecting WGLC soon.
- Reordering Robustness. Item on charter was DCR and blanton-allman draft. Allman, Blanton will combine collaborate with DCR. Draft renamed to NCR (non-congestion response). Getting fleshed out, some under-specified details. Working to get doc to look like a real specification.
- revising 2581. Getting bug fixes and other small fixes. Draft expected in a couple weeks. Send input directly to Allman, Paxson, Blanton.
TCP Roadmap, Wes Eddy
- Easy to RFC search for 'TCP' but returns many, many hits and understanding relationships is difficult. Goal: help newcomers by categorizing and providing brief commentary.
- History. Started on e2e-interest mailing list. Originally draft-duke-tcp-roadmap-00.
- Soliciting feedback. Current version mostly complete listing of TCP-related RFCs. Still some questions about including peripheral; documents. The brief descriptions are tweakable.
- Goal. Have a good amount of feedback to apply an increment version. People seem mostly happy (?).
- Open questions (looking for comments):
- overall structure: Should we reorganize/reclassify? Propose a couple formats on the list and take vote?
- Take out notions of what's in "modern OSes"?
- RFC citations: retain or nuke?
Braden: (erstwhile author of this document). I oppose removing references. At least the names should be there. (why are they there? they take up three pages) I have some other changes. Not enough said about IPv6 TCP. I don't know how the IPv6 describes how the pseudoheader has changed. need to be a more careful definitions of the updates and obsoletes. Looking at the text I found several places where there should be some updated/obsoletes but aren't. Then there's the MIB thicket... In historical documents, there are several that should be promoted (e.g., RFC1718 "silly windows" should be in implementation issues). The Dave Clark Five should be included as they are quite useful. The problems those doc describe still exist. Finally, missing reference to Reno in congestion control section.
Jon: need to be mindful of replicating information on the RFC Editor pages in obsolete. This is a moving target, e.g., for MIBs.
Braden: don't think this is a big issue but I see your point about duplication.
Anantha Ramaiah, Cisco: is there a way to list what RFCs a stack implements
Ted: this makes me uncomfortable
Braden: that question reminds me of a short section on conformance in the doc. wonder whether we can get away with saying so much or little.
Ted: agree. we should be cautious about laying too much law here
Braden: yes. but perhaps we should be giving a little more advice.
Pekka presenting for Fernando Gont: Soft Errors and TCP
- Proposed fix in document could lead TCP to abort connections that would be aborted unnecessarily. Practice indicates this seldom occurs. Except in rare circumstances.
- Other comment: why not parallel connection attempts? Either try every IP address available, in parallel or wait some time before trying each address. First approach is hard to distinguish a valid connection request from a DoS attack. Second will likely lead to long delays.
- Next steps. Take as WG document?
Ted: comments? (none) There were some impassioned statements on this in SD IETF. How many people read the draft? (3-4) How many remember the draft in SD? (none)
Joe: one issue from before, not addressed today, is changing treating a soft error as a hard error as an optimization which should be done as an application optimization. Haven't heard a good argument to address this. You're trying to fix things by using transport layer signals which the application should be dealing with.
Pekka: I'd like that every application doesn't need to know how to deal with this kind of error.
Joe: but what about application which don't want this behavior?
Pekka: this proposal only applies to all of the end system.
Joe: this seems like a big problem. it should not do it unless a user asks for it. (default should be off).
Ted: what about a SOCKOPT?
Joe: I have no problem as long as the default is OFF. The catch-22 is that, if the app is going to set the SOCKOPT, the app can do the right thing anyways.
Ted: it's easier to set a SOCKOPT than write a library
Casner: what is the right application behavior? This mechanism is just more convenient for applications.
Pekka: trying to fix this in one place instead of two million.
Allman: can't fix this without involving the app
Joe: I agree
Ted: we don't have enough folks to make a decision now, take it to the list
Lars Eggert, NEC - TCP User Timeout Overview
- Overview. Want to use per-connection user timeouts negotiated with a TCP option. Longer timeouts = tolerate longer periods of disconnection. Draft describes only the TCP mod, not the policy that you use for picking appropriate user timeouts.
- next steps: want draft to be a working group item.
Ted: how many read draft? (few)
Of those who've read, it how many like it? (all who've read)
Will take this to list but it looks like there is interest.
Comments on Experimental vs. Standards? (none)
A Modification To Make Paws Robust To Segment Reordering, Noritoshi Demizu, NICT
- Problems: PAWS may discard reordered legitimate segments when retransmission happens. (gives example)
- Possible solutions.
- 1. receiver-side modification
- 2. sender-side modification
- 3. redo PAWS
- Current proposal. replacing PAWS. record the following tuple for every 2^30 bytes. (Ed: I don't understand this and he's going too fast.)
Ted: anyone read this? (1) This is fairly technical draft. See if it technically feasible. Send feedback to list.
Lars: is this implemented? (no)
Ted: even doing this in ns would help.
KC Poon - Use of TCP timestamp option to defend against blind spoofing attack
- Resolved IPR issue by removing the mechanism which touched IPR. Valid range of TSecr is limited. Issue: current proposal does not protect against wrapped around ACK, will be fixed in next revision. (There are four ways to interpret RFC1323, this causes issues.)
Touch: spoke about this at BTNS BoF. I feel it is inappropriate to deal with security issues by changing a transport protocol. Deal with Spoofing by fixing spoofing, not by changing timestamps.
Ted: are you interested in timestamp misrepresentation draft. Joe: yes.
Tim Shepard: I didn't like this ideas because dialup users may run into problems when two users share one dial up port. This makes it impossible to reset a connection if a system doesn't support resets.
KC: suggest allowing application to chose whether to use the TCPsecure mechanism so it won't be everywhere.
Tim: yes but this doesn't address my problem.
KC: this also applies to anonsec
Ted: how many have read: (5-10) of those, should this be a wg item (1); Read and don't think should be a wg item (2) "lukewarm, if any support, for a making this a wg item"
Braden: I've been involved in this and think we should require simulations before making any changes.