notes-ietf-99-taps

https://www.ietf.org/proceedings/99/agenda/agenda-99-taps-02.html

AGENDA ITEM 0. Working group status

* standard set of terminology for important transport features
* published 1 RFC at the last IETF; since then one last call on a set of usage docs to refine this analysis + come up with nomenclature

* two docs for two author sets: TCP/STCP and UDP/UDP-lite
* they have completed last call
* they should get to Spencer this week
* this would complete the first of the three milestones

Gorry: We just got comments from Zahed and submitted a new rev to respond to those comments
Mirja: Will we keep them separate or merge them?
Aaron: Separate docs but as a pair
Mirja: Why?
Aaron: just easier for the authors not to merge them
Milestone 1: went through all IETF protocols (deliberately excluding security because had no one who wanted to work on it)
Milestone 2: minimal set of Transport Services for TAPS systems
Last IETF: Tommy from Apple agreed to look at security protocols
Several implementations under way
Starting to discuss policy: need some way for apps to express prefs, to reason about them and choose among them
* what is the output going to be ? RFCs to describe the various implementations? describe the general behavior of a TAPS system? hope to propose work items
- Schedule

AGENDA ITEM 1: Minimal Set of Transport Services for TAPS systems

Mirja: I think it was not an oversight to not adopt it because this is completely different from the previous version. This is going one step further, which is not wrong, but this perhaps should be Step 3.I had wanted to see other parts: how can we automate it, how, and what other things might we want to see from the application
Michael Welzl: This is just an extension of the work, it hasn't changed. Last draft you saw was unfinished. Haven't invented a new API, just restructured.
Mirja: You're proposing an API that is not the final API TAPS wants to develop?
MW: It's not a proposal of one specific API that TAPS will deliver; it's a list of services. API is just an abstract way of listing it.
Mirja: It's confusing to list it as an API if we are going on later to deliver an API that is different. The textual description is fine
Brian Trammell: What I see here I don't see this as an API for implementation, it's a bit too low level. It's a supply-side API. After an analysis of the minimal set of things, this is the shape of the interface that TAPS has to provide to the thing that's going to implement the API that apps are going to be implementing
MW: Yes, it's just a list of functionality
Brian Trammell: I agree with that. If it's the API apps have to implement I'm less happy
Aaron: Perhaps we should call it something other than API.
Brian: 'minset abstract interface' probably removes the discomfort here and makes the whole conversation go away. This is pretty sane and coincidentally happens to match what we've come up with for demand sockets (?) on the prose side (?) -- which is good because it suggests both sides have it right.
Tommy Pauly: I agree with that as the distilled interface. ... I think this should be adopted as the WG doc, if for no other reason that it's the right starting point/has the right core. Specific comments:

* the idea of things falling back to TCP or requiring that feels too specific. Could we express it as "things fall back to a byte stream" or something like? What the interface falls back is not necessarily TCP-specific.

* TLS is very similar (at this level) to TCP. there's no reason that minset couldn't work for falling back to TLS, too, or other five-tuple byte stream
* Aaron: would it be acceptable to have an implementation that only fell back to TLS and didn't fall back to TCP?
* Yes
* Tommy: I don't particularly like the comments about sending messages and receiving streams, as they get too much into the implementation of the API and may not always apply
* MW: I can't allow hiding streams and not have this abstraction without naming how it could potentially work
* thinking of doing another draft explaining how one could implement the minset; some of the options here come from the necessity of having this be implementable
* Tommy: application using this minset API really doesn't know what ended up getting chosen. Should that be added? As an app, I can CREATE() this, and I may not know or care what protocol it ended up being, but maybe I do care.
* MW: That then makes this more dependent on the protocol.
* Aaron: Tommy, you OK with making this a WG doc? Tommy: Yes. Aaron: In interest of time, let's focus the commentary on supportiveness/things that would need to change to become a WG doc

Spencer Dawkins: Adopting as a WG draft means it is stable enough for the WG to work on it instead of having an individual make the right choices really quickly (so the WG isn't just watching the author continue to type). Is it stable enough? Will people help or just watch?
Anna: Good starting point, I'm for adopting. It's important to have it in the WG because once we build an API, our interpretation needs to match the minset abstract interface
Phillipp Tiesel: I really like the doc, analysis, appendix. I fear the kind of minimal interface is limiting what could be built on top of that. Some care needs to be taken so this minset doesn't limit what can be built on top. Let's work on that. Otherwise, I am for adopting it
MW: I agree, shouldn't limit the API on top. How might it limit that, though? Appendix outlines how want to avoid that. Automatable features, just because we moved them out of the minset doesn't mean they can't be exposed.
PT: Biggest limitation is in send_frame and recv_stream abstraction. Hard to fix this in something extending it. But this can be part of discussion in WG
Colin Perkins: I agree this should be adopted. To Tommy's comments and fallback comments: Why should things like fallback be mentioned in this doc? Aren't they higher-level policy things? Maybe we should separate policy of how you fall back + how you automate things from the minset of features
MW: If you want to be able to fall back to TCP you end up with this minset. To fall back to UDP you end up with a different minset. If you want to do no fallback at all, it's a bigger set.
CP: Some apps need to be able to fall back to a TCP-style bytestream; not all apps want that. MW: That's fine; then it gets bigger.
Kyle Rose: Choice made in coming up with this draft is that TCP is the most widely deployable transport and so any app that wants to be widely deployable would need TCP as a fallback. May not be true, but I think that was the assumption that went into this. I am for adopting this.
Bob Moskowitz: In security, sometimes we look at UDP as our fallback, because you can't get anything through. e.g. DOTS does TCP signaling when all si well, falls back to UDP under attack.

* much of OSI work died because of complexity; TCP was about simplicity. As underlying calls this looks really interesting, but better not be what the app sees. Need to get to a more simplistic API model.
* I work in highly constrained networks + devices; I can't afford IP + TCP. Doing direct messaging with cambus(?) with only 64B for my MTU. So if I had something like this the application could use to wrap everything up + send to the gateway, that would be a huge win.

Colin: to follow up on that: simplicity in API is good, but we should be realistic about what the current API is. If you turn this into sockoptions, this looks like exactly what you would write for ?? today.
Dimitri Pichulin: Rock-solid synchronous interface. App should call these for transport services. What about an asynchronous interface? Maybe send some callbacks with recv and send and app can recv some data without calling send/recv at all
MW: not a concrete API, just a list of services. This and other doc just an analysis, with the goal of influencing later API decisions. Could have made a fallback to UDP, but would have made the doc longer; this was just a choice. Implementation could offer callbacks.

Chairs call for consensus:
    Please hum if you support adoption? (dozens)
    Please hum if you do NOT support adoption? (few)
    We have consensus to adopt.


AGENDA ITEM 2a: Transport Security and Crypto Separation (Chris Wood)

Mirja: What is the record box?
- More an API thing...
Hannes Tschofenig: The reliability layer doesn't differentiate the handshake? Error messages bubble up to the App.
- There is a distinction that reliability is for the handshake in DTLS.
Colin Perkins: one addition: Secure RTP is a record protocol, which is usually keyed with DTLS. issue here is record protocol is different -- does partial encryption.
* Chris: yes, there are other candidates. for each of these we ran into tiny details that were specific to the protocol -- SRTP providing partial enc, minimalT unusual API.
* Chris: please email us if you have other candidates!
Need to add SRTP to the draft: email the list for others

AGENDA ITEM 2b: Adding Security (Tommy Pauly)

Brian Trammell: lower layer needs some change in the source address, whitelist or blacklist
* Chris: it's not about validating the source address on an incoming packet is tied to something -- this isn't anti-spoofing, it's a higher-level mechanism [missed next par]
* Brian: so it's a cookie fail. I share your perplexity on this.
Bob Moskowitz: been working on this area for a couple years -- drafts about secure session services + secure session envelope. Number of drivers: environments with no IP, networks that have gone down the tubes. May want to change wording here: inheriting word "handshake" from TLS + others. Change to control channel. It may protect what you need to do with peers, but may inherit other functions as well; more off to the side than underneath.
* am also dealing with 802 MAC layer security. 15.9 power security ?
* Very interested in working with you
* am the author of HIP, an identity-based environment. Looking at moving identity up to the app, not just in the network
Tommy: looking at things other than IP etc. definitely in our goals
Brian Trammell: likes "handshake" -> "control channel", and that it embeds the handshake in the main interface. From a WG perspective: we pointedly decided to ignoring security at the start of taps; this doc shows tha we do know something about it. Can't embed security in the doc we've already published, though
Tommy: saw this as a parallel doc
Colin: these are great drafts. Would like discussion of what a "maintenance phase" should be
Tommy: referring to minset and whatever APIs post-sockets (?) build on top of that
Colin: I see things like minset + this being separate interfaces *below*
Tommy: so we have a pyramid of protocols up to minset; another pyramid up to minset control; we combine them in phase 3 ?
Colin: yes, define a layer above on how to combine them. Question on scope: this is assuming point-to-point security? not including multipoint security?
Tommy: Out of scope here for sure. Would be interesting to look at multiparty transports later.
Clarify multiparty out of scope
Colin: Meeting with the PERC (Privacy Enhanced RTP Conferencing) WG -- multilevels of encryption so you can have semi-trusted middleboxes. Also out of scope?
Tommy: Could see that as a composition of TAPS' or POST's layers
Aaron Falk: Are you bringing this as a WG doc?
Tommy: Yes. Do we need to make a change to the wording about security in the charter?
Spencer Dawkins: Concern was about TAPS people not knowing enough about security. This seems to be a sea change in the knowledge about security. Would be thrilled to make a charter change; this would also help getting through the IESG
Brian quotes from charter
Chairs: When we submit the drafts to the IESG there should be no surprises for the security ADs. I'd like to ask out ADs to check this.
Kyle Rose: Speaking as TCPINC WG chair, we probably do need to recharter. It's clear we don't want to limit this to TCPINC. Brian: strike the paragraphs? Kyle: Will look at charter and see what needs to be changed. We need to include security as a first-class element of TAPS. Would not be in favor of a charter change where TAPS e.g. designed its own record protocol (Aaron agrees)
Michael: just remove this paragraph and be done with it; no reason to keep this paragraph. Aaron: goal was to prevent unintentional harm
Mirja: Goal was to decouple from security to work independently; things have changed, just make sure we're aligned now
Spencer: Wants to see this work done, and in TAPS; happy to make a charter change
Aaron: We'll look at the Charter, I don't wish to edit the Charter in real-time.
[missed next comment[
Aaron (Chair): A first-order question: should we add security transport protocols to the minset work we're doing in TAPS? not clear we need to change the charter
Kyle: I propose removing the last paragraph of the charter and changing the third bullet point right above it to <see the mailing list>
Chairs call for consensus:
Please hum if you think the WG should work on this topic? (clear hum)
Please hum if you do NOT support work on this? (none)
We have consensus to go forward.

AGENDA ITEM 3: Socket Intents, Concepts & Communication Granularity (Philipp Tiesel)

Tommy Pauly: Good doc! Of all the details we should talk about the policy discussion at the end. If we want a policy mgmt doc to go into all those details, this would be a good starting point for doing that. Could imagine having one document around that. You brought up r'ship with TAPS guidelines docs I had done; I think that also ties in well with happy eyeballs doc. As a proposal: we could grow the happy eyeballs doc (currently talks about how to do the protocol racing) generalize that to other ways to build a connection; doc on that establishment. Separately could see a doc on policy. This content should be brought up in some form though we should maybe chop up lal the docs.
Anna Brunstrom: Agree with Tommy. We have a number of systems doing policy and it's encouraging to see there's so much commonality. Possible to merge into a number of docs that describe these different features that a TAPS system would need.
Aaron: 3rd milestone of the WG is really about experimentation -- we've come up with a common language, let's build it and see what comes of it. If it turns out there's rapid convergence on (?) socket intents as input to a policy engine, that's desirable. In terms of the WG's goals, if all we do is come out with an RFC that is a compendium of different approarches to doing TAPS, that is consistent with the charter. I think we're actually doing better than that. Question for the implementation folks: how do you want to work together? Find a way to collaborate and build consensus. Would like to see a description of the efforts + lessons learned in the 3rd milestone.
* People are interested in this work and like it, please continue to participate and maybe we'll find a way to fold it all in together

AGENDA ITEM 4: Happy Eyeballs [Anna Brunstrom]

Spencer ("as a nosy individual"): since you mention cache lifetime, not sure if this is about architecture or implementation, but it seems like there's an interaction with mobility. Happiest answer you can give might change with moving onto a different networks with different characteristics. Mobility should be on the list.
Tommy: The model here is a good basis for this. As mentioned before, would be good to bring in other forms of racing besides protocol stack racing: derived endpoint racing, if you're dealing with higher-level endpoints include those.
* policy will evolve and grow, can be somewhat independent from implementation that gives the input. We should describe the i'face the happy eyeballs algorithms need as an input, like transports specify options needed to configure them.
* Anna: could implement interface in different ways once you go to implement happy eyeballs racing
* in v6 opts, Tommy & David Schinazi have a happy eyeballs update; (a) reference that (b) include "there is a lifetime parameter that should or must be configurable on these systems, here's a sane default value"

* Anna: setting a default could be difficult, cache problems could be on different levels

Colin: connection probing, etc. sounds like you're describing ICE, STUN, TURN... Look at what's happening in that space and bring it in, it's doing the same thing for connectionless protocols

AGENDA ITEM 5: Discussion: Application- & System-Specified Policy & TAPS, Framed by Brian Trammell

Gorry: There are multiple blobs in this slide that do quite different things: to do with what your provider offers, capabilities of network, transports, user/org policy... multiple building blocks here and we in TAPS don't talk about these things together. Maybe we should write some documents that try to bring these things together. We may not understand all the blobs yet, and we need to do because they all interact together.
Brian: Should draw this out as a matrix; some boxes are well-defined. Could turn into doc, could just be a learning task. Put verticals in
* Did hear that just about every talk that mentioned policy included what was in its vertical box
Aaron: My iPhone does all this...
Gorry: It would be nice to know HOW it happens so we can understand the decisions made.
Brian: Another problem here: maybe you have user policies in CSS, maybe in the UI, ....
Colin Perkins: need to be careful to avoid boiling the ocean.
Brian: That's why we avoided the conversation, but now we've run out of stuff to do...
Colin: There are low-level bits of this, as engineers we can make engineering choices about here are the knobs to adjust these policy things. How much of the higher-level stuff should be in scope for this group?
Brian: Agree that the higher up the stack you go, the farther from our scope you go; at the same time, the choices we make at the low level define the possible languages at the top level, and we need to do that with eyes open.
Tommy: Agree not all of this needs to be specified in TAPS, but all of it needs to be acknowledged. Main point where you're wrong is the ordering of these: put app boxes on the top. App + system capabilities collapse into each other and likely aren't too important; if I try to load SCTP and it's not there, then the race fails and we all move on. In addition to prefs + constraints, there are intents that go towards designing socket options
* Essentially, there's an oracle as you're creating your connection. App policies are different than user/enterprise constraints. App policies + constraints are prefs that you feed into this oracle "I'm an app, here's what I want to do, tell me what I CAN do". User + org constraints should be the same language; internally they fold into the same language for us, that are configurde in different places; enterprise could push an XML file that describes which apps can use roaming or not; overload with user prefs about whether they want to use roaming in a given area. We don't need to get too into the weeds of how that is done: it's system specific. But we should define the parameters for the oracle that a TAPS system should consult.
Spencer (AD): All these things being at different layers, with different people responsible for decision points, etc. -- I just observe, do the right thing. IETF should be able to work across areas, and go to the W3C if we need to, and that's where the CSS experts are.
Zahed (from the floor): You can have app policies that define what user/org policies you can have, so they can become collapsed. If I have a choice between wifi, 3G, tend to prefer wifi. Things are happening on other side as well: network operators can send a policy [to apps?]. That can define how you do selections: on this network TCP works, on another QUIC works. That affects what TAPS is going to do. My thinking is that all the policy decisions we need to think of the most robust way of doing it. We also need to think about how TAPS will be used, why TAPS will be used, and the underlying network as well.
Philipp Tiesel: my guess if you have two kinds of stack. First is capabilities, what CAN be done; that's on the lower layer. Above you have policies. Once you have one CAN be done, want to filter out what should NOT be done from a policy standpoint ("I don't want that app on cellular"); last you have to fill the point of ordering it. CSS really matches well the idea of how to do that. Once you have the ordering, then you're back to happy eyeballs to decide what to do.
Shiweta: does system capabilities express network capabilities? Brian: Yes, yes it should. ??: multiprovisioning, path selection -- that work should come in here. Brian: agree.
Anna: preferences and constrains are very different, and so are implications. Brian: Yes -- I like Philipp's formulation
Michael: I think it's about who has what knowledge. Can't have system delivering out of order if apps can't accept that. But apps might not know about user preference for WiFi. Thinking of who knows what could help simplify this discussion