* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rum Status Pages

Relay User Machine (Active WG)
Art Area: Francesca Palombini, Murray Kucherawy | 2019-Apr-12 —  

IETF-110 rum minutes

Session 2021-03-10 1530-1630: Room 3 - rum chatroom


minutes-110-rum-00 minutes

          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
                  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
          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
          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
          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
          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
              AOB [0:05] : Chairs

Generated from PyHt script /wg/rum/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -