Note taker: Tom Jones TSVAREA @ IETF-104 (Prague) Tuesday, March 26, 2019 13:50-15:50 - Tuesday Afternoon session I Room: Grand Hilton Ballroom * Administrativa - TSV ADs - Note Well, Blue Sheets, Jabber Scribes, Agenda Bashing Welcome Magnus!!! Thank you Spencer (six years!) - TSV Overview and status Mirja: We will close TCPINC soon - Performance implication of path characteristics (Spencer Dawkins) * Handling of Co-affilliation of ADs - Magnus and Mirja 15 minutes Magnus: There is an increased risk for conflict of interest now. Perceived conflict of interest will be handed over to another AD, i.e. such as IPR involving Ericsson, AD sponsoring documents with Ericsson authors, concensus issues involving Ericsson. Spencer: This is fairly close to the routing area plan when Alia and Adrian had the same issue. Colin Perkins: (as an individual) This is a sensible plan. In cases where there are many Ericsson people, we have an effect transport review team to sanity check the doccument. Lars Eggert: Even in areas with two different affiliations, we will also do this for any AD conflict; Like in this case you are handing it out of the area? Magnus: Yes Spencer: It is possible to have the responsible AD from another area, but keep the working group in the same area. This happened with YANG in OPS. Bob Briscoe: All seems fine to me. Someone that perceives a conflict might not want to report to you. Mirja: Of course, you can speak to us or the IESG or your WG chairs. Bob Briscoe: That needs to be documented. Mirja: I sent out an email with this. Florian Baboesu: Is there any binding document with this details? Mirja: An rfc? You can always have a conflict, we are just being more careful. Spencer: Remember we all partipate as individuals. We have more running code here. We always had to deal with this issue. This has come up a lot over a period of decades. That said, this feedback is good, just don't look for a lot of documents. Florian: I would like to see more clarification, this is a good time to take a step forward. Mirja: If you have some text, you are part of this community to define that. Brain Trammell: It is not that hard to write an ID. Lars: Florian, is there anything in particular that needs to be clarified? The nomcom rules try to help, but we only had one option. What is missing? Forian: It shows that it would be better to include a couple of paragraphs with the expected good behaviour. Spencer: In transport this is enough, across the IETF we need to have a larger conversation. Lars: I could see an IETF wide statement on conflict of interest being useful. This case isn't so important. The spotlight will be on Magnus and Mirja. There is a well defined process to remove an AD if required. Magnus: I was the only candidate. If **YOU** had run we wouldn't have had this problem. Mirja: Let me add two points. Going through the process can be an interesting experience, having a rehersal before you do it might be fun. If you end up with ony AD for an area it is doable, but it is a hard situation. It helps to have someone else you can talk to with the expertise. If you can help, please do. Tom Herbert: My impression of being an AD is that it is a lot of time. A full time job. Magnus: You need some backing to do it, if you offload the maximum amount of work you can do it in 1-2 days a week Mirja: I was keeping my AD time to 40%. That is another reason why it is important to have another AD there. Magnus: Part of looking at the documents can be offloaded to the review teams and you can balance on their input. * MASQUE, obfuscating networking applications behind an HTTPS web server - David Schinazi https://tools.ietf.org/html/draft-schinazi-masque-00 15 minutes David: The cool kids took the good acronyms. Lars: I was wondering about the properties of this system. If I wanted to detect this, I could look for spikes of traffic to servers. A VPN would show up with a lot of new traffic. Do these servers need to have enough traffic to mask this? David: That is one option, better is to put the masque server in a different jurisdiction. Lars: Wouldn't they be able to tell that the non local url would be getting a lot more traffic. David: The idea is to make a small localised deployment. Me and my friends. Or a big content provider could do this a service. Lars: You could still be detected by the volume. David: Writing a popular blog post could also generate a lot of traffic. David Black: Security gremlins live in fallback mechanisms. Colin Perkins: This affects timing of packets. You may want to consider seperating datagram and real time traffic to do the obsfication differently for the two cases. Potentially to trade off real time for predictable. David: Zo clarify, for less time sensitive traffic add delay to hide better and for real time stuff we don't? Colin: Enable this functionality for all applications. Classify the different types and provide policies for how each are treated. David: How do we expose this in an api to an application? Do people have ideas? Bob Briscoe: Once you are going, all the requests in the flow can be different and difficult to see. Don't call all the bad people state actors. Mirja: Maybe take the traffic analysis question offline. Tom Jones: We do have a good way to do PMTUD for tunnel endpoints, it is called dplpmtud, but for the tunneled traffic we have some other problems. Colin Perkins: There is an easy way around cc in tunnels problem, turn it off. David Black: Seconding Colins remarks, one cc is much easier than getting two to interact. Getting assureance of a high level cc operating is really hard. Andrew McGreggor: At some point someone will have to solve nested cc. I have seen some interesting math papers. David: Please share. Mirja: Where to continue discussion? David: Would a mailing list be of interest? -> about 20 hands David: I will arrange a mailing list Aaron: This is interesting. BBN had folks working on this, it predates quic and doh. I am looking for links for anything they published. Mark Nottingham: We had a similar proposal for H2. The threat model was similiar, that work didn't go anywhere. There is a community interested in this capability. It doesn't have to be big CDNs. Please engage in the http community, to work well this needs to be in a web server and commonly deployed home variety web servers. David: I expect this for common web servers. Valdimir: HTTP has a protocol upgrade functionality, maybe we could use that. David: That is pretty much this, it is the same as web sockets. Eric Sue: Are you aware of tor pluggable transports. They have mechanisms to hide onion traffic as HTTP. * Logging, tooling and debugging for modern network protocols - Robin Marx 30 minutes * QUIC tracing at Google - Victor Vasiliev 30 minutes * Quic logging and in-network measurements - Jari Arkko 5 minutes Brian: This is one of the better BoFs I have been to for a while. I am wondering if this is the point where we hum to form the working group. I would be very interested in knowing who would be interested in doing work on this in the future. This is a good place to find some of the things we loose going to QUIC. Anonymising is required for research, and it is helpful to get help with debugging (refering to Jari's slides). Brian: I see a lot of synergy in all three presentations, it isn't just logging or debugging. It is observabilty. A unifed view of things would be good. Jana: I too am grateful for these presentations. One of the concerns I have had for a while is tooling for QUIC.Having some combined effort is good. Tom Herbert: This was good. This is fantastic as a protocol developer. As an end user this is terrifying. Collecting this at the server is exactly what an attacker does. Page 1 should be, what are the security and privacy considerations. IF you can't answer that then this doesn't matter. Eric Kinear: This would be excellent as an implementer for debugging prior to deployment. In deployment you need to do anonymisation. I would be willing to participate in that. Andrew McGreggor: The privacy issues have to be solved. This can be done anyway and is in the implementations. Jana: Anonymisation is super important. The info at the endpoints with tcpdump is what you get with QUIC. Brian: These presentations were focuesed on QUIC, mostly as h3/QUIC. Looking at QUIC as a transport in general, how general should these logging formats be for transports? Aaron Falk: Looking back at the evolution of performance measurement, I remember TCP plots and the web 100 kernel. This feels like the future here. Things were a lot harder back in the old days. I am in favour of it. Mirja: I hear that you want a way to continue this discussion. If you want a working group we have to consider the starting point and the aspects for this working group. Jana: I want to gently push back against that. Want to drive work, but not do standardizing until implementation has stabilized. I think a working goup might counter the work, as you want agility. The work in here is integrating the logging formats so implementations don't need 15 different formats of logs. At a first run this is a draft. Gorry Fairhust: We don't have a charter so we don't have a working group. Roni Evan: We need to look at what we want to acheive in the logging. We need some standardisation on that. Robin: I want to push back against Jana. The QUIC use case can be split up, a working group could go broader. David Black: Wanted to support the idea of doing a structured log format. Lets go solve the problem for QUIC and once we know the good ideas, then we can generalise. * Open mic 10 minutes