Wednesday, 29 July 2020
13:00-13:50 UTC - Wednesday Session II
Martin:
ALTO is wrapping up its charter
MASQUE met for the first time, welcome to Chris Wood and Eric Kinnear.
QUIC base drafts are past WGLC!
TSVWG had an interim about the ECT(1) marking - the decision for now is to focus on trying to make L4S work. Also lots of discussion on the status of the transport header encryption draft - whether that draft will be published as an IETF consensus document will be determined at IETF Last Call.
Magnus:
DTN has been struggling with core documents, since the scope is large
NFSv4 making progress
TAPS is having regular interim meetings
TRAM isn’t making too much progress, hoping to close up last document
Martin:
LOOPS BoF is on Friday, covering transport issues around loss detection and congestion control. This is a working group forming BoF (previous BoF was not).
Magnus:
Many documents have gotten into the RFC editor queue, not as many having been published. We expect a large set coming up.
Martin:
TSV area team is a great way to get reviews done, not too high of a load. Frank Brockners was recruited to do a one-off review, thanks to him.
Magnus:
I will step down from being AD in March, and will not renew. We need someone new to step up! Please nominate yourself or others for the role.
Martin:
As a new AD, I came in without a ton of IETF experience, but the transition has been smooth, and we have good documentation, etc. Please consider helping out!
Yiannis Yiakoumis, Selfie Networks
https://datatracker.ietf.org/doc/draft-yiakoumis-network-tokens/
Group is thinking about traffic differentiation (zero-rating, firewall, QoS). Some of these aspects can be good, and help user experience. They are also used for monetizing.
There are also negatives: this is done through traffic classification, which has both high overhead, and conflicts with user privacy and encryption goals.
It is not clear who is in control: the network, the user, the apps, the OS, etc.
How can we do better? Make something easy to deploy and operate, easy to access for apps and users, respecting privacy, works with encryption (ESNI, etc).
The Network Token proposal is an explicit and secure coordination between client devices and the network. Replaces signatures and DPIs with a deterministic mechanism. Influenced by JSON Web Tokens, access tokens, OAUTH2, etc.
Tokens carry simple claims (“I am App X”, “I need QoS N”). Can be signed or encrypted.
Provisions against replay and spoofing.
Represented as JSON, CBOR, custom, etc.
Tokens are policy-agnostic. Policy is dictated by how tokens are distributed.
Generic kinds of tokens are:
If the user wants to use a specific QoS service, they can request it, and the OS can fetch credentials from the network, and mark on traffic.
Mailing list network-tokens@ietf.org
Looking for BoF in IETF 109/110
David Black: Seems like most of the work is in token design, more than other aspects.
Yiannis: Looking first at QoS in mobile networks, and once we get the tokens through, we can use standard diffserv markings. Mapped to bearers on the wireless side of things.
David Black: What gets interesting is that this maps to more than one mechanism. I can map to diffserv for some networks, and use other mechanisms where I know more details. I like that.
There’s also an individual draft in TSVWG about mapping diffserv to mobile bearers, and that’s having trouble. Thanks for raising.
Jana: We’ve been around this block before in the IETF, trying to start and having issues. What makes this different or more interesting than previous attempts? The biggest reason we haven’t gone down this path is that there are serious implications about privacy. We also have adversarial relationships between networks and endpoints. Applications have been shy to go down this path. Get applications who are interested in working on this involved. Look hard at the privacy implications.
Yiannis: One difference is our priority around privacy and security, and the relationship between the entities. There is an inherent tradeoff between perf and privacy, etc. We first deal with privacy, and put efficiency later. See Privacy Pass, etc. Our work started by looking at net neutrality.
Zero-rating is very common—hundreds of operators and most big applications have some zero-rating relationships. Let the applications decide if they want to give this info.
Brian: Thanks for being this meeting’s reinvention of PLUS and SPUD! The main challenge will be actualizing these design priorities. The efficiency is less interesting–do that in the working group later. What I’m hearing is that you’re trying to build a system that replaces the detection of application traffic in an encrypted world, where the application has control over tagging, and the tagging happens on the layer that carries the IP traffic.
The application presumably knows that it is on the network in order to do the marking, and uses some API to fetch the token. Please read 8170.
Adrian: Echoing Jana, are we talking about how you’ve already built this, or how it should be designed? If we have a “I am Skype” token, not sure how we get privacy. Talk more about design priorities before solution.
Yiannis: In the EU, there are two approaches: QoS is agnostic, but zero-rating is category based.
Tommy: Thanks for sharing. Not sure where the work goes, but I’d like to see something make good progress here in a privacy-preserving way. I think your approach is coming from the right mindset, and that gives me some hope. User transparency and explicit consent is critical.
Especially for a work with encrypted DNS (see ADD group), we need to also discovery from the network to let the application know it should redirect traffic or DNS. This is more than marking, but re-routing.
Yiannis: You’ll need a discovery mechanism; in tests, you know the environment based on carrier. So far the discovery has been out of scope. See also APIs to query data plan.
Colin: There’s a long history of this, to Brian and Jana’s points. One outcome of SPUD and PLUS was that we believed we didn’t know how to solve this well, and we started the Path Aware Networking Research Group. We looked at what didn’t work before. Please look at that, and engage there.
Sandeep Rao: The context of the user may change over the lifetime of a given session or connection, as traffic continues. Do you have a way to change the token stance?
Yiannis: Arguments both ways. If it is in a TLS extension and is protected, cannot be changed. In IPv6, that would be different. We often see that extension headers are reset. We want something that will get through without the network changing things, so that the marking can get through the first hop network into the actual network provider.
Stuart Cheshire: In your presentation, you talk a lot about the desire of network operators to provide this service–this isn’t new, but existing markings like diffserv haven’t been successful. They’ve relied on deep packet inspection, and complex heuristics. In Section 7, you talk about three ways to implement: TLS extension, STUN, IPv6 HBH extension; the tokens are ~250 bytes long, so this can be pretty expensive to do on every packet. I’d like to see a stronger proposal about one way to do this, and it already has three ways to do this. Let’s just give operators one thing to look at.
Yiannis: The reason we’ve kept this open is that we’re looking to see which layer has interest in integrating. I agree that we should pick a specific scenario and a specific stack. We started this with STUN and WebRTC, since they are a common QoS use case.
No jabber indication there were open mic issues; used the time for Network Tokens.