Re: [V3] New mailer and IETF107 BoF on RIPT - voice over httpbis/quic

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 24 February 2020 15:48 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: v3@ietfa.amsl.com
Delivered-To: v3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B9B3A0D8B; Mon, 24 Feb 2020 07:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 mFsNSin3-JZh; Mon, 24 Feb 2020 07:48:24 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 15B8C3A0D96; Mon, 24 Feb 2020 07:48:18 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id l16so7147078lfg.2; Mon, 24 Feb 2020 07:48:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=di1QdoOEPHH1TttieGv1BXsEX9etvWRnwd/+2kLvGySPQn3Z+osnaesUVESY0XT631 0WYYvChLX6BiHw8CT+4/DgxfYoeGIj2ipv5UtwQHpzO732WCk/Q1lkxJUHeHI8UAfW2Z 2pAv/F9Xq3TUUW+xF/TfjkksEnTYEc6aPlwD9UV3wGlDGMDkTfQIYBfHWzFDhMxC5g7M DlNX9+8dkwMvnarLY06jo0JZqPhkQdI+SZPH9qfN2FKuZZL6Vd7Z73OO0k6G4LJTHPUj x2ZDPxIY9Qi00soblWQAjYVJuWdGixWpnrU0gumhcAzSLHnsQuccANEZCv0ySnAF1pIV /dqA==
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=Mgbc9zYAEdmhBOiu05RkSboh08jIpkV6+DQahAz0ewI=; b=tvEA2ozTdHcBY1FfwffjSgktxkmmb/T8GspDY2RnnrdwJSCZckiRpF0PVN746F8PK4 pMsKVthMiO2HNPqp+1ewUaz65Nzq1rlfDCRncqLdBROZLw4Nm/J5CjU6uF8VE4olLzYn UgbMVi9uRmFlWy5a/ereqwCHpsSpM/jbKoY3HI8JS2hVqfauBB2d8r7nU0Cnz64pOBXl N4YUS81hMo1vuGzTyDO3RKFFBfLf5fxNumgX67FqgnyusqY73P9m0OxNONzWEMJyUMQr UktiwgQUxS9e8RqLRYA0OfFuIttY813SwPyzeWW8ShjK4Nn7gE6BlNen4sIqWIxffUVX xU3A==
X-Gm-Message-State: APjAAAUGBdINvraYQyML1IQb1KfauO2so7+vk1sUa6j/T+eO/IdXbVht ZY8GGxowJyA7P80qOlbCUKREWQleeeLSQ3oAVh7keogUXz4=
X-Google-Smtp-Source: APXvYqx+yCAAoz0pD33gMsfuYz8NyzxCPMPKTwrXJbKCc3tDH2gGFfVKbuOMaNs+W1xoJ8a/ecgw3b2MYN1hlJci42Q=
X-Received: by 2002:a19:ca59:: with SMTP id h25mr27858599lfj.27.1582559296182; Mon, 24 Feb 2020 07:48:16 -0800 (PST)
MIME-Version: 1.0
References: <CA+23+fHwc9NEpgJCZHdEdpXKrt1nLKufQzPEusz9NiewQOO=bA@mail.gmail.com> <CABcZeBPWEZnRz39NeeMfvgej335t8qFVcWjefqJTt74rHV1ORg@mail.gmail.com>
In-Reply-To: <CABcZeBPWEZnRz39NeeMfvgej335t8qFVcWjefqJTt74rHV1ORg@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 24 Feb 2020 09:47:49 -0600
Message-ID: <CAKKJt-dbgh4r3vdtDZkj3ZNodgucGsy3Arze=WLtfdsdJ0CKag@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jonathan Rosenberg <jdrosen@jdrosen.net>, v3@ietf.org, IETF QUIC WG <QUIC@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af5c52059f544c1f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v3/fkPXz2M35dzv_druf0GPEgvqUs4>
Subject: Re: [V3] New mailer and IETF107 BoF on RIPT - voice over httpbis/quic
X-BeenThere: v3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <v3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v3>, <mailto:v3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v3/>
List-Post: <mailto:v3@ietf.org>
List-Help: <mailto:v3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v3>, <mailto:v3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 15:48:28 -0000

Hi, Eric,

I'm not Jonathan, or any of the proponents, but ...

On Sat, Feb 22, 2020 at 4:00 PM Eric Rescorla <ekr@rtfm.com> wrote:

> Jonathan,
>
> Thanks for sending this.
>
> While I think it's interesting to explore the question of how
> to reinvent the real-time comms infrastructure using modern
> Web-style technologies. I have a number of concerns with
> the design and assumptions embodied in this draft.
>
>
> WEB ARCHITECTURE
> This document talks multiple times about how it's designed to work
> with existing HTTP infrastructure and there are a number of features
> of this design that seem to be dictated by that. However, it seems to
> me that you are making a number of surprising (and perhaps incorrect)
> assumptions about architecture and in general this seems misguided.
>
> - Transport Connections and HTTP Requests Need Not Fate Share There
> seems to be an implicit assumption in this design that HTTP LBs have
> semi-persistent routing, such that if request 1 and request 2 go to
> different servers this is a "migration" event (S 8.9). This may be the
> case in some architectures but it's not by any means guaranteed. The
> LB is free to send every request to a different server, and Web
> applications need to be designed to accommodate this..
> (see, for instance:
> https://www.oreilly.com/library/view/programming-google-app/9781491900246/ch01.html
> .
> section The Runtime Environment).
>
> While this might in principle be compatible with RIPT as designed, it seems
> unlikely to work well if each byway goes to a different server.
>
> - Use Datagrams, not Raw H3
> Relatedly, trying to simulate an unreliable channel by round-robining
> a reliable set of streams is clumsy at best. For instance, in cases
> where you are transmitting too quickly, you now build up a backlog
> of HTTP requests which must still be (re)transmitted even though they
> out of date -- and they may even be transmitted before the timely
> ones.
>
> We already have a technology designed to provide unreliable messaging
> for QUIC (https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/).
> As far as I can tell, the only reason not to use it is that you
> are trying to avoid making any new requirements on the server,
> but I think that is a mistake because (1) as noted above, you
> already are making non-standard assumptions and (2) the future
> is bigger than the past, especially given the state of QUIC deployment.
>

I asked about this, too, in a different thread. The two things that came up
were

   - They really do want to fate-share everything over HTTP (although
   you've added concerns about why that might not be a good thing), and
   - QUIC's recharter to include datagram support was only approved last
   Thursday, so there was a race condition between QUIC being chartered to do
   datagrams and other proposed charters that might make use of QUIC datagrams.

I am hoping for continued discussion about the media story on list before
the BOF, because I'd expect having this discussion during the BOF would be
"more robust than we would hope". :-)

Best,

Spencer


> - H3 Is Not Guaranteed
> Conversely, you can't assume that H3 will be available. A significant
> fraction of networks already do not pass QUIC, so if you want a
> viable system it has to gracefully fall back to H2. I would deal with
> this and the previous point by just pointing at WebTransport, which
> already is expected to provide both unreliable service and fallback.
>
>
> CALLING MODEL
> Assuming I am understanding this draft correctly, it does not
> meaingfully support incoming calls to end-user devices because you
> have to run a server (which end-user devices will not and generally
> cannot). I see you have some notion of having an extension for this,
> but that should be provided from the first. This seems like an odd
> omission to say the least.
>
>
> LACK OF E2E SECURITY
> Your charter specifies e2e security, but AFAICT, this is not
> provided by this specification, nor is it obvious how to enhance
> it to provide it. Indeed, it seems like there's not any support
> for a disjoint media path. You may recall that I made similar
> comments at the DISPATCH session in SIN, and I had understood
> that it was your intention to accommodate these cases, but
> I don't see anything here, which is somewhat disappointing.
>
> I see that the charter says
>
> "The protocol uses HTTP techniques for authentication and authorization
> (notably OAuth), and requires hop by hop encryption (i.e., https). The
> protocol will also allow for e2e media encryption, although keying is
> out of scope, and is expected to be handled by other protocols such as
> MLS."
>
> I can't agree with this. If you're going to have STIR, then
> you have what you need to provide for E2E media encryption,
> and it's a regression from WebRTC not to provide it.
>
>
>
>
> DETAILED COMMENTS
> I also noted some more detailed issues, as noted below.
>
> S 3.
>    REQ4: The solution should hide the number of servers behind the load
>    balancer, allow the addition or removal of servers from the cluster
>    at will, and not expose any of this information to the peer
>
> This seems like an odd requirement. I'm not sure how one would even
> analyze this. What about timing side channels, host-ids in cookies, etc.?
>
>
> S 6.
>    To ensure authenticated caller ID everywhere, the TG specifies the
>    set of allowed caller IDs through an [RFC8226] certificate.  This not
>    only informs the client about what numbers it can originate with, it
>    also proves to the client that it is capable of vouching for those
>    numbers.
>
> In what way does it prove to the client that it is capable of vouching?
> Certificates are public information. Is this tied to the TLS connection
> in some way?
>
>
> S 8.4.
>    The customer TG URI has to be reachable by the server in order for
>    the it to receive calls, and for security purposes it must also
>    support TLS and present a valid domain certificate using the same
>    trust chains configured into browsers.
>
> 1. There is no real IETF normative definition for the trust anchors
> for browsers. This is a local (And browser-specific matter)
>
> 2. It's worth noting that in this design it's not clear that you
> would need to have a WebPKI valid ceritifcae.
>
>
> S 8.5.
> I'm really not a fan of the handler syntax, which seems not
> very finished and kind of unspecified. For instance:
>
>    "clientDirectives": "1 to 1: opus;
>                                  2 to 2:
>  H264,max-width=1280,max-height=720",
>
> Why are you using JSON and then requiring me to parse a string?
>
>
> S 9.7.
> Why are you inventing your own cert enrollment protocol as opposed
> to using ACME? Now we have to analyze this protocol too.
>
>
>
>
>
> On Tue, Feb 18, 2020 at 7:46 AM Jonathan Rosenberg <jdrosen@jdrosen.net>
> wrote:
>
>> There is a new work effort underway to standardize an application
>> protocol on top of httpbis for real-time voice and video, basically
>> replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and
>> UDP-based transport, that makes httpbis more amenable to real-time. The
>> current draft also makes use of webtransport.
>>
>> We've got a mailer set up:
>> https://www.ietf.org/mailman/listinfo/v3
>>
>> And you can read the core draft here:
>>
>> https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1
>>
>>
>> We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering
>> a working group.
>>
>> It would be great to get participation and support from the experts in
>> the quic community.
>>
>> Thx,
>> Jonathan R.
>>
>> --
>> Jonathan Rosenberg, Ph.D.
>> jdrosen@jdrosen.net
>> http://www.jdrosen.net
>>
>