TCPM meeting I, IETF-89, London, England, Monday, March 3, 09:00 - 11:30 --------------------------------------------------------------------------- (minutes from Thursday session can be found below after the Monday minutes) Chairs: Michael Scharf Yoshifumi Nishida Pasi Sarolahti Note takers: Gorry Fairhurst Richard Scheffenegger * Alexander Zimmermann Making TCP more Robust to Packet Reordering draft-zimmermann-tcpm-reordering-detection draft-zimmermann-tcpm-reordering-reaction Michael Scharf: Is re-ordering a more common effect in the present Internet? Brandon Williams: We have done fairly extensive testing in the Akamai network looking for reordering and jitter and had trouble detecting conditions under which reordering is a significant problem. Matt Mathis: There is a long history fighting reordering; answer: make protocols more adaptive to reordering, will become an issue Jana Iyengar: I think it is important that we look at this. Have you looked at latency measures of how CR performs? Does latency increase for short transfers? Alex: Not really - we looked at long flows, so that we could find reordering events and react. We need 2-3 events to do the adaptation. Short flows would need more work. Jana: I would like to see numbers. Andrew MacGregor: Yuchung's work was based on reordering in data centre networks. We also saw lots of reordering in some African studies. Andrew MacGregor: MAC layers in wireless do work had to avoid this. Consider reordering of transactions over the same connection. Alex: The original work was targeting non-congestion events. Gorry: Some people in the IETF go around to other WGs and warn how bad reordering can be for TCP. We need to fix this, but even if this requirement is going to take a while to go away immediately, we do need to start working on this. Anna Brunstrom: Loss mixed with reordering is also important. ------------- * Lars Eggert, PRR and NewCWV for FreeBSD (no draft) Michael Scharf: Is the patch likely to go into BSD? Lars: The PRR part is ready. Depends on FreeBSD committers. Jana: Some form of pacing is likely to be useful. Raffaello Secchi: We will show some results with pacing. Jana: The result is because of the burst or because of the increase in cwnd? Gorry: I think it's the delta increase in cwnd, the result may be the same if the "burst" was paced. Lars: Yes, I think so. ------------------ * Andrea Bittau, tcpcrypt: the case for ubiquitous transport-level encryption (Mini-BoF) draft-bittau-tcp-crypt-04 Michael Scharf: What prevents forward secrecy in TLS. Eric Rescorla: TLS does have forward secrecy modes. Michael Scharf: Interface to the App is the socket API. Why can you not use this? Andrea Bittau: You need certificates. You could use self-signed certificates, we can use TCP 3WHS to ask if the remote can do this. Michael Scharf: There are other ways to do negotiation, e.g. pre-existing drafts. Andrea Bittau: This avoids sending multiple packets or a need for a Start-TLS sequence. Ekr: There are two things that may be orthogonal: (1) Comsec negotiations - I see a strong argument. (2) There is a new com sec layer that is negotiated. There could even be a use of the negotiation to allow TLS to be used. Michael Tuexen: The socket API is the boundary to kernel land. Tim Shepherd: It does not have to be in the kernel. Michael Tuexen: The negotiation part is hard to place in the kernel. Ekr: Unauthenticated keying is used, Michael has an argument that you have no way of knowing who you are talking to this, allows to later transition to encrypted operation. Michael Scharf: What about TCP-AO? It could be made to look like this. Andrea Bittau: It doesn't exist, but it could go that way. Tim Shepherd: How can you distinguish a downgrade attack, from the other end not supporting tcp-crypt? Andrea Bittau: We expect this to be widely deployed. Bob: Actually, this argument requires universal support. Ekr: In the TLS WG we found two cases: attackers that were "real" and middle boxes that were trying to be helpful. However, distinguishing these two is near impossible. Matt Mathis: This can be used for detect failure. I think that security failure detection is really valuable. David Mazieres: Yes, from the ISP perspective you can't monitor (via a middlebox) without being found. Ekr: Anything we exchange (DANE) uses a single public certificate to sign the ID. David Mazieres: We need to link the parts, code needs to be written. M Suriar: How do you deal with multiplexing? Andrea Bittau: We assume all the sub flows are from the same users. Brandon Williams: Are you against using this as a way to provide privacy/integrity for apps/users who decide not to do security? Andrea Bittau: This gives protection from eavesdropping and man-in-the-middle attacks, but not authentication. Mark Handley: This provides a generic building block that splits out authentication. Bob Briscoe: Is it compatible with TFO and MP-TCP? Is this worked out or aspiration? Andrea Bittau: We're talking to MP-TCP, we have only just started this thinking with TFO. Michael Scharf: Do you think if the protocol evolves, will you need data in the payload? e.g. rekey? Andrea Bittau: Rekey does not need this. You can use multiple options? Michael Scharf: Multiple options can get messy. If there are multiple times this is not a TCP start negotiation. TCP-AO copes with extremely long connections. ?? : This is a lightweight proposal with a small amount of options space that seems to not need lots of work. Tim Shepherd: Some security boxes will "choke" when they have to parse the data and find this, will result in some unwanted issues. The backwards compatibility is with NAT, but not all boxes. Ekr: Are there TCP inspection boxes that cause problems? Bob Briscoe: False start already saw this problem. Bill Canon: The most common intermediary is a deep-inspection client-side interceptor, such as a virus scanner. I'm interested in information about windows machines. Do you need admin-level permissions to do this on windows? Mark Handley: In future the virus scanner could be granted access to either encrypted or clear versions of the data - both are in the stack. Andrea Bittau: We have code available for download to find out more about deployment. Bill Canon: From a Chrome perspective we would be really worried about support for old OS (such as XP) that will not be updated. Andrea Bittau: We need to think about the possibility in user space. Matt Mathis: Why is this needed? Most unencrypted traffic may exist due to a lack of deployment, not because of lack of protocols - this is largely because content providers do not offer certificates - clients already do this. Tim Shepherd: +1 Matt Mathis: Solutions exist. It's a content provider problem. Ekr: HTTP is discussing ways to do this with TLS. There was opposition to automated updates that need this at a recent workshop. Patrick McManus: The idea that servers are not upgrading is not the issue. Some people can't deploy HTTPS. I worry about duplicating the work of TLS. TLS is improving. Will Chang: There were previous studies with websockets over TCP port 80. For Chrome (primarily windows) saw about 70%, a separate port 86%, TLS had 95%. David M: We need more data, the worst case is bad. Will Chang: Stripping out an option is one pathology. Hanging a browser is a different, more important, problem. Mark Handley: The MP-TCP WG saw that most "odd" paths seemed to remove the TCP Option - the ones that pass the option and then continue and more the issue. (We don't have data for this). Jana: This seems to secure something that apps do not choose to do. The failure mode needs to be understood. This has a different deployment case. Andrea Bittau: This is a different use-case. We could get an RST back. Ekr: What will people do if the deployment goes bad? In this case, most people tend to just not do the deployment. Mark Handley: Starting with traffic on port 80 may be bad - other apps may find more benefit. Michael Scharf: How do you know if a session will (later) decide to use TLS? How do you avoid double encryption? Andrea Bittau: You need to have a way to know, maybe update the API to tell the stack? Will Chang: How much data do you try to MAC? Andrea Bittau: Each segment has an individual MAC. Will Chang: It sounds ideal for latency, how does this impact high-bandwidth throughput? Andrea Bittau: It looks OK based on old data, but there is no updated data for modern case. Michael Scharf: Saving option space can also be an issue. Andrea Bittau: We use 11 bytes. Michael Scharf: We talked a lot about whether to use options with MP-TCP, but the considerations may be different here. This for instance is data-touching with MAC. Costin: In cellular networks http is often intercepted. Current crypto support in mobile devices is not so common. Mark Handley: What matters is whether you care about protecting the TCP header. Michael Scharf: TCP-AO has been specified, and needed for a specific use-case. We have not seen wide usage beyond this. Andrew McGregor: TSO is incompatible with pacing - use is not always helpful. TSO has many issues, and google is looking for dynamic ways that use TSO. I expect less usage with time. Ekr: The cost of TLS and this method are not hugely different. Ekr: The previous discussion of RST protection was focussed on BGP. This was the one case why TCP-AO needed this to protect from off-path attacks against routers. I think this use-case is not important for the tcpcypt. Michael Scharf: What about data in SYN? Andrea Bittau: We can update our draft to look at this or even use it. Brandon Williams: I think the world of transparent intercepting proxies is an important use case - and it is important that a transport-layer proxy does not give the impression that the session is encrypted. Andrea Bittau: Middleboxes could be updated to work with this. Brandon Williams: It is important to think whether the encryption should be tied to the transport layer, or whether this is the correct place to deploy. Andrea Bittau: Our goal is to provide benefit to 90% of the remaining cases where encryption is not used. Tim Shepherd: What is the killer app that needs this? Andrea Bittau: HTTP seems like the killer application for content that does not deploy encrypted content. Michael Scharf (as WG Chair): We need to deciding on next steps: (1) Is there interest in working in this space? (2) Is this draft the basis for this discussion? Lars: We have several things already proposed in the world of TCP and encryption. There seem like a set of things that could be integrated. Bob: Is TLS a better building block for this - i.e. as a way to build an un-authenticated encryption method? Ekr: I hope so. I think one protocol is best, at the moment this looks possible. Ekr: Does this work? Was will correct on deployment possibility? Jon Peterson: We came from a recent workshop that suggests that other protocols can benefit from opportunistic encryption. Jana: Understanding failure modes is hard. We need to find ways to extend this. I think this is a good starting point. Matt Mathis: I wonder why people do not use encryption? I'm intrigued to know if this is just a deployment attack? Will Chang: My personal opinion this is the wrong mechanism for encrypting the web. I'm not sure opportunistic encryption is the correct way, and deployability will be hard for web. happy eyeballs approaches don't work for security - since it can be forced to down grade - down grade attacks may happen often. For web, caching is often wanted and this doesn't seem like a way that offers real value. Don't discourage real HTTPS security. Costin Raiciu: I think we want more of this. Combining this with MP-TCP may work with this offer more security. Lars: We do not know where unauthenticated TLS offer a good fit, and where this may be best. I think this is useful start. Martin Stiemerling (AD): I see interest. However, this does not fit the charter of TCPM or the charter of MPTCP. Is there harm in working on approaches that do this sort of TCP encryption (not necessarily this draft)? - No responses. The AD will consider the best way to proceed. End of meeting at 11:34. TCPM meeting I, IETF-89, London, England, Thursday, March 6, 13:00 - 15:00 ========================================================================== Note takers: Brian Trammell Alex Zimmermann * TCP Roadmap / Alex Zimmermann draft-ietf-tcpm-tcp-rfc4614bis Will announce WGLC after meeting (no feedback at the mic otherwise) --------------------- * Updating TCP to support Rate-Limited Traffic / Raffaello Secchi draft-ietf-tcpm-newcwv-05 [kernel code slide] Michael Scharf: Is there a chance this will be integrated and enabled (in Linux)? Raffaelo: We hope so Gorry Fairhurst: We're speaking with [some people] to help with that. We have clean code and would like to get it into Linux as well as BSD. [eval slides] Alexander: This is Reno on Linux? Do you know if Linux already has something like newcwv? Raffaelo: Yes Linux Newreno. No , only "maxburst". Michael points out that this draft obsoletes RFC 2861 (old CWV) Gorry: Raised in the slides that we want to obsolete oldcwv Michael: We have to understand whether there is consensus to make oldcwv historic. Silence means consensus [Silence] Michael: Okay, no feedback Michael: Operational experience is highly desirable for a proposed standard. It's not clear that this work has operational experience. We would like feedback on the working group. Mirja: Should be experimental. Would like it in the mainline before PS. Moving to PS later not big effort. [clapping] Karen Nielsen: not sure whether the document is viable as proposed standard w/o a pacing algorithm standardized Gorry: we don't have a place where pacing is defined. not sure this is the right place to do that. don't know how the ietf will do it. if that's a stumbling block we need to talk about it Michael: Important but we haven't figured it out. Mirja: We should do pacing. Anything except completely unpaced is fine Michael: Does anyone disagree that it should be experimental? Gorry: Previous experiment is done. In another group we'd have gone through the experiment, devised new alg, specified it. Bar here is different. Putting forward case for PS now. We could also freeze the draft. Matt Mathis: Experimental. Andrew Mcgregor: Agree. In terms of pacing, we know some things will be a problem, need to find some language about them, e.g. don't use a system-synchronized jiffy timer. Precise timing not even implementable, hard to specify. Point is to minimize output rate variance. Evaluations should mention rate dist. Doesn't have to be in draft if so. Mirja: How did you implement? Is it enough to limit maxburst? Rafaello: Linux Kernel 3.(12) fair queueing patch. Gorry: No ack clock at this point. Maxburst as in linux meaningless. So you need a timer. Mirja: Isn't there one case where you raise the rate? Michael: Pacing details are not in the draft Gorry: That needs to be timer-based Karen: ref. SCTP experience, just limiting burst size isn't enough Andrew: I wish Eric hadn't called that fair queue. Flow queue maybe. Gorry: So where are we? Michael: Intended status is experimental, strong consensus without hum, will confirm on list. Side effect: bar for improving document is lower. As PS not close to WGLC. Gorry: OK. Experimental based upon deployment experience? Michael: I agree with Mark (Allman)'s feedback (as individual): design not motivated in current text. Okay for experimental. Motivation required for PS. Gorry: I'd like comments on the list to improve motivation. Gorry: We still propose to update/obsolete 2861 Michael: I think there is consensus on that in this room. Will confirm on list. --------------------------------------------------- * TCP and SCTP RTO Restart draft-ietf-tcpm-rtorestart-01 (Per Hurtig) Alexander Zimmermann: Are there numbers? Do we see a gain? Per: Running experiments. Benefits for certain kinds of traffic. Will present numbers at next IETF. Alexander: The idea sounds good but without numbers can't evaluate. Per: Eval in referenced papers Pasi: What are the tradeoffs? Per: Risk of spurious RTO, or RTO instead of FR Pasi: there was past discussion of Implementation complexity? Per: yes Michael Tuexen: Does Linux know if it has four packets outstanding? Per: yes Michael Tuexen: How expensive to maintain this? Per: I don't think really Alex: We should not specified a draft which requires a segment-based stack. We should define the RTO restart algo for a byte-based stack too. Take a look at the Early retransmit algo (RFC 5827) Michael: In summary, we need an update --------------------------------------------------- * Problem Statement and Requirements for a More Accurate ECN Feedback draft-ietf-tcpm-accecn-reqs-05 / Mirja Kuehlewind Mirja: We want to move on, start WGLC. Richard: +1, let's focus on implementations. Michael: Feedback from WG? [silence] Who has read most recent version? Six hands. Gorry: Will review. If we do negotiation, will we change behavior? Michael: This is reqt's only. Mirja: accecn just targets feedback Gorry: we should move to WGLC and have that discussion Michael: document stable, but (speaking personally) requires reference to DCTCP (next draft) Richard: We can do this in a week Bob Briscoe: Ref to DCTCP... appendix is about brokenness in DCTCP feedback, already fed into DCTCP in github Mirja: Appendix very small, don't need to read if you've never heard of DCTCP. Michael: Plan: small editorial update then WGLC. --------------------------------------------------- * Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters draft-bensley-tcpm-dctcp / Lars Eggert Bob Briscoe: I sent a full review Lars: Part one of two. Is there a part two? Bob: Everything important in part one. Main point, why do you want this in the IETF? Draft doesn't talk about its applicability Lars: Why we want to describe it: it's been shipped widely, describing it is minimum goal. I'd like to see DCTCP-NG. Bob: Intended status standards track was confusing Lars: That may not be intentional, what's there now is descriptive Bob: We've looked into making it deployable on the Internet Lars: As an IETF effort? Bob: Yes. Let's not use something broken when we could take it apart Lars: Would be nice to get more stuff from MS authors e.g. switch configurations Bob: We should take the section about the sender algorithm forward, another draft on AQM stuff. Matt Mathis: Would strengthen separation between information about what's been done and things that we could do. DC clearly too narrow going forward. Should be public cookbooks of DCTCP switch config. I'd bring that in. Scope here would be purely informational. Andrew MacGregor: Those were for compound TCP Matt: Oh. Gorry: What are you asking? Lars: Ask 1: would the WG be interested in reviewing/polishing current description for an informational RFC? Ask 2: Do we want to take on expanding this in the WG (new environments etc) Gorry: Just on 1, I think this is a great idea, I will review Mirja: Agree. Informational can also help with other implementations. On 2 if we bring it in there might not be much left when we're done. Martin Stiemerling: It could also go through the ISE stream. If goes through IETF stream, IETF gets change control. Lars: Does the IETF want to take DC CC algorithms on as a work item in general. Matt: Yes, but let's not call it data center. Very important. Lars: BoF proposal maybe? Bob: no reason, this stuff won't make it out on the public internet Mirja: would be interested for building this out for use on the internet if it works in dc as well then that is also good. Lars: DCTCP would be one thing. +accecn is a bigger topic, but a valid topic Mirja: why work on DC in IETF? Michael: to motivate ECN Brian Trammell: i want to use my new IAB dot. strongly suggest stop saying DC, siloes things incorrectly. big motivator for DCTCP is because you can actually do in-network stuff. we have working groups for than now (AQM), so this fits very well with things we're already doing. Andrew: Outgoing traffic crosses DC fabric. Disincentive for classic ECN. Kevin Lahey: I'd like to see an information document on his this actually works. Let's do that before we peck it to death. Mirja: For nice documentation of what Linux is doing, let's go to laminar and clean it up. Example for DCTCP, when you see an event you go into congestion state... Lars: This talks about Windows code. If Linux can't do it due to Linux structure... Mirja: Was talking about future work on the Cubic draft. Lars: Isn't that written for Linux? Mirja: Would be much easier to explain stuff if it were cleaner. Or describe what's there better. Lars: We can bring the Windows spec here for feedback, decide in parallel about how this gets published. Bigger question is if we do traffic jail TCP stack Michael: Assuming we have this info document and assuming it should be published in this WG, would this be in the charter? Is documentation of a widely implemented thing in the charter? Martin: No. Vendor-specific impleentation of a thing, vendor retains change control. Publish thorugh ISE with IETF LC is cleanest way forward. Lars: must be clear that Gorry: Regardless please continue discussing it here Micheal Welzl: We could publish in ICCRG Lars: IRTF is the wrong stream for things that actually exist Michael Scharf: We look forward to future presentations here. More work is a separate discussion. --------------------------------------------------- * More Accurate ECN Feedback Solutions draft-kuehlewind-tcpm-accurate-ecn draft-kuehlewind-tcpm-accurate-ecn-option Five have read these. Andrew MacGregor: Is some of these drafts implemented? Richard: NS-2 code only Mirja: I plan to do a Linux implemention Colin Perkins: The option draft is similiar to RFC6679. You should take a look on it Brian: Urgent pointer makes me nervous Richard: Michio is running tests and we see some overwrites but nothing else Mirja: We could address this in these drafts or in the ecn fallback draft --------------------------------------------------- * Timestamp negotiation and Clock exposure draft-trammell-tcpm-timestamp-interval draft-scheffenegger-tcpm-timestamp-negotiation Richard: Does the wg see value in this group? (no response) (end of meeting)