TCPM meeting / IETF 67 / Thursday, Nov. 9, 2006 (Ted's laptop not working with projector) Steve's presentation and security discussion first, because of scheduling contraints. Steve Bellovin - Towards a TCP Security Option motivation / requirements for a new tcp security option existing tcp-md5 has number of serious problems cryptographically "laughable" - should use HMAC or other real MAC not easy to say "this packet keyed with key X", so at times of key change, receiver may get confused no key management people using TCP-MD5 are generally using ascii strings as passwords We [the IETF] know it [TCP-MD5] is weak, we know it was done incorrectly, it would be wrong to advance in order to advance BGP, we needed a process waiver why not use IPsec? turns out not to work particularly well in the real world protection down at IP layer, hard to get key from user layer plays very poorly with NATs. BGP speakers rarely behind NATs, but can't usually use hardware IPsec given way routers are built today one major brand of router notorious for underpowered CPUs TLS doesn't protect TCP header, very easy to destroy TCP connection by injecting just one packet integrated key management perceived to be too heavyweight for some apps requirements for a new TCP security option must protect TCP header proper crypto key management protecting the TCP header in case of encryption, some portions should NOT be protected (due to NAT, proxies, etc) questions about port numbers, window, congestion-related flags key identifier long-lived connection needs to change keys at some point Joe Touch: key word is "efficient" if there are multiple connections between a pair of machines, should they be able to share some state? joe touch: whole thread belongs under "key id or not key id" not under "we need a key id and here are its properties" steve: not saying anything about format, just suggesting properties, without saying anything about how to do it sctp with tls can get some efficiencies automated key management rfc 4107 ikev2 may or may not be a good choice tcp part should be done here, key management done in security area Tim Shepard: why not use ipsec? you explained it, but I'm wondering if the router design issue is the problem, could we use ipsec, but label the packets with a different protocol number Steve: the problem is in the location of hardware assist on the linecard and then to control plane, real concern is CPU DoS attacks against central processor Tim: isn't this problem no matter what solution we adopt, does our solution have to use linecard hw assist? Steve: we've gotten pushback when we said "just use ipsec" ipsec is descendant of sp3 [as in layer 3, network], developed by dod, we should look at sp4 [as in layer 4, transport] Michael Tuexen: will key management be inband? Steve: unspecified, decision for later working group; ipsec would've been done a lot faster if split out from base wg Joe Touch: clean reason not to use IPsec: impossible to force FIN to clear out SA and rekey Steve: I could call the daemon and tell it [the daemon] to destroy it [the SPI] Joe: between FIN and call, another SYN could come in; fundamentally can't tie key to particular session at transport. Steve: ipsec comes from ip layer and doesn't have strong notion of connection Matt Mathis: when bgp1 was being developed, it was refered to as layer inversion, doing layer 3 function over layer4 TCP; critical to address in this document - TCP liveness isn't appropriate for routing liveness; I'm afraid of using other protocols for rekeying if we don't have connectivity when we lose a BGP session Steve: key id could refer to out of band or cached material, think of TLS session resumption Matt: you're talking solutions, question still needs to be well-posed in document Ron Bonica: clear that we need automated keying, but would like to see this decoupled due to differing skillsets required and timeframes Caitlin Bestler: main concern is whether or not this is truly general, I think it isn't general and shouldn't be solved at layer 4 Steve: there's been a fair amount of rumbling since late 90s over problems ipsec was causing for transport and measurement communities; ipsec is protecting too much and has wrong granularity, TLS is also unworkable Yushun Wang: BTNS working group is trying to solve first bullet Ted: Mark and I liked this draft because it directly addresses why tcpm should be working on this would like to have a design team look at this and come forward with a proposal if the wg agrees that this is worth solving Joe Touch: lot of academic/completeness reasons why I think this is needed; this is cleaner than connection-latching; but fundamentally question is "who needs this" and answer is limited to situations where you may be just as good setting up an IPsec tunnel; I can't make a good case that it's absolutely needed Steve: I'll argue both sides too, talking in saag this afternoon about discription of very sophisticated attack that low-value machine in my lab was hit with, we discovered 2 weeks ago that the machine had been compromised since may, it's out there and I'm not the only one whose seen it; connection hijacking and worse is out there, mac address for over 200 other machines was used by this machine, which was demonstrably capable of hijacking tcp sessions; my concern is "is the market going to buy into this?" Ted: not sure market buyin is requirement Ron Bonica: from customers there is demand Caitlin: might slow down deployment of this, TLS, and IPSec with three competing options Joe Touch: this would not necessarily prevent steve's attack, just help limit its scope in propagating Ted: don't get wrapped around axle of attack or about marketing (hum if there is support for doing the work to advance tcp-level security system) solid hum (hum if you oppose) weaker hum (hum if you have no opinion) similar to opposing volume Assuming this isn't immediately contradicted by mailing list, we'll move forward with design team and coordinate with saag Ted / WG status Blind Attack Robustness (tcpsecure) - new revision out soon, approaching last call ECN SYN stuff - Mark raised questions, Sally will address via simulation SYN Cookies - need to roll in freebsd work, and new version out soon 2581bis - Mark working on implementation reports, powwowed with IESG as to format, should be moving forward quickly Antispoof - should be moving towards 2nd last call, limited to updated sections Lars: TCP-RLCI (presented at last ietf) should be looked at by group for consideration for publication Ted: Mark and I getting brand new cattle-prods for christmas, so we should be better at moving these items through more quickly TCP User Timeout Option (UTO) draft-ietf-tcpm-tcp-uto-04.txt - Fernando Gont Lars Eggert (as author): some confusion as to whether UTO should go experimental or PS, charter had it as PS and got consensus, I don't care as either author or AD as AD, would like to go to experimental Tim Shepard: same here, other than experimental should go to list Received feedback from Gorry Fairhurst, which is where most changes since last presentation came from overview Peers advertise their timeout and adapt local value accordingly Main changes introduced in -03 Rearranged introduction Removed discussion of 2 socket options that were not really relevent Clarified that UTO is disabled by default and has system-wide toggle Enforce minimum of one RTO Main changes introduced in -04 Feedback from Caitlin and Jamshid UTO should be sent in first segment after SYN, information could be lost if using syn cookies Made it clear that if option not included in initial SYN, systems that break are already violating TCP requirement of ignoring unknown options Changes to be introduced in -05 Editorial tweaks from Mark Allman Moving forward We think ready for WGLC Gorry Fairhurst: what was mark's comment on 60 seconds Fernando: RTO could be capped at 60 seconds, might not be doubled forever Gorry: do we agree that you don't have to send options in syn exchange Ted: scope that, not violation of an rfc to my knowledge, does it cause problem - yeah Matt Mathis: lot of language in 1323 about not surprising tcps with new options mid-stream, but that was written when the Internet was a much friendlier place Fernando: 1122 says MUST ignore unknown Matt: a lot of companies have trouble with "if the other end does something stupid, don't make it worse" Ted: you're advocating this in order to get rid of bad stacks? laughter Lars: it might be interesting to use this as a test case to see if fragile stacks are still out there Ted: technical issue is that this is not negotiation, it's advisory. Caitlin: key point is that receiving side may not remember whether you've sent it on syn, and don't want to obligate them to reject if they can't remember David borman: back in days of 1122, big issue was that there were implementations that could successfully handle unknown options during syn exchange but no later, but that was 10-15 years ago, we should lose that old baggage and move on; UTO is good example for adding in middle of connection, because it's not negotiated; I think this document has been through enough hammering for simple concept that it introduces Joe Touch: worth clarifying why you're allowing it to be set in mid-stream, and explaining why it doesn't matter, where for other options it does matter (anything that has to be synchronized with data stream) Ted asks Joe to make sure this is addressed Lars: might want to consider a BCP for what to do with TCP options David: document currently says it should be in syns and in first data packet - implies you don't HAVE to have it in both syns and later Gorry: trying to be clear that I wasn't objecting to way it's done, just want it to be clear Matt: people may argue that implementations that do it later are wrong Ted: think that's an inaccurate reading of SHOULD, do you have alternate wording? Joe: should do it this way, but must allow for it to be done other way Matt/Joe: problem is that definition of should is not precise, and doesn't say anything about backward compatibility Anantha Ramiah: not aware of any TCP that doesn't just ignore option David: only clarification is to say MUST accept UTO option even if not sent in initial SYN Caitlin: except in sense of not resetting, it's still free to ignore it David: absense of UTO in SYNs should not preclude later accepting Ted: we all agree with statement, path is to last call document, someone will suggest text (hum if you think ready of WGLC) strong (hum if you don't) none next week will go to WGLC ICMP attacks against TCP - draft-ietf-tcpm-icmp-attacks - Fernando Gont Overview Describes a few ways icmp can be used to break tcp connections 3 attacks spoofing various icmp messages Well-known issues, but no documented countermeasures Most implementations have some countermeasures, for 10 years at least Joe Touch: we had email exchanges on this; wg agreed to "describe" solutions, not "propose" them Counter-measures (1) Check tcp sequence number included in icmp message - not complete solution Change reaction for hard errors to that of soft errors - within current specifications/recommendations counter-measures (2) Ignore source-quench - violates 1122, but generally accepted Bob Braden clarified in Vancouver that if anyone got Source-Quench to work, then we should still be responding to them Matt Mathis: 1122 is just wrong, understanding has changed since that time Matt's comment is on honoring the fragmentation needed [ICMP message] if there is no progress on connection (wait for RTO) Document Path Adopted for informational, question about whether parts should be standards track ICMP provides easier attack than blind rst attack, whose defense is standards track Moving Forward Need to decide on which way to go info or standard, and whether describing or specifying solutions Proposal (1) Split current document into 2, one std track, one bcp/std track with PMTUD-specific parts (in tsvwg since for all transport protocols) this is probably right thing[says the slide], but sctp, dccp, etc have to agree proposal (2) General informational document in tsvwg, and std track in tcpm proposal (3) Stay as is (on informational) Fernando: personally like option 1 or 2, but not 3 Ted: document covers a lot of ground, some people might have different opinions on parts, and then issue of whether we have something to say about transports in general, 2 axes here (hat off) should be sliced up Matt Mathis: curious if you counted number of rfcs that mention icmp (nearly 500), talking about a lot of work, not a small project Ted: restricting to tcp is much smaller Matt: consensus that something should be done, old fraternity joke that "we ought to" means other person, somehow need to start down this path, answer to tcp part may change a bit, state direction and all people using icmp need to consider implications for their own protocol Ted: do you want to articulate vision for icmp here or in tsv? Matt: belongs in TSV Ted: putting consistency check into tcp is small and we can do Matt: small document should begin us thinking about bigger problem, people have inconsistent notions about how icmp should behave Joe Touch: strongly in favor of splitting up into component parts, vetting is simpler, source quench first Ted: would have more boiler plate than text Joe: take it to ISOC, would love to apply header compression there; with regard to individual solutions, unlike rst doc, signals from icmp are not bound to come back within any window, no rule about issuing or receiving icmps within some window, don't want tcp in odd environments to break, maybe more than 4 documents, some may be informational "here's what people do", then we can talk about what to standardize fernando: ICMP is out-of-band signaling, why in case of RSTs are they required to be in window, but not ICMPs Joe: ICMP is not comming from other end of connection. Joe: want to bundle based on semantics Ted: he wants to argue about the issues separately so long argument about some issues don't slow down source quench (really the whole doc.) David Borman: good idea, comment on ICMP - you shouldn't be getting random messages, only in response to sent packets, trying to verify that received ICMPs are in response to something you actually sent Ted: right, it's a really good idea David: if you accept that, how do you do that, and is sequence check good/sufficient, what if router slow path causes delay and it shows up later, but in general idea is sound and good, but we get into is this the right thing and is it always accurate; could also have general purpose document with TCP stuff, and separate with SCTP Ted: Randall tells me SCTP ignores ICMP Randall/Michael: except for PMTU, and Proto Unreachable David: TCP spec doesn't talk about ICMP, but 1122 does Ted: proposal - go to TSVWG with lance in hand say "here is unified view of icmp that all transports should adopt" David: come up with "this is what we're going to do for tcp", and structure into generic and tcp-specific parts within same document Ted: still need to break mitigations into separate documents David: can still be split up, within each mitigation include a general part Ted: should that go on here or in TSV? David: split-it up and continue here, becomes prototype that other things can reference and use Matt: like using TCP document as example for other protocols Matt: RTT through control path of router may be longer than end-to-end RTT, result is valid out-of-window ICMP Fernando: if error really is hard-error than later packets will generate more that will be valid Matt: one thing missing from document is with PLPMTUD, would like to capture message from probe and you get only one, which you can be way past in window; I used to do measurement using ICMP, but implementations are written for clarity, not performance or robustness Anantha: thinking on ICMP processing, this draft makes it more robust, why are we even discussing things that may be implementation specific and vary from system to system Ted: one of issues is that in earlier versions it was put forth as security mechanism (hard guarantee and not hint - concerned with false negatives), discussion that has to be had Gorry: as DCCP chair, general document is useful, whole bunch of little ones on tcp, whole bunch on dccp, sctp, etc; if we're talking about source quench, we can all agree quickly Ted: I hear what you're saying, this group's ability to more forward isn't happening due to it all being tied together Gorry: I like slicing, just make slices address max number of wgs Bob Braden: proceedural problem, issue for tsv at least, who should lay down general principles and direct particular wgs to fill in details, apparent problem is addressing at lower level rather than higher; whatever TSV decides to do with it Ted: put this on hold [in tcpm]? Bob: present it to TSV and let them decide what to do Ted: not move forward here? Bob: right Lars: comment on jabber from John Heffner: trying to shoehorn ["]real["]security into ICMP handling is difficult (long comment, see jabber log) Joe Touch: backs up Bob Braden, suggest TSVWG continue with it split up, and which ones to do in tcpm or there Bob: in response to Heffner, whenever I hear anyone talk about real security I worry, problems come from people who use icmp (transport layer), making recommendations on wringing as much security as possible out at transport may be helpful Ted: Took away [from Heffner's comment]: standards docs are not good at talking about corner cases and tradeoffs Joe: could impact something legitimate, if misinterpreted as attack; if in fact doing validation check, that's one thing, if security issue, take to SAAG and ask if it provides any security, proceed after [if] laughing stops Lars: John had "real" in quotes laughter Fernando: keep in mind that ICMP is unreliable after all, many many reasons they could be wrong Dave Borman: if all ICMPs get lost, TCP should still work, they provide good information that allow things to progress faster, losing potentially good information, greyscale as to how much we're willing to give up benefits for risks Lars: with hat on, going to TSVWG would be totally appropriate Fernando: I have something I could submit, not finished, but close Lars: we'd look at agenda request favorably Ted: non-binding hum, try to measure room 1) stay with what we have 2) work from tsvwg, stop here until that happens 3) split here and work here with generalization sections Joe: 4th, take it to tsv with big question, or start there with split doc, not mutually exclusive Dave: do we split or not is separate from does it go to tsvwg agreed by room (hum for do we take to tsvwg) medium hum (hum to continue here bottom up) weak (don't care) NONE (in favor of splitting) medium (presenting unified as stands) NONE Advancing F-RTO to the standards track - Max Hata FRTO status Experimental RFC 4138, august 2005 Several known independent implementations Several experimentations Outcome: sucessful and straightforward, performance excellent, no adverse issue reported Will prepare some summary of good things, analysis of conrner cases, and make sure it will not be harmful Recommendation for drafting new RFC Focus only on algorithm and tcp Leave pieces for sack and sctp as experimental Plan on submitting by march 2007 Ted: main reason for this presentation is for people using or who would like to help to come to him or Pasi, bunch of good solid data, would like to happen quickly.