Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?

Roman Shpount <roman@telurix.com> Thu, 15 July 2021 06:30 UTC

Return-Path: <roman@telurix.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1753A1EA9 for <stir@ietfa.amsl.com>; Wed, 14 Jul 2021 23:30:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.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 LfkerkX39Ahp for <stir@ietfa.amsl.com>; Wed, 14 Jul 2021 23:30:31 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 1E7023A1EAE for <stir@ietf.org>; Wed, 14 Jul 2021 23:30:30 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id s193so4181775qke.4 for <stir@ietf.org>; Wed, 14 Jul 2021 23:30:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kA5hhIRwULR4v70ES7tOB5nq7KuDl7xBRq4gyd0uCZY=; b=XEGi5JlgWrUfIyTeFKfqYhOXAsQDxSljmXM/G3snKu4qQR1UNM0WHCQkJd+hfwW5aY zjcIvpvm98Z3nmLw27HZTEh/o9aVexuxlZvVEdaAFiEauxaDtpyabngn+EqIQufdkvJu tRkeeAqBujG7VN+T+Gqh6ETzRtG80oW9NHCL8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kA5hhIRwULR4v70ES7tOB5nq7KuDl7xBRq4gyd0uCZY=; b=bQC1QkJzrN0H8qoqXE2Fhqhf0O+e4kV5CA4CYlZSrQtsmWYnIbRq/QLN+dc0xMsw8p YrsLfwQEz7VDZ00BWJKXTghuI74gybShiYhTPKuB1Ja8SM5L0frilGOGrqfCqpCwhFMp qFUwfookLrL2HzENAMZbIVFjGrNubnPwJkQ1uKoBi/Uw3DeXrQQbITIcoLMzsqvt2uWA CALSWkL2oI87kpIKYQDccW3QD8Y3PHa4CeptFbnctxGCTK6dln/tN5eaEBCzLuPiw70+ oAfsmYPJeIuc/0PWYA6nDVNhnQkt8oPsp74vbVbaLSeZEWTv3AT7A/jmXseE0/VX9ARx NS1Q==
X-Gm-Message-State: AOAM533eB3Rr2OqgrjK6ghcw0+Jq3WHveM+sbChSDSnVm+d6OsEK17Xf pRY4IHOGOXW9Rwe9dOWzeAQ4b3Xl9tgupg==
X-Google-Smtp-Source: ABdhPJxnyt8yv+so6qMsMVqNSROpCkG8kd13GaCrwRfHnE2ZW1Rgeg5IFmrwjNPYiWxmNykyaKf8uA==
X-Received: by 2002:a37:bb81:: with SMTP id l123mr2195387qkf.50.1626330629477; Wed, 14 Jul 2021 23:30:29 -0700 (PDT)
Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id b2sm1720952qtp.7.2021.07.14.23.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Jul 2021 23:30:28 -0700 (PDT)
Received: by mail-yb1-f173.google.com with SMTP id c16so567232ybl.9; Wed, 14 Jul 2021 23:30:27 -0700 (PDT)
X-Received: by 2002:a25:c9c7:: with SMTP id z190mr3264410ybf.21.1626330627668; Wed, 14 Jul 2021 23:30:27 -0700 (PDT)
MIME-Version: 1.0
References: <B0BBFDFA-4203-4660-A982-80A5B8DED746@contoso.com> <CAHBDyN57-8-ctw8L-5ob_ti2azBwEGqyEApGVSMwJgNM68Uscw@mail.gmail.com> <CAD5OKxsy3xODy2mXHJcKB=ihwdOeLLYiLaDpORa4B33j7TUuhw@mail.gmail.com> <FDA56FC9-ADDD-4A5C-8624-3F0CC822E230@edvina.net> <CAD5OKxvYMERn9++0-igHxCLf5=DwPGH7E-T+OzH1NNiGZp0tHA@mail.gmail.com> <357B6EDB-C403-4539-B760-F76118F3E7B5@edvina.net> <CAD5OKxuW5PCQQHT7nYrrD6zJuuppPYhUTqyw5q-_rKdKYKaMLw@mail.gmail.com> <FFB02EC8-F437-4469-82F1-052B3052FBCC@edvina.net>
In-Reply-To: <FFB02EC8-F437-4469-82F1-052B3052FBCC@edvina.net>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 15 Jul 2021 02:30:16 -0400
X-Gmail-Original-Message-ID: <CAD5OKxugdycNMFPjvjWAiKoDj0FL1Fps5_N9CYDMcinoY90hGA@mail.gmail.com>
Message-ID: <CAD5OKxugdycNMFPjvjWAiKoDj0FL1Fps5_N9CYDMcinoY90hGA@mail.gmail.com>
To: "Olle E. Johansson" <oej@edvina.net>
Cc: "stir@ietf.org" <stir@ietf.org>, SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059807705c7239b1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/z8gal5l6Bo4txLDrObKrKKDt_1Q>
Subject: Re: [stir] [Acme] NYTimes.com: How Do You Stop Robocalls?
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jul 2021 06:30:46 -0000

On Wed, Jul 14, 2021 at 2:04 AM Olle E. Johansson <oej@edvina.net> wrote:

> 13 juli 2021 kl. 17:35 skrev Roman Shpount <roman@telurix.com>om>:
>
> On Tue, Jul 13, 2021 at 3:11 AM Olle E. Johansson <oej@edvina.net> wrote:
>
>> I would love to have a discussion on that - either on the sipcore list or
>> somewhere else. I gave a lot of input to the SIPconnect update but there’s
>> still a lot of work to do on the server2server case.
>>
>>
> The areas I wanted to investigate were:
> 1. Handling TLS connection failure at all stages of an INVITE transaction.
> Design a test suite for proxies and SBC to test this behavior.
> 2. Support for multiple bidirectional TLS connections between two SIP
> endpoints or two clusters of SIP endpoints
> 3. Dealing with slow proxy thread or slow proxy in the cluster when
> processing SIP transactions
> 4. Best practices for high-performance TLS connections between proxies,
> including connection reuse, connection resumption, cipher suites, etc
> 5. Look at SIP-over-QUIC as a next-generation secure SIP transport
>
>
What do you think is the right way to proceed to deal with these issues? I
want to limit the scope of this on addressing the issues related to set
up a high scale TLS SIP connection between two service providers. I think
these issues need to be addressed rather urgently, considering both the
growing SIP message size as well as privacy concerns and regulations. It is
time to move from UDP, and if implemented correctly TLS connection should
be more reliable and only require about 10% extra CPU resources.

I know there are also multiple issues related to TLS SIP connectivity from
clients, but they might be slightly different than high-scale
server-to-server connections.

>
> A good list. One thing that comes up now and then when meeting SIP
> developers is dialog survival.
>
> We have many solutions for failover if a server dies, meaning we can
> always set up a new dialog. But when a server inside a route set dies, we
> have less documented survivability. There’s some hint in RFC 3263 if I
> remember correctly that if there is a DNS name in the route header, DNS srv
> may apply.
>

I never quite understood why target refresh request updates Contact and not
the entire route set. It is generally useful to update the list of proxies
used for the dialog.
_____________
Roman Shpount