TCPM Dublin IETF 72 Monday 1740. Wesley Eddy chairing. 1 - "TCPM Status" - Wesley Eddy - 10 minutes Introduction. New chairs, replacing Mark and Ted. Note Well. Agenda run through. (About 30 people in the room.) Request for any other items. None. WG STATUS Review of active drafts. softerrors to IESG; 2 items of concern to be addressed by Fernando Gont UTO draft - similar state, Allman was to finish. 2581bis - same state, Ted was to finish. ECN+SYN - changes post IESG, may need TCPM to rereview tcpsecure - authors awaiting WG feedback on wording. Asks audience if there are objections to current draft wording. No responses. Wes says take to list. 1323bis, Auth Option, ICMP attacks etc - nothing major. Charter needs to be redone. THIS IS NOT A JOKE. Items from 2006 that haven't been addressed. Current items not in charter. Change charter to suit. No comments from audience. Active WG Item Presentations: 2 - "F-RTO Draft" - Markku Kojo - 10+ minutes draft-ietf-tcpm-rfc4138bis-02 Detecting spurious retransmission timeouts. One small change to algorithm, preventing F-RTO alg if an earlier RTO recovery is underway, except if there are multiple timer expirations for same segment. Just like previous prevent if SACK recovery in RFC4138. General editing, including suggestions from Alfred Hoenes. Draft in WGLC until 8 Aug. No questions. 3 - "TCP-AO Update" - Joe Touch - 15+ minutes TCP auth update. New version on WG list around last call timeframe. Various protocol updates in -01. - require keyID; remove odd/even info. - relax restrictions on key reuse; use nonce, suggest key rollover. - clarify NAT interaction. - all options included or all options excluded (deleted, not zeroed). Jabber comments - Eric finds nonce confusing, Adam thinks we do need NATs. Joe says that that type of NAT not needed. Joe says take discussion to the mailing list. Discussed minor text changes. must is not MUST; explicitly clarified with note in doc. Discussed open issues: - deprecate TCP MD5? - pick which two MAC algorithms - do we backoff to none or to TCP MD5? Joe thinks discussion is favouring not, more discussion needed. Question re MACs from Gregory. postponed. Joe says when SAAG says what MAC algs are, they will be plugged in. Various new discussion items. Replay protection (Adam Langley) Key issues reviewed in brief. Replay protection. Joe reviews; extended discussion on list over last two days. Do we need unique key per session? Rekeying probably takes place. IP-ID is not unique - this is being taken up in the INT area, to make v4 assume, like v6, it is not unique. Proposed solution considered good enough, if you want more use IpSec. NAT accommodation - include addr/port in MAC and use those, to keep header size down by not adding unique per-connection ID> KeyID rotation - current is change every 2^31 bytes. If MAC alg not strong enough, Joe says don't use it! keyID location - end or beginning of option. Implementation bugs affect this decision. Is KeyID 0 valid? Can it be used as a cookie to implementers? Want feedback. Adding another thing to get right vs benefit to one person. Hideaki Yoshifuji @ Keio Uni./WIDE Proj. Knows someone who has implemented TCPAO for Linux - discussing with that implementer. TCP MD5 does not use 0 ID. Comment on MD5. Thinks that zero should be prohibited. Joe response : kind fields tells you if it's MD5 or not - zero doesn't tell you if it's MD5 or not. Joe says don't decide here, need more info. Alfred Honnes says - offlist discussion on coding of keyID. He proposed not using bridge space in TCP option, but use option number space - index into keyID table. Joe response - only get one option, not possible. Alfred says avoids problems with option size, talks about unused (historical) options vs used options... Joe says discuss historical options and reallocation with IANA. Joe says just use three bytes on end of MAC instead for KeyID. TCPM doesn't control option space. Wes - major enough change that this needs to be talked about on mailing list. Joe: needs IANA on board! Out of our hands. Eric on Jabber: avoid specifying algorithm - random or sequential. Don't presuppose it in spec. Scott Bradner - not IANA's choice - the IETF choice to ask IANA. Joe: out of our hands! Joe: how do you avoid burning CPU cycles? Design a MAC where first three bytes of MAC are nonce. Check MAC, check first couple of bytes, don't need to check rest if that doesn't match. Wants to take all crypto properties out of header. Thinks crypto belongs in MAC. Anantha from Cisco - we should do something about TCP option space. Joe: been there, done that in this WG. Two ways to go: not backward compatible (bc) or bc. SYN bc not possible. Do we create a new protocol. Wes: way offside. Anantha: many genuine requests for TCP option space. We should revisit discussion on the mailing list. Wes: keep talking about it on the mailing list. Request for in-band keying. Design team told not to do this - no space in SYN packets. Proposed solution requires OOB keying, but does not prohibit in-band somehow. Gregory Lebovitz: if we do this, we blow out the roadmap; multiple varying implementations. Believes in-band keying should be explicitly prohibited. Joe: Adam is completing Linux impl. We aim to wrap this up by Oct 2008. We are circling round repeating. Need to make hard decisions, not unanimous decisions. Andrew Lang: this draft is dead. Has been dead for a couple of years. Router implementations are different. draft-bonica is different, not compatible. Why implement this draft when there's draft-bonica in the field? Joe: Bonica was on design team, coauthor of this doc. Some other design team guy dissents. (?) TCPAO in this draft makes sense, still a good idea. Lange: Burn this to the ground! Use what's implemented. Wes: the base isn't reviewed by the group. Fast discussion. Tim Polk: security AD. Stuff coming from us in next month. Shouldn't be a surprise. Making tweaks. Hope to enlarge review circle, with complete set of answers by late Aug/early Sep. It's total package - not just KDF/algs, but also structures, how they change. Aim to give complete recommendation. Apologises for slowness, AD (Tim's) fault. Pushing for something between the two drafts. Ron Bonica: I am John Doe. Sees two sides to the args. Improvemnets over bonica - ISN to generate key material, better protected from replays. Andrew has good point - three vendor deployments, but undocumented. We continue on TCPAO, but we should publish bonia as informational. Lars Eggert: often we publish original doc as informational. But not until the 'better' doc is out, so that we don't favour the early implementation. Nothing special about this situation. Andrew Lange: We could be pissing around for years with this doc. Lars: the draft is already there. Standard policy - do not publish RFCs describing pre-IETF efforts before the IETF effort is out. Do not publish draft-bonica at this time. Greg Lebovitz - implemented, out there, nothing to tear down. If this gives a firm step towards proper key management, good. Lange: wants backwards compatibility. Fine with draft-bonica-bis. Changing header for random reasons (strong phrase) not liked. Joe: changes in the protocols. How much TCP state needs to be coordinated by the endpoints? TCPAO is consistent with don't-add-extra-states-unless necessary. Lange: bonica is the same. Joe: the IETF draft details what to do with the TCP state diagram. Specification of bonica not as detailed. Lange: we have 3 interop implementatins! Existence proof! Eric (jabber): from security perspective, draft not improvement over Bonica. Does it use ISN? It mentions it, doesn't really use it. Joe: grep on ISN Ross Callon: comments from IESG discussion perspective. I was at first IETF! Almost always changes from standards, we have to deal with this. Value in documenting what is deployed, even if pre-standard. While on IESG I have noticed several cases like this, hold doc until the std comes out, then publish both. (Basically What Lars Said.) Thinks can tell which form it is from option space (Joe notes TCPAO doesn't have option allocated), so supporting both possible in implementation. Put a few words on how to transition from/handle both. Ross: if deployed equip from two different vendors, both need to upgrade before they can do both. Joe: you can't change TCP MD5 and escalate it to a different mechanism. Not allowed. Can't change existing proposed standard that is deployed. No hook to get out of MD5. Ron Bonica: you can't change auth mechanism without bouncing connection. Implementation: some routers aren't authing, some RFC2385, some bonia, some TCPAO. Know which is which, options are distinguishable by kind. Lange: ?? Joe: more to protocol than what's on wire. Lange: don't document state machine. Joe: document effects on state machine and bits on wire. May not be on the spec. Not everything implemented is documented. Do interop implementations have corner security cases? We'll never know. Hence more rigorous doc. Lange: routing world concerned with interop. Joe: protocols are bits on wire, states and actions. Very important. Greg: if we improve, we change bits on wire. Lange: what are the improvements here? Greg: incremental improvements, accept it. Lange: we documented the state machine! Really what's better. Lars: How is Wes enjoying first chair session? How is scribe enjoying it? Lange: I'm not seeing improvements! Lars: standards track doc. This is what we do. Consensus process. Design team output adopted by WG. Not aware of dissent and hum. We have now had second revision. Lange: there WAS dissent! Lars: no dissent, otherwise the doc wouldn't be a WG doc. Existence proof. How can we make progress? Don't publish bonica as IETF std. Bonica is deployed because it came late to the wg. Socialised in routing community to solve a problem. What would routing people think if transport people implemented BGP extension? Old protocols, strong communities around them. Take this offline. Wes: Close this after Anantha Chandra: there was feeling that soln was predecided, not run past right group. Gets same feeling from output of design group. Bonica uses 254. Breaks if 254 is used for something else. Bonica needs codepoint. Lars: if we publish, 254 goes to bonica. Need to shuffle experimental codepoints. Shouldn't have used an experimental codepoint. Not to be described in an RFC! Not happy. Joe: exp codepoints - once you let someone take a codepoint, doors are open. Don't allow it! Anantha: TCPAO doc format. Don't talk about state machine. No changes there. Not comfortable with database discussion - makes doc too long, hard to follow. Doc needs to be crisp. Mentioned this on mailing list. Other Proposals and Presentations: 4 - "Clarification of RFC 1122 language on ZWP" - Anantha Ramaiah / Mahesh Jethanandani - 15+ minutes Persist timeout draft. Mahesh Jethanandani finding pubs in Dublin draft joke. Mahesh: persist is getting reliable acks from receiver in zero-window condition. older persist-timeout-02 draft covered sender behaviour in persistn, and DOS caused by sender behaviour. Previous chairs suggested splitting draft into two to address each topic separately. Informational draft on DOS still in works. this draft doesn't talk about DOS. RFC793 vs RFC1122 may close vs must stay open. Stance; RFC1122 cuses confusion. Behaviour must be clarified. Believe sending TCP can close connection in persist condition. DOS scenario: persist condition, sending TCO continues to hold data indefinitely. COuld lead to buffer/connection exhaustion. This is for 2nd draft. Next steps? Vint Cerf: What part of RFC793 not clear? Could close connection at any time. We are consistent with what you are trying to do. 1122 is unclear. Anantha: implementations say '1122 prohibits this' in their code. Discussed stack handling orphan connections. Eventually aborts connection. As general mechanism, clarifying language, okay to write a 1-page draft to clarify that. There are tons of solutions for DOS mitigation. Wes: lack of agreement on DOS part. Next step: ask WG if this is WG item to clarify 1122. Dave (jabber): 1122 prohibits.... arcane point. (?) Why aren't we revving 1122? Wes: I'll take that as a joke. Joe: because of all deployed code (joke) Wes: mailing list needs to decide whether to take this on. Need people to read the draft first. We aren't going to decide anything to do. Anantha: response to Dave - app can abort it, but app knows nothing about TCP status/resources etc. Lars: TCPM is Minor. Updating 1122 isn't Minor! It might be done, but not in this WG. Anantha: what is procedure for revving 1122? Lars: 1122 is very broad in scope. IETF has grown. Lots of stuff to review for interactions. Is it worth it to correct a single point that could be more clear. Anantha: DOS nature of this issue is important. Wes: there are many other ways to mitigate DOS suggested by list. Scott Bradner: this group is not the right group. Is TSVWG better? Lars: TSVWG is better Lars: the other danger is making sure what we are attempting. Avoid updating all of 1122. Is it worth updating 1122 for such small change? Anantha: Allman had same view, go informational doc. Lars: don't remember that email. Wes: I had understanding that WG had not accepted this, but easier to get just a clarification (informational) accepted by the WG. Lars: if I was chair calling consensus - FAIL - don't adopt it as WG item. Call on WG for proposed std failed. [ Note from AFTER meeting: In offline discussion with Lars and others it was clear there was confusion about which draft was being requested for WG item. Yes, the original persist draft had not been accepted by WG. On suggestion by the chairs (Mark and Ted at that time) a short information draft describing just the sender behavior was written and presented in the meeting. It is that draft which is being requested for adoption by WG ] Anantha: this is about basic plumbing of Internet. There was no clear consensus. People agreed it was an application issue. Reviewed history under previous chair (allman). Wes: we have doc. People need to read it so we can discuss it. Tim Shepard: I have read the draft. two pages of content. Short. Sweet. Non-controversial. in favour of it being WG doc. No objection. There is a problem with 1122, this can be fixed. No opinion on DOS draft. shout from back: not on charter! Lars: saw questions on list about why we need this, can't we do this another way? If updating 1122, need to check TCPM charter. Is it in scope? Wes: this could be an erratum to 1122. Lars: if it gets submitted as an errata, it will come back to the WG for review, so this does not help. Wes: read the draft. report findings to list. Cut and paste body to mailing list so people read it. Dave (jabber) 3 places TCP can be aborted: TCP, kernel, application. Mailing list discussion - TCP shouldn't abort. Kernel can abort if appropriate for resources. Mahesh: assuming TCP and kernel are one. In small footprint, it's one entity. Don't want to wade into that territory of who should terminate connection.