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 >> >
- Re: [V3] New mailer and IETF107 BoF on RIPT - voi… Eric Rescorla
- Re: [V3] New mailer and IETF107 BoF on RIPT - voi… Spencer Dawkins at IETF
- Re: [V3] New mailer and IETF107 BoF on RIPT - voi… Phillip Hallam-Baker
- [V3] E2E Security and P2P media Cullen Jennings