Last Modified: 2005-01-17
| 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) |
|
TCPM notes - Thursday, 10 March 2005 at 1300-1500
Thanks to Steve Casner for the excellent notes. These notes do not include information from the slides, which are in the proceedings. Hums: - ICMP Soft error draft to informational - strong support - Malformed tcpsecure question - inconclusive due to pilot error - tcpsecure support "do you think this should ramin a wg item" strong support Minutes: Status - Allman RFC2581 revision - Allman Revision not done before meeting, but nearly ready. Draft expected next week. Soft Errors - Pekka Savola Joe Touch: is it feasible to go with socket option document, because those are not standards? Ted Faber - we could document the api, not a socket option. Pekka Savola - prefer first option (just informational rfc) instead. Matt Mathis - Will informational rfc mention that this could be done with a socket option? Explain the technical issues while avoiding political issues. Pekka Savola - could do that. Mark Allman - Rephrase: follow option one [document the behavior of treating ICMP soft errors as hard during set up], explaining how it violates 1122 - is this reasonable as a working group item? Joe Touch - yes, should be a wg doc - similar to tcp errors document. Maybe we should just glue this onto that doc? Mark Holinger - Should we just propose changing the behavior? Tim Shepherd - Do we need to say anything about OS behavior (vs protocols)? Ted Faber - Issue is this document changes what 1122 says. Tim Shepard - does this affect interoperability? Joe Touch - TCP has behaviors both ways, up and down, and 1122 covers both. Ted Faber - To tell someone to do something different than 1122 requires a standards doc. Hum was clearly in favor of making this a wg item for informational. ICMP attacks against TCP -- Pekka Scott Bradner - Router requirements deprecated Source Quench already, so ignoring them should be fine. Joe Touch - Discussion of counter-measures is incorrect because reaction needs to depend on state (initial connection or later). It is wrong to assume that if a packet reaches the dest that any errors associated with it can be ignored. There could be dups, one with error, or router may send icmp later. Document is wrong in its assumption about sequence numbers. Matt Mathis - there are tunnel devices that send both icmp and fragments and don't honor df bit. working to improve pmtu discovery as part of getting rid of icmp entirely. So strong link between pmtu discovery and this document. 1191 is only document that requires icmp; if we update that, we could make all icmp to be soft errors. Ted Faber - makes security issues of this draft go away. Joe Touch - 1122 specifies required app behavior, so this would be affected by making all icmp soft. Dave Borman - should it be moved to tsvwg to be more general? icmp does not know about the upper protocol, only ip. but how you handle the icmp is protocol specific, so for tcp behavior this should stay here. implementation should always do as much checking as it can that any received packet is related to something it is doing, including checking sequence numbers. this is just good practice, even if it is more strict than the specs say. Ted Faber - want stacks to do the same checks with the same semantics, so this should be standardized. Dave Borman - need to make sure that the checks are valid, e.g., can't check both seq and ack in a reset packet. Joe Touch - agree except with conclusion. check needs to make sure this belongs to their outstanding packets, not just to the connection. This is 1122 global, so needs to be tsvwg. Matt Mathis - 1122 section on icmp needs "freshening". we realize now that things should be different. go to tsvwg. [should that be pmtud?? -- tvf] Dave Borman - tsvwg should address general issues of transports reacting to icmp, but not for specifics about what a tcp implementation should do. two docs, linked. Ted Faber - seems like you could do one doc that covers all protocols, or separate docs. Dave Borman - issue of soft vs hard errors - point of hard errors was to deal with situations where the error would just recur, vs soft errors might work next time. hard error allows keeping at it forever. but it is gray between hard and soft, not binary. so some errors may be hard sometimes and soft other times. need to consider situation. Randall Stewart - against making hard errors all soft. Need to pay attention to protocol unreachable to keep yourself from becoming an attacker when you get misdirected toward an innocent victim. prefers separate docs because sctp will already address this in own docs. 1122 is a must only for tcp, does not apply to sctp. Mark Holinger - agrees with the need to refresh. Not talking about large machines in computer rooms anymore. During establishment, may need to know more about hard errors. But during connection, don't want to pay attention because path may change with mobile devices. Mark Allman - will take discussion of this back to the list. Also need to see what overlap there iswith pmtud. Pekka Savola - agrees that revision is appropriate. tcp-antispoof -- Joe Touch Would prefer to state a prefered solution, but if wg can't agree on one, then willing to refrain. Looking for references to say window should be related to bw*delay. John Hefner - this has been implemented in linux (to automatically set window size) Dave Borman - need multiple of bw*d in order to allow for lost packets. Joe Touch - if you do sack, don't need as much Mitesh Dalal - use of tcpsecure or md5 Aaron Falk - needs editorial pass to fix structure. proposal, solution, issues. Joe Touch - the problems are related, so discussed them together Aaron Falk - didn't see the tradeoffs in reading the draft Ted Faber - wants to be unbiased, fair expression of all solutions. Wants feedback from other "horses in the race" tcpsecure - Mitesh Dalal Tim Shepard - 7 vendors who implemented: what kind? Mitesh Dalal - 2 routers, 2 end host, 2 firewall... Tim Shepard- year's worth of experience may not be meaningful if many applications have not tested it. Randall Stewart - an xp service pack does include this? Tim Shepard - draft name and title are a problem because it implies too much. but don't have a better suggestion. Peter Lay - xp serice pack 2 implements this proposal (in response to Randall) Joe Touch - 793 says you should handle things outside the window, and this contradicts that. this should be mentioned. Randall Stewart - Joe should send text Ted Faber - this is a wg item, put there by fiat. wants to confirm this. this does have IPR. Mitesh Dalal - this status [the IPR] has not changed. Faber & Touch discuss whether we need to talk about the target (info/experimental/etc) of the draft. Jon Peterson (Transport AD) - we do need to say what target the draft will have, but not at the start of process Tim Shepard - Joe Touch - there are alternatives that are well-spec'd, including tcp md5. not a problem for all hosts, only well-known one. Jon Peterson - tcp md5 is not yet standards track, but hums were taken and people were comfortable. Ted Faber - hum for comfortable with this -- result was unclear Jon Peterson - refine the question Ted Faber - hum for individual desire for this to be provisional wg item - result was affirmative. Ted Faber - please everyone review, and help decide what status doc should go for. non-congestion robustness -- Mark Allman Matt Mathis - Jamshid and he worked on rate halving, but problem was that you pull down actual win rather than congestin win. cwin becomes half of actual window. loss is discovered when actual win is at low point. need to revert to sending packet every ack when loss occurs when actual window falls below cwin/2. this is the hard problem that stopped their work. Ted Faber - asked for words to the list. Sally Floyd - read it and liked it, will do more detailed review. [ this review has subsequently appeared ] TCP Roadmap -- Faber for the authors Says it is really nice doc, wants everyone to read. [There is a jumbogram issue, but nobody here knew about it.] borman - jumbograms are only for dealing with mtu and interface larger than 64K. code won't ever be used if interface doesn't handle that. Ted Faber - good reason not to put it in roadmap? Dave Borman - main issue for doc is urgent pointer, but you need to deal with issues even if not jumbograms. and treat all 1's for mss to be unlimited. so, changes to tcp are minimal, so should not be objections to including in doc. can't use jumbogram mechanism if not sending more than 64k. Matt Mathis - issue is that people who don't want jumbograms don't want to have to refer to it. another issue is implementeations with sign-extension bugs for mss. detecting all-1's mss. Sally Floyd - take question to mailing list Tim Shepard - you can't skip reading about jumbograms even if you don't have big interface, so this should stay in the document. Dave Borman - two parts: 1 - support for jg's in 2147 2 - changes to tcp to properly support jg's Ted Faber - happy to receive text Sally Floyd - good document, and should be updated every couple of years. from jabber, Wes Eddy (an author) says he is inclined to keep it up to date. |