Re: [Rum] Let's get into it
"Olle E. Johansson" <oej@edvina.net> Wed, 10 July 2019 10:28 UTC
Return-Path: <oej@edvina.net>
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 CEDB112011A for <rum@ietfa.amsl.com>; Wed, 10 Jul 2019 03:28:33 -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 Q7wGNTRafr-J for <rum@ietfa.amsl.com>; Wed, 10 Jul 2019 03:28:30 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 DF1D1120099 for <rum@ietf.org>; Wed, 10 Jul 2019 03:28:29 -0700 (PDT)
Received: from [192.168.1.80] (static-212-247-19-62.cust.tele2.se [212.247.19.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 15A32A40; Wed, 10 Jul 2019 12:28:26 +0200 (CEST)
From: "Olle E. Johansson" <oej@edvina.net>
Message-Id: <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_52F0934B-C0F9-47CB-8AB1-2AE32245BA6B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 10 Jul 2019 12:28:25 +0200
In-Reply-To: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net>
Cc: Olle E Johansson <oej@edvina.net>, rum@ietf.org
To: Brian Rosen <br@brianrosen.net>
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/MULOORtUki0a5yJ657hDOdAdgn8>
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: Wed, 10 Jul 2019 10:28:34 -0000
> On 9 Jul 2019, at 21:48, Brian Rosen <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
- [Rum] Let's get into it Brian Rosen
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] Let's get into it Gunnar Hellström
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] [EXT] Let's get into it Janett, Amy E.
- Re: [Rum] Let's get into it Brian Rosen
- [Rum] RUE NAT Traversal in draft-rosen-rue-01 Paul Kyzivat
- [Rum] RUE client credentials Paul Kyzivat
- [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Let's get into it Olle E. Johansson
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Let's get into it Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Richard Shockey
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] RUE client credentials Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] RUE client credentials Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Adam Roach
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Paul Kyzivat
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Gunnar Hellström
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Brian Rosen
- Re: [Rum] Codec requirements in draft-rosen-rue-01 Eric Burger
- Re: [Rum] Codec requirements in draft-rosen-rue-01 James Hamlin
- [Rum] Media security Paul Kyzivat
- [Rum] Distinguishing RUE and Provider requirements Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security DOLLY, MARTIN C
- Re: [Rum] Media security Brian Rosen
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Media security Chris Wendt
- Re: [Rum] Media security Eric Burger
- Re: [Rum] Media security Paul Kyzivat
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… James Hamlin
- Re: [Rum] Distinguishing RUE and Provider require… Brian Rosen
- Re: [Rum] Distinguishing RUE and Provider require… Keith Drage
- Re: [Rum] Distinguishing RUE and Provider require… Eric Burger
- Re: [Rum] Distinguishing RUE and Provider require… Gunnar Hellström