Transcript Day 2: Working Sessions
|Slides||IAB Workshop on Stack Evolution in a Middlebox Internet (semiws) Team|
|Title||Transcript Day 2: Working Sessions|
|Abstract||Transcript Day 2: Working Sessions|
|Other versions||plain text|
--------------- Possible Working Sessions Overview -------------- 1. Trust Domain - Ted (no slides) --- - Any box that modifies w/o permission is a MITM; question is whether it is recognized by the ends. - There are cases where one or the other end would consent if they knew. However, it's easier to stand up a MITM rather than configure something explicitly. - On path, explicitly configured MBs (e.g., HTTP proxy) require change in destination - Questions: - Given failure of deployment is that the best deployment model for other things? - Can you take consent and not change destination? - If you wanted to do with on path devices, need a pre-shared key or another trust mechanism - Pre-shared key: client encrypts, if mb has the key it can mangle. This reduces the problem to a previously unsolved problem, namely how to establish a shared secret with the Internet. :-) - Currently two models that work in some situations: - CDN works if explicitly configured as CDNs are part of the trust domain of the content provider. - Explicit proxies work fine but they don’t scale and don’t work where you have services in path that are unexpected by one of the endpoints. - Both models don't work because they require that you know explicitly something... - Is there a different model or way to resolve problem with the current model? * David Black: wonder if we should do this here - DNSSEC could help leverage this one; do we have the expertise here? * Bob: must be split into 2 different problems: MBs that just want to look, and others that want to mangle (change bits). Leads to different use cases: look but don't touch (or drop), mangle and forward. * Ted: but "drop" is a form of mangle. * Eliot: we’re dealing with this problem at the wrong layer. Problem is that when there are signaling aspects around “normal” transport mechanisms. * Brian: this sounds like a constraints on what we do on middlebox interaction (point 3 below) and balance of power (point 6 below) * Brian: these are things we can learn from when we are setting constraints for MB interaction * Gorry: If we trust the first MB, does that mean we trust those in the chain? * Ted: it doesn’t mean you trust them. Once you have handed unencrypted bits, there’s not much you can do to control how they’re used. Enforcement is not a protocol activity. * Jana: trust domains is a transport problem since it’s e2e. But, don’t know purpose of a working session here. Need to solve it if we want to think about how transports would evolve. If we are trying to articulate problems rather than come up with solutions... It’s an important problem but don’t know that we need to find a solution here. * Christian: believe that this kind of protocol with contracts, application, etc. tend to evolve organically. Not sure we can plan them in advance. Maybe just need to try things and see what works. 2. Path Characteristics API --- - How to get control of e2e in-network functions back to the client? - MB detection mechanisms * Bob: not interested because I think it’s impossible * Brian: but is it useful? :-) * Bob: have been trying to get these things to talk ECN... * Brian: an incentive problem * Christian: competing between e2e and explicit agents on the path... * Joe: we haven’t tried providing any info to an app such that they can do something with it. IF we had a paradigm that you could get access to it and also make use of it, people would do interesting things with it. * Bob: had this with ECN: can't do it in 2 bits? => forget it. * Gorry: If we maybe take it as hints from the network, we can do it. Hard signaling I don't believe in. * Brian: as long as we can ensure you can't win by lying. * Costin: E2E sensing of the path is not enough. Test doesn't work. API: Doable if you go toward a cloud model - talk to your first-hop provider. * Colin: we've tried to build this E2E signaling thing many times, and failed every time. What has failed. * Lars: network can already tell the ES s/t via ICMP. * Ken: but application can't get to that info. * Jana: no standard way to get info. Problem is not unsolved. It’s a deployment problem. Bits can already be made available. This isn’t something we can move much on. Many things show up as Path characteristics. It might be useful to talk about precisely what characteristics we'd actually want to expose with this API. * Michael: it’s true that we’ve tried these things again and again. Have never seen an example of a way to do this (making use of info) that’s useful. * Joe: agree hints is the right way to think about it, but trust domains raises the possibility/need for getting something stronger. 3. MB Interaction (Joe) - Which information would be needed? - Protocol design - Requirements for path API - Deploy on existing inet w/existing kernels (deploy via libs/browsers). Implicit: in user space, non-root. - choices for cong, retrans, etc. * ?: are you concerned at all about performance? 10-40Gbps? * Joe: yes. Want incremental deployment and be able achieve improved performance over time * Jana: for performance need to separate client-side and server-side considerations. * Lars: may have different APIs - Requirements for path API (cont'd) - single FW traversal mechanism, multiple transport semantics * Joe: lots of protocols have done some of these things. Believe we can get some MBs to at least implement one thing in this space. * Brian: there is a base assumption that since you’re talking about interaction being explicitly inband, it’s tied to whatever transport you are using on top. * Joe: right, the protocol being described is NOT in itself a transport protocol - it’s a "session protocol", but *under* the transport. - Requirements for path API (cont'd) - multiple interfaces for each endpoint (MPTCP) - determine which protocol is in use (fast, but not port specific) * Ted: you’re expecting FWs to behave differently because you’re giving it when there is start and stop on transport * Lars: if you have that requirement why is there not a new IP protocol option. You are teaching MBs to do UDP payload inspection. * Joe: current MBs can’t tell start and stop of sessions. * Aaron: there’s nothing about identity or authorization in list, is this intentional? * Joe: intentional to be an inline protocol. As much as possible, all pieces of flow follow same or similar paths through the NW. - Requirements for path API (cont'd) - associate packets with a flow (fast) - policy per-flow - separate contexts for in-flow path-> application (p2a) and application -> path (a2p) - possible to hide the plaintext - treat as ignorable hints both ways unless authorized - p2a, a2p, have separate security context from e2e * Bob: lying? * Joe: if I declare I’m using this protocol, and I don't, and network breaks me, it's my fault. * Bob: I don’t have to say I’ve stopped my UDP sessions. Because it’s in user space, it’s easier for attackers * Jana: don’t think holding end of flow is in interest of application. You rely on NATs not dropping bindings. it could be nice to have signaling to tell MB to drop the bindings. Are we talking about new protocol (or could be use UDP checksum bits)? How are you scoping this? * Joe: don’t think we can use UDP checksum bits. Believe that can have a relatively small protocol inside UDP - e.g., you can build TCP encapsulated in this... This might just be a set of requirements for next version of DTLS. * Jana: you would need an incredibly minimal shim - 16 bit. * Bob: we’ve done a 32 bit shim for something similar. Christian’s presentation: Let’s reuse TLS - define DTLS 1.3 so it meets user level transport needs. --- - transport innovation requires encryption. That's hard. let's re-use TLS! - very scared of multiple TLS stacks - every one gets it wrong at first! -> So reuse as much as possible (TLS/DTLS) - TLS/UDP doesn’t meeting many requirements - don’t have a multiplexing layer independent of port - doesn’t expose sequence number - With DTLS 1.3, define it to meet the needs of user level transport: headers, sequence numbers, API... * Ted: agree that this seems like something we can bite off and chew. But, this may need to be a fork. Some don’t want to expose these bits. * Dan: we need to figure out to do that. There was a mailing list discussion about DTLS - we have in the past validated ICMPs but can’t do that with DTLS. We need to fix that with 1.3 - don’t need a sequence number but need some number. * David: wondering about DTLS session regularity - is there another mux layer on top of this? What is the right scope of a DTLS session from a security point of view ? * Christian: no, multiplx would be a library function used on top. current DTLS design says session IDed by port. If we want to do TCP multipath, need a single transport session getting packets from multiple ports - like HTTP2. * Brian: in TCPinc discussion, discussed putting it in kernel. There are possibilities when discussing this as a sublayer, that DTLS 1.3 won’t be backwards compatible. This might tie into Ted’s suggestion that if we’re using this as a sublayer of a transport, but there might even be features we won’t use. * Christian: would very much like to have a single implementation of the crypto stuff. Most of the bugs we find in security aren’t issue with crypto, they are bugs in wrappings of protocols and negotiations etc. * Richard: It will be important to be clear on what bits really need to be part of DTLS in layer that enforces crypto boundary, in crypto boundary layer and outside crypto boundary layer. * Brian: Meta-question: is Joe's thing a separate thing, or is the proposal to make it part of DTLS 1.3? * Answer (room): maybe. Suggestion: look at/refine requirements, then look at overlap with DTLS. 4) MB measurements --- - failure reports in happy-eyeballs protocols - define methodology and data model for aggregation * Aaron: of protocols that exist today, what kinds of detections can we make? Oughtn’t be a long discussion. Folks that want to work on this should get together for a BoF. 5) User-space stacks --- - can this support faster deployment of new protocols/protocol extensions? - include UDP design goals? * Dave: we need both how to use UDP as well as how to layer HTTPS for dummies. Marc’s document (position paper) says the problem is important, but doesn’t give guidance * Jana: maybe should be more general - transport protocol design guidance. * Brian: this is Taps * Lars: it’s not so easy. * Brian: DCCPizing it is already happening in Taps. 2nd is guidance * Jana: not easy to get all bits. Still valuable to talk about mechanisms. This is new framing that we don’t know yet. The problem is that not everybody who does this takes the time to understand. * Gorry: not sure TAPS is quite the same things. Describing mechanisms and how interact is a lot more detail - only exists in textbooks that don’t reflect reality. * Michael: IETF shouldn't be giving guidance about how to write transport protocols. Our job is to create good protocols and interfaces to them. * Joe: if we can design a good set of protocols, then agree. But, we need internal guidance. * Bob: Disagree most with Mark Nottingham's paper, which says that apps should decide themselves about transport. * Christian: amused by this business about "guidance". If you want to provide guidance, go write a book. * ?: think of the poor PhD student who has an idea about some piece of TCP. Don't want him to have to re-implement the whole thing. We need to think about how composition can facilitate experimentation with individual components. * Ted: Amused by the fact that this is part of the stack evolution program and we have already moved ISO session layer. When we talk about transport we are conflating multiple different kinds of "transport". Transports such as UDP and transports that will be inside a DTLS encapsulation. They will have different characteristics. We need to invent terminology to go along with technology. Example: what people are doing on top of https - not a "transport", but app semantics that people are doing to get stuff through the network. Look, there's a "fleen". It might run over UDP or HTTPS, but if we call it "transport"... * Jana: may have a document that has the new terms. Back to design guidance. Want to clarify. Main point is that we have a lot of mechanisms that we’ve built - eg. TCP roadmap. As it turns out, all those lessons apply to any new transport. There’s not way for user space work to fit back into the mechanism. * Brian: conclusion - doesn't make sense to split the room. Do middlebox interaction first. Trust & balance of power are parts of it. Enough interest to do that as one group. * Aaron: if you don't solve the trust problem you have no chance. Boils down to a topic about communicating with mbs, and one about building new transports. 6) Balance of power (encryption) - using encryption to provide extensibility of existing protocols - WG charter? - How much of DTLS will we reuse? -------------- Working Session on middlebox interaction (incl. Trust & Balance of power) -------------- - Agenda: - Middlebox protocol interaction sketch - what info is interesting to apps? - What info is interesting/useful to network that apps are incented to provide? - Trust domains and encryption requirements Session protocol for UDP datagrams (SPUD) (Joe) (see slides 6-11) --- - protocol "sketch" - UDP for per-app demux - Magic number - (one possible way, not the only one) - Session ID - Command (open, close, error) - Transport inside (e.g., TCP or SCTP) - path-to-app flag, app-to-path flag - Simple transport for p2a, a2p: frags, CBOR (RFC 7049), MUST ignore unknown * Bob: are you assuming MB state is shared? * Joe: would expect that if there are multiple things on path, each would have some session state * Christian: what if multiplexing on wireless NW and WiFi? * ?: Session ID - strong enough to cross IP addresses? * Joe: might want that stronger thing to be above this... * ?: shouldn't this go right on IP? * Joe: Make that a part of the design, but not the only way. * Ted: MBs telling app they are on the path vs. MBs saying path to them must be stable... * Spencer: how much more work is needed to stdize this? * Joe: please ask again right before lunch. * Jana: what's the use of "open" and "error"? only "close" is interesting. * Michael: expected to see ICE here? * Joe: it's one of the things you put inside this... * Bob: what happens in the middle of a tunnel? ICMP doesn't work anymore because of tunnels... * Ken: is there some way for the MB to ID itself? * Joe: yes, hold on. * Ted: whether it's on the 5-tuple or not is a red herring. Problem is bootstrapping the crypto state. If you used another 5 tuple, you might be able to get away from making up source ID. Agree NAT traversal will be problematic if unmodified. * Joe: agree. Also: want this to work through existing NATs that allow UDP to pass * D. Black: if we get this right, is there some possibility of something picking up some ICMP and putting it through all the pinholes all the way back? If so that's a big win and addresses some of Bob's tunnel problems. * Erik: There’s a flag in the base header and some protocol that goes along with that. * Jana: "This is just ICMP on steroids. It's broken in the same way." * Bob: tried to document all the reasons ICMP was deprecated last year. * Mirja: if we also use it to get ICMP like information, how do we ensure the same thing doesn’t happen to this protocol? * Joe: Good question. - A2P examples - request for special handling - I would prefer you drop rather than delay - application/device capabilities - measurement probes, requests * Aaron: L2 triggers. * Miroslav: have problems when you mention this as “a path”. Who responds when you make a request? this applies even more when you have multiple devices. * Joe: kinds of things and not qualities * Ken: applications and capabilities. You can split into: this is what I’m doing (capability), here is my credential - Joe wouldn’t put latter in capabilities (in a2p path) * Joe: wants to be more explicit - what app knows when paths change. P* hilip: should be able to do some things implicity * Joe: go back to what we’re signaling and not how * Dan: In PCP a single request can have multiple responses come back. Concerned about protocols where we want network to do what I mean. E.g., Need different NW characteristics for various codecs. * Lars: more info is not always better. Much more important to have a limited Api that avoids pitfalls. Had a draft that argued or this in TCPM. Example: indicating link is up. Turned out to be bad b/c if application was stupid with it, it would make things worse. * Mirja: also concerned about application having the info. Further NW makes a bunch of assumptions about packets - if a2p will change assumptions, then need to consider. network should not make assumptions. keep as declarative as possible * Ted: Agree with Mirja. Thinking of application like a video call - a p2a response might be that you are rate limited. By the time the first media packet is going out, the signaling is completed. Should rate limit come p2a even if you don’t know application cares. It might be part of an application state (e.g., webrtc context). Anything requires request/response misses application point of view. What is your example of a MB? When talking about hints, if it’s declarative, you can deploy must faster. * Brian: it might makes sense to keep p2a and a2p separate (ala Mirja’s comment) and both as "nice to have". Don’t know how any of this will be used. We are trying to have a discussion about that but we don't know. Could be enabling a bunch of application-path signaling that works well and vice versa. * Ted: Point you are making is good and also high problematic. What I was getting at was that you needed info about rate limit before you start flows. Sending all the info that might happen on the path is a potential DoS attack. If you do that for the full flow, you’ll hit lots of problems with mobiles which have to wake up radios to receive stuff they don't want (or may not want). Need a narrow set of these initially. Add to this relatively slowly. * Michael: is this per-packet? * Joe: no, thinking about it as every packet is either E2E or P2E/E2P, but not both. * Mirja: need use cases * Spencer: back to Lars about creating problems. Do we think we’ll get enough benefit for the additional complexity. Trigtran (2003) - increasing complexity of TCP state machine without enough benefit. * Jana: top part of this is massively useful, the other is nice to have but a massive rathole also. There is also a use case of networks where UDP transport is inefficient. * Brian: propose to limit discussion of trust issues to what is needed to make the stuff above the line work. (That is, to make UDP work where it does not now.) * Christian: I have a bad feeling about the "below the line" part. It is basically saying "how do we enable maximum complexity in the Internet". * Joe : what we are fighting against is the *assertion* by people who carry a lot of traffic that the only way they can provide their features and value-adds is to have access to the whole plaintext sp they can change it. Believe that this protocol would mean that they don’t need to see the plain text but could still achieve objectives. Trying to redirect the energy to s/t that is less destructive. Christian: all your examples are focused on the enterprise firewall and how do we open a hole in that. But in my experience they only open a hole when there is a business reason: if you don't, your org will be less productive than the one that does. Joe: if we look at service providers as the enemy we will continue to have problems getting things deployed. - p2a examples: - mtu - BW - ECN - Pacing - Timeout info - Backout scatter: find non-complaint path elements? - errors with URL reporting, diagnosis - non-error status for determining break point (Ping++ on path) * Gorry: first 4 P2A examples (MTU, BW, ECN, pacing) are things I want to know E2E, rather than getting them from individuals. ... you created a space that's "this wide" (holds arms apart). * Joe: yes, some of these are path characteristics. * Mirja: if all nodes on the path have to reply to get the requested information it should not be on the list. * Brian: we have 19 minutes to solve the trust problem. * Eliot: first action item from workshop = develop use cases in which this should be deployed. Swiss army knife - figure out a way to ensure that it's used for good and ensure that it's not used for evil. People in the room should think about how they could use the capability. Trust Problems --- - Can you make the problem smaller? - What are properties of trust model? Probably depends on sematics of information being exchanged. - If we say "all we are doing is start/stop, session ID and flags", can we draw a box around the trust problems? * Mirja: need use cases first * Bob: Tunneling issue needs to be understood before trust model can be discussed. Trust model is easier if you signal things only in forward direction * Spencer: you’re talking about two vaguely related sets of issues. The further you can pry them apart, the better the uncontroversial issue can be resolved. "Basic SPUD" is 'not quite a no-brainer', the other is fabulously complicated. * Brian: the rest of the agenda (except middlebox measurement) is figureing out how we are going to organize. * Gorry: it would be useful to know if there's anything useful in the backscatter? Because we know how to do forward. * Ted: slide with vague framing format - we’re talking about a framing substrate. Many things are being born inside it - “fleens” that we’ve been calling transports. There are a small number of things we can send forward or back. If you make Session ID sufficiently strong, anyone that is backscattering using this Session ID is on path that knows enough about the flow. For things inside, there’s way too much information - e.g. app semantics. If we solve framing substrate trust model and let people that are specifying specific things inside figure that out. Suggest to defer the latter. Bad news is that we may have to specify an addition to the framing substrate that carries crypto information. e.g., session key encrytpted. If you decrypt that, then you can decrypt more information Need a general mechanism is substrate to trust someone with information inside. Might not encrypt all the payload. Dave: Is there some way to draw a trust box around a smaller portion? Yes, thinks we can do this if constrained use cases. 1) endpoints are authoritative. 2) some p2a stuff. may need hints ala current ICMP model 3) everything else resolves into existing unsolved problems. David: there may be a division of the trust problem based on who is introducing the MB. Erik: think ICMP thing that Dave brought up, this is better than that - can restrict to on path attackers. are we doing enough? It’s not just about the protocol. What are the things that the actual MBs do? Aaron: ? Joe: over lunch, boil your question down to a few syllables. --------------------- Afternoon Session --------------------- * Brian: What is the best way to take what we got this morning and turn it into something that we can actually move forward on? * Mirja: is this already close to something that you would write down in your charter? * Joe: Bob's tunnel issue is an existential question. Have to figure out whether we're going to be able to do anything. If not, we'll weaponize https and the providers get nothing. * Aaron: if Bob has a show-stopper, best use of time may be to explore that. * ?: Do we have consenus on put a header with session id, and a very little bit more? * Christian: we should document what we have consensus on. It can inform DTLS 1.3 or 1.4. * Joe: we have consensus but it might not be informed consensus. Have Bob put up his slide and we argue with it. Interlude: Middlebox measurement and aggregation (Aaron) --- - There has been some research on probing for compatibility with ECN, some options. - First question: what are the existing protocols that are candidates? HTTP, happy eyeballs. - If a stack tries to make an ECN connection and it doesn't work, record that fact...steal from EDNS0 privacy guidelines. * Michael W: I think this is great. * Aaron: work for some people, like Microsoft. * Dave t: first step is collect the same common data. * Brian: sounds like a BOF, or a doc coming out of a bar BOF. !!!Action Item: Aaron will work with others and put together a doc. Target Bar Bof in Dallas on client-side middle box detection and error information aggregation SPUD and tunneling - Bob's slide (12) --- - in diagram are three layers of tunnel but cell networks may have 7 layers of tunnels or more - Need to know how far to search to find SPUD - Big problem if it’s creating a packet that’s going an opposite direction, needs to turn around all the addresses in the outer headers. - Needs to understand all possible protocols and existence of shim layer: VXLAN, GRE, GTPv1, GTPv2, L2TP, IPv4, IPv6, Another tunnel, future tunneling protocols * Mirja: thinks most use cases don’t have the MB in the tunneling * Bob: our NW has this * Brian: problem is for reverse path, need to keep a lot of state * Joe: for some of these kinds of tunneling protools, ones with relatively good encryption, it’s unlikely you’ll be looking inside to get access to stuff. * Christian: … ICMP to the tunnel endpoint …. * Bob: how do you deploy a load of tunnels that will understand SPUD * Christian: need a conversion from ICMP to SPUD * Erik: if a MB can't understand the tunnel protocol, it can't be a middlebox doing DPI. if you’re going to build MB, it needs SW to parse tunnels. In itself, needing to reverse addresses is not that difficult. Problem is when tunnels are asymetric - g.e., MPLS. * David: to what extent are you assuming a content aware MB. Are the MBs possibly doing something else where if we weren’t talking about SPUD, MBs would do something clever at another layer. * Brian: anything that can mess with SPUD or anything under SPUD have already solved the how to find SPUD problem. Reverse path is a separate problem. * Mirja: we haven’t decided that we even need to send the packets back. * Bob: security issue - can get it injected into the forward path. Don’t know how to get it to work in the opposite direction. * Joe: think we can take another approach. Not all MBs will have the ability to send traffic in the backward direction. for boxes that can send protocol back, they can perform the backwards. For those that can’t, then add a bit (two bits on) that indicates it can’t. Some will only be able to send forward, so the receiver has to bounce. Bouncing has a trust issue - but it's a smaller unsolvable problem. :-) Can say "there's something in-path that needs you to start doing traffic analysis"... * Bob: bouncing has less of a security problem. * Joe: could imagine leaving space in early packets so you can add something that’s reflected * Bob: Use cases about path characteristics and not box characteristics * Brian: reflective mode is a problem * Joe: okay with different MBs have different performance characteristics * Erik: It’s not clear to me what the trust model is in the reverse. Lots of details to work out. * Jana: want to take a step back. Worry that we are going forward with a solution that may not be a solution to a particular problem. Don't know what path characteristics are useful. What can the path tell me that I will use, and solve a problem that I can't already solve right now? Back to the question of what problem are we trying to solve? Joe: if we come up with one use case that's not stupid, will be enough? Ted: will volunteer to write up a use case centered around RTCWEB !!! Action Item: Ted writes WebRTC use case for sub transport session (SPUD) -00 draft * Jana: have some real problems that we could use this for * Brian: pretty much consensus that start, stop etc are useful * Jana: want a minimal transport * Joe: I want a minimal transport that has incentives enough to be deployed. May not be optimal for everyone. * Jana: that reduces incentive * Ted: can I invite the two of you to dinner? :-) * Brian: this conversation needs to go into a smaller group * Christian: if we think about bits and packets, the bits that the Internet box can trust are the bits that the end application would use no matter what. It's much more robust to say "I designed this because it's a natural thing that I need in the transport protocol, but I designed it in such a way that it's also useful to middleboxes." If we remove the redundancy, it increases the trust by the operators. * Mirja: basically when writing LEDBAT doc saw need for a general feedback mechanism in UDP. If we want to use this for MBs, then need to explicitly allow MBs to look at this * Jana: need to think about what we want to be de-ossified. think what we would like to ossify for minimal SPUD. I would consider that success. * Joe/Brian: have to design it in such a way that it's *necessary* to implement the options. * Ken: CBOR is absolutely crucial for that. !!! Action Item: Joe write Minimum-SPUD draft. - Have two weeks to get to a BOF proposal (can do it w/o publishable document). - Input to stack evolution program -> input to IETF...? * Joe: Would like to request a BOF. Whether it is WG-forming, don't know. * Dave T: in an actual BOF, most useful thing to start with is what is the problem we are trying to solve? Bob: there are things that are implicit - basic assumptions that we didn’t talk about; maybe need an IAB statement on basic assumptions about transport evolution. Discuss on Stackevo mailing list. * Brian: yes, these are so uncontroversial that we didn't even discuss them. * Lars: I think this is a bad idea. I wanted to see one concrete thing that had incentive for deployment. I didn't see that. As far as I am concerned, we are done. * Jana: there are things that apps want to deploy. I want two bits: Stop bit and session ID that can be used by midboxes to pin a flow. * Brandon: agree on the question of incentives. I see incentives for the application and for the network, but not seeing them line up. Network's are not big enough to do the implementation. * Dave T: again, 3 categories: (i) info to the network; (ii) hints from the network; (iii) other stuff that reduces to a currently unsolved problem. * Brandon: Use cases need to be able to get critical mass without the middlebox support. Has to be deployed first in the clients. * Brian: agree, need to be a clear win even if no middlebox vendor ever reads the document. * Christian: DTLS work item - need to document how it can be used as the framework. Consensus that most of these E2E apps will be using encryption. If they do they will very quickly get into trouble. * Mirja: is that a requirements document? * Richard: two parts: what does DTLS already provide? What can we add to DLTS that would make this easier? * Christian: take SPUD as a requirements document. !!!Action Item: Brian, Eliot, Mirja: Minimum-SPUD Dallas (non-WG?) Bof proposal * Lars: this assumes that we all think this is a good idea. Name one piece of info that you want from the NW that the NW is willing to give you that you trust enough to act on it * Brandon: need incentives articulated. Use cases need to be compelling without MB support. Brief discussion about extensibility of existing protocols (Bob) --- - Should there be a BOF? UDP, TCP, both? * Brian: need to regard extensibility/encrytion of UDP and TCP together * Michael (?): TAPS? Not chartered to create new transport protocols. !!! Action Item: Bob, Mirja, Jana: BoF? on transport protocol extensibility. - Do we need it? * Jana: don't think we actually need a BoF. * Mirja: but we have work on Minion on going and innerspace ongoing. It's not tcpm, not in taps, so where? * Brandon: concern is that tcpm is not necessarily the right place to deal with the middlebox. Not a receptive audience for discussing talking to middleboxes. * Gorry: if you want to implement in tcp stack, tcpm is the right area. Why not give a useful presentation in tsvarea, explain the use case and how it's useful. * Bob: As currently written, Inner Space has to be done in the kernel. It's nearly impossible to do things that can be out of order except in the kernel. * Christian: not sure this last thing is really overlapping with DTLS - lots of things it wants to do tcp already does. * Dan Wing: there is a proposal in IETF right now to do layered keying for SRTP. Cisco and Ericsson both have protocol. * Bob: last TCPINC session in honolulu was mostly about "this". EKR was there. * Aaron: this has been one of the more architectural discussions I've seen in an IAB context. WS report will not be done by Dallas. But we are starting conversations in Dallas with a lot of people not in the room. We should have a plenary presentation on the workshop, not presenting too many findings, but saying what was discussed.