SPUD @ IETF 92 # Brian Trammell - History - Brian Carpenter: comments about DiffServ; I'd be amazed if you can't work the existing DiffServe into this. - Brian T: DSCP is a good way to implement traffic treatment derived from SPUD properties. - David Black: dscp issues? - Dave Plonka: Why UDP encapsulation? - Brian T: because it lets you do stuff in userspace and middleboxes kind of know what it is. - Yoav Nir: Firewalls want to know what traverses the firewall, otherwise they want to drop it. - Brian T.: very aware of that as a problem. Can have things beintegrity-protected so it's clear if anyone has tampered... - Eric ?: Can spud be used for multi path applications? - Brian T: Depends on scope of tube ID; use case is in scope; discuss later. - Toerless Eckert: Were you talking about coming up with new traffic classes? - Brian T: We're talking about tube properties, which may map to traffic classes, but are not traffic classes themselves. There is no specific treatment expected. # Ted Hardie - Requirements - Hannes Tschofenig: Similar problems than SIP with session border controllers. Couldn't we just compute the signature over those part that mbs do not touch. Then the problem is figuring out what do mbs not touch? The answer is: very little. You make the assumption of what they want to do... - Geoff Huston: what's the relative priority between the session state setup and the annotation requirements? Ted (personally): session state setup, less privacy troublesome. - Ben Schwartz: help to understand game theory. 2 days ago a CA used this kind of improper use of a MB and was killed. Almost all UDP traffic by volume is already encrypted today. Ted: Yes, but some can't be done... see CH's DTLS proposal. - Spencer Dawkins: "non-WG forming BOF" because we've talked about time travel and Mr. Potato Head :-) # Joe Hildebrand - Prototype - Aaron Falk - Did the prototype implement signaling from path to end? - Joe: Not yet but have thought about design. Pull request are welcome. - Aaron: What happens if two path elements want to signal to an end system? - Joe: Current thinking is that the second path element creates a new packet with the senders source address that carries only SPUD info. - Mirja: for some uses a path elements may re-write the signal like max avaiable capacity. - David Dolson: is intent to work around firewall blocking (of everything except DNS as it is today)? - Joe: Intent is to allow administrators to make an explicit policy decision. - Jana Iyengar: thanks for seeing that this is not the primary protocol. - Mirja: Would be nice to also discuss other proposals. - Eliot: If we have multiples might go for a RG. - Joe: Architecture vs. Research: For architecure we know where we are headed; research we don't know. - Jana: Not all transports will have same semantics as TCPconnection. May not need "Open". - Joe: Agreed e.g. multicast. - Tom Herbert: leverage commonality with udp encapsulation as we had a lot of discussion about how to get it through middleboxes. - Joe: With IAB hat on, we should absolutely have that conversation... - Dave Crocker: when is the discussion allowed - Ian Swett: you mention wire shark, is giving middle boxes and network operators a tool for diagnostics a goal of spud? - Joe: It's one of the motivating factors. # Christian Huitema - DTLS as Subtransport protocol - Lorenzo Colliti: If we want zero RTTP setup, is that fundamentally the operator responsibility. - Jana Iyenger: Assumption that SYN-ACK is needed isn't true when you have TCPFast-open. - Lorenzo Colliti: Thought one reason UDP was not an option was that MB want's to see Ack to ensure it's not DOS... that's why a major carrier drops UDP. - Michael Scharf: key question, similar to tcpinc, is if this can be offloaded in hardware? - Joe: yes. UDP not in the h/w offload path. - Yoav Nir: you expressed concern that options outside encrypted partcould be modified. But that's not the way it works: EAD could coverand protect them. - Bob Briscoe - there seems that everybody's making the assumption that this has to look like TCP 3WHS - aren't there better models; maybe s/t more like TURN/STUN. SYN-ACK is the important thing. Maybe SYN-ACK should come first...? - Jana: point was not so much the opening, as the closing. Everybody can see that something is starting. # Open Discussion - Jana: That ship has sailed. NATs block UDP unless they see outgoing. - Joe: Question I meant was what do we map opening into... maybe we need finer/coarser signaling... - Christian: The key is about the end of sessions. All the elements along the path have resources allocated to the flow. Curently this is based on timers. They would like a better way to know when to release the resources. - Bob Briscoe: will need timeout mechanism - cannot trust close. - Christian: If 90% of your guys are well behaved, you have saved resources. - Bob Briscoe: Are we going for a quick hack or a careful design? How important is rapid deployment? - Brian: we have to have some experiemntation. Explicitly designed to NOT ossify into the way we finally do it. Why DTLS is better? - already an ecosystem, people understand tradeoffs. - Bob: Think we should spend a lot of time working out the control channel and how we do that - we are designing a new protocol, do itcarefully. - Brian: protocol discussion is separate from this. - Dave Crocker: TCP/IP was an experiment with the intent that another protocol would be designed - Joe: This is that protocol or one of them - Dave: We've been taught more than once that the thing that is anexperiment, if it succeeds turn out to be "the protocol". On average, building s/t not to be the long-term does work. - Joe: Don't know what do w/ that other than stop working. I won't. - Dave: don't stop. What I mean is you have to keep in mind that the protocol you develop may see wide and long term use. Don't design expecting it to be temporary. Early PARC Put port # in net header (likeOSI). You are making the waist thicker. Would encourage a "concepts and facilities"-type doc. - Brian: bad attempt at that is draft-trammell-stackevo-newtea-00. - Joe: see IEEE Spectrum article - Dave: good job but fear is that this is an easy space to get lost in. Need to get community to be clear on concepts - What and why? - Doug Host: can cookie be used to protect close context - Christian: yes, info in header DH can encoding protect from spoofing - Phillip Hallam-Baker (PHB): I really like this idea. Hope we end up with a consistent spec and not Frankenstein - wants to see more TLS concepts - look at small number of example applications, inculding DNS and achieving DPRIVE. On timeouts: implicitis the idea that all these connections are bidirectonal. But timeouts are strongly directional. DNS server has to respond in a time window. - Joe: That's an interesting use for path-tp-app: timout-length - Ted: more than one back and forth available here - Erik Kline: don't forget about MTU. MSS rewriting is real. Could multi pathing be a design goal? Christian: yes, encryption/security is a requirement for doing multipath. - Joe: we would have a separate tube for each addr pair. Similar tomptcp. Have mbs treat them as separate, then on top bundle them together - Ted: Multiple ways of doing this - can't just assume same tubeID and address is same session. Need crypto credential. Also this is a substrat on which things can be builte. Transport semantics MUST be on top, else it will ossify. If you've got a transport requirement, build that on top of this. - Brian: early name: SPUD was called MCP - minimalistic common transport. Multi path is hard and need help on scoping rules. - Michal Tuexen: debuggability is an important part of deployability; SCTP has been there. Need access to transport fields such as sequence numbers to debug performance problems. Consider exposing such fields if encryption is not required. - Mark Nottingham: good stuff. please continue. At the same time new hotness is adorning encryption. Exposing meta data is hot button. Suggest need s to be systemic approach to this. Make sure there is ample security folks involved. This is fundamental change to internet and we need to avoid surprsing folks when this stuff gets rolled out. Privacy is a big deal. - Joe: Started from IAB perspective. We want to go slow enough, requires deep introspection. - Mark: This discussion need to be held in parallel. - Mikael Abrahamsson: several questions: 1) wants ??? 2) black hole detection 3) never fragment at IP layer - Toerless Eckert: Need to be implementable by unprivileged applications: probably implies UDP. Need to be something middleboxes vendors will carry. Won't element ICE? Can ICE be extended for flow and build on that? Joe: explore with Paul Ericson. - Jana Iyenger: +1 to what Mark said. Be careful to expose as little as possible. Max benefit for min exposure. Avoid blue skywork, imagining what all we could expose. Believe there are lots ofthings the net does that it doesn't need to do. Also: ossification is a good thing - means people are using it. - Ted: diff between stability and ossification. Latter = taking s/t that ought to be soft become hard. Re first point: strongly agree - as little as possible to let things get through the network. Some of what's going on is non-technical - malware protection (content). Nothing we do will ever restore that point of control to the network. - Jana: Then every bit should be heavily discussed - Joe: Absolutely. Things people are doing should be visible to the user. Management needs to be explicit - Jinxhu Wang: how can balance between ??? - Christian: spud prototype has explcit bits to do zero order check - Liand Geng - worried about verification of request. How dowe make sure request is legit and non-greedy? - Joe: look at HYBY method of proving protocol is implemented at connection start. put suggestions on the list. - Quiu Fu: attended BarBoF where they raised same qustions. What about netneutrality? If we expose info to network it will allow prioritizatio nand break net neutrality. - Christian: Use encryption for all other data. - Brian: restricted vocabulary - Joe: just explicit signaling - Bob Briscoe: About exclusiveness of this approach for IAB. Working on TCP-based approach. Start with something that gets through and add to it. Not right to have only one approach. - Joe: IAB members on tsage who have been trying to be very inclusive. - Eliot: Just to be clear, we have not decided what to do about this. Next discussion will look at this. - Brian: absolutely will look at BB's TCP substrate - Daniel Kahn Gillmor (dkg): worried about metadata. Not convinced that prototype won't be deployed. Extensibility is unacceptable when minimizing vocabulary. Extensibility will open door to all kinds of censorship - Christian: if we take the DTLS approach to extensibility, way to add a new attribute is via RFC - much more constrained. - Brian: endpoints will have control of what goes in the packet from theendpoint. - dkg: don't see how you provide integrity protection in face of middleboxes. Don't see how you can provide verifiable close. - Wendy Seltzer: echoing privacy concerns, especially how to prevent from things being added by other actors in the path. E.g., GPS trackeradded to car once it's left garage. Without the user's consent. - Ted: one of the really concerning problems about P2P signaling is that adornment becomes invisible to endpoints. Jana's principle that every bit should be debated is very important. # What are the next steps? Start writing a charter? Another WG-forming BOF? Do we need a lot morediscussion? Research Group? - Martin Steimerling: speaking as an individual, not ready for working group. Figure if this is the way to go. Complexity is in the middle today. - Tim Shepherd: one of the best BOFs ever. Well done, esp. inclusive language. Keep going, you're on the right trajectory. Like having openness for next steps. Have another BOF, staying open. - Andrew McGregor: most important thing is what is exposed. Not much discussion about what the network can usefully expose to network, which is arguably the more important. A lot more potential there. Next steps: sounds like stack evolution - PHB: would like to see another BOF. Open forum. Has idea on breaking out key mgmt - Spenser Dawkins: thank you for doing a good job and involvingthe rest of the community. Not just one answer for next steps. Wide range of possibilities - think in more than one bucket. Some things are decomposable/separable. For some things I would submit a charter immediately. Some things are clearly insane. Range from blue-sky research to why isn't this coded today? - Ben Schwarz: if you give me bits to tell things to my middleboxesI will lie. If you give my ISP bits they will lie. Next round on BoF: figure how to talk with people with that viewpoint - Jana Iyeger: Trust is really important. Stay in StackEvo program, thencome back as a bof. - Gorry Fairhurst: I've seen a lot of evolution, that makes it interesting. Not ready for WG charter but keep working. Wide problem area. - Natasha Rooney: Network management is big use case. Trust issue is big problem. Think a group would be a great way to go. Need another BOF. - Liand Geng: Need another BOF - Aaron Falk: Dont' think this is research, not IRTF. Get a WG for anexperimental protocol. Get something out there and get experience.