DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT These are draft minutes, as of 4/24/2009, about half of the second day still need to be edited. -David Borman ========================================================= TCP Maintenance and Minor Extensions (TCPM) Working Group IETF 74, San Francisco, CA Monday, March 23, 1520-1720 WG Chairs: Wesley Eddy (via jabber) David Borman Mailing list: tcpm@ietf.org Jabber Room: tcpm@jabber.ietf.org Notetaker: Gorry@erg.abdn.ac.uk WG Status Published drafts: # Soft Errors - Published as RFC 5461. # UTO - Published as RFC 5482. Drafts completed WGLC: # 2581bis - This has now cleared WGLC, an update is needed. # F-RTO - In the RFC-Editor queue, this is blocking on a reference to 2581bis. # ECN-SYN - This has cleared WGLC, publication has been requested. # tcpsecure - Publication being requested (with a boilerplate change). Active WG drafts: # Auth Option - This is progressing; it is nearly ready for WGLC. # Early Retransmit - This needs WG feedback. # ICMP Attacks - This needs work. # 1323bis - This is progressing, an update is available. # MSS - A new draft is available. David asked people in the WG to read the Charter for the WG and report on anything that may be missing or should be corrected. Current WG Items "The TCP Authentication Option", Joe Touch draft-ietf-tcpm-tcp-auth-opt-04 Joe Touch: Does anyone have thoughts on using the term "traffic key" in place of "connection key"? Anatha: I did not like the TSAP as a part of the RFC. Could this be placed in an appendix (this just specifies a database). Gregory Lebovitz: I argue that we should not backup the use of keys. Usually there is a reason why users install a key, so I do not see why we need backup to an older key. Joe: There is an order issue, where the preferred key can not be used. Gregory: I sent an example to the list that described how you could do this. Joe: Alison suggested that you remove an old key from keyset if you do not want it to be used. Gregory: So this is going to result in loss of packets. Joe: I do not want to do this. Eric Rescorla: The problem situation arises when the keys are misordered. What is the reference? Gregory: I sent comments on this. Eric: I suggest using a preference value. Brian Wise: Manual keys mean that it is hard to guess the ordering. I can see why reodrering protection is useful, but I do not think TCP should decide. I agree with Alison, we should remove the key if one end no longer wants to use it. I think we should keep it simple. Gregory: I think we can solve both problems. I suggested using 3 local values associated with the keys. Joe: That describes a system that prevents backing up with keys Joe: There is also nothing in the draft that requires you to use the same key in both directions. Gregory: Why burden this with the complexity of directional keys? ...: This may be simpler than symmetrical keys... Joe: The key tuple is symmetric, but you do not need to use it. Gregory: I have not heard why two keys are better than one. We do not put keys to traffic keys. Joe: There is one keyid for the master key. The tuple is {string, algorithms, length, keyid}. Eric (acting as a proxy for Russ): There could be one table of keyids and it may be hard to find a jointly open slot. It is desirable to find a common key. Gregory: I do not know the port ahead of time. Joe: I do not understand how this helps. Brian: The same key can have two names. We do not have this feature today. Tim Polk: Russ was trying to say that we need to know how one end has assigned numbers. You need to know what the other end calls the key. This is likely to b the case when you use the same keys with multiple parties. Joe: The keys need to be bound to something. The TAPD specifies the policy. Eric: People may want to configure keys with a wildcard. Joe: Shall a master key be used in both directions? Gregory: It depends if you mean a key, or the number of a key. Gregory: People often do not deploy keys with BGP. Joe: Master keys can now be used in both directions. Gregory: This is all more complex than simply using one key. ...: No. Eric: You have to allow different master keys in the two different directions. Eric: I think you would like a system that if we have three keys configured, it will chose the same key in both directions. Gregory: That is it will converge on a key (due to the condition). Eric: Joe's design allows this implementation. Lars Eggert: I want to understand if the choice of multiple keys is a critical issue, or a prefered choice. Gregory: My passion to see this close quickly is high. But, the new approach is this so much more complex than a single password. So, I would also like to see this deployed. There was a consensus call on whether to allow key use to backup and reuse previously used keys or not. The consensus was to allow backup using the method in the current I-D. Gregory: I think the draft would be better if we kept the main part simple. Can we make the default example to be when a user uses the same label for send and receive. That would help people to think this is allowed. Joe: Yes. Gregory: Can we agree on the following: 1: A master key is bidirectional. 2: The key id may be different in each direction. 3: Does a master key have to be used in both directions at the same time? No. Joe: 1,2, agreed... Gregory: I would prefer not to say 3. Eric: We all agree we can have different keys in both directions. The question is do the algorithms converge when we have keys in different directions? Gregory: There are issues if the two sites order the keys differently, and the two pollciies do not match... Brian: They are just different keys. Eric: What would you like to happen? Gregory: They should break, and return an error. This way people know that the expected keys have not been used. Matt: I don't think the BGP people would like this to break. Eric: I agree. Eric: Keys can fall into 3 categories. If we currently use a key and there is a new key, the we should transition to using this. Joe: I think we need a key management system to handle the complicated keying cases. Eric: We need to check the timer. Based on the timer, we can see a problem if you get packets periodically and it keeps a key active. Joe: We start the timer on the first segment only. Eric: Ah. I need to think about whether this is OK. Gregory: How does the operator know what key is current? Joe: You would call to the stack and ask at both sides. Gregory: That means you need to continually query the box. That means a non-determinsiic choice of the key could be used. ...: We can flag a key as compromised, and log in sylogd, etc. ...: Its OK to put it in the log, but operators should not need to scan the log to find out if the key is now working. Lars: We could update the estats MIB to specify this extra data. Joe said we also need to scrub and check the terminology used in the draft. Would someone volunteer to check? Eric: I will be happy to check the I-D. Joe noted that the document now included the "TAPD" and discussion ensued about the TAPD, and whether this was implementation specific. Joe: TAPD is described as a database because we want the 'unique index' property of databases, that a given socket pair/keyID will index exactly one master key tuple. Eric: I agree, there must be a key tuple for each datagram. I am not sure this seems like a database. IPsec experience showed that when you describe things as a database, people believe there actually needed to be a database implemented, and that's not necessarily what we want them to do nor is it needed. You can put all the information you need in the TCB. Joe: The default case is to ignore unintialised cases. What do you do when a SYN arrives and there's no TCB? How do you distinguish between policies? If no-AO, then you issue a RST, but if AO-required, you want to remain silent. I want to be able to lock the ports and then enter the keys. Eric: you can turn on AO-required with a socket option. Joe: This works only after you are listening to a socket; there is a window of time between listen and setsockopt. Eric: This depends on the order. You create a socket, set sockopt and then call bind and listen. The detail can go in an appendix. A valid approach is to have a global flag that says whether TCP-AO is needed. Tim Shepherd: I agree. Eric: We need to keep the main part of the I-D simple. Joe: I should not need to have to change an implementation of BGP to run TCP-AO. Eric: For any given datagram that you send or receive, it should be unambiguous which one to use. There could be a default. (The rest is an appendix). Joe: So you just want an index rule... Matt Mathis: and a default behaviour. Joe: You need various things. We agree, we will update the draft. There was a consensus call on the use of TAPD. The consensus was to describe the need for the unique index for every incoming/outgoing segment, but to move the TAPD as a database to an appendix. Gregory: It is very difficult to write things if you do not have container terms to describe the first set of things that need to be configured, and second the set of terms that need to be configured. Eric: I agree. What is the second term? Joe: The second is called "per connection state". Gregory: I am also happy with using the term TAPD. I do not mind. Gregory: Was there consensus on the last issue about key chains? Eric: I did not see this. Gregory: A question to implementors. Should there be a section in this document to say where we hold keys? Joe: This is outside of the implementation of TCP. ...: The concept of a connection database was described in some document a time ago. I like the idea of an appendix. Eric: There is a patented part, that relates to this. There is an IPR issue on this topic. The question of how to handle configuration around keychains was asked. The decision was not to put this in the document. Some implementors may meet to discoss this somewhere else, outside of the meeting. Lars: I agree - this is out of the charter for TCM. "Cryptographic Algorithms, Use, & Implementation Requirments for TCP Authentication Option", Gregory. draft-lebovitz-ietf-tcpm-tcp-ao-crypto-00 Gregory described two cyptographic algorithms and what should be specified. The requirements wording was discussed. Joe: I do not care on the ordering of the requirements. I do not like the term "MUST-", etc., although I have seen this elsewhere. Eric: No one can understand this terminology. I would rather see both the algorithms specified as {MUST MUST}. Gregory: We need to decide on the correct keywords to use for the two algorithms. A set of consensus calls were put to the meeting: Who disagrees with {MUST MUST}? - small hum. Who agrees with {MUST MUST}? - More agreed. Who would oppose {MUST SHOULD}? - one or two, Who would support {MUST SHOULD}? - More. There were fewer people who would like {MUST, SHOULD}, than {MUST,MUST}. It will be {MUST MUST}. KDF input was discussed. Eric: This is wrong. Gregory: This was copied from a FIPS specification. Eric: There are 2 functions being used - a PR function with a master key and input value and one the produces an arbitrary length output. We need to define the inputs correctly. Joe: The text I used looks more like what Eric just said. I think the KDF takes the three values. The other stuff is fixed. Gregory: You are saying that several inputs are constant. I understand the terminology to be used. Tim: We need to check, it may be bad to use a key of zero. Gregory: This is straight from IPsec. Joe: Do we do the first step once, and then we do the second step several times (i.e. relating to getting a 128-bit key). Gregory: Yes. We would setup IANA registries with the different combination of key and algorithms. In a manual key system there is no need for these labels, but it helps later. This impacts user interface design, and naming. Eric: I like labels, and propose we use the short names of the algorithms. Gregory: Should we define the structure today? Joe: It is nice to have one name to refer to things. Gregory: We could start with using the KDF name to start. Eric: I am confused about the way this would be used. We do not have a manual key mode. Tim: I think we have made a mistake if we need to know whether the source was manual or not. I strongly suggest the label should be rolled into a new draft, so we can complete the current document. As an AD, I think this is the right thing to do. Would this be a working group document here? - yes. Lars agreed to this - suggested the dates should be fixed to deliver a WGLC by May 1st. Tim: We need to remove the labels and get moving with this. Brian: We will get review on this. Gregory: This should be a SAAG discussion. The main changes that were discussed were: 1) TCP-AO key coordination allows 'backup' When a nextkeyID is received and indicates an available master key tuple (MKT), it shall be used, regardless of any previous use or timers on that MKT. The existing text in section 9.5 stands, removing the note in item 2.f.ii.2. 2. Clarify names for key entities currently in section 5: master key tuple (MKT) = keystring, sendkeyID, recvkeyID, algorithm (i.e., different keyIDs in different directions) 3. Address the timers When is the 2MSL timer set, when is it cleared, etc. Note that the timer is just advice to the user on when NOT to remove a MKT because it could be in use; it is not binding. 4. Move TAPD to the appendix Change section 5 to address the important properties of the TAPD, notably that: - - each socket pair indicates: - TCP-AO not required - TCP-AO required When TCP-AO is required, the socket pair indicates: - one or more MKTs - one of which is the preferred MKT to send with (sendcurrent) - one of which is the preferred MKT for the other side to shift to (recvnext) the set of MKTs cannot overlap in either sendIDs or recvIDs Non-WG Item: "Make TCP more Robust to Long Connectivity Disruptions", Alexander Zimmermann draft-zimmermann-tcp-lcd-00 Joe: Asked about sequence number ambiguity. There was discussion on whether the ambiguity mattered with an RTO. Tim: I think this is a cool idea. Gorry: What happens when there is also congestion elsewhere on another parallel or later path? There will be hum on this on Wednesday. Agenda time was short, after the extended discussion, so some items would be concluded in the TSVAREA meeting later in the week. ------------- "TCP Extensions for High Performance", David Borman draft-ietf-tcpm-1323bis-01 "TCP Options and MSS", David Borman draft-ietf-tcpm-tcpmss-00 Non-WG Items: "TCP Urgent Data", David Borman draft-gont-tcpm-urgent-data-01 "A small issue in RFC3782", Yoshifumi Nishida http://www.us.nishida.org/newreno "Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation", Markku Kojo draft-jarvinen-tcpm-sack-recovery-entry-00.txt ===================================================================== ===================================================================== Day two. Notetaker: Matt Zekauskas * David Borman "TCP Extensions for High Performance" draft-ietf-tcpm-1323bis-01 (see slides) rfc1323 under revision for way too long. How many people have read the document? A handful. How many people have read the diff diff of the previous doc? similar The mss discussion has been pulled out into a separate document, it will be discussed next. This version added text about Matt Mathis' discussion on window retracton, a ganularity issue. There is now a non-zero security section. Send any other items to the list to be put them into the issue tracker. -- -- Open items: 1) Remove changes from 1072 and 1185, and update changes from 1323 2) Timestamps option: New draft from F. Gont. Do we want to make changes to 1323.biss to allow this? Currently timestamps are only consistent within a connection. question that should discuss here. do we want to do that? so after that, submit if no other issues. people need to read to comment. Joe Touch: Hasn't wrapped his head aorund the tiemstamp issue. It is not a security thing, should not make it related to security. field with big space, try to relate it to security properties. think mistake. summary: seqno to id different connection, use timestamp to do same sort of thing. joe: not saying right/wrong. if fn scrambled to produce add'l check ok with that. secret_key makes me nervious Iis it really an attack, and worry about it. if worry about attacks, use security. rather than make this a rube goldberg mechanism. putting in things that think might fix. rediculous. With regads to the draft right now, the original rfc talked about timestamp. this one talks about global timestamps, modified on a modify per-connection. please comment to mailing list XXXX[anders persson anders.persson@sun.com ?] nope. Alexander Zimmerman. Alexander Zimmerman: A quesiton about the PAWS check change so that segment size 0 is acceptable now. If we have one way traffic and reordering of the ACKs on the reverse path, the new PAWS check discards the out of order ACK. This slows down connections that are counting ACKs for opening up the congestion window. Is this an issue or is it OK? David Borman: What I'm hearing you say, is that the rules now, with the additional check of 0 size, ACKs are thrown in some cases? Alexander: Will send an example to the mailin list. Lars: react to joe a little bit. He shares the general feeling, but the formula here, is same as from rfc 1948 for ISN selection. two things... read abstrackt two reasons claims 1. harder for an attacker. can argue about usefulness also lets you cycle betwene connections faster, a benefit that isn't secuirty related. That is all he is willing to say w/o reading more of draft. can say why, w/o requiring. would allow to cycle faster if so desire. but not requier just like today not required Tim Shephard: Same sentements than lars. from joe's comment earlier... tweak to security... the right higher level point. this just feels like not a big deal, so if any benefit at all, go ahead. joe's point is valide. ... then randomizing. but had implmentations of how to do it to recycle connections. so this kind of thing allows that re-use, with some randomizing. Joe: The key is to be careful on languagne use. purpose here is very much like any other system. when open > 1 conn, don't step on # very often. helps spin the counter more quickly. so don't reuse # provides very limited protection from off path attackers as speeds go up , abilty for attackers grows with sq of speeds. careful to say limited, only off path. timer at same rate, but ports mean differnet isn using T. "TCP Options and MSS" draft-ietf-tcpm-tcpmss-00 see slides. David: Over years has explained this multiple times. At a previous IETF it was suggested to move this to a different doc, so it is not buried in the back in an appendix. comparing who adjusts for options whaddya do when options are in the mix. lower rh corner, if don't adjust, too bg, and that's wrong. then get frags. other 3 boxes are "ok". options, variable length, can change. when first send, receiver can't do the right thing so why sender should just take care of it. joetouch: only complication here, is when have databases, mibs for apps to find mss from tcp, and sometimes they use this info find that I can send 1400, but send 1300 because 100 bytes of options would like to lie to apps, so sends right amount. # not just local to tcp, depend on who telling to. MSS is specific to tcp, doesn't matter to paps Joe:: look at RDDP protocol. want to sorta adjust socket calls to sync with tcps in weird ways. doing nasty stuff that don't think is ppropriate want to assume send on wire at certain wais. make happen this is simplified. if ipv6, lots o other headers in between, need to adj for that. when I'm sending tcp, have knowledge of effective MTU, and knowledge of own stack, in terms of headers. have to know Matt Mathis: When did we first see this table? Thinks 10 years ago, it would be useful to date it. This is something that has been known on the inside a long time, and people keep discovering it. Stwart Cheshire. is it accepted that mss is supposed to indicate total buffing recever has for options as well? David: MTU is packet size MSS is # of TCP data bytes in segments, not counting headers and other stuff. Most implementations should put in 65535 for MSS options, everyone can handle packet that large. That's what is supposed to be there. So why don't people do that?. On a local ethernet interface, the MTU is known to be 1500. So, using that to calculate the mss, someone won't send larger packets that have to be fragmented. But if have two interfaces on a system, with two different MTUs, to fill out MSS take larger, and use for all connections. you are correct. But if people are limiting, this is what they need to do. Gorry: Comment, found confusing, although remmember. Thinking more recently about effective path MTU. that is a bit of debate. David: Path MTU overrides what's in here (if smaller than MSS), the local interface overrides both (if smaller). * Yoshifumi Nishida A small issue in RFC3782 http://www.us.nishida.org/newreno An issue in New Reno after Fast Recovery (see slides) -- an issue 1 smss, might delayed ack, and slow things down -- pix of issue -- pix of other case ?: transmit new data 7. cong window is 1. under slow start thresh (is 3) so can perform slow start, no? no. because at this moment... no, actually is good poitn. need to receive ack packet to enter slowstart. is ambiguous. ?: linux in this case would perfom slow start -- other possible scenarios -- proposed solution ensure cwnd at laset 2 SMSS -- ns-2 mod for rfc3782 ns-2 is slightly differnet... -- sim result better -- discussion * is rare dont' think so * do like ns-2 and increase cwnd after fast recovery [(enter sstart?)] Matt Mathis: This is exactly the code that causes relentless problem pulling cwnd down to flight size. The idea was introduced when rfc2581 was in draft, and treated as editorial change to switch cwnd to flightsize. It was not accurately investigated, and regretted not fighting it then. one change others have done, might help here if tcp always generates bursts that are 1> std ack covers typically 3 packet bursts. can justify "might be ok to send in any state" also if get stretch acks. in order to open window, have to tolerate bursts stretch + 1. used to justify adding reordering parm to burst size, when pull down cwnd can do that here. one of sender mss mult by reorder help in several cases at least one kernel aready dos this. complicates? MM woudl be more complicated to explain borman: what would you like us to do. take on as wg item? for our time schedule. hjm. feel that they understand and how many worthwhile how many peole not take on unsure. like as wg itme, if everyone else does work? take to ML and put out thing for people to ask if wog item. prepare internet draft, and take to ML * Markku Kojo "Using TCP Selective Acknowledgement (SACK) Information to Determine Duplicate Acknowledgements for Loss Recovery Initiation" draft-jarvinen-tcpm-sack-recovery-entry-00.txt (see slides) -- alt alg to trigger fast retrans -- the algorithm. see draft :) -- potential issues first two, tcp sending small segments. if so, can't repair fast retrans on time. will modify draft to deal with this. see next version recevier misbehaving. no sack info. don't use with NewReno delayed dupacks will be counted as extra. -- trying to solicit feedback qquestions, if burst interest. questions at this time? this is basically the algorithm that linux already implements MM think it appearedin FACK paper 10 rys ago. believe it's in paper concurrent with 2318. ahven't read your doc. looked at seq based criteria for ... think similar but not exactly same. mm: already widely implemented w/o being standardized implementing existing practice. know enough to take hum? no ope. take this to ML. will propose there as wg item, see what people have to say. Lars: quick general comment. don't think discuss here. tcp has pretty impressive set of RFC to thepoint where need roadmap doc. we're into docs that fix nits in other doc. if do, have explosion of docs in tcp space think o fa way to consolodate set. not topic for today, but. dborman: yeah. no one wants to open up host requrments tho borman on TCP Urgent Data draft-gont-tcpm-urgent-data-01 rfc793 is conflicting 961 corrected 1122 reiterated mostly been ignored. fernando lists. 4.4 bsd. -- other thing want to metnion, but don't want to talk about OOB data if sent oob data, would pull it out of interface that's just wrong. put a way to make inline. in tcpm, only concerned inline. don't care about old stuff. my recommendations: take on as wg item, and use fernando's paper as starting poitn. think that should change defintion. with fernando's survey, everyone imple other way. either say everyone change, or we change the doc to not change impl. my personal feeling, easier to change the doc. gorry: nicely documented right way round. but my comment really is, worth considering a rec just not to use. this seems to harp back to old fashioned way of doing things. David: fine. think should still fix it. joetouch: agree with gorry. also useful w/alfred's comments about renaming dont' want to do that. but include description of if use it "this is what actually means" try to push forward your processing of bytestream to follwoing point because something may be interesting fast forward when you can. nothing about how much info, or useful info. yep, correct. just points to interesting point to data stream. say explicitly . doesn't look like OOB. up to app to determinge what means, and what is interesting. telnet makes use of it. timeshep: rec that we not use it, declare dead. doesn't make problem go away at last meeting... can't deprecate all protos that depend on it. should proceed as you just said. gorry: to get back to joe. didn't want to contradict. doc. and conclude: don't use it. this is backwards compatability thing. David: and clear that not OOB data, and don't try to use it that way. Lars: agree w/suggestion to explain and deprecate. tim: deprecate is odd, not reccomending that telnet deprecateding. not implying telnet neds to be rev. joet: phrase really want to say "SHOULD NOT BE USED FOR NEW APPLICTION" deprecate is not work. implementation is required. should not be used. David: so, change definition, and also say don't use because not that useful and explain why. hum keith? request for clarification? write telnet, still must truth is, useful in telnet. right. don't use. * also at end, finish discussion about Alexander Zimmerman from day 1 Tim: great idea, wish I had thought of it. So take to list if wg item. There are still things that should be discussed. Gorry: Not sure if it is ready for a wg item. Thinks it is a cool idea, but not ready to think wg item. David: Let's discuss this on the list, so we can decide if we want to take it on.