Minutes IETF110: rum
minutes-110-rum-00
| Meeting Minutes | Relay User Machine (rum) WG | |
|---|---|---|
| Title | Minutes IETF110: rum | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2021-03-10 |
minutes-110-rum-00
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