Re: [Rum] Let's get into it

Brian Rosen <br@brianrosen.net> Tue, 27 August 2019 19:45 UTC

Return-Path: <br@brianrosen.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 9D827120113 for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 12:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 Nfmjj0E70JrD for <rum@ietfa.amsl.com>; Tue, 27 Aug 2019 12:45:18 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE3D1200FF for <rum@ietf.org>; Tue, 27 Aug 2019 12:45:18 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id l9so262797qtu.6 for <rum@ietf.org>; Tue, 27 Aug 2019 12:45:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AuWROjL/HhH8wTZnRnTq79QliCy17i2qjVMscdY3+Z0=; b=NeAyw2NU4ifPaHnYX4DfmlCIqLCHoFWqMdVgbc+apMC4UuKIrCSLnTlk8rhxxULwmb ft3Od6PUehHvuswnNLR4F9ocS700DzT0yS2z7hT516qOVbHV2ZMNkst/WLp/n+Os8/N6 f1guMCdwN4dMAmUr0plosyYVzzSl3gtOya9qTmqNBqtucWRw4kHYxcf2CuAL3wAtEyGU MhwuU6+PlvmX0hSb5jlI+Jx0ItzeN6xRbtUjFr5Q6PLg7wKUAvtd2vKx+e6G9w+6yzje XLXVtppbQ53wvmZROJjFVjhWD/Ymf0D3bzMeIwvBRe5nJv1mdmDXcBRQgP326itDKw57 cQcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AuWROjL/HhH8wTZnRnTq79QliCy17i2qjVMscdY3+Z0=; b=YOFWtVSB86Tee0/anQCOpvasGJLnJYS67UEYBmQ5hJhe3DEDEEU78Jy7vNPSwVx7Tn Dis1DxK+UcfErLnQrxdF6P59Zh4oO81C9/CvCMb5cOHmqzcKYT0XnX6+9vW6ACnrU+my WORxCju5z2FESQJdYTaCOoUhlCKjvzGSmddnKI8pTiw4QLtud+5ZUUvrt8UcGt9cMzSo SLqYgK+PMmsFXjscYM+PCBlVICXBb9jGLnB2HlGp28MtpqrDAKiawPYCSS5AtdE0n9Lu Em9mdUMLeEDkuNnOHsCJ9qjlpexf+K2XtAMuBeZ25tbfYupECj7PVV/kKgLPmpGjrD8+ RgPQ==
X-Gm-Message-State: APjAAAVdd5EvSUis86cPeyGW17zsrAJ+IvkrDnHXkUNRlofzi60z9MaR ZMxO/7qIj6g0hS59RQfpFXVG0kNSBVU=
X-Google-Smtp-Source: APXvYqxA6zeKhTTiaUn1hC+fqXN6EFac35IDuhi85QfogXcAk6AO4+tFShmq/Xgivo2/8vNmd+9Acg==
X-Received: by 2002:ac8:6b93:: with SMTP id z19mr598938qts.48.1566935117131; Tue, 27 Aug 2019 12:45:17 -0700 (PDT)
Received: from brians-mbp-2369.lan ([24.154.122.195]) by smtp.gmail.com with ESMTPSA id s3sm205232qkc.57.2019.08.27.12.45.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:45:16 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <93ABEC0D-9B2D-42BC-A337-1602464F0CB7@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4248C2AC-09BB-40A2-BF40-90E0D9936134"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 27 Aug 2019 15:45:15 -0400
In-Reply-To: <B19C6634-4B3C-46A0-A037-77BE3F0C9E77@edvina.net>
Cc: rum@ietf.org
To: "Olle E. Johansson" <oej@edvina.net>
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <B19C6634-4B3C-46A0-A037-77BE3F0C9E77@edvina.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/v9QOi0rQuKVOXB9GqkpVSC3T0Vg>
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, 27 Aug 2019 19:45:24 -0000


> On Aug 13, 2019, at 2:45 AM, Olle E. Johansson <oej@edvina.net> wrote:
> 
> 
> 
>> On 7 Aug 2019, at 23:14, Brian Rosen <br@brianrosen.net <mailto:br@brianrosen.net>> wrote:
>> 
>> Working on these comments.  I submitted a new version (-01)
>> 
>> I edited the doc to say the client cert is provisioned.  Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert?
> I would encourage that to get some base level of interoperability. 
See the note to Paul about whether we want to keep this option.  If we do, then what else should the doc say?

>> 
>> I’m fine with requiring support for SIP-over-websockets (RFC7118), but is that a general goodness these days?
> I just noted that it was excluded. Adding it will certainly help implementations that want to use WebRTC.
I’m getting more comfortable doing this.  Any other voices for or against?

> 
>> 
>> The general requirements require TLS for SIP, so I don’t think I need anything else for telephone number privacy, right?
> The phone numbers will end up in log files, in all kind of middle boxes. TLS is no guarantee of privacy any more, if it ever was.
> My general experience is that is a bad identifier in SIP as phone numbers seldom are permanent and people by law has the
> right to have hidden phone numbers. You want a more permanent identifier.
The use here is for dialing other people by phone number.  The whole VRS system is based on that in the US.  There is an ENUM based routing directory that is used to route calls to a user with a videophone in the system.  We can add text to the security section that discusses this, but when we have to say “worry about log files” I think we’re pretty far afield.   Would you rather say we can’t use phone numbers?  I don’t think that would work.
> 
>> 
>> 6.2.1 says “Route headers MAY be included in one-stage dial-around calls and emergency calls.”  6.2.2 is one-stage-dial around, so it fits the exception for the SHOULD.
> ok
>> 
>> I added the reference to RFC6351 for xCard.  
> ok
>> I think we should have a discussion of whether this mechanism should be retained.  The purpose was to deal with an objection from providers that if they supported this interface, anyone could download some random code claiming to meet it, and they wouldn’t have a clue where it came from or a way to contact anyone if it didn’t behave.  As you point out, there isn’t any way for the server to put any trust in the data.  The requirement for TLS covers eavesdropping, but it still could obtain PII.  I left the text for now, but we should discuss.
>> 
>> You said “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?”,  It seems obvious to me that the proxy URI is found in the configuration and the SRV resolves to an IP address (or addresses).  What is unclear?
> Usually you start with a name that by using DNS can resolve into many proxys. you don’t configure “a proxy” in SIP, you configure a SIP domain and end up with “the proxy”. That’s two dfferent things. Your text bypasses the DNS  NAPTR/SRV resolution by indicating that “the proxy” should be configured, which I don’t think is a good thing.
> And since you write about incoming calls, the problem gets worse, sincie your device may end up with one proxy and get incominig calls from another, unless you force
> it by using SIP Outbound. Wiith SIP Outbound the proxy has to use the incominig connection, which I think is a good thing.
Okay, I see your point.  I’ll change the text to just talk about the provisioned domain.
> 
>> 
>> Simultaneous ring is a pretty well known thing, which I think everyone does with parallel fork in one form or another.  There is only two MUSTs for the server (if there are multiple registrations, ring them all, and CANCEL any ringing UAs that didn’t answer). 3261 doesn’t discuss CANCEL when forking and I don’t see where we say anything that could be construed as violating anything I can see in 3261.  I’m at a loss to understand what I should change.
> Implementers may think that by writing something that is obvious in 3261 you may have changed something. You may add a disclaimer saying “this is just a clarification, not normative text”.
Ok
>> 
>> The reference to OUTBOUND also confuses me.  Yeah, you could get some forking when following Outbound, but that wouldn’t change this fork of independent registered UAs would it?  What text suggestion do you have?  I’m very happy to clarify anything unclear, but I don’t see the problem yet.
> As most programmers doesn’t have experience of SIP Outbound it may not be clear that when using outbound there will be a combination of parallell and serial forking. Parallell on the various registrations, serial in the various reg-id registrations from the same device.
Ok

>> 
>> I added the RFC references to REFER, and included the 7647 update as well as explicit support for norefersub,
> ok
>> 
>> Could we have a discussion of whether we require support for IPv4.  I think we do, but are their other opinions?  I fixed “domain part”.
> What is the problem you are trying to solve by adding this requirement?
Interoperability with other endpoints, and in lots of remaining networks and systems that don’t yet work without IPv4
>> 
>> I replaced the media and SRTP sections with references to the WebRTC media specifications.  There is a significant problem where there are existing endpoints that simply can’t be upgraded to support SRTP video.  This may be less of a problem if the systems that support those endpoints anchor media in their SBCs.
> If you switich to WebRTC you are also adding AVPF which is not compatible with most SIP devices. Some sort of b2bua will be required for legacy interop.
Yeah, in a pracrucak sense the providers use SBCs, which I don’t like, but it sure is common.  That solves the problem.  The problem with anything else is a downgrade attack.  
>> 
>> The example operator URI in Section 11.1 doesn’t contain a number-which-is-not-an-E164, and thus doesn’t need user=dialstring.
> ok
> 
> /O
>> 
>> 
>> 
>>> On Jul 10, 2019, at 6:28 AM, Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> wrote:
>>> 
>>> 
>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> -- 
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>