Taps Status PagesTransport Services (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2014-Sep-23 —Chairs:
IETF-101 taps minutes
Session 2018-03-21 0930-1200: Park Suite - Audio stream - taps chatroom
Transport Services (TAPS) working group - IETF101 Chairs: Aaron Falk, Zaheduzzaman Sarker Note taker : Tom Jones Aaron Administrivia # Blue sheets / scribe selection / NOTE WELL - 2 min # Agenda bashing - 3 min Agenda 1. Chairs update - 10 min Michael W: There was security stuff in minset that I took out. 2. A Survey of Transport Security Protocols, draft-pauly-taps-transport-security-01, Christopher Wood, Apple. - 25 min discussion point: - updates since last version and review remaining issues - revisit goals as they pertain to new TAPS charter text - possible adoption as a WG item Kyle Rose: In the proceess of working on this document there is something that is making me uneasy and I was speaking about it to Aaron. It is about scope and scope creep, are we going to cover every security protocol? So, I am wondering if a better approach might be to choose enough protocols to analyse to cover the set of features that each of these protocols might have and then derive a set of shim features that are an interface to TAPS itself. If we try to go for everything we are not going to get this done Chris Wood: I think looking at the implementations we will confirm or deny if we got the selections correct. If there are things that we do that are not in the standard that everyone does. I think that there are out standing issuses on the github tracker to add these new protocols. We could say for now to stick to the ones we have and maybe increase the scope a little bit. We need to be sensitive to time. Kyle: We can go as far up in the stack as we want. There is envoy that uses these protocols in a sense. You want to choose a set of protocols from which you can distill out the features that a TAPS layer will need and which protocols that you need to support. TLS and DTLS are the same protocol at the record layer, but they differ. Chris: In theory I agree Brain Trammel: In favour of adoption. The question about scope, I think we can go relatively quickly though the list of open issues and agree if we are going to get something into the set of charactaristics. RFC8095 has a glaring issue and doesn't talk about gQUIC, but QUIC doesn't add any features. Two questions: one: post quamtum crypto...? I don't think that will change anything Aaron: is it deployed on the internet brain: second: there is a split between handshake layer record layer, this is very TLS chris: in the crypto set document we rephrased everything. brian: it seems a very natural way to seperate. aaron: great document. not sure if I am wearing my chair hat. To the question of which protocols to include, we need input from the security area. They might have priorities that we don't appreciate. The other thing is, will all these security protocols be considered behind the TAPS API? That's the way it looks from the diagram. chris: in practice we would go up to the TLS layer, higher is open to debate. aaron: the goal is to allow applications on top of this thing. apps people might not have as clean as a seperation. chris: this is another area of the scope that is fuzzy Tommy Pauly: what protocols are in scope, we should limit to the types of things we have. they are providing a pseudo transport layer. aaron: could you come up with a test to see if a protocol is in the set? tommy: Yes. we are considering security protocols that behave like transports kyle: we don't need to be exhaustive zahed: the scope of the doc is explicitly not limited to IETF protocols tommy: quic had an interesting discussion regarding the realtionship of TLS and the layering of the QUIC protocol. We have an analysis of the current IETF QUIC. If QUIC is in flux I am now sure how our doc can track it. aaron: This isn't a critical problem. We can complete doc and let it rest while QUIC matures. Then, we can revise our doc later to be consistent. chris: the stream 0 problem they hope to have resolved by the next ietf, hopefully they will align mirja: quic, crypto for quic is still tls. the handshake is the same the record layer so not the same. chris: we need to review that text 3. A Minimal Set of Transport Services for TAPS Systems, draft-ietf-taps-minset-02 - Michael Welzl, University of Oslo. -10 min discussion point: - updates from previous version aaron: is there anything in the document that lead to a seperate discussion about security protocols mw: there is text that references the security document. aaron: do we think a minimum taps implementation must support some security protocols. this document is one place, the security document is another brian: I think, we do need to say it is an implementation requirement. given the pattern of the rest of the documents we are putting security on the side. draft-wood seems to be 80-95 minset+security. minset should have a reference to the security document. mw: which it does aaron: In minset, we should say the minimum security requirements for a TAPS system are captured in the security document kyle rose: a system using taps should have a minimum layer of security built into it. are we going to say transport protocols should have a way to do security to be a taps transport mw: there is away to derive the minimum set, security stuff is the other document. phillip; for the usage document we have a seperation between minset and usage for non security features, do we need the same for security features? aaron: that one document will cover both tommy pauly: the security set is much smaller than the transport features. if transport had come together more neatly we wouldn't have need the documents. mirja: what is he plan for the decision tree mw: it stays as an example brain: previous conversation to reiterate, the three stage documents is because we didn't know the process before we started. we know how to do the process now. the security document can be faster. aaron: sounds like we agree. sounds like we are done aaron: shall we last call? hum: strong consensus in favor of moving draft-ietf-taps-minset to WGLC (none opposed) mirja: shall we hum for the security document tommmy: we couldn't before the recharter. shall we hum for adoption? hum: strong consensus in favor of WG adoption of draft-pauly-taps-transport-security (none opposed) 4. An Architecture for Transport Services, draft-pauly-taps-arch-00, Tommy Pauly, Apple. -20 min (excluding discussion) discusion point: - Design principles - Terminology and concept definitions - Applicability for charter milestones 3 5. An Abstract Application Layer Interface to Transport Services, draft-trammell-taps-interface-00, Brian Trammell, ETH Zurich. -20 min (excluding discussion) discussion point: - the unified view (post sockets, NEAT, socket intents) - concepts of an interface at the level of a language-independent, abstract asynchronous interface definition. - relation towards taps proposed architecture (see agenda item 4) Jonathan: are you assuming dns is async? brian: yes mirja: I am wondering why the properties are in the api document brian: these are the things an application developer will have control over it depends on what the application implements. mirja: are we assuming these are the mandatory ones brian: not yet, these are common, but not mandatory tommy: the implementation draft is focused on things that are hidden from the application, these are knobs to turn, but option to use. kyle: a set of suggestions of things you could implement mw: we should clarify these are optional for an app to use, but not optional to implement brian: we don't have normative language yes. today we are asking if this is the correct approach. we need to back it up in the impl document jonathan: it is not tcp acks? (refering to Sent event after sending a message) kyle: it is not delivered brian: if we have a protocol for this we might want to include it. 6. Implementing Interfaces to Transport Services, draft-brunstrom-taps-impl-00, Anna Brunstrom, Karlstad University. - 15 min (excluding discussion) discussion point: - implementation aspects - relation to taps application layer interfaces Lorenzo: does the candidate gathering occur in two different time phases? tommy: there are interleaved anna: conceptually there are different issues, they happen in parallell colin perkins: one of the open issus we have on this draft is resolving all the issues, nat traversal, happy eyeballs, ice... colin perkins: to clarify, for udp one of the open issues is to integreate with things like stun. we are aware there are details missing at this point jonathon: you are forbidding half close anna: there is no functionality in the api tommy: a close is interpreted as a termination. we are still discussing a half close. it is sending parameter, not a termination parameter 7. Combined discussion slot for agenda item 4,5 and 6. -30 min discussion point: - see agenda item 4,5 and 6. aaron: the most important thing I want out of this discussion is whether or not to adopt them: hum: in favour: strong hum opposed: silence need more information: silence aaron: OK, let's have a technical discussion... kyle rose: the section in rendezvous, there is an intent for rendezvous to be very general. we are going to want that, it is not just dns but sevice discovery by a database brain: we know that and we need help michael tuexen: two commments on send. you had ttl on partial reliablilty. you had atomic send. I agree there is a need to provide the send call where a message begins and where a message stops. it could be limiting to do atomic sends which limits the size of the message to the size your stack can handle. brian: there is a notion of partial send and partial recv. if the lower layer cannot find end of frame before end of buf you will get a partial recv mt: I will provide when it is finished brain: a stream looks like one long message tommy: it os the same for the send. feedback on naming would be good. for a while we had content as the piece of data that you can send, related to the larger overall message. we have changed the wording to be more message centered. there are properties of that message seperate to the sending data. colin: rendezvous, the initial goal is to support he and ice. once we have that we generalise it to anything else. it is fairly clear there are a bunch of terminology issues. suggestions welcome. tommy: on rendezvous if when looking at use cases if you see things that are limited by the current architecture please bring these up. colin: we are aware we need app level help with these. zahed: without chair hat. Policy, arch draft says there is a system policy, but there is nothing in api, impl says we have multiple policy. Rename system, or api to include more on how to install polices. anna: there is some inconsistency in the naming tommy: api draft is about the interface provided to the application developer. there is missing language about the api for a sysadmin, this is an oversight. app isn't going to be setting system policy. we should add something about an administravie interface anna: there are different timescales on these things. zahed: you have priorities between different policies tommy: the architecture puts these in implementation concepts. the classic example is on a phone blocking using cellular data. the part of policy to interact is path selection properties. zahed: applications need to say something about the policy that the system should listen to. I am asking for clarification when you have multiple policies active. anna: at the moment we only have the constraints you have to follow. in practice it is more complicated and you have trade offs. some is imple dependant jonaton: first it is better to say these are read only to the application not invisilble brian and tommy: yep jonathon: the one event I didn't see is tcp low water. is it okay for me to send tommy: this was brought up in the discussion. we are trying to avoid this, it is a propety of how you interact with the socket jonathon: not that specifically tommy: this is the point of the callback. we have this in public apis already, don't enqueue before you get the call back jonathon: it would make you more confident if you were eating your own dog food. could you implement quic on top of this or ice or rmcat briain: we have a plan for research on this in go, quic and tcp in this api tommy: at apple we are using this internally and for our own prototypes for quic interop praveen: in terms of service, apps wanting lower latency higher throughput. in terms of those is there anything in this api. socket api cannot provide intent phillipp: laughs theresa: right now we have the capacity profile, low latency or high bandwidth. we have intents 'this is a big transfer' the app wants to be as precise as possible. we need to figure out which properties to include brian: all that right now is an appendix on the interface doc. everything we didn't have concensus on what went into the appendix tommy: these are elements we have finalised the semantics for. look at the appendix, open an issue on the ones you think are important. praveen: real value, that is what is missing. the abstraciton is great. some sort of consistency guarentee would be useful tommy: for deployment it is important that the preferences can take this into account. praveen: my question is different. if you did racing and end up with x the app would prefer to keep picking that brian: there is chunk of the arch we didn't talk about. the security state cache and transport state cache. any implementation will have to learn about paths. we can recommend parameters. you need this cache to make it work. tommy: in he we already do this, we are stick to addresses we have done gorry: on policy, there are multiple viewson what we have as inputs. some are predictable and some are optimisation and tuning. I am also concerned if we do everything we end up with a giant spec. tim chown: the sysconfig you pull these from is a bottomeless pit. pvd in intsrea is something interesting to me. brian: it sounds to me like there is a collection of things people would like to see. maybe a fourth doc. there is ahole we need to consider aaron: yes, we can't write it yet aaron: do you have a thought on cohabitation with applications that have needs for more granularity from the api anna: part of that is protocol specific properties. aaron: does taps have to implement that. brian: no that won't work. this is tided to an issue we just noticed in london. the interface document is the low performance version of the document. We probably need to get out of the way for batch and memory mapped io. we need holes in the api aaron: we have focus on simple should be easy, can complex things bypass taps? tommy: my gut is that it should all go through taps. we cannot be worse than existing standards. if all you do is allow someone to setsockopt you expose that there is a socket there, which exposes things that might not be true. have a mapping to important sockopts and have a mapping aaron: doc should say this theresa: about properties, we have a zoo. required, preferred, can be quieried. I propose we make one section in api where we sort this out. phillipp: the taps system should have some auto mode where an app specifies in an easy way "i am doing stuff, give me appropriate transport" on the other hand allow the app to ask for precise transport protocols with set properties. An app can mix and match with these modes. How exactly to specify what I am going to do. tommy: I agree. It is really not diverging from what socket applicatons do today. colin: this api is being built on our best guess of what it should look like and our protocol experience. It would be good to get WG input on protocols that do not fit with this api. aaron: multicast colin: yes multicast, and maybe icn. If there are styles we should have the discussion. aaron: taking the documents as working group items should not fix the set of documents we work on aaron: I am going to assume WG adoption, we will confirm on the list brian: the authors put together a github org. do we want to bring that under WG control. 8. Problem Statement Regarding IPv6 Address Usage, draft-gont-taps-address-usage-problem-statement-00, Fernando Gont, SI6 Networks. - 10 min discussion point: - whether the topic is of interest for this working group - possibly adopting the I-D as working group document gorry: I see two things in the document. Something about use of ipv6 addresses and policy and I see the need for a new api if we need to react. I am interested in how 6man felt about privacy and use of addresses. Maybe it should be two documents. What happened in 6man? fernando: I presented twice, reponse was it belonged elsewhere. myself, the properties might fall into 6man or int area. the api is something is more clearly in taps ole: in 6 man we defined these mechanisms for generating addresses with these properties. we have specifed one document on source address selection with policy tables and ways for applications to make preferences for which type of address. we are very much bottoms up we made it available without an idea how it should be used. which is why we wanted to drop it to the people that can make use of this. tommy: there are two seperate concerns. tha aspect of privacy and security, when to use one over the other belongs in another document which isn't in taps, maybe int area. however the mechanism for selecting these is a taps arch selection property. as a server what source address do I want to bias towards. this is all very relevant, the right place to specify would be in the interface. rather than adopt, what if we add this to the taps api? ferndando: for me that is fine. I agree there are two parts. the analysis of the properties is neccessary to do the other part. what I wonder is where do you keep the analysis, the api could belong in a different document. some place or another you need a disucssion on mapping addresses. tommy: it would be useful to reference that document. also what should the taps system do for default, listener vs outbound. where? aaron: I don't think it is us theresa: I see potential input to the impl draft. I see relationship to the security params in the api draft gorry: is it possible to revise the draft to make it clearer between the api and the problem space. this would really help me figure out who should look at this. an api section should be in taps, the other section needs someone looking at it. fernadon: for the api we have a problme statement, but no api gorry: talk about the api implications in a seperate bit to where you talk about implications tim chown: I think the bulk of it should happen here. 6774 says this should happen for out bound, pvd may change this.