Re: [Rum] Let's get into it

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Tue, 23 July 2019 21:20 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB16C1202CC for <rum@ietfa.amsl.com>; Tue, 23 Jul 2019 14:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNQPC57zYVRe for <rum@ietfa.amsl.com>; Tue, 23 Jul 2019 14:20:47 -0700 (PDT)
Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B28E1202C3 for <rum@ietf.org>; Tue, 23 Jul 2019 14:20:47 -0700 (PDT)
X-Halon-ID: b894f67e-ad8f-11e9-bdc3-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.43.70] (unknown [94.234.32.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id b894f67e-ad8f-11e9-bdc3-005056917a89; Tue, 23 Jul 2019 23:20:41 +0200 (CEST)
To: "Olle E. Johansson" <oej@edvina.net>, Brian Rosen <br@brianrosen.net>
Cc: rum@ietf.org
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <850aa083-2426-0e9b-b7e2-b6de6ccf0bbb@omnitor.se>
Date: Tue, 23 Jul 2019 23:20:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net>
Content-Type: multipart/alternative; boundary="------------6247E26842754230531789EB"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/DbEzzlNlrdWSo8DBZZrscp-ykOU>
Subject: Re: [Rum] Let's get into it
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 21:20:52 -0000

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:

"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.

“
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 <br@brianrosen.net 
>> <mailto:br@brianrosen.net>> 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
>
>
>
>
>
>
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288