TCPM minutes ============ From notes by Pasi Sarolahti Thursday, July 13 at 1300 - 1500 [11:30 on ietf66-ch6-thur-noon.mp3 in the audio archive] WG status update -- chairs (Mark Allman, Ted Faber) ---------------- Agenda bashing.. Listing WG items.. TCP-secure almost done Antispoof almost done rfc2581bis syn flooding Cross-WG items.. Non-WG individual drafts.. In RFC editors' queue: * TCP Roadmap very close to be RFC * NCR -- mitigating the effect of reordering past the IESG WG Status * UTO: tcp-uto-02 -- new revision in progress * Soft errors, ICMP attacks -- awaiting new version from authors to address comments * ECN-SYN: awaiting simulation results to shed light at the issues discussed last time * SYN flooding: accepted as WG item * Anti-spoof: several issues raised during WGLC. WGLC considered "mostly passed". Will have a two week review of changes when next revision appears. That 2-week review will be a WGLC, with the primary focus being on how well the author has addressed concerns raised in the last WGLC. * Blind Attack Robustness (tcpsecure) -- soon ready for WGLC * Revising RFC 2581 -- new version submitted. There is one outstanding item, after that is resolved, ready for WGLC? F-RTO * some proposals for getting this to standards track * not clear if there is energy to do that now * should collect more experience with this * soliciting feedback from people to Pasi Sarolahti * Pasi: Would prefer to have the comments on the mailing list as well. [18:30 on ietf66-ch6-thur-noon.mp3] Updates to TCP secure -- Randall Stewart --------------------- * Lots of comments from Joe Touch * Going through Joe's comments, sent in an off-list email. Summarized on slides. * Updates to tcpsecure * Run spellcheck * Added text to security section * Purged the interoperability section * Language fixes * ACK throttling fixes * Should have done more about the language? * Ted: RFC editor can worry about grammar * Hoping to get this to WGLC Comments: * Joe Touch: Gave comments privately. Last revision was not a big revision. Hoping that there is another version coming addressing rest of the comments * version-05 is the last version. Between -04 and -05 the doc didn't change much. * Joe: revision did not address much of the feedback. Disappointed with that. Hope version-06 addresses the comments. Some comments might be open to debate. Should make the overall structure better. If the rest of the group says it is comprehensible, then it is, but Joe thinks it isn't * How many read the draft? Quite a few, not bad. * Chairs: should distribute the comments & changes to the list to check what the rest of the group thinks of them * Randall Stewart: I didn't understand all of Joe's comments. * Ted: This is a WG document -- if you see a problem, send text. Get it on the list to get broader set of opinions [28:30 on ietf66-ch6-thur-noon.mp3] TCP SYN Flooding Attacks -- Wesley Eddy ------------------------ * Lots of off-list feedback, trying to encourage people to send feedback to the list Slides: * Background * Attack well-known * This was felt important during TCP Roadmap work * Status * This was accepted as WG item * There will be WG draft, not yet out. Currently individual submission. * Some comments pending to be addressed in the draft * Goals: * Clear technical description, overview of mitigations * WG input * From implementors: both commercial and open-source * Would like to hear more * Are there real-world success stories? Comments: * Mark: When is the next version out? * Wes: Next week is possible, but it wouldn't have all the comments addressed. * Ted: Encourage folks to make comments this list * Lars Eggert: Should have milestones for this. There are no milestones. * Mark: Have been thinking of having this done in 6 months -- that would mean WGLC is in January * Pekka Savola: all the current milestones on charter are in past, update all the rest of them as well [36:10 on ietf66-ch6-thur-noon.mp3] Revising RFC 2581 -- Mark Allman ----------------- Slides: * Motivation * Advance TCP congestion control along the standards track * Touchstones * Very modest changes * Fix bugs * Rolling in few small RFCs on standards track, like Increased initial window, limited transmit * Issues: * How to set ssthresh after backed off timeouts? * RFC 2581 scheme: set ssthresh to FlightSize/2 on each timeout * Problem: After second RTO on same segment FlightSize is 1 segment and ssthresh becomes one segment * Suggestion #0: don't do anything, this is out of scope * Suggestion #1: set ssthresh to half FlightSize on first RTO, then ssthresh/2 on each subsequent rto * Suggestion #2: set ssthresh to half FlightSize on first RTO, then don't adjust it again * Our hit: #1 was our intent * Proposing to pick #2: it helps in some cases, and doesn't hurt much. cwnd still collapses, and on heavy congestion ssthresh would collapse anyway. * What to do with this issue? Comments: * Matt Mathis: Question -- under what circumstances you get RTO twice for same packet, and get other ACKs? * Mark: don't know any. * Matt: Doubtful about use of the FlightSize. Don't know if real stacks use FlightSize at all. It's easy to find examples where you get pathological behavior on using FlightSize. * Randall Stewart: How does ssthresh collapse down? * Mark: if network is heavily congested you get another loss, and ssthresh will come down more. * Gorry Fairhurst: Second RTO could be a loss, and probably it is. How long do we carry out without cutting the ssthresh, if there would be third RTO, fourth RTO, ... * Mark: Proposal is indefinitely. Want to get feedback if that's a bad idea. * Gorry: it's not that different what you do in the beginning of the connection. So I think it is ok. * Ted: Is there some implementation that does this? * Mark: Not that I'm aware of. * Mark: If you have ssthresh 1, you will increase cwnd linearly after RTO. I think this came up with some wireless case. On suggested approach you get a little bit of exponential behavior * Gorry: if you flap ssthresh down, it takes a long time time to restore window back up on a long RTT link. * Mark: Let's take this issue to the list. * Mark: Not hearing anyone say this is a bad idea. Let me know if it this is a bad idea or dangerous? * Ted: No need to hum on the issues. [49:05 on ietf66-ch6-thur-noon.mp3] Antispoof -- Joe Touch --------- * Current status, no slides: Few proposals of alternate approaches to change the document, no substantial changes proposed. Trying to update the document and incorporate the feedback received. Trying to come up with a version that is satisfiable to everyone. * NB 2-week WGLC planned for after the meeting, primarily addressing comments from the last WGLC. - Faber * No comments [51:15 on ietf66-ch6-thur-noon.mp3] BEHAVE: NAT Requirements for TCP -- Philip Matthews ------------------------ * Presenter is not one of the authors Slides: * Scope * Minimize nat-hindrances to TCP. * Don't make any changes to TCP. * Don't redesign NATs * SYN Handling * Goal: Allow unexpected inbound SYNs whenever possible, allow diagnostics otherwise * Most current NATs just silently drop such SYNs, some send RST packet * Should allow TCP simultaneous open, 3WHS to internal host with existing mapping for P2P applications. Silently dropping SYNs would allow that. * Sending RST packet back is not good. First behave proposed to silently drop SYN, but Joe Touch commented it is bad for diagnostics * Decided to signal failure using ICMP error, first waiting for 6 seconds, if there are any more SYNs to arrive for that flow. This give p2p apps a change to make simultaneous open work * Fred Baker: Would this be configurable option? There is an attack here. If you reply with anything it admits your presence. Would like to have it to be possible to turn this off. * Joe: This is important, since NAT that acts like a host pseudo-terminates connection. Do what what regular router or host would do. If you want to be invisible, turn off ICMP. * Saikat (via Jabber): Requirement is SHOULD, so NAT is allowed to hide the ICMP to defend against such attack * Matt Mathis: What ICMP error is sent? * Philip: Port unreachable. Would like to send back soft error, would make things easier, because wouldn't have to wait 6 seconds at NAT. * Matt: It is not allowed to send unspecified ICMP code as hard error. * Philip: Could use a new type. * Joe: ICMP should be soft error for SYN that establishes connection, hard error if it is from some nonexistent connection. NAT should be a proxy for the host. Port unreachable is just the right error. There already is an ambiguity for host behavior in RFC 1122. If you want to do otherwise, you'll need to change RFC1122. * Joe: There is nothing in TCP that knows you are doing simultaneous open. Port unreachable is just the right error. * Ted: You are already changing RFC 1122, with the ICMP delay. * Joe: There are no requirements on timing to respond with ICMP, so this is loopholing RFC 1122. Trying to find a way to you could make NATs work, by doing what a regular host does. * Philip: If this was a soft error, you would not need the delay on sending ICMP. * Lars: Asking TCPM to review this. Are there significant problems for TCP if this goes published? Seems that it looks reasonably ok for the TCPM wg. * Ted: Question on Jabber, if 6 seconds is a security problem * Philip: If you cannot wait 6 seconds, alternative is to silently drop. * Joe: that is defined in RFC 1122 * Conclusion was that this is the best possible option. No humming, but there seemed to be agreement in the room. * Goal 2: NATs to guarantee at least a large idle timeout * Guarantee idle TCP for 2 hours, 4 minutes * Handling of TIME-WAIT state is left unspecified * no comments * Initially 3-second delay was proposed for waiting TCP SYN, Philip originally wanted longer delay, due to p2p applications * TCP overlaps * ICMP errors during connection initiation * Peer to peer apps don't want soft errors treated as hard errors, as suggested in some documents * Ted: I can point you to the draft that talks about this. Would like to get feedback on this draft * NAT may send ICMP port-unreachable * non-p2p application can abort on receiving ICMP * p2p application may want to persist in hopes of TCP simultaneous connect and ignore soft error * Something to consider in Gont's ICMP draft * Matt: there are different situation where exactly the opposite behavior is preferred: multi-homed machines, where only some of the interfaces are reachable, and want to get the error as soon as possible. * Ted: that said in soft-error draft. During connection setup soft errors should be treated as hard errors. * Matt: It would be useful, if application would have the choice on soft error semantics. [1:15:40 on ietf66-ch6-thur-noon.mp3] RDDP: TCP framing -- David Black ----------------- Slides: * RDDP Partial overview * Remote direct data placement * Aligned zero-copy placement at receiver * MPA draft defines framing for TCP * Earlier comment from Joe Touch: RDDP is not supposed to change the TCP protocol. There is language that looks like it is changing TCP Diagram of the big picture on TCP, MPA. Also optimized TCP/MPA discussed. Proposal: * Specify MPA as strictly layered on TCP * Explain zero-copy optimizations in Appendix No comments/questions [1:22:10 on ietf66-ch6-thur-noon.mp3] Combined fixes for TCP over dynamic paths -- Wesley Eddy ----------------------------------------- Slides: * Combined from two paths * Combination of LMDR and retransmit-now * LMDR: short term connectivity disruptions * retransmit-now: long term disruptions * Basic idea: generic connectivity change indications: Mobile IP, HIP, SHIM6 * Avoid long RTO idle time * Reprobe path state * Notify peer to do the same * Requires new TCP option * Designed to do the right thing * Friendlier to network * Performance optimization * Next steps * Read draft and post comments to tcpm * Going to simulations -- will post results to tcpm * Should be candidate for Experimental RFC Comments: * Mark: Are you putting it up as candidate for WG item? * Wes: Yes * Matt: Have you thought about generalizing this to other protocols (SCTP + DCCP)? One solution for the whole problem. * Wes: Should think about it. * Mark: How this relates to the TERNLI proposal? Do we know enough about this to be ready to pursue it as a WG item? * Wes: Short-term part is running on Nokia implementations, also retransmit-now has implementations. * Lars (as co-author): Would like to enter "read the draft and post comments" stage. Haven't got any comments on the combined draft. Talk about the future later when also Magnus is in the room. [1:30:40 on ietf66-ch6-thur-noon.mp3] Portnames -- Joe Touch --------- Slides: * Goals * Increase limited registered ID space * Increase ID space for single service * Decouple de-mux ID from service ID * Resists off-path attacks * Constraints * Minimal modification to TCP * Compatible with existing use * End point control maintained * Alternatives Considered * Ask a third party * Ask out-of-band (portmapper/TCPMUX approach) * Dynamic renegotiation * Tim Shepard's Internet-Draft * Explaining the mechanism, some diagrams on the slides * Benefits * Decouples destination port from service ID * Randomizes dport * Works with nats * IANA mechanism discussed on the slides * Download IANA databased periodically, local lookup * DNS SRV mechanism discussed on the slides * Have to register services to DNS machine * Lars: additional issue: there is no dependency on DNS currently, you could use IP address, this would add dependency. * Portmapper discussed * Like DNS SRV at endhost * Additional delay * TCPMUX * Changes semantics of TCP open * Additional delay * Port reassign mechanism proposed by Tim Shepard * Inverse of portname * SYN dport == service / option == de-mux * Change port during connection, does not work with NAT * Randomizes dport * Works with firewalls * Decouples demux/service id * Does not extend port space * Proposal * Portnames as a working group document * Which track? Unclear what experiment this would show? See no reason not to go through standards track? Comments: * Matt: Have much have you thought of deployment issues? * Joe: Can be incrementally deployed, backward compatible * Matt: What would cause me to put this in the TCP stack, if I was a large software vendor? * Joe: If you need port space to be extended, this is the right way to do it. * Matt: Obvious use of this would be to first try use the IANA port with this option. If this succeeds, you can use other ports for subsequent connections * William Leibzon: Going to require quite a bit of changes to system and APIs. Many applications need to be modified. * Joe: Apps that know this scheme could bind to any port, use socket option to indicate port name. Then you could add shim layer that maps binding to port 80 to really bind any port, and use socket option to say this is http service * William: You make assumption that binding to port 80 means binding http, there is no such assumption in current systems, they want to use any port available. * Joe: Right. Therefore prefer the use of portnames option if possible * William: Large number of applications that use port 80, but don't use HTTP. Don't want to name the service use, but just use a number to identify port. * Joe: If application uses HTTP on different port than 80, also the other end needs to know this. Picking a string requires some coordination, but so does picking a number. Yes, it is going to involve re-coding. * William: Going to take a lot of work in future. Not sure this is the right solution considering the legacy apps. * Joe: Any solution requires changes to legacy apps. * Gorry Fairhurst: DCCP uses service codes. How does this compare with that? * Joe: Very similar. But service codes aren't identified either. No intention to do this for DCCP. But thinks this is much simpler. * Lars: 16-bit port numbers are an old thing used by transport protocols so far. How does this affect to transports overall? * Joe: still using the 16-bit port number as de-mux. Just changing where service is indicated. * Mark (no hat): See two things. 1) Split of demuxing/ids is one thing, notion of that is ok. 2) Use port space better -- should think about the header field issues in a broader sense. Maybe this is the right thing, but not ready to agree yet. * Joe: This can be backward compatible, which is a benefit. So it might be interesting to existing TCP. * Mark: Counterpoint -- if we use this reasoning, we might end up with number of small hacks, might become something what we don't want * Joe: Even with TCPx2 might want to consider this. IPv6 did not make IPv4 go away. * Randall Stewart: I like this solution, would like to see this expanded. Used PPID in signaling earlier with SCTP to separate demux and service ID. Would like to see this expanded this to DCCP and SCTP. One solution for all protocols, one change in socket interface * Joe: Agree * Ted: Already done in DCCP as service ID. * Matt: You learn something by building implementation. Therefore I think experimental is right approach. * Matt: Could consider some of the other protocols being deployed, like placing this to HIP. * Joe: Don't want to put this to something that is not widely accepted and deployed yet. * Matt: Yep, there is a chicken and egg problem * Joe: HIP is network layer issue. portnames is pure transport layer issue * Joe: Agree about implementation. Would not put this forward without having an implementation on this * Matt: Some want to see RFC before implementing things. Therefore would like to see this experimental * Ted: Let's discuss on the list. No hums at this time. End of meeting.