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

[Eric Rescorla <[e-mail]>]

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.


- 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 <[e-mail]>
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.
> [e-mail]
> http://www.jdrosen.net
>