TCP Maintenance and Minor Extensions WG (TCPM) Tuesday, 2007-12-04, 17:40-19:50, Salon 2 IETF-70, Vancouver, BC, CA =============================================== This session was "guest chaired" by David Borman and Lars Eggert. The chairs, Mark Allman and Ted Faber, listened to audio and were on the Jabber session. Matt Zekauskas acted as scribe. AGENDA: 1. WG Status + Agenda bashing (10min) 2. UTO scraps (10min) 3. ECN-SYN WGLC (5-10min) 4. Advancing F-RTO (10min) 5. Acknowledgment Congestion Control (10min) 6. TCP Authentication Option 1. WG Status + Agenda bashing (10min) (see slides) Lars opened up the meeting. There are two working group last calls underway: 2581bis and ECN-SYN, which run until 21-Dec-2007. Please comment. Tcpsecure has been delayed waiting for an applicability statement by the authors for discussion in the working group. The statement should indicate which mechanisms that the document proposes are suggested to be implemented by TCP (or which TCP implementations should consider implementing the proposed remedies). The TCP-AUTH design team has finished. They have come up with an initial proposal to obsolete TCP-MD5. The team has been running for 6 to 9 months; the working group now takes over. (This is the subject of the last agenda item.) The draft is pretty solid. There are a few remaining issues, but nothing large. We expect to move it quickly through the working group. Work has been started outside TCPM for algorithms and keying components. There will be a discussion in the security area group (SAAG) later this week. 2. UTO scraps (10min) draft-ietf-tcpm-tcp-uto-08.txt -- Lars Eggert There were no slides for this item, as Lars just wanted to call attention to the current state. This draft is in working group last call. There has been a revision posted that Fernando and Lars believe addresses all comments. If you commented, please check and see if you agree. If there are no further comments we will end WGLC. Magnus will be acting as AD for this draft, since Lars is an author. 3. ECN-SYN WGLC (5-10min) draft-ietf-tcpm-ecnsyn-03.txt -- Sally Floyd This draft, too, is in WGLC. See Sally's slides for a summary. One issue that was left open for a year was how to respond when a SYN/ACK is marked with ECN. Should we decrement the congestion window immediately or wait one RTT. They finally did some simulations, which was reported on at the last IETF. The current version addressed issues in raised in the meeting. There was also some general editing. There is one open question from WGLC comments. This was raised by Bob Briscoe (who showed up while this point was being made during this meeting). In Section 4, there is a subsection on backwards compatibility. Old (current) implementations (Linux, Windows (which is not enabled by default), Mac OSX (again not enabled by default)) ignore the ECN mark, which is what the current standards say. The problem is if the originator, who sends the SYN, doesn't understand ECN marked SYN/ACK, with a new responder -- and the SYN/ACK is marked in the network. Does the originator ignore the marking or tell the other end point. Current implementations will ignore. A new implementation will "do the right thing". The draft did not add negotiating capability... this is a transient backwards compatibility problem. The authors felt it was not so terrible; few are using it now, and if the sender doesn't hear about it; the sender will hear eventually on data. This seemed a "ok to live with" problem. Bob disagreed during WGLC. What do you do? One could use one of 4 reserved flags left in the TCP header. The flag would be only meaningful in SYN. [option 2 on slide] One could use an ECN-SYN option, but Sally did not think that would be a good idea. So, Sally would be happy going with the reserved flag (since it is only meaningful in SYN, and could be reused later) or ignore [option 1 on slide]. What did the group think? During Sally's explanation, Bob arrived, and commented that he would generally be happy with 1 (ignoring the problem), but felt we should better understand the problem before deciding. He could see problems with short flows. He was not as happy with using one of the reserved flags for this transient condition. Gorry Fairhurst asked Bob to clarify the bad situation -- is it when the whole transaction is just 4 packets? Sally replied first, saying yes, that's that's the bad situation, if servers are old and marking the SYNs, and there are lots of short transactions. This could be unfair with respect to others that did not use the ECN marking. If the endpoints that use ECN have all their packets get through, and those that don't have their SYN/ACK packets dropped, and thus timeout. Bob stated that a quick back of the envelope calculation showed that something like 70% of objects are served in one initial window. If the SYN/ACK is ECN marked and the receiver does not understand, then the sender never responds to congestion, and this is bad if there are a large number of flows. Mark Allman commented that the cost to solving the problem is too high. Sally remarked that she didn't think it warranted study for another year. David Borman noted that if you choose option two (an additional TCP flag) you are stuck with it forever. If you ignore the problem, it goes away once the transition is over. Unless severe problems crop up, thinks ignoring the problem is the right way to go. Sally commented that it is easier to upgrade web servers than users, and web servers that could be problem. Bob disagreed, in that the upgraded web server with lots of stupid old clients is where the problem comes up (since it's marking the SYN/ACK). Sally agreed, and said one factor in favor is that the old behavior is not enabled by default. If this comes out after a large release that enables it, then we might have a problem. Lars stated that he's leaving it to the real chairs to declare consensus: please discuss on the list. 4. Advancing F-RTO (10min) draft-ietf-tcpm-rfc4138bis-01.txt draft-kojo-tcpm-frto-eval-01.txt Markku Kojo presented the case for advancing F-RTO to proposed standard from experimental. See slides for background. The revised draft added back enhanced SACK, which was removed in -00, because the authors discovered that most implementations do use it. There is also a clarification of multiple timeout behavior. The main question to this group: is it ready to advance? The authors think there are strong arguments for advancing the specification; there is a wide base of independent interoperable implementations. Lars noted F-RTO has been experimental for a long time; there is a desire to move it to proposed standard. There are lots of implementations. He wanted to get a sense of the room if people supported advancing the draft. Sally noted that she has not followed it in great deal lately, but it seemed reasonable to her. Lars said his personal take was that there is a very strong show of support for this, given the number of implementations that use it by default. In his opinion it has already passed the bar for full standard, and it should be easy to go forward. Mark Allman thought personally it should have gone to proposed standard to begin with. Ted agreed. Please comment on the list. 5. Acknowledgment Congestion Control (10min) draft-floyd-tcpm-ackcc-02.txt --Sally Floyd. Sally presented acknowledgment congestion control, which is something she has been working on. It is "mostly specified"; there have not yet been any simulations. The question here is if it looked like a reasonable item for the working group to take on, targeted for experimental. There is one slide on what's there; basically if there are lots of lost ACK packets, use a higher ACK ratio. The sender uses byte counting and rate-based pacing. There are lots of changes from the last revision. The use of SACK will change from REQUIRED to SHOULD, most likely. The big possible complication is what happens if TCP skips sending some ACK packets, or a middle-box suppresses some of them. There are many proposed mechanisms, but it is not clear if any have been implemented. the problem is that if ACKS are skipped, the sender doesn't know if they were dropped or not sent. What can we do? 1. receiver could say, I will not skip ACKs if using ACKCC 2. receiver could use a TCP flag to tell the sender that it is sending aggregated ACKs. Sally noted that she was not asking for a flag today. Simulations and other evaluation will start in January. Sally asked if there were any comments... did the group feel if this was baked enough for the group to take on as an experimental specification? And if so, what kind of experimental -- how cautious should we be in the advice to implementors paragraph in the abstract. That really would have to wait for the evaluation. Lars asked who had read -- a couple, one of which was the co-author. Gorry asked if he could ask a question without reading -- how does this draft relate to RFC 3449 from PILC, relating to asymmetry. Sally said that she thought she looked at it (a document by Hari Balakrishnan over lunch; that document cited a bunch of proposals and related work. This document could be thought of as a successor to that one, and cites it. Hari had his own proposal that wasn't so much highlighted by that draft/FRC; it was presented in an earlier paper. In that proposal, all ACKs were ECN capable, and the sender and the sender would detect the loss of an ACK packet because it was ECN marked; it wasn't trying to detect dropped ACK packets. The proposal in this document is more general and robust than that one. Gorry said he was thinking more about the case in 3449 where middleboxes were considered. (There was some confusion if Gorry and Sally were talking about the same document or not; I believe Gorry thought so.) What happens if they reduce ACK rates? Sally didn't know off-hand, but it was one of the things that Hari's draft talked about (using middleboxes to reduce ACK frequency); she thought this draft's technique should be much better. Mark Allman commented that there was work in TCPSAT on this issue as well. Over the next few weeks Sally wants to hear on the mailing list if this draft should become a working group document. 6. TCPM Authentication Option draft-ietf-tcpm-tcp-auth-opt-00.txt --Joe Touch Joe Touch explained the input, a bit of process, and the results of the design team looking at TCP MD5 replacement options. As input were the candidate drafts for updating TCP MD5, and a draft from Steven Bellovin on the security requirements for a TCP MD5 replacement. The output is the current TCPM I-D. As part of the work, however, the group updated and augmented Bellovin's requirement document. The new list is summarized and addressed in the TCPM I-D. One question for the group would be should we move forward with two documents (the TCP Authentication Option document, and a requirements document) or just one. Joe also summarized the key decisions of the team (see slides): * Use a new option type, as it is both safer and easier. A "Key ID" is available for use during long-running connections to easily allow rekeying. It is optional, and intended to be used for the short period where there could be key overlap. * Do not directly support NATs, as they do what this option is designed to detect. If you must use a NAT, tunnel TCP over another transport protocol -- which is what IPsec does. * It is optional to say if TCP Options are authenticated. There are various boxes that munge them, and you may want to detect this (it is again in some sense the attack that TCP AO is designed to detect). However, there may be cases where it is desirable to disable them. This is another place where the group needs to make a recommendation on how to go forward. * 8 bits of key space should be more than enough to support all the keys a single connection needs at a given time. * The draft does not specify which algorithms should be used. That's for the security area, which has the expertise, to help us with. We just want two that are mandatory to implement, so there is backup if one is cracked. * Authenticate before TCP processing. The temptation is to be able to drop a packet early. However, it is possible that any packet you process might update a TCP action -- like reseting a timer or duplicate acknowledgment processing... so you need to check the validity before processing. * The draft is agnostic with respect to key management. There should be some external key management solution. * You cannot start a connection with TCP-MD5 and then switch to something else. The existing TCP-MD5 specification does not allow it. However, the new TCP AO system could include support for MD5 for backward compatibility. [The draft currently recommends this.] The group decided to start with draft-touch-tcp-simple-auth and modify that, since it required the least amount of changes to match the requirements. It was updated to reflect the key decisions above, and address Steve Bellovin's issues. It has a TCP Security Association Database (TSAD) like SAD in IKE. Joe then went on to show a summary of the proposed algorithm, including some packet headers (see slides). There were some things the design team deliberately left out. * In-band key negotiation. The TCP header space is not big enough during the initial three way handshake. * Replay protection. TCP provides that in the transport layer. Between sessions, don't re-use the key; this is an additional requirement. Use IPsec if you want to maintain keys. * Key synchronization. You don't want to deal with packet reordering or anything else, so the KeyID was introduced to allow you to choose the right key during rollover. Paul Hoffman asked a question about re-use of keys. He remembers a discussion, perhaps in Dallas, where a desired use case is that people use passwords. Here you couldn't use the same password twice? Joe replied that in that case, the password would not be the sole input to the session key. This is part of key management; even with manual keying, you don't re-use per-session keys. Paul asked that in the case of a password, you would not just use something read over the phone; Joe replied again that there are techniques to generate a good session key, and he thinks we can do that. What do you lose if you do allow reuse? You are encouraging use for long periods; you could have an attacker take some material from an old connection and put it in a new one. Paul understood that it was "bad hygiene". Joe said that non-re-use is a SHOULD in the current document; they were thinking of allowing explicit overrides for some cases. Paul said he was worried that it's not necessarily clear when the session changes. Joe noted that if you have a TCP session, an endpoint can go away and return, and TCP would continue to accept data with the same key. In any case where the connection closes or aborts or restarts, the connection should have gone into time-wait, and it should be noticeable, and yes that's when you would use a new key. If that is not clear in the document, it could be improved. Ted commented on Jabber that the term session is misleading. Joe means TCP connection lifetime which is well defined. There was a comment that replay was the only issue; any of the new MACs is strong enough to run for a long time. So, the next step is to get feedback from TCPM. Section 1.3 has the open questions list. Please ignore for now errors in the table of contents and numerous typos. In addition, there is a joint discussion this week in SAAG on key management and algorithms for TCP-AO. Please participate there. Sandy Murphy said that there was at least one point in the document where it states that key re-use MUST be prohibited. Given the several comments here, and the comments in the design team on key re-use, Sandy expected this was an area that needs some attention by the working group. If there is replay possibilities between the same source and destination, one of the ports should change. Joe noted that after time wait, TCP can re-use ports, however. One of the most dangerous attacks has to do with injected SYN packets; if it is accepted, it will abort the connection. Lars noted that the algorithms will be discussed in the Security area (SAAG) on Thursday. It would be good to get input from SAAG on keying -- understand if the document is going in the right direction, or is completely wrong. Please read and comment. Lars called for a two part question for the room -- to get a feel for the room, not deciding anything. Hum if you think that modulo some fixes and clarification this document is what eventually will be put forward as a replacement for TCP MD5. [high-moderate hum] If you don't think this is the right base, and would like something else [no discernible hum]. Lars felt that this was a strong indication that this document is a TCP MD5 replacement candidate. Paul asked for clarification on what SAAG would do regarding helping with key management and MACs. Joe said that the design team felt that there was little expertise here, and we should request input from where the expertise was -- SAAG. There didn't seem to be a particular working group that fit, so considering it in SAAG and TCPM seems to be the right choice. As long as two authentication algorithms are recommended, that would be fine. We would also like them to be reasonably fast. A question was relayed from Jabber: Ananth asked why does the document specify that it obsoletes 2385, but it still allows co-existence with 2385? Ted Faber stated that he thought it would obsolete 2385; Ananth clarified that it allows MD5 to continue to exist, though. The document is intended to be backward compatible. Sandy asked if it is an "obsoletion" if we are proposing that the two might work at the same time? The RFC editor allows only a small subset of verbs. "Obsolete" is the only one that fits. It is not updating, and it is not deprecating. Paul noted that "obsoleting" means deprecating the old document immediately. Joe noted that it should be deprecated for a number of security reason. Paul clarified that it means deprecating on the day the new document is published. Paul thought that this is similar to a discussion he had about SMIME; we shouldn't say obsolete. The right thing to do is not obsolete the document, but have a separate document to deprecate or make historic or obsolete TCP MD5. When that one passes, TCP MD5 will fall off the acceptable stack. Lars felt that Paul was right with respect to the verbs. Paul said that when something says deprecate, it means "change status to obsolete". Joe said that the design team intended to make the old version obsolete, but not completely prohibit to support legacy code. Tero Kivinen thought we should look at IPSEC as an example. IKE2 obsoleted IKE1, yet most everyone continues to use IKE1. There are even RFCs out after IKE1 was obsoleted, supporting and adding stuff to IKE1. The working group should get a better indication of what the names mean, and indicate which one we would like to use. There was a question about the use of option types. Joe said we could use a single option type, which the security association would encode (if you didn't have the right algorithm, you could not verify the stream). The reason for multiple option types is that it is clear when we change the MAC; it's really mostly for the human beings, so that they note we are switching to something completely different. Sandy noted that it's also easier for humans to write the implementation. Joe said that it wasn't strictly necessary, though. We are not going to use the MD5 hash as a viable algorithm for TCP-AUTH. Thus, the hash would never generate a result that would collide with something else. Lars noted that TCPM probably doesn't have strongest feelings about the continued use of MD5; it is the security folks that should have the most input with respect to what should happen with MD5. We should take their input and go along with that. Lars then went back to fact that the document currently contains two parts; the TCP-AUTH protocol, and the requirements that are an extension of Steve Bellovin's document. Should this be one document or two? There was a general feeling that we should do whatever makes the document come out faster. Gregory Lebovitz recommended two documents. Brian Weis felt that two documents would be both faster and clearer in the end. Joe argued for one, feeling that there was less for people to go read. Mark Allman felt that we should have one document unless there was a compelling reason for two, and they are somewhat combined right now. Gregory was not opposed to one document, but felt both would move faster than one. There was a short discussion on list of requirements. We could change the requirement that we MUST single key. There are a few more things along the same lines in the document; the design team made some decisions, but if the working group wanted to change them, it could do so. Gregory said that he hasn't read the latest on the requirements, but were all of Ron Bonica's concerns with BGP addressed? Joe said those requirements are for keying, not authentication. The keying issues will be considered in SAAG or a spinoff; but it is a real concern -- how fast can you generate keys. With that, Lars closed the meeting.