RUM WG Meeting IETF 110 - Virtual Wednesday, March 10, 2021, 9:30 - 10:30 AM EST Chairs: Brian Rosen, Paul Kyzivat Note Taker: Jonathan Lennox First draft notes: Introduction [0:10] : Chairs Agenda bashing and WG status update Eugene Christensen: We’ll discuss issues from the list that haven’t been resolved? Brian: Yes, we’ll bring up issues we think need to be resolved, and at the end people can bring up other issues that they want to talk about it? Isaac Roach: Can you share the list of issues? Brian: Yes, the slides I’m going to present are the issues, they’re in the meeting materials. Interoperability Profile for Relay User Equipment [0:45] : Brian Rosen https://tools.ietf.org/html/draft-ietf-rum-rue-04 Outbound: What does multiple outbound proxies in the config mean? Brian: I think if there are multiple outbound proxies, inbounds are allowed from any of them, any of them can be used for outbound. Is that right? Paul: It’s optional for the provider, not for the RUE. Outbound RFC is clear if it’s being used. Question arises if provider is not supporting and using outbound. How and if you would restrict incoming calls is not well-defined in that case. Brian: proposal: if you specify more that one proxy in the config, then you must support the Outbound RFC. Is that reasonable? Olle: You’re confusing the Outbound RFC from Outbound Proxies. Brian: The configuration lets you specify one or more outbound proxies. Eugene: Are we just talking about where the endpoints register? Brian: No, when you place a call, where does the call go? Olle: It’s registration too. Brian: right. Brian: there’s a use for multiple outbound proxies with the outbound RFC. Olle: There’s a use for multiple outbound proxies even without the outbound RFCs. DNS failover, or choose one. Brian: But we need interoperability in what that means. Olle: You need to look at DNS SRV. If you don’t use SRV you need priorities, or randomly pick one. Paul: We could define it that way, but I don’t see any value in it. You could do that with DNS. Olle: outbound proxy needs to be resolved like any other SIP URI. Paul: Maybe we’re getting ourselves tied up in knots by terminology, maybe we should say RFC 5626 when we mean that behavior. Olle: The only practical use of SIP Outbound I see today is SIP over Websockets. Brian: So should we just get rid of the Outbound RFC, if no one implements it? Olle: Its implementation rate is almost zero, we don’t see it at SIPits. Brian: Maybe we should just drop it, allow just one proxy in the config. Paul: Two functionalities in RFC 5626. One is registration failover, the other is connection re-use. It’s the only well-specified mechanism for connection re-use for SIP for the devices that don’t have their own domain name. Olle: Especially if you want SIP over TCP through NATs or firewalls, Outbound is the only standardized way to specify it. Also allows TLS without requiring certificates on client phones. Brian: All that’s really good stuff. Olle: We could copy that part from SIP over websockets, it’s good stuff. I call it “half-outbound”. Paul: That requirement drove 5626; it’s tightly tied to our requirement to only receive calls from proxies you want. I don’t know how to do that without RFC 5626. Brian: I will try to craft words that only require the connection re-use part of RFC 5626, without the registration parts. Olle: Look at SIP over Websockets for text that does that. Paul: But I believe it’s a power sucker for mobile devices. We’d better not have a requirement that prevents implementation for mobile devices. Isaac: That’s definitely one of the concerns we had. Mobiles need push notifications. Brian: Multiple people have had that problem, there’s an RFC that deals with it. [RFC 8599] Isaac: If there’s an RFC that references that we’ll need to pull it in. Olle: Another issue with Outbound is that it does pre-forking. Brian: But that’s the registration piece, right? That we decided we weren’t going to do. Brian: I think I know how to go forward, I may call on folks to write text. OAuth Isaac: How were we thinking of using it? Every provider provides their own OAuth server/service? Brian: Yes; it would be an alternative to configured usernames/passwords that you use directly with registrations or the configuration service. Olle: When SIP was defined the best we had was HTTP Basic and Digest, now it’s 2021 and we have a lot better. It’s easier for people with web experience to handle, it’s harder for people with SIP experience because it’s a crazy monster. Isaac: but for OAuth to work you need a web browser? Olle: No, there are standards for OAuth with IOT, with no UI at all. But most logins are web-based, yes. Isaac: How do I know I’m talking to Google without a UI? Isaac: I don’t think it’d be a good idea to require every provider to implement an OAuth server, it’s a big can of worms. Brian: So you might be okay with having OAuth in addition to existing auth, but not as the only method? Isaac: Yes. Olle: I think the best question is whether we recommend MD5, I suggest not. Then we can see stronger stuff. Brian: That’s a separate issue, let’s stay on OAuth for now. Does anyone else think that we should require OAuth for the RUE. Paul: Mandatory for the RUE or the provider? Brian: Mandatory for the RUE, optional for the provider. Paul: Olle, are you aware of any implementations of it? Olle: No, but it doesn’t seem to hard. Brian: I don’t see anyone other than Olle say that they want to implement it on the RUE side. If no one else wants it, I think we’re in rough consensus saying we don’t. Olle [on chat]: RFC 8898 Brian: Separately, we should require SHA-256 rather than MD5 for Digest; there’s a recent draft on this. MD5 has been broken for a long time. Olle: Problem with that RFC is that it has negotiation that can lead to downgrade attacks. We need to be pretty clear in the RUM RFC that you only allow a single hash algorithm, avoiding the downgrade attacks. [RFC 8760] Brian: You need transition because you can’t get rid of everything instantly, but you really want to get rid of MD5. Paul: When providers start supporting RUE, they still have their existing MD5 infrastructure in the field. Brian: But RUE devices could be SHA-256 only. Olle: Providers could have different policies for different domains, all RUE devices could be in a domain that requires SHA-256. There are ways to handle this, though you may need to help people understand this. Isaac: I was wondering if we needed to add something to the configuration service to indicate this. Brian: The RFC has a negotiation mechanism, so that may be sufficient. Olle: The challenge indicates which hash algorithm to use. Anything else? Isaac: IPv6. That got added in one of the most recent updates. We can just say the RUE is going to support IPv6, but I’m not sure it’s that simple. Brian: The way I know how people do this, is the B2BUA handles it. Olle: The problem arises with dual stacks. Isaac: Apple requires support for IPv6-only now. There are some things we had to solve, e.g. SDP has IP literals. Or you have 300 candidates, your SDP is 1 megabyte. I think we need to clarify that the interface to the provider is IPv4? Or that IPv6, you just have to do it, at least on mobile. Brian: Or other networks, not hitting consumers yet. Isaac: A lot of issues, I could go on and on. Paul: Isaac, could you go on and on on the mailing list? Isaac: Well, I only have so many hours in the day. Brian: If anyone else has an issue that hasn’t been discussed, put it on the list please, we need to know what we need to do before we finish. Isaac: Do you want a separate e-mail thread for each issue? Brian: We’re far enough along now that I don’t think that’s necessary. Start however many threads you want. A list is fine, I can deal with it. Paul: Whatever works best for you, better to get it sooner, whatever’s easiest. AOB [0:05] : Chairs