Subject: [Rum] Let's get into it

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Jul 2019 15:48:01 -0400

Please read https://tools.ietf.org/html/draft-rosen-rue-00 <https://tools.ietf.org/html/draft-rosen-rue-00>

Please comment on anything.  I will propose we adopt this as  the basis of our work, but I’m happy to do anything on it before hand.
If it is adopted, chairs will appoint a non-chair editor.

One specific I know about:

The charter discusses re-using the WebRTC media specs.  The most direct way to do that is reference:
For media and media transport:

https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17 <https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17>
https://tools.ietf.org/html/rfc7874 <https://tools.ietf.org/html/rfc7874>
https://tools.ietf.org/html/rfc7742 <https://tools.ietf.org/html/rfc7742>
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17 <https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17>

For issues around media security:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1 <https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1>
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.5 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.5>

Paul K made a suggestion that there were the SIP/MMUSIC documents done or in progress that are themselves intended to be compatible with WebRTC.

Preferences?

Brian

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 10 Jul 2019 12:28:25 +0200

> On 9 Jul 2019, at 21:48, Brian Rosen <[email-masked]> wrote:
> 
> Please comment on anything.

Section 5:

"Both HTTPS and all SIP Transactions MUST use TLS 1.2”

“Transactions” doesn’t work well here. “Connections” would be better.
Instead of hard-coding a specific version of TLS you may want to point to the BCP by the UTA wg,
unless you anyway will update this profile from time to time.

" During the establishment of secure connections with a provider, the
   RUE MAY be asked by the server for a client certificate.  In that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.”

What’s in the client cert? How do you validate the client certs?

Section 6 doesn’t mentionSIP over WebSockets. I assume that would apply.

Since you are using phone numbers as identifiers, I from an EU standpoint
suggest disallowing all non-secure transports. Phone numbers are 
considered personal identifiers and are affected by the EU GDPR.

Section 6.2.1 forbids Route headers in initial INVITE requests. The example
in 6.2.2 has a very visible Route: header in the initial request.

Section 6.2.3 talks about an xCard without any references or comments
about trust for that information.

Section 6.2.4:

"The RUE MUST accept inbound calls sent to it by the proxy mentioned
   in the configuration.”

The proxy is found using DNS and may be a list created from NATPR/DNS SRV
records. What is the defintion of “the proxy” in this statement?

"If Multiple simultaneous RUE SIP registrations from different RUE
   devices with the same SIP URI exist, the Provider MUST parallel fork   the call to all registered RUEs so that they ring at the same time.
   The first RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.
"
Is this normative (you have many MUST here). If so - how does this
change the behaviour of RFC 3261?
Also, I think this texts forgets about SIP outbound. Since Outbound is a MUST,
you need to clarify the mix of parallell and serial forking that will happen.

Section 6.3:

"The RUE MUST support   REFER to enable call transfer.“

Which combination of REFER? I assume that “Mid call signaling” is “in-dialog transactions” in SIP lingo,
but REFER with or without Replaces? With or without subscription for updates?

Section 6.4:

" Relay Service URIs and User Address of Records (AoR) MUST resolve (in
   accord with [RFC3263 <https://tools.ietf.org/html/rfc3263>]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.”

How do you resolve a complete URI into an IP address? I guess you mean
the domain part that resolves to a list of addresses using DNS.
Why is IPv4 a MUST?

Section 8:

"All media streams between the RUE and another endpoint or relay
   Provider MUST be exchanged using the secure real-time transport
   protocol (SRTP) [RFC3550 <https://tools.ietf.org/html/rfc3550>] using DTLS [RFC5763 <https://tools.ietf.org/html/rfc5763>], [RFC5764 <https://tools.ietf.org/html/rfc5764>], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.
“

How do you handle the risk of downgrade attacks here? That exception is dangerous
and maybe should be handled elsewhere, not in the client. 

Section 11.1

The example operator URI for red.example.net <http://red.example.net/> seems to lack “;user=dialstring”

Section 11.2

"outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be
      used when sending requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.
“

Outbound proxy is of course something you look up in DNS to get the list of
actual servers. Is there a need to have an additional list in this json format?

" ice-servers” - propably a bad name. I don’t remember seeing “ice server” as a term.
As turn servers are also STUN servers, I think “turn-servers” is better.

“credentials”: This is tricky indeed. Sending credentials in clear text like this,
even if it’s over HTTPS is an interesting approach in this age and time.
Regardless of that, make sure you consider OAuth/OpenID connect auth
for some services.

“lifetime”:; You are really not clear on what happens when the configuration
expires. Is the RUE forbidden to use anything here? What about emergency calls
- will they work even without configuration?

General:

You do not mention bundling of RTP streams, which may be beneficial here.

Good work!

/O

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 23 Jul 2019 23:20:41 +0200

Brian,

I agree with Olle.

For now, just a couple of minor comments.

1:

Section 5. General requirements.

These requirements are not exactly general. Most of them are security 
related. Security interested readers might miss them under the current 
header.

I suggest to make two subsections under 5:

5.1 General security requirements

5.2 General coding requirements

(the last two lines)

2:

Section 8:

“
I assume that the reference for SRTP should be RFC 3711.
You may move the reference to RFC 3550 one line forwards, to after RTP.

Good work

Gunnar

Den 2019-07-10 kl. 12:28, skrev Olle E. Johansson:
>
>
>> On 9 Jul 2019, at 21:48, Brian Rosen <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> "During the establishment of secure connections with a provider, the
> "Relay Service URIs and User Address of Records (AoR) MUST resolve (in
> The example operator URI for red.example.net 
> <http://red.example.net> seems to lack “;user=dialstring”
>
> Section 11.2
>
> "ice-servers” - propably a bad name. I don’t remember seeing “ice 
> server” as a term.
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Tue, 23 Jul 2019 17:23:09 -0400

Thanks.

I think when we bring in the WebRTC media specs, the SRTP stuff comes with it, so this text may leave.

I’ll look into separating the general requirements as you suggest but I’m not a fan of a one paragraph subsection.

Brian

> On Jul 23, 2019, at 5:20 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Brian,
> 
> I agree with Olle.
> 
> These requirements are not exactly general. Most of them are security related. Security interested readers might miss them under the current header.
> 
>>> On 9 Jul 2019, at 21:48, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288