TCPM WG Meeting - IETF 65 - Dallas, TX Notes taken by Pasi Sarolahti [2:59 @ ietf65monch2.mp3.1] Agenda Bashing WG status TCP authentication and encryption draft-bonica draft-weis 2581bis ecn-syn anti-spoof draft new additions Updated charter * aggressive milestones - all WGLCs before montreal * Left out milestone for 2581bis, but it would probably be mid summer ----------------- [3:01 @ ietf65monch2.mp3.1] Status TCP roadmap * approved last week as informational -- at the RFC editor queue NCR passed WGLC In-window attack prevention (tcpsecure) - new revision available * needs review, much new text. User Timeout draft -- new revision in progress * missed Dallas deadline Soft Errors draft -- need reviews on this * Need to look whether the draft starts to match WG consenus, i.e. it is written in farily neutral way * Is it starting to converge? * Lars Eggert: suggestion: find volunteered reviewers * Ron Bonica volunteered ICMP attacks draft -- did not get on charter, needs reviews ---------------------------------------- [3:05 @ ietf65monch2.mp3] draft-bonica-tcp-auth-04 -- Ron Bonica How many have read? * several (about third of the room) Presenting slides: Many operators do not authenticate TCP control protcols * BGP and LGP Concerns on 2385 * CPU utilization * key management, rolling over keys Better TCP-layer approach * new tcp option * hitless key rollover * stronger crypto Alternatives * TLS, does not protect TCP session itself * IPsec, operators prefer somethin simpler, and there are coordination issues with pre-shared keys Key chain * up to 64 keys Sending system procedure * identify key candidates Receiving system procedure * look at incoming option, find matching key, calculate mac Authentication error procedure Coming soon * Currently relying pre-configured keys * Automated session key distribution * draft-weis-tcp-auth is a super set of this approach Proposing this to become WG draft Joe Touch sent long note to list * Allman: could you sketch his note and respond it? * merge Bonica and Weis drafts * Ron: would like to push back this a bit, would like to separate the two * Some authors might want to refer to separate drafts * Have to get draft-bonica through quickly, even if the other one takes longer * Ron: Don't remember the other topics Bob Braden: sounds like a fundamental mechanism that should be included in any security solution. * Why there isn't one solution? * Ron: Don't understand that myself either * What threats are you trying to protect against? * Ron: Attacker guesses all it needs to guess to insert packets into TCP stream and cause TCP session to reset or become pathological Mark: what do you solve what TLS doesn't and what do you solve IPsec does? * Can't think of something we solve that IPsec does not Mark: What is motivation at doing something at layer 4, instead of relying on layer 3? * Customers not happy configuring IPsec, or rolling over IPsec keys Bob Braden: security area people to evaluate the solution, that problem is real and solution is appropriate * Mark: what Bob suggested should be part of process in adopting this as WG draft. Need to have security folks look at this. * David McGrew: One reason was that we wanted to find replacement for TCP MD5 option, which is not very good mechanism. Replacing bad mechanism with better one * ?: Have requirement to move this draft rather quickly * Lars: why isn't L3 mechanism working * Ron: Need to have a way to roll over preshared keys. Operators have felt IPsec was too difficult to configure * Caitlin ?: Why not solve this on layer 3. If real problem is key turnover, why not fix it there. What is the real benefit of doing this on L4? * Brian Weis: I'm strong supporter of IPsec. First thought that IPsec can fix this. IPsec offers several way for host authentication, use of public keys, private keys, or use certificates. Several cases in BGP where using certificates is not optimal. Will they agree on CA? Could use pre-shared keys, same issues as with MD5 keys. It takes longer to rollover keys in IPsec. Operators are not willing to use ipsec, so to me layer 4 alternative is appropriate * Matt Mathis: In earlier BGP design work we discussed layer inversion problem with BGP: Mission critical routing system. function of layer 3 routing is depended on layer 4. One could say it was architectural flaw. Routing system has constraints that are different from other apps, therefore BGP might need to think of special solutions, in absense of other resources. * Anantha Ramaiah: It is not only about BGP, but also SCTP and others, that are current users of TCP MD5 option. * Email comments from Joe Touch were summarized on mic * Dave Borman: Draft talks about adjusting MSS, because TCP header size affected, because now more options are being use. If you just adjust the MSS you just adjust it for the fixed header, not for the options. * Ron: ok. * ?: There is nothing in this draft that mandates use of time-based keys, it just suggests that time-based keys can be used. * Get it to review by security people. Security directorate are available for this kind of review. ---------------- [3:28 @ ietf65monch2.mp3.1] draft-weis-tcp-auth-auto-ks-00.txt -- Brian Weis Presenting slides: How to manipulate set of MAC session keys * manual keys are not optimal * light-weight mechanism to dynamically set the keys Goals: * Improve operation characteristics of MAC session keys without heavy-weigth protocol * human-generated keys are not good * Better performing MAC algorithms can be used with automated keys Proposal * one endpoint pushes MAC session key to the peer, encrypted with pre-shared key Still a long term key * less burden on operations staff * better MAC keys Uses K bit in draft-bonica Sender processing Receiver processing When should a new mac key be chosen * when no key available * may recommend that when sequence number wraps, etc. * may have some other policy Better performing MAC algorithms Newer MAC algorithms to use nonces * most obvious means to generate is sequence number * TCP sequence number is not sufficiently trustable Lars: I don't see strong argument why these mechanisms are needed at L4, now mentions one specific application. Will any other application actually use these ever? If IPsec cannot be configured to support changing keys, what is it good for? Maybe we need something done at L3. Do we need to have application-specific fixes in TCP * Brian: Don't want to say this is a general purpose TCP auth mechanism Joe: 1) In IPsec it is impossible to have session key that is specific to one TCP connection. 2) IPsec does not understand the impact the key roll-over. Higher order bit is, there is lot of re-inventing what is in IPsec. I don't think this should be done here. * Brian: SPI indicates a whole set of policy in IPsec. Getting the SPI requires a whole different protocol. Need a lighter mechanism for this case. Matt Mathis: In flow routing table you have bits in the routing table from every instance of BGP. Constraints to version management. There are not many implementors, do they want to put energy in implementing this, IETF needs to check this is done right. * Brian: draft-bonica has authors from three different router vendors Scott Leibrand: BGP is important enough. It depends on TCP, if you break TCP you break BGP, you break routing. We have MD5 now, we need to have something that is as simple as MD5. This sounds like promising way to do it. Joe Touch: Different router vendors have had different excuses for not installing MD5. These drafts address only some of the problems, not the loudest recent one. One is CPU will get overloaded, and people don't want get it overloaded, and won't do this. Draft doesn't address this problem. Initial key exchange is another problem. Agree that It would be nice that there was a mechanism to negotiate the keys. It would be nice if the proposals got together. At some point it is re-inventing IPsec. * Brian: We were set up to do a simpler mechansim that IPsec. IPsec complexity does not satisfy operators Alex Zinin: CPU overload issue is not enterily correct. Router vendors have had TCP MD5 implementations for years now. It's a problem of service providers turning it on. DTL is a solution to the CPU problem. David McGrew: New MAC authentication code is the fastest code around, alleged by the designers. This is improvement over TCP-MD5. Joe: Alex is right -- DTL is much faster. If you are one hop away that works well. If more than one hop away, you end up doing IPsec. DTL won't work, you are going to be spoofed. MD5 is fastest algorithm around. Difference between AES(?) and MD5 is factor of two. Even if new MAC is faster than MD5 it is still too slow for people turning it on. It is the operators who are afraid to turn this on. ?, cisco: Having highly utilized CPUs processing with thousands of sessions, putting this thing on is not that significant(?) Alex Zinin: If you have highly utilized CPU due to thousands of session, no security algorithm is going to help in that case. Security always comes at a cost, and CPU utilization is one of them. IPsec has also other costs than CPU utilization, like management and configuration cost. Joe Touch: IPsec has a mode that not use certificates: private keys. The roll-over problem can be handled with private keys. It is already implemented. This is not implemented. Not convinced service providers want to use time-based authentication. Mark: some of this stuff is a little bit premature, need a motivation this is something that is solved in tcpm. We need to have security folks review this, and need to understand why we are doing this, and then check that things are done in the right way Scott Leibrand: How do I do this in my router with IPsec, if I cannot do it today with IPsec? If IPsec can be made as simple as MD5 it is viable, if it can't then people will want to use something like MD5. Alex Zinin: In the transport side, What is the summary? -- We do have a motivation. If SAG says this is ok, will you start working on this? Mark: Transport aspects of this are somewhat mild. Security people should say that we need this. We cannot evaluate key rollover in this WG. We need to have views from both sides of community. Need to have this well motivated. Lars: ease of maintaining and configuration is soft metric. Different opinions on that. We cannot judge that. Mark: Need community help with that ?: Seen that it requires just three lines of configuration to set up manual keying in IPsec. Just need to have vendors come up with an alliance to set up the keys. Problem with router vendors was manual keying, need to come up with a configuration solutions between the vendors. I don't think it is a configuration issue in terms of technical problem. Aaron Falk: argument sounds usability argument. Tradeoff is security arcitecture tradeoff, out of the scope of this WG. Is there a transport problem here? Authors should come up with crisp statement what is the transport problem they would like the security solution for, then security people review that and have proposals on how to solve that. --------------------------------- [4:03 @ ietf65monch2.mp3.1] Revising RFC 2581 -- Mark Allman Presenting slides: * Modest changes * Fix bugs in the doc * Roll in small changes * Initial cwnd * Limited transmit * Keeping diffs very small Clarification of what dupack is Setting ssthresh * Proposal: do not lower ssthresh for backed off RTO * Seems out-of-scope, but it's so small change. Maybe it shouldn't have to go thorugh experimental path as separate document. * Arguments on both sides * Authors are muddled * Sally Floyd: Does anyone argue this is technically not a good idea? * Mark: Most people said this is ok, it is mostly procedural question. It is unclear would change like this hinder it from going to DS Anantha Ramaiah: General comment, if we have small little things in algorithms, where can those be fixed? Things that have been implemented, but not reflected in the drafts, just curious. * Mark: small little things have usually become own small docs. Maybe it would be reasonable to have a "implementors guide" on these. David Borman: If there are no problems in including this change, put it in. If it becomes problem, take the change away. Continuing slides: ssthresh: MAY set to infinity => SHOULD be set to infinity * Pushback on the list: hosts might have reasons not to make this infinity. That's why it is SHOULD, not MUST. Definining infinity * suggestion on list: set infinity as big as current winscale would allow. Seems like reasonable option. * Matt: That's what one major stack already does * John Heffner: It was me who suggested this on list. DSACK * should define what happens if an ACK with DSACK arrives * we should probably say something * RFC 2581 would count them as dupack, maybe it is not the right thing to do. Duplicate acks after RTO * don't really indicate more loss * what to do with dupack received after timeout? * seems too out of scope to be included, number of small issues that are related No other comments ----------------------- [4:20 @ ietf65monch2.mp3.1] draft-ietf-tcpm-ecnsyn-00.txt -- Sally Floyd Presenting slides: Purpose * Modification of RFC 3168 * TCP SYN/ACK packets to be ECN capable * Avoids RTO if SYN/ACK packet would have been dropped SYN/ACK can be sent as ECN-capable only if SYN has ECN flags Security concerns * Do bad midboxes drop SYN/ACKs with ECN? don't know any * There is no danger on congestion collapse Changes * suggestion to use similar thing also in other protocols * added discussion of one-way data transfers * added discussion on SYN cookies Response to ECN-marked SYN/ACK * option 1: set initial window to one packet, continue in congestion avoidance * option 2: wait for an RTT, proposed by Mark Allman * is this a congestion signal, or a special case? Showing simulation graphs of the two above mentioned alternatives * in practice seems that there are not very much difference * Sally would go for proposal 1, because wnen senfing SYN/ACK packet, there is no initial sending rate though there is initial congestion window Matt: at what point in time a non-ECN case crosses ECN case, after RTO and going in to slow-start? * Sally: Depends on RTT. If there is congestion, slow-start is not likely to continue very long. Mark: I don't understand the rate argument. The response is not a major issue, does not matter much. More concerned about the consistency point. Like response 2 better, because it is better aligned with ECN RFC (should wait when you get CE). * Sally: congestion window is just a mechanism. Sending rate is the principle behind it. * Sally: there is response: reducing cwnd from 4 to 1 * Mark: But you have never sent four packets. The load has not changed. * John Heffner: if you have congestion on 40-byte packet, you should not have larger window. Sally: One vote more mark. TODO: * converge om the response to the marked SYN/ACK packet * look at the costs of adding ECN-capable in a worst case scenario * find out what tcp implementations do in response to syn/ack that has been marked How many people have read this draft? a few Hum on CE response one vs. response two * hums on one: little bit * hums on two: little bit Dave Borman: what if you have bunch of connections starting at the same time and all are marked CE. What is the aggregate effect: on option one bunch if connections start with cwnd of one, in the latter the connections wait before they start. Looking at one connection doesn't help much on selecting response. Should look at many connections * Sally: agree that if option two gives better aggregate performance, we should select it. Scott Leibrand: sounds a lot like SYN flood. Would non-ECN capable connections beat the ECN capable connections? * Sally: I think smart routers would not be marking packets under SYN flood, but rather drop packets. Router would drop non-ECN capable packet that it would have marked if it was ECN capable. Matt: I think a SYN flood would not cause marking * Sally: It would have to be SYN/ACK flood ---------------------------------------- [4:46 @ ietf65monch2.mp3.1] draft-ietf-tcpm-tcp-antispoof-03.txt -- Joe Touch Slides: comments from Ted and Pekka Changes: * Revised references * Clarifications in text * Extended tables * Discuss advantages to transport solutions Seems to have convergenced mailing list: ready to have last call. Mark: who has read it? not very many. Needs a bit more review. Working group last call should be quite soon. Joe: Would like to set some target date on list to get review. Let us know even about the high order bits, if things look ok. Would like to get this done soon. Mark: WG Last Call is taking place before next IETF, unless something earthshaking happens. End of meeting.